There’s always a reason.
All developers I know are alike in several aspects. The primary aspect being that they are all creatures of logic and design. They are able to imaging and implement the most elegant solutions to complex problems. They really are a talented bunch of individuals. Many of the developers I know also have an interest in game development. And every single developer I know who has an interest in game development has difficulty completing a game project.
Over the years I have made observations as to why this happens. Here are a few examples, see how many of them you agree with.
- The hard drive containing the source code/media data for my game failed and I lost everything.
- The game was working then some unforeseen development challenge meant that I could not continue without a substantial re-write.
- I ran out of steam.
- Life happened – Job/Baby/Wife/Health
- The game turned out to be not as much fun as I imagined.
- Members of the team left and I could not continue without them.
- Feature creep dragged the project on for too long.
Every one of these has happened to me. None of these things affect any other project I work on – only game development. Why is this?
Well, there is the assumption that game development is simpler, easier, less serious to application development and that a detailed design is not required.
In fact the opposite is true. Game development is much harder than regular application development as there are so many critical pieces working together all of which need to be delicately designed and implemented.
It’s far simpler to write a design document for an application and frameworks exist to make application development simpler whereas many games are written from scratch.
However even with a framework or even and engine, game development stalls. This is often due to scope creep and the failure to adequately describe features so that they are either missed or become far larger than initially planned.
Ideas over Beer
This New year, a very good friend of mine and I sat with beers and discussed writing games. We’ve both started many and finished few. My friend said that he wanted to write a game this year, but would probably not manage it all the way through to being able to publish it.
It was then that I had an epiphany. Why only make 1 game? You could make 12 if you made one game per month.
My friend looked at me as though I was strange.
If you break down the project into 4 distinct phases and force the developer to adhere to a very strict set of rules, you will create a game in a month, or restart from scratch to refine the idea.
So with this, I drew up the list of rules for my friend and the next day, he started work.
The first phase was Design. Creating a design document to describe his game entirely. No code must be written during this week. Think about the game, how it will play, what the purpose of the game is and who the intended audience will be. Describe any gameplay rules, win conditions, multiplayer elements and power-ups. Design them well because next week will be the time to build it and you cannot change or deviate from the design during the coding phase.
The coding phase can be completed using any engine, framework or set of tools as you want as long as you do not spend more than 1 week working on the physical implementation of the game. Failure to complete the coding part of the game within the week will result in a complete restart of the project.
Once the coding is complete, the next week brings the Play, test and review phase where you choose people to play your game for a week and give feedback. During this time you should not interfere with the pure review process and you should not write any code. At the end of the week, the reviewer will provide a document listing their feedback. This feedback should be read at the start of the final week.
The last week involves polishing the game. Based on the feedback, make any tweaks needed and polish the game to a point where you can release it. At the end of this week, you release.
So by following the rules, you can create a game in a month, or fail and learn what your limitations are allowing you to start again and eventually create a game in a month.
This process has several benefits.
The first and most obvious is that it gets things done in a structured manor.
By enforcing strict time limits, the developer can concentrate on what is important at the time. By following the rules, the developer learns the discipline needed to write a game and finish it.
This process also limits the scope of the game meaning there is a higher chance that the game will be completed.
It also means that the game will probably be immediately fun which adds to the potential of sales on a market place.
So short simple games which can be completed within a short timescale sounds like a recipe for success to me.