Introduction

Ack! Zombies is a project I worked on as part of a five-month culminating project at Full Sail. This is where everything we had spend the last two years studying would all be put to practice. I had a blast making this game, and from the feedback we’ve received from friend, family and even anonymous folks out there on the Internet it turns out we made a pretty gnarly game! :) Out of everything I’ve worked on, this is probably the project I would like to revisit the most.

Direct from our design documents, a basic synopsis of the game is:

“You are Johnny, a typical american student with the daunting task to save Earth from certain brain-eating destruction! Nearly the entire populos of Earth has been converted to one large horde of zombies through some unexplained means. It is up to Johnny to blast his way through swarms of the undead to save the last few remaining people and escape into the cold reaches of space!”

Sounds awesome, doesn’t it? :) Ack! Zombies offers an action-packed adventure full of zombies, creative weapons, and more zombies. So go pickup the game at the website, give it a play, and then I can go into some of the technical details about how it all came together. Go ahead, I’ll wait here…

My Role

For this, the final team project at Full Sail, I was again nominated to serve as the team’s Technical Lead. Using alot of the experience I gained from writing the core engine architecture from StickJitsu! and research projects I had done along the way, I developed a modular and (hopefully) easy to develop with state architecture. To enable the hordes of zombies, I decided it was important to implement a resource manager which would cache asset data wherever possible.

Along with these jobs, I was responsible for writing the graphics engine for the game. Static rendering uses a simple Octree implementation using spanning polygons to eliminate the need for splitting. Additionally, a full shader pipeline was implemented, but was unfortunately pulled at the last minute due to performance issues and lack of time for profiling. The engine also uses skinned animation for all game characters, which is scales according to the hardware the game is being run on.

As far as smaller utility additions to the game, I also wrote the game’s console system and command parser, which powers the cheat system and was used by Jon Zimmer to create the entity placement editor for the game. The most fun I had making this game was writing the particle effects system, and the corresponding editor.

Adventures in Tools Programming

Throughout my time at Full Sail, I had being using C# more and more and became very interested in it’s appeal in quickly and easily creating interfaces for use in game tools programming. The perfect chance to try this out was with the particle editor I got the opportunity to write for Ack! Zombies.

Inspired by screenshots of the then upcoming Unreal Engine 3, more specifically their effects system Cascade, I decided to make a more freeform editor for creating particle effects for our project. The problem I had with effects editors I had seen done in school previously, is that they were all powered by a collection of textboxes and dropdowns where a user had to experiement with different values and see what kind of results they could come up with. It’s really an engineer’s approach to creating an artist’s tool, and creating these effects is an artform in itself — not an exact science that can be defined easily in numbers. In reality, this experience is only a small step up from editing scripts or code which define effects and running the game to see the result. I wanted an experience for my artists and teammates to use that was familiar to tools they were already using in asset creation suites like Maya and 3D Studio Max.

Using the .NET Framework made the creation of the interface a snap. Most of the time was spent creating custom controls for editing values of the different “attributes” in an effect. An attribute is in this sense… well, an attribute of an effect. Things like colors, size, rotation and velocity make up a majority of the tweakable values in an effect. The editor allows keyframes to be defined for a given attribute, and the particle system interpolates all the values of each attribute to get the current state of a particle. Unfortunately, a large amount of time was also spent on recreating the same particle system in the managed world, which was one of the things I would change if I had to do it all over again.

Post-Mortem

What Went Wrong

• Know your timeframe, and scale the project accordingly – The graphics engine I had planned for this 3-month project was ambitious, perhaps a little too ambitious. The full shader implementation could have been done if I had less on my plate with the rest of the project, or if I had started a bit earlier. Because I went ahead with my ideas anyway, the final submission of the game ended up less pleasing than desired. If I had started from the beginning with a solid fixed-function renderer I may have had the opportunity to add more polish.
• Reuse whenever possible – While I was writing the particle editor, I had to reimplement the particle system logic in C# to get it running in the editor because the game had not been built in a modular form that would have allowed the graphics engine to be used outside the game. If that were the case I could have wrapped the graphics engine from the actual game in C++/CLI (or Managed C++ at the time) and used the same code base. This would have greatly lowered the amount of time spent on synchronizing the behavior of the two implementations.

However, even with these “lessons to learn”, I believe we still ended up with an amazingly fun game to play.

What Went Right

• Great team experience – Months before Final Project, most people knew who they were working with. Most of our team went as far as to move into the same apartment. The extra availability of team members made the turn around for bug squashing and feature decisions quick and easy. Even with the extra stress with always being around your teammates, it was well worth it.

• Awesome game idea – Our game was the inspired brain-child of Jon Zimmer. It came from a similar 2D game Jon created early in the program when we first started doing DirectX. The basic design allowed us to go totally nuts and make the game we all wanted. It really says something when we were having as much fun playing the game at the end of the project as when we were first getting started.