I wrote this postmortem and didn’t know what to do with it. It’s not exactly the kind of story that a team of developers can take with them and say, “this is how it’s done”. In fact, it’s the complete opposite kind of success.  If anything, this article is proof that it is possible to make a game with less than 200 developers; about 199 less to be exact… Enjoy!

Introduction

In 2003, one man had a dream. It was one that he had experienced many times before, in his sleep and in his wake. His dream was a simple one, to create and publish a video game. It wouldn’t be his first, as he had worked for an industry leading developer, but this game would be on his own terms. It started out as a small dream and grew into an obsession that would take him down many roads unknown. He had been burned repeatedly, over several years in the past while trying to keep others motivated enough to finish a game, any game. He knew that it was hard enough to motivate people who were on a payroll, so motivating people on the promise of exposure, a stronger portfolio, and future revenue sharing didn’t seem to hold much weight for most. It was heart wrenching every time he had to pull the plug on yet another failure due to partners leaving the team or underperforming. Late in 2007 was the breaking point where he had abandoned all conventions of forming teams and building spreadsheets and task orders. He gave up on schedules and rousing speeches to keep his fellow indie developers in high spirits. He turned his back on every success story that told him to build an A team before anything else and dared to make his game, alone. Follow him through this short story about a long period in his life where he learned a thing or two about this new generation of game development and just how far he would go to keep his passion alive.

Background

Zombpocalypse was an entry in the 2009 Independent Games Festival and is a free downloadable game at www.zombpocalypse.com. In this game the player is thrown into a zombie infested world and his only objective is to survive. Designed as a throwback to the days of arcade cabinet games, Zombpocalypse was meant to be a mindless shooter, an escape from the massively epic story driven games that claim to pull at your heart strings. It is also the first released title under my company, Inland Studios, LLC.

What Went Right

1. The Perfect Storm

Between the years of 2003 and 2007 I designed and developed three complete engine rewrites for two first person shooters, one role playing strategy, two puzzlers, and a turn-based tactical strategy game. Several of these games had epic stories with overlapping plots and a complete game design document as icing on the cake. Despite my readiness, all of them were complete failures. So why then would such a tragic story be part of what when right? For each failed project I had a micro victory. Every game got just a little closer to completion, and every game inspired me to go out and learn a newer and faster technique to a problem. My knowledge space grew and my code got faster over the years. It was because of that series of unfortunate events that I was free to completely scrap my old solutions and find newer, faster, and better ways for the next project that arrived. As painful as it may have been, those failures only made me stronger as an engineer and a leader; teaching me to better manage my expectations of others and myself.

The flamethrower was an instant crowd pleaser with anyone who played the game.

As a programmer by trade I was often sucked into technical curiosity. I became enamored by the challenge of solving a difficult logical problem, typically with an elegant solution. My problem on this day was how one person could possibly make a modern game, alone. Putting aside my bag of cool little research ideas, I made the choice to stop building tech demos and create a full game. I had no idea what I would do with it once it was done, but I knew that I wanted to finish something and introduce it to the world. I thought that the worst-case scenario would be that I make a game that at least one person would enjoy, “this guy”. I immediately threw out the idea of building an A team since I had recently come off of a four year indie slump and was turning a new leaf.

One year later, I released Zombpocalypse to the world and the Independent Games Festival (IGF). Although I did not emerge victorious from a crowded room of over 220 solid entries, the experience of turning loose a multi-year effort and not getting completely burned on any forums (that I know of) was reward enough. I learned more in this past year than I possibly could have dreamed to do in my day job, game industry, or otherwise. With the exception of a few notable programmers in the game industry, most programmers are forced into becoming a master of a very small piece of code. We are seldom given the opportunity to play the role of architect; the all seeing technical visionaries that preach to us buzzwords like, destructible environments, high density crowds, or Megatexture. It was refreshing and educational to design and develop this game from the ground up while trying to meet industry standards on a non-existent budget.

Unique lighting conditions were easy to test with a dynamic lighting pipeline.

Though the game only took one year to create, the technology was a culmination of years of my curious tinkering and previous failures. Over those many years I gained interests in a myriad of topics such as AI, physics, exporters, processing tools, multi-core processing, graphics, and much more. Building those exporters allowed me to expand my knowledge of modeling and animation techniques. With the priceless guidance of some of my fellow co-workers through the years, I was able to learn just enough about modeling and texturing to be dangerous in a pinch. Learning the basics of modeling proved to be the integral part of my life lessons that allowed me to create and release Zombpocalypse.

