Working with development phases when creating a game is not going to clear up your process. In almost any case it shifts focus from what is truly important to the game.

At the end of the day, it’s about getting your game on the table. It must be well thought through, look good and must play good. I think development phases can mean a great deal if you wish to achieve that and phases can help you and your team to focus on what the phase is for. But then again, than it is not about your game anymore, it is about completing the phases and completing the process.

I believe that if you focus on the steps that must be taken in order to create the game, there is no confusion and you will never be ‘stuck’ in a previous phase. I have never done a project in which the design document was completely written and final the moment the production phase started – another problem of development phases is that there is always an overlap. And that is not going to clear things out.

This is what generally goes wrong with student games – school requires the game to be created by clear phases that must all be completed before the other. The problem is that for most students, this suggests that when you are in the production phase, you don’t have to work on your concept anymore. And beside that, writing complete design documents based on assumptions is never a good idea – the same goes for planning. This is the reason why most student games are either crappy or not finished.

You must be thinking about SCRUM now, but that is on a whole different level – SCRUM does not let you look into the the coming months, only into a week or so. Thats why I like the word ‘milestone’ – milestones don’t need names, they only exist when a certain level of production is (or is going to be) achieved and they are great motivational boosts when you are near or at one. Now, take it from here.