Game development process - prototyping

Developing a game of any size is a big undertaking.  It is very often the case that you get a few weeks (or even a few months) in to the project and come across something that leads to the project needing extensive changes - or worse - cancelling the project.

 
Of course, it isn't possible to foresee everything that could go wrong with a game development, but there are steps you can take to minimise the risk.  
 
One of the major things is the development process itself. If you don't already, look at using a variant of agile software development, which is an iterative development process where your game is developed in small steps.  If changes are needed during or after any of the steps you don't need to go back too far to address them.
 
However, what I want to talk about is prototyping - something we at Pixelthis are very fond of. Our game development process itself is broken into the following steps (some of these steps can be further broken down):

• Concept
• Game design
• Technical prototype
• Gameplay prototype
• Asset generation
• Complete development
• QA testing #1
• Localisation
• Porting
• QA testing #2
• Distribution
• Archive
• Post-release analysis

You'll see that right near the top there, after game design, we have two prototype stages.  During the game design stage we plan exactly what we want in the game (we in fact split this up into (1) Must haves (2) Should haves, and (3) Nice to haves).  From this we then try to identify any potential technical issues (e.g. Can we have that many sprites moving at once?) and any gameplay issues (e.g. But will that actually be FUN?). 
 
You can prototype anyhow you like.  You can cut bits of cardboard and move them around a table if that is going to help you visualise your gameplay, or you can prototype a wireframe version of your game in the tools you will be using to make the game, and then use this as the basis of your actual development.  
 
However, at Pixelthis we almost always use Flash.  We have a lot of experience with Flash, and find we can knock up a prototype in half an hour that could take us days using other tools (like xcode, for example).  Of course, this works best for the gameplay prototype - this is where we are testing whether aspects of the game itself will be fun to play.  the technical prototypes, which involve testing if certain things are actually even possible, need to be done using the tools and languges that the final game will use - so for the iPhone that means xcode and objective C.
 
So for your next project, consider banging up some prototypes and save yourself a bunch of time and headaches by finding any potential problems early.  I can't think of anything worse than developing a game for several months, ready for release, and finding out it is not actually fun to play!