I’ve been working on a game project for almost two years now. Unfortunately it’s taken a lot longer than I had planned, but let’s be honest, how many side projects finish on time?
Since this has been my longest in-development project I’ve ever worked on, I’ve been able to see the phases of the project play out fairly clearly. I thought it might be a good idea to list the stages that Baron has gone (and will go) through as it is developed. If your’e making a game, take a look at this and see where your game fits. It may give you an idea of how far along you are, and what you have left to do.
* Initial idea – This is the “I want to make a game” stage. Here we decide don the initial genre of the game (platformer, 4 player coop), platform (xbox 360), and the type of technology we’d need to develop. First was the need for a platforming engine that could handle tile-based collision without snagging, next was a good tile map authoring tool. At the time, FRB had a program called TileEditor, and that’s what we decided to use.
* Creating a prototype…or trying – We quickly found how lacking the FRB Technology was for platformers at the time. We started working on that instead of the prototype.
* Design change – Eventually we saw how bad XBox Indie Games sold, so we changed our minds and came up with a whole new game – a tower defense-like game. Not only that but we changed our platform from the XBox to phones.
* New prototype – We started a new prototype, this time using technology that we already had, and things moved very quickly. This pushed us through a lot of questions like what is our resolution, what’s our camera, what kind of basic controls do we need.
* Mockups mockups mockups! – Once we had our initial idea and game working, it was time to see how it all fit together on the screen. This also helped us realize what was visually necessary and what wasn’t.
* High level numbers – If the kind of features define half of the scope of your game, then determining high-level numbers determine the other half. This is where we asked things like: How long should the game take to beat? How many enemies should there be in the game? How many levels? How long does each level take? What kind of side-objectives does the player have?
* Fleshing out details – For Baron this meant deciding on the abilities that the characters have, balancing it on a spreadsheet, and a lot o back-and-forth between design and programming to find a good mix of fast implementation and game variety/quality.
* Large game-specific systems – This is one of the bigger development phases where we implemented systems decided in the last phase. For Baron this meant the ability system that could be defined in a spreadsheet, scripting system for the designer to control the levels, profile/unlocks, and any other system necessary to enable non-programmers to add and modify game content. In a way this phase never ends until the game ships.
* Tutorials – Writing tutorials for your game is something that many developers don’t consider until they’re in the middle of the game, but for many games (including Baron) this is the “tipping point”. The tutorial did two big things for Baron. First, it made us realize all of the missing functionality that our game needed. Second, once we got through a good portion of the tutorial we started to see the game really take shape. Our game was playable, we started to see how the core systems worked together with the auxiliary systems.
* Implementing the numbers – This is the phase that Baron is currently in. At this point we have most of the systems implemented, most of the art done, and a good sense of how the game will look when it’s finished. Now we have to “fill in” the rest of the game by completing all of the levels and finalizing the art.
* Bugs bugs bugs – Of course throughout development we’ve been encountering and fixing bugs, but as the game nears completion the team will transition into fixing bugs – mostly bugs unrelated to platforms.
* Platform-specific issues – One of the final steps of the game is to start looking at the game on hardware and identifying issues that are specific to hardware. This includes handling when the game is put in the background, dealing with platform-specific performance issues, handling various resolutions, and dealing with manufacturer’s certification process.
* Submission – The final phase before the game goes live is submission. This means preparing builds, content needed for submission (such as screen shots and videos).
* Marketing – Many games overlap development with marketing by creating development blogs and keeping in touch with game communities/publications. Baron will be doing this; however we haven’t started to do much of this yet.
* Post-launch support/updates – This stage requires watching how the world responds to your game, fixing bugs, and making updates.
* Sunset – The game is done! No more updates, no more involvement with the community.
As you can see we still have a good way to go on the game, but it is becoming more and more fun to play every day. I can’t wait to share more as we get closer to release.