It is difficult to summarize years of random occurrences and life lessons, but the perfect storm may be the best way to describe the end result. It was like every unfortunate event I ever had has taught me something new about the industry and how the pieces of this puzzle fit together. I definitely learned not to deny my curiosity for things outside of my comfort zone; it proved to be the critical factor in my success with Zombpocalypse.

2. Setting an Ambitious Technology Bar

Of all of the interests I mentioned above, graphics has always been my happy place. I wanted, if nothing else, to create something that had a real visual appeal. I wanted my screenshots to look pretty and the game to look even better when it was in motion. I had just one problem, me. I was a programmer, what could I possibly make? My first thought was to go simple and make something 2D, so I rushed for a pencil and a pad to put down the vision that was floating around in my head. My pencil was a whirlwind of thoughts that scribbled their way onto the paper until there was nothing left. In the end, it was bad; like a car had run over my foot and didn’t let up until I stopped drawing. I promptly put the paper through an industrial strength shredder, never to be seen again. There had to be another way…

The indirect lighting was kept in the final build to avoid frustrating the player with blind-sided attacks out of the shadows.

I eventually returned to what felt right to me, 3D. It may sound strange but there was something very mathematical about modeling and texture mapping that made it easier for me to wrap my head around. It wasn’t easy, just easier than traditional art was for my programmer brain. It was not an ideal scenario, but I did what I had to for the sake of the project. I started developing the game with cubes at first, which eventually formed into some kind of human shape, and finally into a fully animated undead killing machine. From the beginning and right up to the bitter sweet end, I had always hoped to replace the art with professional work but was unsuccessful. My goal however, was to do whatever I could to improve the quality of the art that I had in case the professional art never came. I wanted to develop technology that would render the most beautiful real-time cube I had ever seen. I knew that if I could at least do this, then anything that was close to professional art would be taken the last step by a series of rendering tricks and post processes. I felt that the leap from 2D to 3D meant that I would be competing with the expectations that gamers already had by playing other modern 3D games like Doom 3, Gears of War, Half Life 2, and many other games that have set the bar in gaming technology.

I didn’t consider licensing technology because I wanted the learning experience of architecting and developing all aspects of the engine. I also didn’t have over a quarter million dollars in my ceramic piggy bank, which I jokingly called my “vacation fund”. It was an ambitious direction to take, but I’m fairly happy with the results. I used a combination of dynamic per-pixel lighting and shadows, directional animated light maps, normal maps, mirrored surfaces, and blooming effects to help improve the visual quality as much as possible. I even toyed with other effects such as motion blur and depth of field, but the performance cost and fixed camera angle only seemed to cause these effects to get in the way of the gameplay so they were eventually cut.

3. K.I.S.S

I probably had learned about K.I.S.S some time in middle school and it has been a part of my code, game designs, and philosophy on life since those days. Keep It Simple Stupid, or Keep It Sweet and Simple; however you choose to say it the objective is the same. My ultimate plan from the beginning was to tackle something with a small set of ambitious goals. I wanted to create a handful of features that would keep my interests peaked and result in a better game in the end. It wasn’t long before I had made a list of goals and cut them down to just a few. Before I even knew what kind of game I was about to make, these stood out as the key objectives that I wanted to achieve.

• Spare no graphical flare; learn every trick in the book.
• Create a world with a clean and architectural design.
• Give the gameplay an old-school arcade feel; using 3D for visual style and depth.

The engine allowed for diffuse maps to be ignored so that the pure lighting could be tested.

If you have played Zombpocalypse for a measureable amount of time, it’s easy to start picking out some of the influences I had in my design. The weapon selection and reloading system feel torn from the pages of some of my favorite shooters. The strategic camera angle was a mixed bag of strategy games and arcade style classics like Smash TV or Geometry Wars. The original game design was actually much closer to Smash TV than the game you see today. XBLA rekindled my flame for this game and it became my inspiration for creating an arcade style shooter. My vision was to blend Smash TV with my love for modern zombie films and introduce story elements of Willy Wonka & the Chocolate Factory. It was bizarre but I wanted to take that fast paced shooting and move it into the third dimension, giving it some depth and High Definition detail. My artistic limits forced me to change to the single arena design of Geometry Wars over the room-to-room design of Smash TV. This was a crippling blow to my original vision but not a fatal one. I still managed to create a good handful of smaller arenas; each having its own unique feel, but forcing me to abandon the story.

