Zombie Slayer mod for Doom III

Zombie Slayer first came into realization not as a game modification but as a sequel to a Doom 3 machinima test film I made back in 2005 entitled Episodes: Episode 1. The storyline of the series was supposed to differ per episode. After writing part of the outline for this subsequent episode, I decided to stow the outline away for two reasons: first, Episodes: Episode 1 did not receive many views, and second, I didn't want to throw that much time into Episode 2 (Episode 1 took 5 months to create - then again, I didn't know what I was doing in terms of animation and scripting). Instead, I ended up creating the Classic Doom for Doom 3 intro and end cinematics.

Episodes Episode 1: What Started it All (youtube)

Classic Doom for Doom 3 - an intermediate project to hone my skills (youtube)

About a year after Classic Doom for Doom 3 was created, I looked at the current mod scene and became fed up with the lack of storyline in most mods. Most mods created were (and still are) catered toward the multiplayer crowd. I decided to make a mod that was strong in story in hopes that others would follow my lead. I looked at all the gameplay elements that I enjoyed that had not surfaced in a while that could use an improvement.

One of my favorite games of the past was Dragon's Lair. It had a storyline and an interesting control scheme that could use an improvement -- namely, the game was too hard. I didn't know how, but I thought it would be interesting if you could have that kind of gameplay with a more linear storyline and a health system. The animation system in Dragon's Lair felt too segmented as well, and the effect was jarring: once you died in the game, the action would pause, the camera angle would change, and the death animation would take place. My prior experience with helping with Classic Doom for Doom 3 taught me that the Doom 3 engine was extremely flexible in that it could do anything which would translate into seamless animation and camera changes when the character was hurt or dead.

The name Zombie Slayer originally was used as a code name for the mod since it sounded similar to Dragon's Lair, but eventually the name kind of stuck, and so I kept it there.

Dragon's Lair - an inspiration for Zombie Slayer

Chapter 2A of Zombie Slayer with a shot inspired by Dragon's Lair

Coding

In order to code the game, I used Microsoft Visual Studio Express. The mod took about four days to code. During this time, I had a test map created with several different triggers set so that I could test out the code. From this test map, I was able to come to two conclusions:

1. If the player died, a map restart would have to take effect. If you had a modern system, the restart wouldn't take long since everything would already be loaded into memory, but you if you had an older system, the map load would take forever since the map and entities would have to be loaded back into the pagefile. I didn't see this as a problem since Doom 3 was already seen as an older game at this point.
2. My idea was possible. This propelled me forward to continue on to the next step: Write the script for the game. I would come up with the method for creating scenes optimally later.

Writing

I liked the idea of the Episodes: Episode 2 script: A zombie infestation on a moon base. The only thing I had done for Episode 2 was write a small outline. I had a general description of each character, the overall message of the story, the mood, themes to touch upon, and a broad stroke of the story touching up each major plot point.

I added details to the outline where I could and thought about the storyline for several weeks. Finally, after I had filled up the outline as much as possible, I wrote the script in Microsoft Word using a freeware script maker program. The actual script writing process was rather quick since I had all the details filled out in the outline.

I didn't outline or write in the gameplay elements. I figured I would put all that in impromptu. At first, I tried, but that grew tiresome quickly. It didn't feel right. I can't explain it any other way.

As far as the storyline goes, I wanted something campy like a mixture between Army of Darkness and Commando. This mood fit hand in hand with the generic horror sci-fi atmosphere that Doom 3 had going for it.

Voice Acting

Not knowing any professional voice actors, I had several volunteers do the voice work. Jack Pattillo, a friend from high school, had a really deep voice. Out of the blue one day, I asked him if he would like to do the voice acting for my mod. I went over to his house in South Austin, we got some pizza, and we went through all the lines in one go. This recording session took about two hours. He did the lines for the main character John McAllen.

I also had my two roommates do two minor roles. I had written in one character - Kane - with one of my roommates in mind, and he did a splendid job of matching the mannerisms I was expecting. He even added his fair bit of improv lines. The other roommate of mine was an aspiring sound engineer and wanted to try his hand at general Allibaster's voice. He added in a hokey British accent.

My only problem with the voice acting was that I had to have general Allibaster's lines redone several times. The recording done on the lines was very poppy and staticy. My roommate redid most of these lines, but the master recording for one of the scenes was difficult to pull apart, so I left those lines in that particular scene.

Lip Syncing

After getting the lines for the project, the next step, of course, was implementing them into the game. One serious problem I had was that, unlike the Source engine, the Doom 3 engine did not have any form of lip syncing built in, especially since I was using 3ds Max for all the animations.

