     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Beam Runner Hyper Cross What Went Wrong1. Tight Schedule, Zero Budget. Since we knew that a tight schedule and zero budget were factors from the start, it might not be fair to consider them as "what went wrong". Nevertheless, they certainly are non-ideal game production constraints, and they made our work difficult. We're graduate students. Everyone on the team had a full class load of project-laden computer science courses, a twenty-hour-a-week teaching or research assistantship, and other activities such as dissertation research and paper publications. But we're not whining — we love what we do. The bottom line is that stress ran high, and tempers wore thin. Without the teamwork, communication, and organization that we had from the beginning, everything would have collapsed. Team Whoopass could have also been called Team Lowcash. We had zero cash with which to work. We all have a small income from our assistantships, but that pays for rent, meals, and if we're lucky, beer. Fortunately, we had access to university resources: PCs, C++ compilers, and a copy of 3DS MAX. The biggest thing that suffered was our content creation. We had five programmers, and while one of us is also a great artist, he had limited 3D modeling experience. We didn't have the resources (money- or time-wise) to hire artists, so we settled for "programmer art". Our sound effects were heavily edited sounds that someone from our team created with his mouth. (Explosions, for example, are just heavily modulated versions of him saying "Kaboom Kaboom!"). We like to think that partially because of these limitations, BHX is a unique and entertaining game. 2. Conflicting Goals. We already talked about how important realistic goals were to our project, but didn't mention that conflicting goals can easily turn excitement into frustration. Unfortunately, we did not have a mix of programmers, with specialists in sound, A.I., artwork, game play, and 3D graphics like most companies do. All five members of Team Whoopass are graduate students studying computer graphics, and therefore we all wanted to work on graphics programming. The first conflict came early in the design process: we did not agree on what type of game to make. Each team member envisioned a different type of game, and initially there was very little compromise. We finally settled on BHX after much deliberation and design tweaking to match people's interests.
Each member wanted to gain experience in computer graphics, and we butted heads trying to decide who would work on what portion of BHX and HyperX. Multiple people wanted to work on the core rendering engine and the scene graph. This was not entirely possible because we were already stretched thin on programmers. In the end, each person had to sacrifice some desires and work together as a team to accomplish the project. We sometimes used extreme programming to allow multiple people to work on portions of the project, with excellent results. A little sacrifice and a lot of collaboration made everyone happy in the end. 3.Content Creation Time/Skills. A well-designed game does not necessarily equate to a fun or visually appealing game. With the time constraints placed on our group and our ambitious goals for five individuals to create a working, well structured game in four months, visual appeal was forced to take a far lower priority. The infrastructure for the game was clean and well thought through. The code and its organization were also developed cleanly. However, much of the final art content for the game became a last minute shotgun run. Of the five members of Team Whoopass, we had five strong programmers, only one of whom had any notable art skill. This was clearly a problem. One of the team members has substantial 2D art talent, especially in comic-style illustration and graphic design. Two others have a little 2D artistic experience, but we had little time or understanding on how to adapt these simple artistic experiences to the expansive demands of a truly rich 3D game. Each of us had some familiarity with many of the common modeling programs available, such as Maya and 3D studio Max, but aside from squashing and deforming spheres into abstract spaceship-style shapes, our modeling experience was minimal. To our credit, we exhausted the paltry artistic resources the five of us brought to the table in the final product of BHX, but the game clearly could have used the touch of a professional modeler, artist, and content creator. 4. On The Fly Game Design. Before we began working on the project, the group met and worked out a general design of the game. After this was nailed down, and we knew that we would have beams, ships, shooting, racing, etc, there was still a lot of detail that was left unspecified. Without a complete vision for the game, decisions about game design were made months into the project by the individuals programming those parts of the game, or by the whole group whenever we had a chance to meet. This was especially apparent in the game play, which continued to evolve right up to the last 24 hours before the project was submitted. Some aspects of game play, such as ammunition power ups, were added to the game late in the project. Other elements that we had planned to include from the beginning, such as jumping between beams, were scrapped because of lack of time. In terms of the educational goals of the project, this ad hock game design did not pose much of a problem. But, in terms of producing the best possible game in the time available, a clear set of guidelines early in the development process would have allowed us to use our time only on the features that mattered. 5. Last minute hacking. Humans procrastinate. If you run into someone who doesn't, be afraid, because they're likely a robot or an alien. The electronic game industry is well known for Crunch Time. We planned from the very beginning to beat the system. The academic semester workload always skyrockets at the end, and we decided to front load this project to avoid that condition. We failed…or did we? We did have the bare bones of our project up and running 1/3rd of the way through the project. However, the last few weeks were significantly busier. Audio was plugged in at the last moment (at the expense of a game-play feature of jumping from beam to beam). The very last night we were a long way from having a good demo. Memory problems had crept into the system, causing floating bugs. Each time we tracked down one bug's location, we would find it to be only a phantom bug, being caused by memory leaks from somewhere else. We locked the code and data (because changing those can cause a memory leak symptom to move as well), and worked on it all night, and managed to fix the final problems only minutes before the class presentation. Somehow, we did manage to sneak in a few final features that night. To help avoid the problems we had we should have been a little more careful earlier on. Specifically, more code checking should have been included to reduce the time spent debugging. Assertion statements, redundant pointer validity checking, bounds checking, reasonable data range checking, and not assuming that a function will return the right value are all encouraged. Trust no one, as it were. We failed in avoiding a last minute crunch, even though we worked hard to do most of the work early in the project. However, the crunch time was small with respect to other teams, and of course real world teams. If we had not prepared, things could have likely been much worse. In the end, many agreed that ours was the best demo in the class.
______________________________________________________  [Back
to] Introduction |
|||||||||||||||||||||||||||||||||||||||||
Education
|
|
