Postmortem: Space Trading Game (C++)

This game was produced on a 12 week deadline in a team of four/five programmers (one late addition) in C++ using Emergent’s Gamebryo.

Click for Postmortem…

Overview

This is an extract from the notes given to industry guests attending and assessing the final presentation of our work:

The students have been allocated into programming teams (‘studios’), given a flaky brief (space-trading game) and provided with industry standard tools (Gamebryo, Subversion). The focus of the module has been to give the students a team industry experience preparing them for life during their placement.

They have experienced a number of typical studio problems including being given particular technology to integrate (Crazy Eddie’s GUI System), one ‘studio’ going out of business and they have recently pulled an ‘all-nighter’ to prepare their game for E3 – it falls early this year :)

What went right

1. From the start we did not underestimate the difficulty of the task – this ‘constructive pessimism’ served us well in hitting milestones. We had regular meetings and insisted on full participation in the project from all team members (knowing from experience that this is a common problem with student projects).We used Assembla, an online project management system, to assign tasks, track bugs and maintain a wiki of useful information. We communicated well throughout the project. We kept in contact through meetings, email, phone and Assembla. We got into the habit of putting full comments on our Subversion commits which made it easy to track what was changing.
2. We wrote systems to be as generic as possible, which was useful in the final stages when we had to add a lot of content in a hurry because few code changes were needed. The basic architecture was a GameObject class with derived Ship and Planet classes. Other objects were composed with the Ships to represent their internals (i.e. engine, weapon bay, cargo hold and resources). This encapsulation was useful. For example, the CargoBay was re-used for the TradingPost class later on).We also wrote a scene graph manager to enable us to ‘warp’ to other galaxies. Each scene graph stored a pointer to its root node and an instance of the Ship and Planet Manager classes.
3. We completely abstracted the game input by implementing InputProvider classes with a common interface to convert input (e.g. from the Xbox360 controller) into a set of defined GameInputs – namely roll, pitch, yaw, throttle and stop. This helped us when we had to make radical changes to the gamepad input code later on, by confining the code that had to be changed to the InputFromGamepad class.It also allowed us to easily implement AI behaviours. Starting with simple wing levelling behaviour, a hierarchy of input providers was built to provide steering towards an object, throttle control, formation flying, and, ultimately, trader or pirate behaviour for NPC ships – all using only the basic GameInputs mentioned above.This AI behaviour was also used to provide a ‘fly-to-target’ autopilot feature for the player’s ship.This architecture would also make it easier to implement a networked play mode, and indeed to extend the AI framework with more advanced behaviours.
4. We decided early in the project to load in all our data via XML. Team member Jamie integrated TinyXML and wrote most of the loading/saving code. This proved to be a very good decision as it gave us complete flexibility to change the design and content of the six solar-systems, from how many ships there were and what they looked like, to the speed at which planets orbited the sun, without any code changes. It also allows player customisation and gives scope for a level design tool.
5. We used FMOD to add music, sound effects and voice cues late in development. It proved powerful and very easy to work with. By using sound to provide feedback we were able to avoid a lot of GUI programming as well as create a more immersive experience. FMOD provided all the sound channels we needed and more, as well as the ability to change frequency and volume on specific channels (which we named using an enum), allowing the variable pitch engine noise and changing music depending on mode (battle/trade/normal).

What went wrong

1. At the beginning of the project we essentially wasted two or three weeks getting to grips with Gamebryo, mainly due to our attempts to extend the engine’s classes for our own game objects. It was not until we abandoned this idea and built our game engine separately (with handles into the graphics engine instead of being part of it) that we made any progress.
2. We should have spent more time reading the Gamebryo documentation. In particular we did not really get to grips with the memory management system until near the end of the project and we struggled with when to use smart pointers.
3. We probably suffered from a lack of design and overall vision initially – being programmers we tended to put programming first (especially as we knew we were not being assessed on our art or design skills). However, at the alpha presentation we felt that our game did not have the necessary wow factor (although arguably the most solidly built). Between the alpha and final builds we spent all our time on visual and gameplay polishing.
4. It was always an ambitious project, and our desire to do it well and produce a great game unfortunately led to us not spending enough time on some of our other coursework, and left no time for personal projects.
5. In the early stages we did not spend enough time working in a group environment, tending instead to code as and when we could. As time went on this improved and we found it very helpful to be working in the same physical location at the same time.

My Contributions

• Management
  • Conducting meetings
  • Keeping documentation
  • Maintaining project schedule
• C++ code
  • Scene graph manager
  • Game object managers
  • Input / AI / Autopilot / Targeting
  • Gameplay tweaking
  • Engine sounds, music, ship voice

Conclusion

We all learned a lot from the project about working in a team environment, and about debugging!

Development Videos

Lead programmer Bret has some videos of the game at various stages during the all nighter:

Alpha Build
Alpha Build Second Video
Development Video 3

Links

Assembla – Free project hosting
Crazy Eddie’s GUI System
Emergent’s Gamebryo
FMOD – Music and Sound Effects System
University of Derby