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

The game concept stayed nearly the same as the initial concept. We started out desiring to make a 3D rendered version of Space Wars / Star Control Hypermelee that had the additions of being networked and having a variety of gameplay modes rather than just straight-out battle royal. The final version of the game was different in that we did not have time to implement any gameplay modes other than just battle mode and it also differed as we decided to add AI ships to the game.

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

The final design showed a marked change from our initial design. Initially everything was very general, object oriented, and was an attempt to provide the most functionality possible. While a good portion of the code used in the final build did rely on this preliminary design work, the code produced later in the quarter followed a design philosophy of getting the specific task at hand done and not worrying about anything else. In this way, our code ended up being an interesting mix of well-planned objects and spaghetti code that manages to do most of what we sought out to do.

Schedule: How and why did your final schedule compare with your projected schedule?

Our schedule showed some marked differences between the schedule made at the beginning of the quarter and what we ended up getting accomplished. The difference can be explained by either a lack of time, more interconnectedness of code than we expected, or by bugs breaking parts of code that were previously working. Gameplay ship code had to be reworked a couple of times so that it would work with the changes in networking. Some of the latter additions of asteroids, dark matter, and mines were delayed due to time constraints, but were added eventually. The networking code was delayed due to unexpected issues in jittering and skipping on the client side that needed to be resolved. In addition, some objects that were registered with the networking code improperly were causing crashes and confusing the issue of which code had bugs in it. The input portion of our code was the best behaved as it was completed within the first three weeks and included keyboard, mouse, joystick, and game pad control. Sound proceeded as expected throughout the quarter, but was brought to a near halt when in the last couple of days when it began crashing in dsutil after a few minutes of gameplay. The cause of this is still unknown, although we suspect memory is being overwritten or freed inappropriately. Due to this, effects sounds were disabled for the demo, but background music still worked as advertised. Finally, the graphics held mainly to the schedule with the exception of meshes, which were only added 10th week, and the dropping of any 'hopeful' code we hoped to get a chance to implement.

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

The fact that we broke up the features into modular pieces in the first couple of weeks (graphics, sound, networking, ship classes/input) made it easier for the group to start coding right away. As we would find out later on, (and as we were amply warned) the true challenge was making everyone's individual code work together. One thing that worked well was this parallel development, particularly because each “feature group” had some idea of what else their code would have to work with, but we did not define rigid interfaces between modules before we started.

The downside is that this could also be seen as a weakness, because this system requires the developers to take initiative and contact the people whose code they need to interface with. One example is when the drone ships were created, they should have extended the existing ship class, but instead, most of the functionality was duplicated in the drone ship classes. This was a problem later when features needed to be added to all ships, it had to be done in multiple places. Eventually, it was so bad that the drone ships had to be rewritten to subclass the ship class. This could have been avoided with more communication between the involved group members.

Also, while having the code be very modular was helpful in many ways, it also led us to in some cases write too much flexibility into them. While this is usually a very good thing, it meant we were spending more time writing general purpose engine code than actual gameplay code. However, it also made it possible for us to basically drop the gameplay in within 3-4 days.

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

Because we were all using James' framework which he had been developing on his own, the group was basically handed a program that was loading the starfield, drawing objects, and handling input. In addition, the groundwork was laid for many other features to just be “dropped in.” So the the task of actually getting our program to work in Windows and handle input, was much easier than we expected.

One thing that was more difficult than expected was the networking. While it worked more or less reliably, it wasn't contained in a good abstraction, and it often proved very time-consuming to integrate other modules with it and add synchronization to new game objects and features. In retrospect, the networking and game objects should have been written using a message/mediator design.

In general, code integration was more difficult than expected.

Tools: Do you see the opportunity and need for new libraries and/or tools that would make project development easier?

One minor tools problem was the time it took to get all the bugs worked out in VS.NET for the lab computers (i.e. Not being able to debug programs or access project properties). Also, some team members were not able to get a stable version of VS.NET running at home until 4th or 5th week. This did take a substantial chunk out of our total development time.