The level designs for each arena were meant to be a throwback to some of my most memorable gaming days of sleepless nights with Quake 3 and Unreal Tournament. By today’s standards these environments seem old-school but their minimalist design still brings a warm, fuzzy feeling whenever I boot those games up for old time’s sake. Their clean corners and chiseled edges reminded me of a time before the smooth button was discovered. I wanted to bring that style back while introducing a little bit of the modern flare. Lighting, lighting, lighting. It turned out to be the key element that let me really set the mood for each environment. I toyed around with warm colors for some environments and cooler shades for others; I just had fun with it. In the end, I was very happy with how well the arenas were lit and I did my best to make that part of the game really stand out.

4. The People have spoken

It wasn’t until the weeks after the release of Zombpocalypse that things really took a hard turn for the better. I posted a link to my game on various forums and braced for impact. To my surprise, nearly everyone had only constructive criticism about the game. They all had nagging issues with various parts of the game and I listened. It was because of the response of those people that the game now has fewer bugs, faster and more fierce zombies, enhanced performance, and an improved camera angle to name a few changes. I can still recall the moment when someone asked me, “So what am I supposed to do? They just keep coming.” It was at that moment when I realized I hadn’t even implemented a progress bar or some kind of indication of progress. In my mad dash to the IGF deadline I had nearly forgotten several fundamental features in the game like a completed HUD, for example. I could nearly play the game by heart and it took a fresh set of eyes to bring up that critical oversight. I can say with full confidence that Zombpocalype is far better now than it ever could have been because of those suggestions made by players of the game.

5. Indie Time Management

We’ve all been there; we’ve all said at some point, “I am going to make my own game.” Whether we were coming down from a soul sucking crunch to meet a milestone, or out of pure boredom of our current place of employment, we’ve all wanted to make something special and on our own terms. Like clockwork, that crunch settled down or that boring job picked up a new and interesting project and suddenly your dream felt more like a brief stint on a borrowed soapbox. It seems impossible to finish anything as long as we have the internet, TV, movies, and many other distractions to absorb what little free time we have. To help make more time in my day, I simply cut out most of these distractions. I rented a DVR from my cable provider and limited myself to no more than four hours each week, including weekends. My internet usage was reeled in to only support my research needs during the height of development, and I watched an average of only one movie per month. It sounds incredibly rigid but if we don’t draw a line in the sand somewhere we’ll find ourselves laying in bed, wondering where the day went.

It’s not every day that someone manages to set a bar this high and actually accomplish their goal. A lot of sacrifices were made but, in the end, I had an experience that I wouldn’t trade back. I did what felt like the impossible in an age where we are surrounded by gadgets and hyperlinks to videos that beg to take just a few minutes of your day, I finished. Well, as finished as a one-man game can be. Even today, I find myself returning to the code, looking to add more features and new tricks I’ve picked up along the way. Indie development may not pay out big (or at all) for most of us but it is a labor of love and that will probably never end for me.

What Went Wrong

1. QA? 2 weeks!

Sadly, game testing was very low on the priority list. In the final mad dash to IGF I was more concerned with broadening my compatibility than enhancing the gameplay. I figured that the best game in the world could not win if the game did not run on their machines. It was only after the contest submission and public release of the game that I was able to implement critical enhancements.

2. Setting an Ambitious Technology Bar

To create more variations of zombies with limited art assets, the skin tone was separated from the clothes and randomly picked from a list of faces and apparel.

The problem with developing technology that can render high quality graphics is that it requires two things, a machine that can run it, and an art team that can produce enough art to prove the technology works. Like a printer with no ink, the greatest technology in the world is nothing if it doesn’t have the data. Even though I am content with the final result, this problem of limited art assets was easily my single largest hurdle and I barely cleared it. Beyond my own asset requirements, many users couldn’t play the game because of the high system requirements.

