Usually, we would have class presentations where a post-mortem would be presented as part of the learning experience but, instead we had something different. This time, our final presentations were given before two games industry professionals and members of the college’s I.T. department. A post-mortem in this venue would be inappropriate. That is why I am content to place it here for educational purposes.
Please bear in mind that these are college students in a learning environment and are not subject to the same conditions as a developer would if they worked in a commercial setting (like the fear of getting fired if you screw up or having more than six weeks to create a game using technology that you have never used before). Also, none of us ever worked in any kind of professional development environment as programmers.
Tuition isn’t cheap and we all had a simple motivation to succeed on this project to make a game that may not have been revolutionary but, could improve our probability of getting employed somewhere.
FireLine is about facing an enemy that doesn’t think or feel. The enemy isn’t subjectively targeting you. Instead the enemy is a force of nature. The object of FireLine is to halt the wildfire’s advance before the entire forest is consumed by deploying Firefighters by ground and Smokejumpers by plane. If the fire consumes 90% of the forest’s trees and shrubs (fuel), you will lose the game. If you extinguish the advancing wildfire completely before 90% of the forest (fuel) is consumed, you will be victorious!
It was suggested that if we could make a game that would cause an XBox 360 console to self-immolate we would automatically pass the course.
We had t-shirts made for both of our class development teams.
What went right?
We (all six of us) made a game for the XBox in about six weeks using technology that we had not used before. Some of us had used different versions of XNA Game Studio before and only one of us had experience using Blender, which our graphics programmer insisted on using instead of Maya. After some unsuccessful attempts to program audio in XNA, our audio programmer took a book I found (“XNA Game Studio 4.0 Programming Developing for Windows Phone and Xbox Live” by Tom Miller and Dean Johnson) and learned how to use the XACT tool for XNA Game Studio.
The graphic art and textures turned out great. I asked for multiple variations and versions for the art required and then everybody got a chance to cast a vote for the logos, menu design, user interface art, icon design and graphic art used. The music and sound turned out great as well.
As with the art, I asked for multiple iterations of sounds, music, and composites. Instead of our group deciding the sounds, this time I sat down with our composer/sound designer/audio programmer (he’s only one guy) and made the decisions on which sounds would best convey the overall feeling of the game’s atmosphere. Choosing sounds the are unquestionably distinguishable as rock slides, fire crackling, blowing wind, aircraft flyovers and explosions were central to the selection. We were fortunate that all of the original music was usable and we set up the XACT wavetable to cycle through the different music loops randomly. Almost everyone has said that the music gets stuck inside their heads.
After several setbacks our graphics programmer delivered beautiful particle-based fire effects that didn’t crash every platform we put it on. They are beautiful and somewhat realistic.
Our user interface integrated fairly smoothly into the project along with individual instructions and controls menus for PC and XBox 360.
When it came down to finally integrating the 3D graphics into our project at week five of six, we hit a massive bug. For some reason, the terrain graphics for the rocks were not rendering on screen but, the preview suggested that they were there. Our audio, graphics and two main programmers (including myself) pulled together and spent the better part of a week trying to find and fix the problem. The contingency plan accepted by the a majority of group members was that if we couldn’t find the problem by the middle of week six, we would replace the rocks with 2D textures. Our audio programmer, who has professional testing experience, found something that indirectly pointed toward the problem. Our graphics programmer went and found the problem. Apparently, our rocks graphics were rendering underneath our game environment.
Despite having to remove about 40% of the intended content as covered in the original game proposal and in the early draft of the development documentation, we successfully created a 3D game using XNA Game Studio 4.0 for the PC and XBox with six weeks of coding time and two weeks of testing. We also avoided causing the XBoxes to explode into flames.
For some reason, something happened during upload and messed up the “Complete” screen. Here is a screen capture of it:
When you win the game, this is what it looks like.
What went wrong?
FireLine is missing graphics assets for aircraft and ground units. Instead of having CGI animations for the group units, we have a group of three unanimated models represent the firefighters that creep along across the gamespace toward a target. Our 3D graphics programmer was overly perfectionistic and spent about four weeks of our six week development schedule perfecting our tree models and animating their gradual destruction by fire despite being told that he needed to move on to creating the fire animation, air and ground unit animations, rocks, water, grass and headquarters graphics. He became preoccupied with trying to produce top level graphics with absolutely no time to do it in. While the grass and rocks and headquarters models along with the water animations and the aforementioned trees and crude ground units were eventually delivered, the fire presented a serious problem.
Then, he went and spent the weekend jet skiing instead of coding.
Once the first graphics were ready to be delivered, our graphics programmer was unable to do so because he did not upload the assets to DropBox like everyone else on the team did. Instead, he wanted to connect directly to his home computer, that was a two hour commute from campus. As it turned out, his computer was turned off and he could directly connect with it. At that point several of us wanted to directly connect our fists to his face. But, I digress.
One week of testing was lost because of the new particle-based flames that crashed everyone’s computer during our testing phase because the particles had no population limit or life span and simply kept being generated until all available memory was consumed. When asked about whether or not the graphics programmer and lead programmer tested the graphics before we handed off the game for testing, the resounding answer from both individuals was evasive at best. It took one week to fix the problem which should not have been integrated into the project to begin with without preliminary testing.
Of course the question should be asked, “were was the project manager in all of this?” Answer: I was in the parking lot walking to the classroom. At first I was thrilled that they were taking initiative to get things in order before class started so we could have as much time as possible to find all of the bugs and get in some solid development time but, as the computers began to crash all around us, my hopes were dashed.
The particle-based fire animation was not the first misstep but, was (thankfully) our last mix-up in a series of mistakes that first began at the top of the second week of our development cycle.
At our very first meeting, we talked about our backgrounds and sought to play to our strengths as developers. The person who would eventually become our lead programmer would have simply been an ordinary programmer if he had not assured us that he knew how to program the tiled gamespace and randomize the tiles to create unique game experiences for nearly instance. He also used language that suggested that he had attempted making an real-time strategy game before. We would eventually discover that neither of these things were true. We liked what we heard though, I made him lead programmer and we agreed that he should begin work on a “Hello World” project and then move onto making a simple 2D gameboard with tiles that could be randomized while I began to adapt my game proposal into a design document. Before we went home for the weekend, I check on the lead programmer’s progress and told him to e-mail me over the weekend if he finished before the weekend was up and needed to know where to go from there.
The next week, we came back to class to hear that our lead programmer had decided to surprise us and “finished the game over the weekend.” Once seeing the code in it’s rough unfinished state with no comments or documentation and with several of its main functions missing, we realized that the game wasn’t even close to being “finished.” He had rejected the development document almost entirely.
It was two weeks down on the development cycle, four more weeks to go before two weeks of testing.
In my daily rounds of talking to my team members to mark their progress, our audio programmer and artist asked me how the project was going. I tried my best to re-assure them that we were going forward as best as we could and then our audio programmer said the word that had been running through my head continually for the past week, “triage.” Yeah, it was all triage at that point. There was no more time left in our development cycle so we opted to try fixing the code we were left with. I sat down and reworked the design document, removing two-thirds of the content and cutting back the game’s functionality by about 40% in order to ensure that we could deliver something that would be considered a success.
We were now stuck at week three with a partial game in it’s early stages that had rejected it’s principle game dynamic. Instead of having tiles with several environmental properties (originally two or four), the each tile represented a single individual property. As a result, each game would only last about two to three minutes long, success or failure could be predicted fairly easily by the player in the minute of game play.
As it turned out, our lead programmer would spend nearly two weeks on pathfinding algorithms, rejecting help and advice from his fellow team members, ignoring our instructor’s suggestions for help. In doing this he rejected my thirteen months of research into sprites and crowd flow pathfinding that worked in favor of a brand new solution that took two weeks to develop that restricted flow of movement and caused more memory problems that we would have preferred.
We tried our best as a group to figure out his code with and without his help but, to no avail. After week four, with still no documentation or heading blocks detailing his work, we realized that the more that we asked him for his help in understanding his code the less we understood it and the less time he had to get it to work right. So we let him alone.
The use of the mouse to select and control units on screen was rejected entirely because our lead programmer told us that they would be too complicated to get working. Reminding him that there was more than one person on the team who could program changed very little.
Other aspects of the game were hampered by his obsession with prime numbers: instead of using numeric values that would be of pertinence to the game itself, he used numbers that had no logical correlation at all. The result was a gamespace that was often too small in one direction or too large in another.
We also had communications issues. Yeah, I know, big surprise. The lead programmer refused to answer our e-mails. His code was written incomprehensibly. He named constants with variable names like, “ARBITRARY_SIZE.” “Arbitrary” is a synonym of “variable”. Just because the person is planning on changing the values of the constant throughout the course of development (which is a given) does not mean that you give your constants variable names, rejecting object-oriented programming standards. This was not just a one-time concurrence, this was found in different places throughout the program.
During our second and final week of testing we found out that our lead programmer had decided unilaterally to change FireLine’s final user interface to one previously unseen, change the font to an Asian-inspired font called “Jing Jing” that distracted from the game’s overall design more than it helped, and selected a menu screen splash image himself.
Visual art was very important on this project and originally we each had a say in what went into the game. By the time we saw these gawdy changes to the art, and in our exasperation wanted the game finished already.
Then came the final insult. We put a lot of effort into creating and integrating the menu, credits, controls (PC and XBox 360) and instructions screens. Our lead programmer failed to program a way for the player to access the screens. I guess the stress finally got to him and he began to blame people for his own short comings. He asked me rewrite the text of the instructions specifically because they were not of any help to the player. I retorted that the instructions were of no help to the player because the player never got to read them because they never were presented an opportunity to access them to start with.
This angered him like nobody’s business.
In all fairness, I’ve never read Tolstoy’s War and Peace. The instructions that I wrote are by no means a comparison to an acclaimed Russian novel but, let’s face facts here: if I have never read War and Peace should that be a reason to rewrite it? I don’t think so.
If given more time, what would we do differently?
I would restore the removed content: aerial water bombers would be implemented; smokejumpers would not detonate their explosives on landing instead, the player would choose when they could get to deploy their payload and possibly get more from supply drops; a wind current and thermal current system would blow planes and smokejumpers off target and move the fire in different directions; explosions would affect aerial units; make every tile have at least two (four at the most) different terrain/fuel properties to increase the complexity of the game.
I would also try implementing mouse controls for the PC version.
Conclusion
When someone says that they know how to do something on a project, insist that they show you reliable evidence upfront and take any opinions from people who have worked with him in the past (or their instructors) with caution and measured optimism. Have your programmers talk about what needs to be in the game on a programming level, before they decide to do the obligatory “Hello, World” program. When your lead programmer shows up and tells you that he has “finished the game over the weekend” despite having read only the game proposal and not the actual development document, sit them down and ask them to explain themselves. If they don’t talk to you, figure out what needs to go in the game yourself and send it to everyone on the team – especially if you are the project manager. One monomaniac with a much-lauded reputation as a game developer can turn out to be the bad apple that ruins your chance to make an interesting game. Self-taught graphics programmers don’t always know how to meet deadlines because they learned in an environment without deadlines or supervision. Perfectionism can lead to a serious loss of development time that could be better spent on another aspect of the game’s development. Know your limitations and don’t see asking for help from someone as a sign of weakness or defeat. Collaborating with other people creatively is a great way to mitigate tunnel vision and preserve a project’s creative vision but, only if all of the team members engender the project’s ultimate goal over their own egos. A development team is for developers. If you want to be a rock star join a band.
Data Box
FireLine
Development team: 6 developers
Budget: None. We were students. Our instructor ordered pizza for us once.
Conceived: Early 2010
Development time: 8 weeks
Total development time: approximately 15 months
The release date of the game: June 23, 2011
The platform: PC and Xbox 360
Hardware used: Hewlett Packard PC, running Windows 7, Nvidia graphics card
Software used: XNA Game Studio, XACT, Blender, GIMP, DropBox, Paint.Net
Size of the project: 30 files (separate files for Xbox 360 and PC versions), approximately 500 GB
