_____ _            __  __       _    _                      __ 
|_   _| |__   ___  |  \/  | __ _| | _(_)_ __   __ _    ___  / _|
  | | | '_ \ / _ \ | |\/| |/ _` | |/ / | '_ \ / _` |  / _ \| |_ 
  | | | | | |  __/ | |  | | (_| |   <| | | | | (_| | | (_) |  _|
  |_| |_| |_|\___| |_|  |_|\__,_|_|\_\_|_| |_|\__, |  \___/|_|  
    _    _                             
   / \  | |__  ___  ___ _ __   ___ ___ 
  / _ \ | '_ \/ __|/ _ \ '_ \ / __/ _ \
 / ___ \| |_) \__ \  __/ | | | (_|  __/
/_/   \_\_.__/|___/\___|_| |_|\___\___|

By René "Havoc" N.
Copyright © 2008

Table of Contents

1.0 - Introduction

This "Making of" will show you how the game Absence was developed, and also set out what sorts of things you should consider when creating a game yourself.

Firstly, I must admit that I made a lot mistakes while developing the game (fortunately though I was able to iron them out later). I'll tell you what kinds of mistakes I made, so that you don't have to repeat them when you decide to make a game yourself.

I hope you enjoy reading this "Making of" and also that you learn something along the way.

2.0 - Background

Before we actually start talking about the development of Absence, we need to go back to the year 2004.

In 2004 I announced a Wolfenstein 3D TC called The Fall. My aim was to make a Wolfenstein 3D TC completely different to anything done before.

It all started with a plain text file that I wrote back in 2004 setting out a simple game design sequence:

  1. Accident occurs in a secret lab
  2. Soldier is sent into the lab
  3. Soldier cleans up the lab
  4. Soldier wins or dies
  5. The end

This was the birth of The Fall.

Even though that doesn't sound like a particularly impressive start, it later evolved into a TC concept that a lot of people liked.

Now you might be asking yourself why I'm talking about The Fall instead of Absence. Well, The Fall was - so to speak - the predecessor to Absence.

I don't want to bore you with details like how the team came together or anything like that. I just want to explain to you why I didn't finish The Fall and why Absence was successfully completed instead.

Once The Fall's initial set of graphics, coding features and just one half-baked map had been done, my team persuaded me to show some progress to the general public. So I started a thread in the Diehard Wolfers forums and gave out some information about The Fall, with some screenshots.

I got a lot of positive feedback and became even more motivated to work on the game. However, I hadn't noticed that my team was already starting to break up.

The reason was that I didn't know what the team should do next in developing the game (as I didn't know myself). Also, some team members had told me that they wouldn't have much time to work on the project any more. As it later transpired, these weren't the only reasons.

I was a bit disappointed by this, but I didn't want to give up just yet. I asked in my thread whether somebody wanted to help me out by creating graphics for the game, as I wasn't much of a graphics artist. However, the response I got was that I should try to create them on my own.

After reading this I became pessimistic about the project and I let the team members know that. They became sick of hearing negative things like this. Eventually I decided to cancel the game and work on something new, because I couldn't see that there was any hope left for The Fall.

At this point you're probably asking yourself why I didn't try to work on the graphics on my own, or try to motivate someone else to do so.

Well, bad planning behind The Fall was the real reason. My aim to create something different out of Wolfenstein was shattered through my naivety, thinking that a game could be created without proper planning, and just making it up as we went along.

So the main problem was bad organisation. The team didn't have enough direction and became less interested as time went on. I was always complaining that we didn't have enough team members, even though that wasn't really the problem. Eventually the others simply didn't care anymore.

As you can see, it is vital to properly plan a game before even considering getting a team together! Never start a project without a plan. Of course, I didn't realise that until Absence was in development, but that's still to come.

After The Fall - but before starting on Absence - I worked on another Wolfenstein TC that I called Operation Overlord. This was going to be a Doom2Wolf conversion with an elaborate storyline. I thought The Fall had been a failure, as my team members didn't want to work on it anymore. So I decided to start work on a Doom2Wolf TC, primarily because I wouldn't have to create very many sprites in order to finish the game. Like The Fall, Operation Overlord was built around a vague initial idea without any real planning. You can imagine what happened AGAIN, can't you? Right, Operation Overlord was cancelled, again because of non-existent planning.

After cancelling Operation Overlord, I finally realised that I needed to properly plan my projects first of all.

I was determined that my next project wasn't going to suffer the same fate as the others, so this time I carefully planned my new project before giving any thought to hiring, coding, mapping etc.

I never made Operation Overlord public, except by mentioning the project on my website. Eventually I decided that doing a Doom2Wolf TC was unwarranted, as I might as well make a proper Doom mod instead. So I decided to start The Fall again from scratch, modifying it a bit and putting together a design document first.

After almost three months of planning, I decided to start the project for real. I was able to convince all but one of the members of the old team to work with me again on Absence (as I was now calling the project). The slightly modified game concept got a good reception from the team.

Fully motivated and with a real plan at last, we started work on Absence, the successor to The Fall. Almost six months later, the first information about the project was made public, with some screenshots.

* Insider information *

The first non-team member to see a screenshot from Absence was Chris Chokan, back on 2nd December 2006. At this point the game had already been in development for a month.

Absence Pre-Alpha Version Screenshot

The rest will be explained in the other chapters - this has just been background stuff so far ;-)

3.0 - Planning the game

As I said in the Background chapter, I took on the basic idea of The Fall once again, with some changes.

The Fall was going to be a shooter with biologically altered enemies. While planning Absence, I thought it would quickly become boring to just fight mutants. As I'm a big fan of System Shock, I thought cyborgs would be a cool addition to the failed biological experiments. That way I could also incorporate the idea of having implants in the game.

Features like password-protected doors and shock barriers were already included in The Fall, but I thought these features wouldn't be enough on their own to make Absence markedly different from Wolfenstein 3D, even though they were quite cool in their own right.

You've probably already noticed that I'm a fan of writing stuff. As I'd always wanted to create a game with a great storyline, I needed to come up with a way of telling the story as the game is played.

Now it isn't that easy to tell a story during a game driven by an engine like Wolfenstein's, but I knew it wasn't impossible, as System Shock had shown. I had previously come up with a way of inserting in-game texts in The Fall, but the problem there was that every text was hard coded into the source code; this made it hard to modify the texts afterwards, because you had to recompile the executable file and also the text content was limited by the width and height of the screen. Besides, this method eats up a lot of memory that is, as you probably know, in short supply in Wolfenstein 3D. After some brainstorming I came up with an idea for overcoming these limitations:

Wolfenstein 3D already had a Read This! feature, and BrotherTank had already come up with a way of creating intermission screens. So I thought, why not modify this function to read external files with different file names, and figure out a way to call this function by clicking on an object? With that idea in mind, I quickly found a way of doing it, and it worked perfectly. Now I was able to tell the story through diaries or something similar, and I could include as much content as I wanted to.

This feature, as well as others, had already opened up a unique gameplay experience, but I still wasn't completely satisfied. I wanted to include something that would make the game even more interesting, and so I thought more about an implant system akin to the experience system found in many RPG games.

When these features had been perfected, I thought about some other features like a security system and food dispensing units, but these didn't make it into the final version. I'll explain why in another chapter.

Now I had a lot of great coding features and a cool story too (even though the story is not really groundbreaking in itself, it was new to Wolfenstein 3D modding at least).

To differentiate the game even further from other Wolfenstein TCs, I decided to give the game a timed ending, so that there would be either a good or bad ending depending on whether or not the player made it in time.

With these features done, I was now confident that this game would be sufficiently different to other Wolfenstein 3D TCs released to date.

As you can see, writing a design document is an important thing. That way, you always know what the game's goals are and you can stay focused on the things you've written down.

Without some kind of planning, you'll end up losing your focus on the really important things, and your team will soon lose direction and interest.

4.0 - Strange game names

You've probably already asked yourself why my games have such strange names which seem to have nothing to do with the game content.

Well, I wouldn't even call them names as such, but rather words that stand for something. I think that while The Fall name doesn't have a particularly significant meaning, the name Absence does.

When I initially started to plan Absence I called it NW3D (standing for New Wolfenstein 3D). At this point I didn't care too much about what the project was called, as there were more important things than the name, like coming up with a good storyline and deciding on the features and setting for the game.

Now the story behind the name Absence is such an interesting one that I decided to give it its own chapter - it will also explain some of the ideas behind the finished game.

At the end of the first month I had started to realise the ideas set out in the design document. I decided then that I needed to come up with a good name for the project. In the beginning I tried to think of words that weren't already used in existing games. I wanted my game to have a unique name.

Unfortunately, all of the names I had already brainstormed were already in use in commercial games, so I asked one of my team members, Metal Overlord, for help. After chatting with him about it, he suggested the name Absence. This one word would make the player immediately think "hey, this must be something where you feel really alone while playing, and there's no hope of help from anyone outside". But this wasn't the only reason for calling the game Absence. After Metal Overlord put the word in writing, it struck me that it would be naturally complemented by the word humanity, as in Absence of Humanity. The name fitted very well as it was not a game name that had been used before. Also, it suggested the atmosphere of the game and the concept behind it very well.

As you can see, we weren't in too much of a rush to decide on a name. We wanted to take our time, as we really wanted the name to have a meaning that summed up the game's story and atmosphere.

For anyone who still can't see how the name has the meaning I've alluded to, maybe this will make it clearer:

5.0 - The enemies

Like the features of the game, the enemies in Absence also needed to be new or at least rarely used in other Wolfenstein TCs. The inability to come up with good enemies was one of the reasons why The Fall got cancelled - there can't be a game without enemies that fit the storyline.

In Absence, an advantage was that there were only two kinds of enemies (robots and mutants) unlike The Fall, where there were only mutants. Keeping to a small number of enemy types made it easier to decide on the particular enemies. This time I had a clear vision of the enemies that needed to be there.

While I was able to take and modify enemies from other games, there were at least two enemies I wanted for the game that had never been seen before in a game and so I needed to create these from scratch. Fortunately, I knew someone who could take this job on, and that was WLHack. He was very interested in Absence when I first told him about it, so I asked him to do the drones.

I came up with the drones idea while watching a Fear Factory music video I liked called Resurrection. There's a little drone which appears in the video which I really liked, and I thought it would make a good, fairly weak robot enemy for the game. I took screenshots of this drone and sent it to WLHack who used it as a base for a Wolfenstein 3D enemy.

* Insider information *

Here you can see the base pictures of the drone, the first sketch and the finished version.

Drone Front View Screenshot

Front view of drone

Drone Side View Screenshot

Side view of drone

Drone Sketch Screenshot

First sketch of the Absence drone by WLHack

Drone Final Version Screenshot

Final version of the Absence drone by WLHack

Most of the other enemies in the game are actually just modified sprites from commercial games, so I don't think I need to talk about how they were created ;-)

Aside from the drone, the only other completely new enemy was the final boss, who was made by Majik Monkee. I really liked Majik's design, and I thought immediately that it would make a good final boss.

6.0 - The objects

Because I wanted to make a game set in an underground lab, I couldn't just take sprites "as is" from other games, as nothing fitted the theme I was aiming for. So Metal Overlord took on the challenge of making my vision a reality. I personally think he's a very talented graphics artist - he made around half of all the sprites that appear in Absence.

I now want to tell you about how one of the sprites in Absence - the chamber sprite - was created.

First of all I made a little sketch and sent it to Metal Overlord, who then built a sprite based on it. With other sprites, sometimes I just told him what I wanted and gave him a reference picture; at other times, I gave him complete artistic freedom.

Chamber Sketch Screenshot

My quickly drawn sketch

Chamber Alpha Version Screenshot

Alpha version of the chamber by Metal Overlord

Chamber Final Version Screenshot

Final version of the chamber by Metal Overlord

I recommend that you do it this way as well. Describe what you want to your graphics artist, and give him/her a little hand-drawn sketch or reference picture to start with.

Also, don't feel obliged to take his/her first version. You should always be honest; if you dislike something that could be done better, tell him/her in a friendly way and he or she will probably be happy to redo the sprite until you think it's just right.

7.0 - The level design

As you know, Absence plays out in an underground lab and so the level design doesn't differ a great deal from map to map; after all, a lab is a lab - it's a functional rather than aesthetic construction. Always remember however that you're creating a game and not necessarily trying to depict a real structure! You can design your levels so they foster enjoyable gameplay as well as being reasonably realistic.

So besides fun gameplay, I wanted to have touches of realism in the game: every lab needs toilets and cafeterias! Of course, using the same bathroom or cafeteria layout over and over again becomes boring after a while, so I tried to make these rooms a bit different in each level.

In order to achieve this, try to come up with a different room shape when you want a bit of variety. This will make the rooms more interesting even if the new room has the same function. That way, the player won't think "oh no, not the same cafeteria AGAIN" (or whatever.....).

In Absence I tried to break away from the traditional ways of placing treasures, where they are just lying around everywhere and you collect them without thinking about it too much. In Absence, I've hidden all treasures behind pushwalls in order to make it harder to get a 100% treasure / secret ratio (of course, if people don't care about the treasure / secret ratio at all, then it doesn't matter where the treasures are, even if for anybody else it's a real challenge).

* Insider information and additional tips *

A lot of levels were sketched out first before I actually started to build them. Here you can see the sketch of the first map:

Sketch of the first map

[ Click to enlarge ]

However, sometimes I built maps without sketching them out first; that was probably a big mistake with some of them! For example the very large secret area on map 12 was originally supposed to be the second route into the complex - the door you can see immediately after leaving the elevator was actually a locked door, so you had to find a different way to get into the lab area. Unfortunately, that wasn't a good idea, as pushwalls are never really bug-free (objects on the other side can became impassable, or enemies can block the pushwall, neither of which should happen, at least in theory). In order to address this problem without re-coding, I had to change this part of the map and so the original idea behind it was lost. If I had sketched the map out first, I would have noticed this conundrum much earlier on.

Another example of not thinking about the design first in sketch form is the final map (map 16). I created three completely different versions before arriving at the one that actually made it into the game, as I was having trouble devising a good final map layout.

Map 16 - Version 1.0 and 1.1 Screenshot

Map 16 - Version 2.0 and Final Screenshot

So as you can see, sketching out maps is very important. This is so even where there are limited possibilities in level design due to the constraints of the "parent" game (as is the case with Wolfenstein 3D).

8.0 - The textures

I had a very clear vision about how the textures should look. I wanted to have lab and computer textures which foster a dark atmosphere. Unfortunately, most games wind up with brightened textures, because the brightness of the textures is controlled by the lighting system in the game's engine. Of course, I could have made the textures darker using a graphics program, but then the textures would have been affected by the Wolfenstein 3D palette (and I didn't want to create my own palette). Because of this, I needed textures specially built using the normal Wolfenstein 3D palette. Fortunately, JackaL had already made or converted a lot of suitable textures for his own cancelled project and he gave them to me to use in Absence.

9.0 - Weapons

In the early stages of development Absence contained weapons like those in Wolfenstein 3D:

After some time, though, I thought it would be cooler to have standard FPS weapons instead. So I asked JoeWolf to create some new weapons that were more contemporary in design. He created a shotgun for me as a replacement for the AK-47, but I still wasn't completely satisfied as I had said that I wanted some uniqueness as well. So I asked him to create a wrench, and some kind of futuristic machine gun.

He wondered why I wanted him to make a futuristic machine gun, but wondered even more about my requested knife replacement: the wrench. Well, the futuristic weapon is easily explained: I wanted a weapon that could have been built in the lab complex, to be used by the lab workers for protection when situations like those in the game arise - ironic, isn't it? Now about the wrench: I simply thought it would be a better and more distinctive "last resort" weapon than the knife.

10.0 - Abandoned features

There were a lot of features in the Pre-Alpha and Alpha stages of the game that didn't make it into the final version. I now want to tell you about these features and why they didn't make the final cut.

10.1 - Security system

Even though Absence does incorporate some security features (like the security lock), originally a fully-fledged security system was planned: the security cameras you find on every level in Absence once had a real function.

You were able to look through them by going to a computer terminal and pressing the "use" key (you may know this feature from Duke Nukem 3D).

Unfortunately, my experience with pointers was still limited at this stage of development. Not everything was working correctly, and even though I'm sure I could have fixed the problems eventually, I thought this feature would have made the game too easy.

The feature could have been used to cheat, because you could have simply found a computer terminal and then checked all the cameras to see what kinds of enemies were waiting for you in the other rooms. In order to avoid this, I decided to remove the feature completely and just leave the cameras as decoration.

10.2 - Food dispensing units

You probably know the food dispensing units from Blake Stone. I wanted to have them in Absence too, to provide an alternative to cafeteria food for the labs' occupants. This feature worked perfectly, but as I also planned to have portable first aid kits, the food units would have made the game too easy in my opinion. So I decided to use them simply as decoration.

10.3 - In-game cut scenes

Yes - believe it or not - at one stage I had in-game cut scenes in the game. I'm not talking about pre-rendered cut scenes like in Blake Stone, Corridor 7 or Operation Body Count, but real-time cut scenes triggered by special tiles!

A test of this feature worked quite well, but doing this for the whole game would have required a lot of special case code. For better or worse I decided not to use the cut scenes after all; it would have taken too much time to get them working as they should in every instance, and I had other features to perfect.

Something similar could appear in a later project though ;-)

10.4 - Drug system

Yeah, Absence had a drug system in its early stages. The drugs would improve the player's speed or strength for a short time. But I worried that some people would complain about drugs being in the game, so I took them all out except one that makes the player invincible for 30 seconds. Beyond that one drug, they wouldn't have made the game much more interesting and they weren't really necessary as there was already an implant system.

Now the features described in this chapter may have been pretty cool and may have made the game even more interesting. However, I think that Absence was - and is - already a great game even without them.

11.0 - Sounds and music

A lot of sounds and music in Absence are from different games, but there are some you probably haven't heard before.

I voiced the first boss, as I wanted him to say something unique to this game. The same goes for the final boss, who was voiced by Metal Overlord.

Some songs were from my favourite bands, because I thought that just using music from other games would be boring and I wanted different sonic themes for almost every level.

While some levels were just meant to be played through in a straightforward manner, I wanted to create distinctive atmospheres on some levels. For example, there's some fast music for map 3, because it's there that the player gets to see the first real lab in the complex. On map 7 there's some rather scary music, because the map is dark and it's meant to give the player the feeling of being alone with just the robots and mutants for company.

As the game has two endings, a good one and a bad one, the music is different in each. While the bad ending's music is kind of sombre, the good ending has an upbeat-sounding but heavy soundtrack.

In any case, I've always tried to specify music that fits the atmosphere of each level.

12.0 - Game testing

Testing your game during development is important, and should be done even when the game is still at an early stage. There's nothing more annoying than a game that crashes almost every time, just because you didn't do proper testing and debugging before release.

The first beta test version of Absence was released once half the game had been done (thus version 0.5). I thought that this version would be relatively trouble-free as I spent a lot of time debugging it. Unfortunately, this alone didn't help much. Even though the game was stable enough to play, some digital sounds were causing the game to crash (because I forgot to add the corresponding AdLib and PC speaker sounds). That's not the most annoying bug to be sure, but you can see how some bugs can persist even if you think the game is ready for a first test release.

Once Absence was complete content-wise, I started the final test phase of the game (version 0.9). By this time I was sure that there weren't any bugs left. However, just one day after release of the first final release candidate (RC1), I noticed a bug that made it impossible to get either of the endings (good or bad) once the game had been beaten once; I had forgotten to add a variable to the savegame structure in order to reset or change the decision that would make you lose or win the game. Of course I fixed more than just this bug in the first RC. In fact, the first hotfix of the game (RC2) contained seven bug fixes! I released four RCs before the game finally went to gold status.

So you can clearly see that even if you think you've debugged your game completely, there can still be bugs which have escaped your attention. That's why it's so important to have a team of beta testers, because people who haven't developed the game themselves may be better at spotting bugs than you, the developer. You should also allocate plenty of time for the beta testing phase; don't rush your game out just because the content has been done. Your audience don't want to play a game which is full of bugs just because you haven't taken the time to test it properly. So be patient and take the time to test your game extensively - your audience will appreciate it and your game will be more highly regarded as a result!

* Insider information *

Absence was originally scheduled to come out in August 2008, but this was delayed by a month because I wanted to have enough time to test the game thoroughly and iron out any bugs. Since the eventual release, there has been only one patch for Absence (this wasn't a bug fix; it was to adjust an enemy's strength a little).

13.0 - Conclusion

Hopefully I shone some light into the darkness of the development of Absence, and I hope that you learned a few things in this "Making of", just as we did in developing the game.

Game development can be really hard. I think good planning is one of the most important things, at least if you aspire to making a game that will earn "gold" status!

You can see how failing to plan properly can lead to failure. I myself know this now for future projects!

Here are some final tips:

Even with good planning and a clear goal in mind, you probably will lose some motivation for the project mid-stream, because you'll feel bogged down in building and testing your game over and over again without seeming to make much progress. In order to stay motivated, you should always bear in mind that once the game has been released, you can lie back and say the game is finished and over with; you got done what you wanted to get done, and all that remains is to consider any feedback you might get, whether it be positive or negative.

If you feel you are lacking ideas midway through development, even in map-making, then just go and play some other games, take a walk, go out with friends or whatever. There were many times while developing Absence that I felt I lacked ideas, but after putting it aside for a while and doing other enjoyable things, I was able to come back to the project with new ideas and fresh enthusiasm. The important thing is to relax a little and let the ideas flow in their own time.

René "Havoc" N.

» Copyright © 2008 «
You may distribute this file, provided that you don't alter it in any way.