Of the several engine rewrites I had mentioned previously, I was trying to avoid another for this game. I eventually settled on using my most current technology which was originally developed back in 2005 for a dark and shadowy zero-gravity puzzle game; think Dead Space meets Portal. The game engine had to be retooled slightly to handle large groups of zombies instead of a small handful of more intelligent enemies and obstacles. One piece of the game code that could not be changed was the animation state and AI logic system; executed almost entirely in Lua script. Running AI on a handful of enemies was not a problem, but scaling to dozens of zombies caused some serious thrashing within the Lua updates. In addition to the CPU load from Lua, the engine was designed as a unified rendering architecture which meant characters and their shadow volumes had to be animated on the CPU before they were passed through the rendering pipeline. Even the game logic was completely 3D despite the fact that the game played essentially in 2D. This meant ray casting, line of sight checks, collision detection, and matrix operations were in full 3D which was far from optimal. To avoid drastic changes in the rendering pipeline I kept all of the high quality features like dynamic lighting which brought modest PC’s to their knees.

3. Abstract vs. Realism

The concept of building arenas turned out to be a mixed blessing. Arenas allowed me to focus my resources onto a smaller space and gave me more time to work with other parts of the game like weapon balancing, or speed. The side effect of building arenas posed an interesting challenge that I did not expect.

Most arenas appeared to have a way out which caused some confusion amongst players.

Geometry Wars has four bordering lines as its environment. Gamers were okay with this, they were willing to sacrifice their belief in an infinitely expanding universe for roughly two screens of blank space. I was hoping for gamers to be as forgiving when I created environments that were grounded in reality. Instead of fighting it out inside of a valley that was mysteriously surrounded by insurmountable cliffs, I modeled a small part of what looked to be a much larger world. This change in scenery flipped a switch for most gamers. Suddenly they were upset that they could not walk through a door or pathway that was constructed to give zombies a point of entry instead of them simply appearing in the middle of a room. I struggled with a dilemma; how do I design my arenas like a roach motel and allow zombies to enter while preventing the player from leaving. I considered creating custom animations for zombies to climb fences, leap from roof tops, and climb out of ventilation shafts but decided against it. The animation list quickly exploded into an unreasonable number and I was forced to use my limited animations to find a better way. Ultimately I resorted to the criminal sin of invisible collision geometry which caused the outcry and disappointment of the gamers when they discovered that they could not venture further into the world. It was a hard lesson for this first time level designer.

4. Flying Solo was Bitter Sweet

I will admit to a certain guilty pleasure. When you are working alone there is no one to argue with over design choices, no one to make questionable additions to the repository, and no one who will ever tell you that you are wrong. But all of the things that make it great are also its downfall. It is often those heated debates that make a better game or that questionable change in the repository that brings to light a new gameplay possibility. Working solo on a creative project was incredibly difficult. It became increasingly difficult when I found myself searching for a little motivation of my own. The pressure of having something to show in my next team gathering was a strong incentive that I just did not get when I had no one to bounce ideas off of.

You’ll always find it easier to get the creative juices flowing with a partner but you’ll also find the work a little harder to manage when your partner starts to slip. It’s a gamble that each of us have to make for ourselves. I may have gone to an extreme to try and make a fully 3D game on my own but it was an experiment worth the effort.  I wanted to prove to myself and others that it is possible if you really want it bad enough.  I would gladly try and work with an artist in my next project because I know that Zombpocalypse could have looked so much better than it did on its release date but there is a certain comfort in knowing that if I was on a deserted island and could take just one game with me, it would be my compiler and favorite art tools, and I would be just fine.

Conclusion

The couryard was intentionally an oversize arena; originally meant for a potential boss fight or heavier populated location.

I learned a lot in the making of Zombpocalypse, but I learned even more on the paths that lead me to it. Even today, I find myself searching for a new fragment of knowledge; something to add to my arsenal. I am daring to pick up that pencil one more time and try again until I get it right. In trying times, we need to find comfort in our failures and know that it just might lead us to our own perfect storm.

Fact Box

Number of Developers: 1 developer, 1 contract composer
Development Time: 12 months
Release Date: December 06, 2008 (downloadable)
Platform: Windows XP / Vista
Hardware: Intel Dual-Core HP laptop PC with 3GB RAM and Geforce 8600M.
Software: Visual Studio, Tortoise SVN, Adobe Photoshop, Autodesk Maya, Audacity
Notable technologies: OGG Vorbis, Lua, DXT compression
Size of Project:
Data files: 945 files of nearly 80MB of unpackaged data
Source files: 247 engine, 197 game
Total lines of code: ~78k engine, ~57k game, ~180k tools and exporters