Gravity Games

I originally started working on the first Aftermath for two reasons: to create an updated version of Star Control 2, and to help me get into the games industry. On the first front I didn’t fully succeed, as I never finished the game.  However, my project did help me break into the industry (nothing demonstrates your skills better than a playable demo), so on that front it was a smashing success.

Several years passed before I found myself in a position to continue work on Aftermath, but when I started looking at the code I realized that the project was no longer feasible.  First, the code no longer met my standards, as I had learned a lot through my professional work.  Second, and more importantly, the game’s scope was far too large for me to complete, even with the amazing content work by ThatSteveGuy and others.  The game was simply too ambitious.  I felt it was time to start over again, and the best way to do that is to evaluate what went right and wrong on Aftermath.

What Went Right

1. Data Driven Design. A data driven game defines a strong separation between code (the engine) and content (art, sound, etc…)  Creating your project this way can increase development time in the short term (creating tools, file formats, etc…), but can payoff in the long run by reducing costly code changes late in the project.  For an indie game there is an additional bonus: moddability.   Moddability isn’t really a word, but it should be.  A properly data driven game allows other people (fans hopefully) to modify and create new content for your game.  In the case of Aftermath, ThatSteveGuy (I never learned his real name) created a huge number of additional ship and weapon designs (art, sound, gameplay templates) that added a tremendous amount to the game.

2. Move to 3D. The improvements in graphical quality (dynamic lighting and perspective) outweighed the increased content requirements.  It also game me invaluable 3D programming experience.  2D isn’t dead (indie games, handhelds, and mobiles), but professional console development generally requires good 3D programming skills.

3. Retain Core Gameplay. The enhanced melee combat using a variety of wacky ships is probably the best part about Aftermath.  The combat didn’t require a new storyline or original design work, and was a better fit for a solo programmer.

What Went Wrong

1. Gameplay Scope Was Too Large. The exploration, mining, ship outfitting, and empire management additions to the game, while interesting, ended up being far too much for me to bring to a decent quality level.  The final, polish stages of a project, if done correctly, can be the most time consuming, and all of the extra features put finalization out of my reach.

2. Platform Dependent Code. Aftermath is a DirectX based game.  Why?  Because I had already worked with OpenGL and wanted to explore DirectX to round out my programming experience.  It was a good decision from a “break into the industry” point of view, but I don’t think it’s the best decision for an open source indie game because it limits your potential install base.  The most flexible solution is to create a wrapper around the API that lets you use any library, but that would be overkill for a project as small as Aftermath Wars.  Finally, if you are a new developer trying to get into the console industry it can’t hurt to learn both.

3. Tried to Reinvent the Wheel. Because Aftermath was in large part a learning experience I tried to create as many systems from scratch as I could.  This led to some pretty crappy systems (like physics) that only barely met my gameplay requirements and ended up costing me a lot of time (both real life and per frame.)  This is a common problem in the professional world but for reasons other than a desire to gain experience.  A lot of programmers, even experienced ones, don’t like working with other people’s code.  It took me a couple of years on the job to become comfortable working in foreign waters, but it’s a skill every programmer should learn.  Sadly, some programmers never learn it and will spend months (or event years) on the job developing inferior versions of systems that already exist.

Based on the above I formed a few core guidelines to follow while developing Aftermath Wars:

• Expand on the data driven design: more content and game logic in data rather than code.  Provide the necessary tools to maintain / edit the data.
• Reduce the scope of the game and focus on core ship vs. ship combat.  Stress feature quality over quantity.
• Use existing libraries whenever possible (expect when learning a new programming area or if the existing libraries suck), as long as they aren’t Windows specific.  Leveraging existing libraries saves time (sanity) and increases quality (happy fans).

Soon I will begin to discuss some of the new and updated systems in Aftermath Wars. I hope to convey not only what the new systems are capable of, but also why I made certain decisions from a system design point of view.  Aftermath Wars is open source so feel free to follow along.

Welcome to The Gravity Well where I will be discussing various topics on game development (both general and specific to Aftermath Wars.)  I hope to use this space to pass on the things I’ve learned about game development.  Initially I will begin by covering the work I’ve done so far on my personal project: Aftermath Wars.  AW is space shooter in the style of Star Control 2’s melee combat, and is the successor to a similar project (Aftermath) that I worked on years ago.