3 Keys for Indie Game Projects

[This is repost from my Journal on Rioki's Corner]

3 Overlooked Keys to Making Outstanding Games (Game Career Guide)

This is a very interesting article, even though it is stating the obvious. The basic idea in the article is that you need 3 "keys" that are often overlooked by independent game designers.

These keys are:

Now let's take some time and look at my so far failed game projects. So far I have had the ideas and started development on (at least designing) the games of Lunar Exodus (RTS), Captain Pink Beard (Point and Click Adventure), Glow Cubes (Puzzle "Shooter") and My Little Garden (Casual Simulation).

Set Clear Goals for Your Game

Basically I have the simple goal for my games, they should be fun. And by fun I mean a game that I would play. The only exception was My Little Garden, this was focused to be fun for my daughter.

A optional goal was to sell the games. This is based on the assumption, if the game is fun, you can sell it. Making a game sellable means also extending the scope of the project; but if you got a fully fledged game doing that is not so hard.

Map Out What You Know and Don't Know

After some years of experience in software development I have developed a more lax approach to design. Somewhat inspired by the notion of agile modeling; I basically shoot from the hip with a basic idea. As the project progresses bits and pieces are designed on the go. No code is written without a design, but that design is only evaluated minutes, hours and sometimes days before the actual implementation. In some cases the design is evaluated and altered as new and unknown requirements come up.

I use the same approach to game design. It feels like it worked, but that is the problem; I can't prove it. In many instances, especially Lunar Exodus and Captain Pink Beard, I did not even come to the point where the basic "from the hip" idea was altered. I never even reached a playable state because of technical challenges.

During the development of Lunar Exodus I wrote the design document along side programming the engine. It feels like the projects that had the largest design documents are those that failed more spectacularly. Alternately you could state that these projects where those with the largest scope.

Make a Simple Schedule

This is one of my favorite points in project management. In many projects, not only games, I see people going around and telling you the properly plan your project ahead. They especially thing on project plans and gantt charts. If a project fails they tell you things like "If only you would have planed properly then your would have succeeded." ignoring the fact that the reason why the project was in trouble was not seen during the planing phase.

My problem with classical project management (i.e. Waterfall) is that it fixes the scope at the beginning, then evaluates what needs to be done and plans for it. If you halt the project mid term or you miss estimate the effort and run out of time (and budget) you basically have nothing. A few disconnected pieces of work but not a working project. Lunar Exodus was relatively well planed and I think it killed first the morale and then the project.

Lately I have tried to take a more feature centric approach. A mix between XP's user stories and Scrum's backlog. Although I am not running in iterations (maybe one of my current problems), I have tried to always have a running version from the get go. If you look at my Glow Cubes (The Demo) project, I wrote a basic NSIS installer script that builds a final installer on day one.

Scope and Motivation

It is hard to tell what killed my game projects. But I think the biggest point is that I fixed a way to large scope for one hobby developer and keeping me motivated for the period required to finish the project.