In order to implement the voices accordingly, I first had to create a set of phonemes (mouth and lip movements such as Ah, Oh, Ee, etc.) for each character head. As such, I reserved the first 18 frames of the 3ds Max animation for each lip movement. I used a third party program that had a model of a face with phoneme adjustment sliders for reference. Unfortunately, that was so long ago that I no longer know what I used.

The first 18 frames were reserved for lip syncing purposes.

Initially, after I created the phoneme animations, I then had to calculate where the phonemes would go in the animation. To do so, I:

1. opened up the sound file in Audacity, a free sound editing program
2. listened to every 24^th second of the sound file for the phoneme
3. notated where the phoneme would go in the relevant frame in the animation in a text file
4. went into the animation file and copied and pasted the keyframes with each phoneme to the notated frame in the text file

Original notations for lip syncing done by hand.

This process would literally take around an hour per five second voice file. I decided then to reevaluate how I could get lip syncing implemented since the current process was a huge time sink. I began to look at free lip syncing programs online before finally coming across Annosoft's Sapi Lipsync (Annosoft.com). Running a sound file through this program allowed for it to automatically generate a text file with each phoneme under a time signature.

An example of an anno file generated by sapi_lipsync.

Having all the phonemes calculated was great, but I still needed to know where each phoneme would go in each animation file. I would have to:

1. Convert the phoneme to the relevant initial phoneme frame of animation (for example, if the phoneme is the Ah sound, then I would need to know that it's the initial frame 4 that contains the Ah sound).
2. Convert the time signature to 24 frames per second in a specified initial animation time. For example, if the talking starts at frame 118, I would need to time the phoneme sequence right then and there at 24 frames per second.

In order to have the phonemes calculated accordingly, I wrote a C++ program that would do these calculations by taking in the .anno file that sapi_lipsync would generate, prompt for a frame number, and then output a text file with the relevant phonemes and time signatures all converted over. I named the program vox.exe (vox is Latin for voice).

Converted anno file.

Thus, the lip syncing would then follow the following procedure:

1. Go to frame in animation where lip syncing would take place
2. Run sound file through sapi_lipsync
3. Run generated .anno file through vox.exe specifying frame of animation
4. Copy and paste keyframe phonemes in animation to relevant frames as specified in converted phoneme file
5. Keep animating

This entire lipsync process took around 5 or 10 minutes, down from the prior minimum timeframe of one hour when I did the lip syncing by hand. In order to further streamline the process, I asked one well-known Doom 3 3ds Max scripter in the community by the name of der_ton to see if he could come up with a script that would take in the converted phoneme file and copy and paste the relevant keyframes, but that was going a little too far, I thought. I didn't want to waste this guy's time with something that wouldn't take me that long to do anyway.

In the end, I was pleased with the finalized method for lip syncing. Surprisingly, it was one of the most difficult technical hurdles to overcome with the project despite the fact that it seems like a minor addition in hindsight. Most engines can handle lip syncing without any custom animation, but Doom 3's animation flexibility made up for this technological deficiency.

Exporting/Scripting

An extremely heavy dose of exportation and scripting was involved with the mod seeing as how all of the animation was done through 3ds Max. The process went as follows:

1. scenes were animated in 3ds Max
2. each model was individually exported out of 3ds Max using der_ton's md5 exporter
3. each model was opened in Visual Studio to take out the renamed model bone names to match the original .md5's bone names (3ds Max did not like scenes where multiple models had the same names)
4. each model and/or animation was specified in the current scene's .def file (each .def file was thousands of lines long)
5. the map to which the model and/or animation belonged was opened up in Visual Studio (the actual map editor was too slow, and the map was a straight text document anyway) and declarations were created as specified in the .def file

An example of a definition file. Note the scroll bar on the right side.

Each time I would complete this process and I would test out the map, something would go wrong: Either I didn't modify an exported .md5 model correctly, I didn't script something in correctly, or I didn't put the model in the map. It would usually take me another 15 minutes to discover what I did wrong. Usually, it was something that was obvious that I had missed.

The scripting encompassed an obscene amount of entities. Since I developed the entire
mod with segmented animation per key press, I implemented 20 or 30 segments per map
with their own entities for a failure, success, or death animation.

Maps

I'll admit it - I'm not a good mapper at all despite the fact that I know all about mapping. Gazz, the former lead designer of Classic Doom for Doom 3, did me a huge favor in creating all the maps for Zombie Slayer. Initially for the demo of the mod, I created the maps, but when I finally decided to finish the entire mod, I asked for his help. He did not have a lot of time to work on the maps, so sometimes I would get maps that had leaks in them, but those leaks were easy enough to fix. He redid almost the entire portion of the demo's levels sans the command room.

Gazz redid the demo level work I had originally done. He was constrained to the
original level work so that the animations would not be broken. Later on, he
would make the levels so that I would be constrained to make animations in the levels.

Music Work

For the demo of Zombie Slayer, I had asked Thumpmonks to do some soundtrack work for the first storyline sequence at the very end. Thumpmonks originally did the soundtrack work for the Classic Doom for Doom 3 cinematics and did this portion for me more or less as a one time favor. I knew they were very busy guys, so I didn't want to call on them for unpaid work. Their plate was full enough, and I'm grateful for what work they did do.

I originally asked Sonic Clang of Classic Doom for Doom 3 fame to work on the soundtrack for Zombie Slayer. He said he did not have time since he had shifted priorities in life to his family, so he directed me to Sonny James of Mystic Realmz Productions.

Sonny preferred a more complete version of the animation in a movie file in order to create the soundtrack for each scene. Depending on what I would have done up to the point where he was ready for another scene, I would either send him a rough render of the animation straight out of 3ds Max or an unpolished video of the animation straight out of the game engine. Most of the time I sent him an unpolished video.

Sound Work

I found most of the sound effects straight out of Doom 3. I created some of the sound effects (eg, sitting on a chair in the tram) by myself. I found a free sound file online of some prisoner's manacles shaking that I used for armor sounds. In order to implement the sound effects in each scene in-game, I first tried to create one huge soundtrack per scene; however, I found that Doom 3's video timing was a bit off, so I had to scratch that idea. Instead, I had to:

1. find the frame of animation where the sound would go
2. declare the sound in the sound shader file
3. place the sound in the .def file (but subtract 18 frames from the framecount since we had to reserve the first 18 frames of animation in 3ds Max for the phonemes)

It sounds tedious, but I could normally skip step 2 since a lot of those sounds repeated. The footsteps were the most annoying due to the fact that they occurred every 10 or so frames depending on how many actors were involved in a set scene.

Sound implementation was tedious as seen through the sound declaration on the left and the sound implementation on the right.

The only bad thing about implementing sound this way is that, in order to do something fancy with the sound effect (e.g., have it fade in, come from the right or left, or loop), I would have to either make a separate declaration in the map file and place the sound there accordingly or create a new sound file altogether.

Loading Screen Artwork

David Kosta, a longtime friend of mine, did the 2d load screen artwork for Zombie Slayer. We would meet at a coffee shop every 2 or 3 weeks, talk about what was done on the mod so far and what would happen in a particular chapter, and then he would come up with an idea that would match the general theme of the chapter. We would meet later, look at what he had so far, and then go from there. He drew the artwork on a piece of paper by hand, scanned it in, and then touched it up with Photoshop.

Before and after.

Polishing

Finally, after the sound was implemented and the animation was there, I would go in and polish various aspects. If an animation looked clunky, I would clean it up and re-export it. If a sound didn't fit in, I would comment it out of the .def file. Let's not forget adding in particle effects such as blood, brain splatters, and miscellaneous sounds. Whew!

Development Hurdles

At the time of developing Zombie Slayer, I ran into various hurdles related to time or motivation. I will list them off briefly:

1. Part time work and full time school for an English degree (still managed to graduate magna cum laude)
2. 25+ hours a week of work on Zombie Slayer for over 2 years
3. Some lack of motivation
4. Burnout
5. Self doubt
6. Girlfriend

Despite these hurdles, I still managed to finish Zombie Slayer. I feel proud not of the overall project but of the team's efforts. We did it.

Deleted Scenes

Script Changes:
I originally had a convoluted Sci-Fi storyline where the events that took place were just an elaborate experiment to see what people would do in a high level of stress and to see if they would do as predicted (deemed the Fate Project). I decided that was too elaborate and hokey, so I ditched it.

Intro Cinematic:
The intro cinematic I originally had showed a little backstory to how Jim got to the HQ room we see at the end of chapter one. He was heading an investigation on the nightmares of the undead that everyone was having. I finally ditched the scene because:

1. The pacing was slow.
2. The information was superfluous. We will figure out there is a zombie uprising. We already know that people are having nightmares of the undead.
3. I didn't want the audience to get bored.
4. It lessened the impact of the initial zombie reveal when you begin the first level.
5. I was running out of time and didn't want to speed the month it would have taken to clean up the scene.

Allibaster final line.
In the initial script, Allibaster had a line where he was trying to make amends with McAllen. I sat with the voice actor for this line, and as he was reading it, it didn't sound right at all:

allibaster
(while choking on blood)
McAllen...you know I tried to be the best leader...I -- I wasn't the best in the military, which is why I tried to make it up here... I want you to kill me. I don't want to become one of those.

The problem here is that not only does this sound awkward, but we had already figured out that information earlier from when Kane was talking to him and when he said he "failed a bad operation." We knew from his general demeanor, he was trying really hard to be a good leader, but that was his downfall.

We cut out the middle section and made it short and to the point. I think what you hear in the final version is better. You'll have to play the mod to find out what it sounds like, of course.

More of the Chainsaw Zombie
In the tram, they were supposed to see a chainsaw zombie in the distance:

Jim looks to the left. Far off in the distance, he can see the chainsaw zombie that they had come across earlier running inside a transparent tunnel that leads from one section of the base to the next. He taps McAllen on the shoulder and shows him.

McAllen sees that a huge crowd of zombies is following the CZ.

mcallen
We'll have to hurry.

This scene didn't seem all that necessary and would have taken an additional week or two of time. It also lessened the impact and shock of his sudden (albeit predictable) reveal at the very end.

End Action Sequence
I really wanted to finish up Zombie Slayer with a bang. I had planned to have a really long action sequence that involved a gunfight with Allibaster and zombies at the same time instead of what you saw where Allibaster got chewed up by Kane. While the end was somewhat anticlimactic, I did not want to spend an additional 2 months on the end. I was beginning to feel burnt out on the entire project. I also figured, what the hell, a short final battle isn't bad. I would rather leave people wanting more in the end of the mod instead of being overwhelmed with content.

Conclusion

Zombie Slayer was one of the hardest projects I have completed not only because of the technical hurdles but also because of the personal hurdles. While the mod was not nearly as popular as, say, Classic Doom for Doom 3, I am still glad to have finished it.

I hope to have inspired mod creators to make less multiplayer mods and more single player mods that have engaging storylines. Despite the fact that Doom 3 is an aged engine, I still believe it has its merits as a highly advanced and highly modifiable engine. I mean, I helped to create a quicktime mod with a health system! How cool is that?

Now I ask myself, "Where do I go from here?" The other team members seem to have found their place elsewhere. Sonny James moved on to work on soundtrack work for a CGI Quake short series called Arenas, David Kosta went on to apply for Blizzard, and Gazz went to work on indie games. I tried to get into iPhone development, but I felt lost in the oversaturated market and ended up selling the Mac Mini soon after I bought it. Currently, I am trying to enter writing contests to get some short stories published. I am a closet writer, after all. We'll see how it goes. Only time will tell.

Afterword: on Team Work

I've had a few people come forward and ask me how the team I was on got along and how we were able to make deadlines. Below are a few guidelines:

• Inspire your team and prove your worth.
  • On all the mods I have worked on, there has been one common theme: a proof of concept had already been created, and the person who started the project was taking on a major brunt of the project. For Zombie Slayer, I took on the full brunt of the project and only asked for help when I could show that my idea was possible and that I could pull my own weight. The demo release was mostly my work except for the music work. It was a proof of concept that took me five months to create.

    If you have an incredible idea for a mod, deem yourself as a project leader, and crack the whip without doing any work for yourself, no one is going to feel motivated. They may hate you for it. Many mods have failed from this mentality.

• Use the Knights of the Round Table Approach with Ideas and Concepts
  • LISTEN to what your team has to say. Feedback is crucial for any project. Even if a team member's primary function isn't what you're doing and he or she says that an aspect isn't working, swallow your pride and take what this person has to say in consideration. If you don't listen, then you'll have a lot of angry fans.
• Release a demo
  • Want to know a good way to get quick feedback? Throw out a demo to the public. It doesn't have to be anything special - maybe a level or two that explores all the concepts. You'll see repetition of comments regarding certain aspects of the mod that may not work correctly. Listen to these comments and take them to heart. For instance, after the Zombie Slayer demo, many people said it was too hard and that the buttons didn't look right. I put in checkpoints and tweaked the timing of the buttons a bit. A forum member of Doom3world.org also tweaked the buttons for me.

    Sometimes, you'll get weird comments that won't make any sense. It's up to you and your team to decide if they work or not. Also, sometimes you get unsolicited help that is extremely worthwhile such as with the button tweaking in my case.

• Know that you will Never Reach an Estimated Release Date
  • This one is self explanatory. Don't disappoint your fan base. Even a year estimate is sometimes incorrect. Sometimes hyping a project's release date is a good way to gain media attention, but it is an indication of poor project management if you are incorrect.
• Keep your Team Small
  • I've seen too many mod groups where there is a communication breakdown because no one knows what to do because too many people are working on the project. Keep your team small and personal and only recruit those whom you talk to often. This concept sounds simple, but many mod groups try to recruit as many people as possible because they think more people = faster work.
• Keep to your Own Work
  • If you're a mapper, MAP. If you're an artist, DRAW. Don't toy around with other concepts of the mod unless you are done with your portion of the work.