Student Game Postmortem: Fairly Evil's Divide-by-Zero Gunner

Author: by Fairly Evil Software

Divide-by-Zero Gunner began in May of 2002 in the minds of a small group of friends in the Game Design and Development program at Full Sail in Winter Park, Florida. The fourteen-month program culminates in a class called Final Project, a small-scale simulation of a development cycle at a real game company. Students are instructed to take the knowledge they have acquired and put it to practical use, building a game demo on their own initiative with oversight from the instructors. Final project at Full Sail is where the rubber meets the road, and our team pulled together to make the most out of the experience. In the end, through the setbacks, breakthroughs, and team restructuring, we were able to create exactly what we'd hoped for: a fun game that adhered to our high concept, "Stunning 3D graphics and fast paced helicopter action".

Based on the popular arcade game Zero Gunner II, Divide-by-Zero Gunner brings all of the fast and furious action of an arcade shooter to your home PC. In our game, you play a game developer named Bob Garrett. Here's your problem: You can't turn a profit because evil software pirates are stealing your work and giving it away for free. Just as you are about to go bankrupt, your rich Uncle Darryl dies and leaves you three bad-ass attack helicopters that were built by ninjas. With this newfound power at your command, you and your programmer buddies can take to the skies and rain fiery vengeance upon the organization known as S.P.I.T. (Software Pirates and Information Technicians)! Yeah... well, arcade shooters aren't famous for their storylines, right?

Prepare for Take-off!

The genesis of Divide-by-Zero Gunner went something like this: "Hey, let's do something with helicopters!" After some different styles for a helicopter-themed game were discussed (with some team members leaning towards a flight sim), it was suggested that we go to the nearby arcade and check out a game called Zero Gunner II. After one play we were all hooked. The game had all the glory of an old-school arcade shooter like 1942, except the player could rotate 360 degrees and fire in any direction. The really wild thing was that even though the game maintained the top-down perspective common in most scrolling games, it featured 3D models instead of sprites, giving it a unique and downright cool look. We realized that our own take on Zero Gunner would make a great final project for several reasons: we knew that building this style of game would be feasible in the limited time available, we wanted to build our own engine, and it was just a hell of a lot of fun to play!

With the concept for the game agreed upon and a working model of it at the arcade for inspiration, we were ready to start building Divide-by-Zero Gunner from the ground up.

What Went Right

So what went right? Well, a lot actually. While our development cycle was far from perfect, it was incredibly smooth compared to some of the horror stories we'd heard. We can attribute this to good instruction, good teamwork, solid documentation, and good ol' fashioned luck. Let's take a closer look at some of these factors.

1.Teamwork, motivation and unity. A great deal of our success is owed to the composition and chemistry of our development team. We were fortunate enough to have five talented, professional individuals that clicked early on. Each member of the team is a competent programmer in their own right, but we had the added advantage of specialized areas of expertise. For example, two members of our team have excellent written communication skills that made our documentation really shine. Another is an accomplished artist with MAX and Photoshop, and was able to punch out most of the game's artwork.

Each week, we worked three days in class and three days assembled at each other's apartments. We felt it was necessary for everyone's mental health if we took Sunday off, but it wasn't unusual for somebody to show up on Monday with a new chunk of code. People would frequently give up their limited spare time in the evenings after class or meetings to work on the project. The best example of this is our particle engine, which was used for missile smoke-trails and spark effects. Once all the A-features were implemented, one of our team members showed up Monday morning with the fully functional particle system and blew us all away.

Personality counts for a lot in a team environment, and again we were lucky in this respect. Four of us were already good friends, and had been through the entire game design program together. Our fifth team member joined our class just for the final project, so he had to face the challenge of hopping on board a team of strangers who had already been designing their game for a month. What could have been an awkward situation turned out to be a great advantage. Our fifth member (who earned the nickname "New Guy" for the duration of the project) was quickly accepted as if he'd been with us since the beginning. He brought a lot of professionalism and humor to the project, and it wouldn't have worked out as well without him.

We all shared a vision of what we wanted to accomplish with our game. All of us had heard horror stories of teams self-destructing when the going got rough, and we were determined not to succumb to that. We learned that when you see the same bunch of people six days out of the week for months on end, you'd better be sure you can work together so you won't be at each other's throats by Alpha.

2. OpenGL rocks! From the outset, we knew that Divide-by-Zero Gunner was going to be an extremely graphic-intensive game. We knew that we needed to display a lot of alpha-blended textures and 500+ poly-count models onscreen simultaneously. We also knew that OpenGL was our best choice for a graphics API because not only does it offer native hardware acceleration for these features, it is also very easy to code. Due to our familiarity with OpenGL from a previous class, we were able to get our content up and running in a very short period of time.

3. They taught us everything we know. We're good programmers because Full Sail has good instructors. Divide-by-Zero Gunner was built on a foundation of everything we learned over the last year, and we were eager to tread new ground. When we hit a wall with a particular API or function we were unfamiliar with, our past professors and lab instructors were there to steer us in the right direction. If the issue at hand wasn't something they had personal knowledge of, they would encourage us to look it up and figure it out on our own. Those cases were the best because when we resolved the problem, we got a sense of accomplishment from conquering territory beyond what we'd been taught.

