Bloody Undead Postmortem


When I arrived at the DigiPen Institute of Technology in Fall of 2002, I had hoped that, given my previous programming experience, I could enter as a junior. After I found out that I could not, I was initially disappointed; I knew that I would be grouped with students who had little or no background in computer science. However, I soon realized that, despite their inexperience, my teammates were quick to learn and eager to make a great game. With all six cylinders firing, we developed a product we were proud of.

As beginning DigiPen students, our semester assignment for Game Design and Production class was to create a text-based game using the Windows console interface. We were strongly encouraged to make a command-line, text-parser adventure in the spirit of classics such as Zork. After I convinced my teammates with a technical demo and confirmed that the idea fell within assignment guidelines, we began development on an overhead scrolling action adventure instead.


What Went Right

One of the most important elements of our success was our discipline. Class only met once a week for three hours, so it was clear that we would need to meet on our own initiative in order to finish by winter break. Finding times we were all free was difficult, but we managed to establish a schedule where we met three times a week for several hours each session. We were fortunate in that everyone pulled his weight; rarely would someone fail to show up without a previously given explanation, and we generally stayed in the computer lab until the janitor turned out the lights.

We managed to get off to a quick start. Shortly after our game format was accepted, I disappeared into my apartment for two weeks and emerged with the game engine, graphics engine, and image editor that we needed for the project. During this time, my teammates, armed with pencils and graph paper, designed dungeons for the hero to endure. With the core finished and debugged, the rest of the semester was open to implementing the levels and game objects.

By dividing the programming tasks according to game object, we were able to clearly define the responsibilities of each member. Seth was to implement the hero, Hesh, and the weapons and projectiles that he used. Aaron was to implement NPCs, conversation triggers, exits, and several of the enemies. Lance had the honor of breathing unlife into the zombies and developing the item pickups. Keith was to implement switches, doors, sliding boxes, crushers, and similar objects. Micah, who had had more programming experience than the others, took on more difficult tasks, such as the bosses, dialog system, pause menu, file I/O, and graphics optimizations. I spent most of our meetings helping teammates solve various programming problems. In my spare time I built the level maps and developed the game event logic, aspects of the dungeons (such as the flowing water in the sewers), and various special effects.

Our enthusiasm kept us going. Team spirits were rejuvenated by pivotal moments, such as when Seth first showed off Hesh riding around on a tricycle, torching the townspeople with his flamethrower; or when Micah unveiled Toilet Papa, the toilet-paper covered boss of the sewers. Because we were doing something we loved, working on Bloody Undead was never a chore.


What Went Wrong

I had originally hoped that we would all be involved with map creation. My idea was to create the editor and town map then let the other members implement the dungeons they had designed. Unfortunately, the levels that the others created on graph paper differed dramatically from each other. I realized that I had not specified the dimensions of typical small, medium, and large rooms and passages, nor had I specified how quickly Hesh would move. Without a cohesive vision, the experiment in democratic level design had failed. Since I had constructed the editor, the team decided that it would make sense for me to create the maps myself, incorporating ideas from their prototypes. I did so, but the final maps barely resembled their graph paper counterparts. The two weeks designing maps on paper would have been better spent some other way.

About two-thirds of the way through the project cycle, Bloody Undead came down with an acute case of feature-itis. It was not enough that Hesh fired rockets; the rockets had to leave puffs of smoke. Spiders had to do more than move randomly; they had to crawl down walls. There had to be body armor, a hidden bank, a bestiary—the to-do list grew faster than we could mark through completed tasks. In most cases we were able to finish the in-progress tasks before the deadline, but we failed disastrously in the case of sound. Micah, Lance, and I spent the two weeks before the deadline developing the sound engine, recording sounds, and implementing them in most of the game objects only to realize, three hours before the final CD was due, that playing the game with sound for more than a few minutes caused it to slow down to the point of being unplayable. With no time remaining to debug it, we had to make the agonizing decision to disable the sound engine entirely.


The Final Word

Despite some problems with level design and runaway features, Bloody Undead stuck to its schedule, met its milestones, and “shipped” on time. In addition to giving me the chance to lead a group of ambitious classmates, the project proved to be an intense, hands-on introduction to C++ and object-oriented programming for many on the team. At the end of the day, we were glad we took a chance to develop something a little more than expected.


―Dan Reed, technical director