My experience of game design as an activity has always been that it is easy to have fun with. This is a good thing, of course, but it also gives rise to a problem. If you spend your time having fun it makes it easy to avoid being critical of what you do. This is particularly true of video games, because most developers seem to enjoy the design work more than the implementation and both of those more than polishing or debugging. Therefore during the early stages of a project there is a temptation to make grand plans likely to take years to complete. During implementation, the huge size of the project becomes a burden and – as is well known – few reach completion. Experienced developers then tend to drift towards shorter and shorter projects for the simple reason that they come to value their ability to complete them. Very reasonable. But maybe still bad. Indie designers have become good at finding games they are able to make at the expense of making the games they want to make.

In this context, let me talk about my new project!

What I realised, just before starting it, was that I was about to make what I call a Three Bears mistake. You know the story of Goldilocks and the Three Bears, right? Well, my previous two projects were two of the bears. Vgypt was extremely large and ambitious. I was very excited about it and developed all kinds of clever tech for it and developed enough to submit a prototype to the IGF last year. The problem was, the project was too big. It got to the point where I was having performance problems and needed to rewrite the entire game engine and probably switch language too. I decided I couldn't justify the cost of doing so and reluctantly put the project on hold. The Unicyclist was my next project. It was much less ambitious and I completed it easily. It's good, if I say so myself, you should play it! The trouble is, it's too small to do well commercially. I got some good sponsorship (from teagames.com) but free games just can't pay enough to justify the kind of development time involved. So, time for a new project that was bigger than The Unicyclist but smaller than Vgypt. Time for Baby Bear's game, the size of which would be just right.

Or maybe not. Because that's the Three Bears mistake. Having identified two problems at opposite extremes, it does not follow that the best strategy is the average of the two bad ones.

The real problem with Vgypt was not that the game was too big, it was that the software required to implement it was too big. If I were to go ahead and write a medium sized game I might well complete it, but I'd leave myself with an awkward marketing problem. Like Terry Cavanagh's VVVVVV my game would be seen as too small for a commercial release whilst at the same time being too big to finance as a free release. (Incidentally, VVVVVV is very good and I personally found it well worth the price even at launch.) Also, who wants to start off a game design with a size constraint before you even have a concept? That can't be good.

The real lesson of these designs has to do with risk. At the start of a project the question to ask is: "What is most likely to go wrong here?". The trick is to make sure that the foreseeable problems are all things you can handle. Working as an indie designer has many positive points but one of the biggest negatives is that you're very vulnerable to risk. I'm lucky to be in a position where I can have an unprofitable year without needing to pack it all in and go and work in a bank.

My new game, as you may have guessed by now, is actually a bigger project than Vgypt. In fact it's easily the biggest game I've worked on. It's the reason this development blog has made it's appearance. I want to talk about the gameplay too, but I think that deserves its own entry.