Game concept: How and why did your game concept change from initial concept to what you implemented?

Initially, we wanted our game to be a racing game, but we did not want to create huge maps to race through, so we changed it to capture the flag. We also wanted the robot forms to be useful, so we abandoned a strictly racing game since the cars would have such a huge advantage. Otherwise, the game remained for the most part faithful to our original concept designed during the first and second weeks.

Design: How and why does your final project design compare to the initial design?

We ended up not implementing several features that we wanted to have that we did not have time to implement. For example, we did not have time to implement terrain, although in retrospect, perhaps a height map would not have been too difficult to implement. We also wished to have other terrain features besides buildings and roads, such as trees, rocks, streetlights, and other objects. We wanted to implement explosions and explosive weapons, but it seemed our design did not allow easy implementation of this besides hard-coding the explosion attributes. There are also several small touches to the game that we did not get to implement. We wanted to implement weapon pick-up rather than just giving the player all the weapons at the beginning. We wanted to have three-dimensional, rotating models of the transformers at the selection screen. We also wanted to implement special abilities that were different for each transformer. We never got to implement a capturing end goal (where the game ends after capturing a certain number of matrices), although this would be easy to implement. We wanted to implement different game modes as well, but I guess that will have to go into version 2. Most of the items under "Would Be Really Nice", such as car spin-outs and improved collision detection, instant replay, a game introduction, a story line, and messaging/trash talking over the network were never implemented. Finally, we never got a radar working on the user interface.

However, we did implement different weapons that we originally had not planned in our design document. We implemented shadows as well. Otherwise, there were no other things that we did implement that we had not planned.

We blame system integration and our shoddy coding skills for this change of specification. Our system integration took us three to four weeks to finish, and this pushed all of our features back. We never really recovered time-line-wise from this.

Schedule: How and why did your final schedule compare with your projected schedule? You should be able to glean this from your status reports.

Again, system integration took up much more time than we originally anticipated. This forced us to push back most of our feature implementations, especially on the "Would Be Really Nice List", since our modules were not fully integrated until seventh week. Also, the fact that the Los Angeles Lakers, formerly from Minneapolis, swept many teams, such as the Sacramento Kings, completely demoralized some group members, while boosting the morale of one other.

We also realized that there was no alpha, beta, or gamma (if that even exists) testing. Spec freeze happened 2:55 on Friday, June 8. We were quite surprised that the server did not crash during the presentation since it underwent a scrutinous five minutes of testing beforehand.

 

What software methodology and group mechanics decisions worked out well, and which ones didn't? Why?

We believe paired programming is not such a bad idea after all. We had several stupid mistakes, such as indexing an element past the size of a vector, in our code that could have been more easily caught if we had programming pairs. Also, our code would have been less obscure and more easily understood by other group members, and thus easier to debug, if we had other people watching and understanding what individual members were coding. If we were to take this course again next year, we would assign teams to each module and make sure both (or all) members of the team were intimate with the intricacies and hacks of the code.

We attempted code review a couple of times, but this proved to be useless. The programmer has full knowledge of the logic of his code, while the observer has no idea. What seems obvious to the programmer, the assumptions that he takes for granted and merely skips over during the explanation, is not obvious at all to the observer(s).

We found the commit logs and CVS (but not WinCVS) to be quite helpful. It allowed us to keep track on the progress of our game and see what had been implemented recently, provided the messages were descriptive. It also allowed us to backtrack our code when we accidentally checked in an unstable code base.

What aspects of the implementation were more difficult than you expected, and which were easier? Why?

Again, system integration proved to be much more difficult than we expected. Please warn future students that system integration takes longer than a week (throw out a statistic that groups took on average 3.621 weeks to integrate their modules). Bug testing (as always) proved to be quite difficult as there were several obscure bugs that we encountered, that we still to this day could not resolve. Instead, we programmed around them.

In terms of individual modules, we found that full-screen implementation was more difficult than expected. Originally, we thought we could just flip a switch to activate this, but instead, we had to destroy all of the graphics devices and rebuild them using Direct3D.

Collision detection also proved to be more difficult than expected. Initially, collision detection seemed like a daunting task in and of itself, but even after we implemented basic collision detection, we encountered problem after problem after we implemented different features. For example, our bullets sometimes moved too fast and would go through cars and buildings without registering a collision. Still today, if cars move too fast, they will move through each other and through the corners of buildings (arguably a feature, since a car would demolish the corner of a building).

In implementing your project, you relied upon a number of tools from the DirectX libraries to modeling software. Do you see the opportunity and need for new libraries and/or tools that would make project development easier?

Project development was considerably easier with 3D Studio Max and the Quake 2 modeler (probably only for our group). Milkshape also helped us make textures and our objects. Adobe Photoshop also eased texture creation. Of course, using separately built collision detection libraries would have made implementing good collision detection easier. We also wanted to make our own sounds, so sound-generation and editing software such as CoolEdit Pro or SoundForge would have been useful. Texture generation software, such as DarkTree, would have been nice although not completely necessary.

Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?

We would stick to technologies that we know, such as OpenGL instead of Direct3D. We spent a considerable amount of time learning Direct3D instead of actually implementing features, and in the end, only two group members ended up having any knowledge of Direct3D, instead of five with familiarity with OpenGL. We would have done paired programming by separating the critical modules (graphics, networking, engine) into groups of at least two. Also, since the lab was not up at the beginning of the quarter, we should have moved our computers to one central location and all programmed from there instead of just relying on one computer. We should have provided ourselves with a good, productive working environment. We also found that our communication was not as good as it could have been when we were encountering problems. There were some problems that some group members encountered that could have easily been solved by other group members if they knew, such as gravity and the hack that we used to implement it. We would have found a way to rip out individual modules and test them with oracles to find out if they were functioning correctly, and we would have created some sort of mechanism to trace the execution of the program through some sort of prompt so we would not have to trace execution through the debugger. We wanted the debug process to mimic the execution process as closely as possible, and having to stop everything in order to use the Visual C++ debugger made debugging more difficult. We would completely separate server and client code as well so that there would be no intersection between the two except for a single interface. This would have cut down on compilation time. We would enforce a specification freeze a little earlier than we did so that our code would have been in a stable and consistent state on the day of the presentation. Finally, and most importantly, we would have devoted more time to integration and would have begun it earlier.

However, we would gladly use other people’s code, artwork, and sounds to shorten our development time. Also, our design process and object hierarchy was good, and we would use that framework again if we constructed another game. Also, we would continue to mark up the CVS repository at stable states, except that we would do it more frequently. The log idea that the professor suggested was also a good idea that greatly aided us in debugging. Everything else would be different because most of this was a first-time experience for all of us.

What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?

Real Time Rendering by Moller, C++ reference books (Stroustrup), 24 Hour guide to DirectX7, and Code Complete by McConnell (better than Writing Solid Code) were all helpful books not on the recommended list. COM book was pretty much useless, but any free books are appreciated.

I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? I will collect your answers and place them in the course web pages for next year.

Read this. Try completing a game before this class for experience or even think about parts of the game. Maybe read Game Architecture and Design first.

How can the course be improved for next year (beyond getting better hardware, etc.)?

Getting sound cards in the lab and maybe a fridge to store food and drinks. Everything was pretty much fine.