The tools most useful to us were: 3D Studio Max, Adobe Photoshop, Right Hemisphere's Deep Exploration, and Truespace 4. Deep Exploration in particular proved invaluable for converting and preparing our models.

As far as code libraries go, we stuck with code DirectX functionality and didn't use any third party libraries.

In Retrospect: How would you do things differently, and what would you do again in the same situation?

All of us learned a great deal about object-oriented design over the course of the class, and there are many ways in which our design could have been better. Most notably, there was a far too much coupling between modules. Almost every module had to "know about" many other modules, such that if the usage of one module changed a great deal of code was affected. Facade classes would have helped here.

Another thing that would have helped would be to have more coding sessions together in the lab as a team. In our last few days before the demo, the majority of our group was in the lab working together, and this greatly improved communication while we were coding just by decreasing latency in response time and increasing the ability to clearly explain what our problems were.

Courses: Which courses at UCSD do you think best prepared you for CSE 190?

The material that was covered in CSE120 was useful in dealing with concurrency issues from DirectPlay. Also CSE100 gives the experience of working on challenging programming projects in teams. However, there is no undergraduate course that currently has a large group of students work on a challenging program project, and that was one thing that our group had to get used to throughout the quarter.

CSE 167 and MAE 293 were both relevant courses that offered computer graphics concepts and techniques that were applied directly into the game. Essential and fundamental issues such as alpha blending, texture mapping, animation are all topics that were covered in these courses. In addition, the seminar course CSE 191 (lectured by Steven Rotenberg), which was offered in the same quarter, provided a great resource and opportunity to immediately implement lecture material into the game. CSE 191 was the ideal complement to this course.

Lessons: What was the most important thing that you learned in the class?

We learned was how to work effectively in a large group. The key is breaking the project into pieces that can be developed in parallel (which we did) and meeting frequently as a group to discuss in detail the progress and what we were expecting in other components (which we didn't do enough of).

We also learned the importance of compromise over the course of development. When integrating, everyone's code had to fit together, and oftentimes one person had to alter their code interfaces to accomodate the work of someone else. This often was a frustrating experience, but as time went on we began to take it for granted.

Along those lines, we also learned (the hard way) the importance of planning for future hangups and design changes, and generally the importance of robust, defensive programming.

Most importantly, we all acquired a better sense of the problems, as well as the advantages, of working in a team to develop a complex software system. As our game was so modular, the class greatly helped all of us understand firsthand the motivations behind OOP and develop our design intuition.

Good Books: What books did you find helpful that were not on the recommended list but should be?

While many of us knew about it from taking CSE191, Real-Time Rendering by Moller and Haines is a great, great graphics programming book. Also, Code Complete from MS Press is a great introduction to good programming style and practice.

Almost every Charles River Media release is worth recommending.

Bad Books: What books were on the recommended list but were not useful and should be removed?

The LaMothe book was helpful for its sample code (it looked like most groups commandeered the particle system from the CD-ROM), but not quite as helpful in its content (a feature of all LaMothe books). Still, it should remain on the recommended list as it seems to be the best beginner DirectX book at the moment. As soon as something better comes out, this book should be removed in favor of it.

What advice/tips/suggestions would you give students who will take the course next year?

Spend as much time as possible planning and designing before coding. Make contingency plans. Keep the entire group involved at every point in development. Work in the lab, together, more than at home. Set long, weekly coding sessions where all will be present. Drop all of your other classes, right now.

How can the course be improved for next year?

Make ACS get off their collective butt and fix the lab! Argghh! Threaten them with bodily harm! What's it take, huh??

Other than that, it could not have been a better experience, and we're all greatful for it. Tim was an outstanding TA - make him do it again.

Actually, we could have used some more free software....

X-Box: Was it a distraction?

Nope! Actually, I don't think anyone in our group really played it, although we did see others playing (this may be because Peter and Marshall have their own, hooked up to large, high quality television sets).