4. Strong Documentation. The building blocks to a great game and smooth development cycle are set in the beginning weeks with solid design documents, and a comprehensive Gantt chart. Since we didn't have the typical length development time, our building blocks had to come much faster and more efficiently than normal. Luckily, in the beginning of the project, after the idea was conceptualized, the team sat down and hammered everything out in detail. Sheets and sheets of notes were scribbled and jotted down as the inner details of Divide-by-Zero Gunner came forth. This was important because from very early on, before one line of code was written, decisions were being made that would dictate how the project was going to turn out in the end. Thus began the design documentation – it started out as hand written notes and throughout the course of the project would come to contain every single detail about the game. We put our faith in two members of the team who were fairly well versed in writing and eager to tackle the design documentation from the start. One also volunteered to take on the Gantt chart and maintain it throughout the project. Having people totally dedicated from the start to working on the docs was a great asset – with most issues planned out and understood before coding began, each team member was able to sit down with their given task and complete it on time.

After the first month of development, much had been written, but not in the form of code. The design docs were at a state to where the game was ready to enter the coding phase of development. Also, the full Gantt chart was in its first completed phase and ready to go. With over 100 tasks on the chart, the team could visually see how much there was to be done, and when it needed to be done by. One of the toughest, yet most beneficial aspects (design wise) was keeping the chart updated and on track. It would be easy to let fall behind, but in the end the Gantt chart kept everyone on track and focused.

After all was written and done, the design docs for Divide-by-Zero gunner were revised and edited numerous times, but included everything from technical white papers, to in depth level descriptions, covering over 40 pages. The Gantt chart was evil and overbearing at points, but in the end helped keep the teams focused and working on time. Strong documentation was one of our biggest assets throughout development, and our planning and scheduling abilities yielded a great project.

What Went Wrong

All right, now for the exciting part. So far it sounds like we had our stuff together pretty well, right? Well now we can get into some of the things that didn't work out so well. To put a positive spin on it, here are some of our greater "learning experiences".

1. So this is a 2D game, right? That was the running joke with our lab instructors and fellow students. Divide-by-Zero Gunner is a fully 3D game, but it plays like an old-school 2D scrolling shooter. The fact that the background terrain geometry wasn't lit didn't help to dispel the notion that we had a 2D game. Early on, we decided that the most efficient way to cull the terrain was to literally chop it into cubic "chunks" and perform a simple screen visibility test based on the camera's position over the level. The problem with this approach was that the vertex normals on the edge of each chunk of terrain were not averaged with the vertex normals on the edges of adjacent chunks, resulting in nasty-looking seams when lighting was turned on. Due to time constraints, we decided to turn off lighting altogether for the terrain and hope that the natural parallax effect would get the point across. The upshot was that the slightly flat-looking background geometry didn't detract visually from the action going on in the foreground.

2. People come, people go. In May of 2002, our team was formed with four individuals. Within a month, we'd lost one member and gained two new ones. This proved a challenge to the project manager, who had to reschedule the Gantt chart accordingly every time, and for the rest of us who had to make sure that the new folks were on the same page as the existing team. Luckily, we were relatively early in development when these changes occurred, so bringing the new "hires" up to speed wasn't all that difficult. The project manager deftly rose to the occasion on the Gantt chart front. Still, we could plainly see why real game studios don't like to lose and gain people in the middle of a development cycle.

3. Take off was a bit rough. By the time Final Project rolled around, we were reeling from the volumes of C++, Win32, MFC and OpenGL that'd been crammed into our heads over the course of the last year. By that point we'd lost about half the members of our original class for various reasons, and the reality of having successfully gotten this far suddenly hit us like the proverbial ton of bricks. We needed a break, a breather, and this was a poor time to take it. We were facing a clean slate, and we floundered a bit when the time came to start producing assets for the game. The personnel changes that cropped up early on added to our inability to get a solid start on the project. We were far from lazy, but for a couple of weeks we failed to maintain the professional work ethic that Full Sail subconsciously drills into its students. We felt guilty for not pushing ourselves as much as what we'd become accustomed to, but once the realization that we were on our own sunk in, we charged into development with guns blazing.

4. Sounds like a copyright violation. Generally speaking, the game industry learned long ago the importance of audio when crafting a virtual world. Unfortunately, we didn't -- sound was something of an afterthought in Divide-by-Zero Gunner. The code base was great; it was the actual content that was the problem. One of the members of our team wrote a great DirectShow wrapper to play MP3 files, but we wound up grabbing a couple of music tracks from another game. No one is quite sure where the effect sounds came from, though they get the job done. Still, this was a bit of an embarrassment when you consider Full Sail has an audio program that is widely recognized for turning out Grammy-winning recording engineers. Oops.

Parting Shot

Divide-by-Zero Gunner was a total team effort all the way through - every member had a valuable role that was executed from start to finish without a hitch. Problems were solved fast, someone always had a fresh idea, and being with the team made hard times a little easier. With all the restructuring of our team we endured, it just seemed right in the end with all five members. No one could have asked for a better team given the circumstances, with each member bringing a unique attribute to the table and all of us working together for one idea unified us early on. Even in the end, everyone on the team was very proud of our accomplishments and no one has any regrets about how the project progressed.

Over the course of three months, Divide-by-Zero Gunner became the realization of everyone's hard work and desire. The game speaks for itself in regards to the level of quality and the attention to detail that was placed into its design and creation. Of course there were things that could have been done differently or even better, but we were students making our first real game, pouring our hearts and souls into what we loved to do, and we were doing the best we knew how. All the times, good and bad, were spent driving towards the singular goal of making a game that we would be proud to show off.

Mission Accomplished.

Special Thanks

Our heartfelt thanks go out to all the Full Sail Course Directors and Lab Instructors (notably Bill Galbreath, Liam Hislop, Richard Wright, Lari Nori and Doug Howard), our modelers, Þröstur "Thor" Bragason and Mike Abrams, our families and friends, and Gamasutra.