Postmortem: Rock Station
By Jonathan Stern, et al.
Mypos Games
GAM350 Winter 2004
Professor: Benjamin Ellinger
The main drive behind Rock Station was to develop a fun game that would be a wholly impressive accomplishment as a junior DigiPen project while maintaining a limited enough scope to feasibly see completion by the end of our junior year. From our point of view, the project needed not only to satisfy the requirements of employing sufficiently complex physics and artificial intelligence systems as well as 8-player networked play, but at the same time provide an exceptional gaming experience, from both a visual perspective as well as a gameplay one. Through hard work, dedication, and considerable reworking we were able to overcome various setbacks and present an extremely respectable final deliverable.
What Went Right
1. Well-Thought-Out Design. From the very beginning we had established that the key to making Rock Station a success was to come up with a design that will ultimately turn heads and wow the audience without becoming so ambitious that we would be unable to complete the project in the very limited time frame available. It is for this reason we settled on a tournament-style space dogfight simulation with a more arcade or console game feel. We limited the battles to take place among anywhere from two to eight combatants – with eight individual fighters to choose from – in a space environment to minimize the amount of content creation required. At the same time, we would employ the use of slick 3D graphics, a flashy particle system engine, and interesting physics and AI to make the gaming experience a memorable one. In this respect we were very successful.
2. Basic Engine Code Produced in Advance. This was a major contribution to our success with Rock Station. We began work on building the basic game engine during the summer months prior to our junior year, partly by adapting code we had written for our previous game or other applications. By the time the semester started, we already had a basic game engine capable of manipulating 3D objects through a world, processing input from the keyboard and mouse via DirectInput, sound and music playback via DirectSound and DirectShow, and rendering text and 2D objects, as well as more subtle or esoteric tasks such as properly maintaining stability across focus loss. As a result we were able to quickly develop more of the “meat” of the game, including actual game flow and game object code, the particle system engine, artificial intelligence, physics, and so on. By the end of our first semester we had a prototype that would be passable as an above-average junior year final project, which we would then refine and polish into a superior product.
3. Ample Time for Gameplay Tweaking. While in many respects simply developing a superior technical product would have been an impressive feat in its own right, Rock Station would still be a failure as a game if it were not fun to play. One of the major benefits of developing the game engine so quickly was that it allowed us much more time to tweak and balance gameplay. Countless hours have been spent determining what elements of the game system and what character statistics, weapons, and so forth to change in order to balance gameplay. We often found ourselves actually removing features in our original design that didn’t turn out to be as fun as we had originally thought. Ship shields were one such example; we had originally designed ships to have sectional shields that would be damaged and destroyed individually, but these were scrapped and replaced with a single shield for each ship when the original shields proved too hard to wear down. Weapon groups – selections of multiple weapons that were fired simultaneously with a click of the mouse button – were another example, one that underwent considerable reworking. Each ship had a number of weapon groups with predetermined weapons that were intended to be used in different situations, but after much playtesting it was determined that in the heat of fast-paced combat, these were generally too difficult to keep track of and players simply didn’t use them, so they were replaced with one default weapon group that players could optionally toggle weapons in and out of if so desired. Countless tweaks such as these really helped us refine the play of the game.
4. Stunning Visual Presentation. For a junior DigiPen project, Rock Station was visually quite impressive. This doesn’t mean simply that the graphics were superior – admittedly, our 2D and 3D assets were perhaps above average for a DigiPen project that relied solely on programmer art, and our particle system engine really contributed a lot to attaining a superior graphical appearance – rather, the entire overall presentation was very professional. A lot of little details and polish – “smoke and mirrors,” so to speak – really added to the visual experience to make Rock Station feel more like a real game and less like a simple technical demo. Rock Station was graced with a slick interface with an excellent and visually appealing menu system and in-game heads-up display, as well as smaller details like eye-catching transitions between game levels and screen fades and flashes when the player’s special meter fills up or a ship explodes. Little visual effects like these are often taken for granted when playing a professionally produced game, and sometimes overlooked, but they really enrich the gaming experience, and for that reason were very successful in Rock Station.
What Went Wrong
1. Inadequately Designed Game Flow. This was in area that proved to be an unfortunate setback during the development of Rock Station. Game flow is a crucial yet often underestimated part of game architecture, one that is not taught in any class at DigiPen (as of this writing) and one that of course must be individually tailored to any particular game. Originally the game flow had been designed so that any individual mode – story mode, fast action, the main menu, the tutorial, network play, and so on – would have its own set of update and render methods specific to the needs of that mode that could be easily “plugged into” the currently running game loop with the use of function pointers. While a good idea in theory, this proved problematic, particularly when we tried to integrate the in-game menu that would pop up during game play with a press of the escape key. After much headache and deliberation, we finally ended up scrapping and rewriting almost the entire game flow code. The result was a lot more workable, but in retrospect we really could have benefited from a much better initial design. A game mode stack might have been the ideal methodology for Rock Station – the current game mode would be pushed onto the stack; upon exit, it would pop off and return back to the previous state, and so on up the chain; we plan to look into this idea for use with our next game.
2. Code Bloat and the Perceived Necessity of Inextensible Code. This of course is a major issue for any project. Rock Station suffered from considerable code bloat as the game grew more and more complex. This wasn’t even a case of mere feature creep – there were simply too many features that were originally in our game design that we hadn’t adequately planned for in our technical design, though some amount of feature creep did contribute. Ship extras and special moves, for instance, proved to be too complex to be coded as really data-driven within a reasonable time frame, meaning that each special move had to be individually hard-coded into the game. The HUD, while extremely data-driven and object-oriented, was simply too tightly dependent on data in the currently running game, and too many special cases caused it to swell in size. The networking, the ship class, and numerous other game systems all suffered from some form of code bloat or another.
3. One-on-One Battles Never Really Were as Fun as We would have Liked. Rock Station had been originally designed with both single-player and multiplayer play in mind. Network play over the LAN in fact exceeded our expectations and turned out to be very smooth, particularly considering this was our networking coder’s first real experience with sockets and network play. Unfortunately, single-player play never got to be quite as fun as we wanted. Whether this was a result of gameplay balance, ship statistics such as speed and turning ratios, or simply a limitation of the nature of dogfights in open space was never really made clear.
4. Insufficient Resources to Meet Art Requirements. As minimally content-based as Rock Station was, the art constraints were nonetheless still taxing given that the art was produced entirely by programmers with other responsibilities. As art director, and chiefly responsible for art for the game, I was unable to produce all the required art assets for the game on top of my duties coding the HUD, network play, and general game flow. These art assets included character portraits and more importantly, ship models, which were crucial to the game. Unfortunately I have had next to no experience modeling 3D objects prior to working on this project and none of the discipline required to produce the numerous models required for a game project in a timely fashion that would come from the training amassed by a professional or student in the field. And it was often unclear how a given ship model or character was supposed to look. In the end, our project suffered due to the lack of my ability to produce sufficient, professional-quality art within the constraints of an otherwise busy schedule.
Conclusion
Though beset by various difficulties, Rock Station is still a phenomenal success. We accomplished exactly what we set out to do: develop a fun and impressive game that really shines as a DigiPen project within a sufficient limited, but not overly restrictive, scope over the course of our junior year. We not only met the technical requirements for a junior year project but exceeded all expectations in producing an exceptional game with a lot of polish. And above all, Rock Station provided an invaluable game development experience.