The blog of Matthijs Hollemans, indie app maker and author of The iOS Apprentice

On sites such as Elance, I often see job listings for games. Here is a tip if you’re considering having a game developed: first hire a developer to make a prototype to see if it’s worth investing in building the full game.

Let there be no mistake about it, making a game is a lot of hard work. There is a ton of design, programming, graphics, sound effects, music, testing, tweaking and polishing that needs to be done. It will take months. And the kicker is, you won’t know if the game is any fun until it’s nearly finished.

That’s a big gamble to take. If the game turns out not to be any fun, chances are it won’t sell very well and you’ve just wasted a lot of time and money on a dead product. Unfortunately, it’s impossible to predict whether the gameplay will be any fun until you can actually play the game.

Play your game as soon as possible

There is a smarter way. First build a prototype in order to test out the gameplay mechanics. The prototype has only one purpose, to learn whether the gameplay idea works. Is it possible? Is it fun? And we want to find this out as quickly as possible.

You can do a lot of the prototyping yourself long before you set out to hire a developer. Start with pen and paper, cut the game pieces out of cardboard, get some friends together and try it out. A lot of games can actually be prototyped this way. You get to do beta testing before a single line of code has been written.

If your paper prototype works, there still is no guarantee the idea can be transferred to a computer game. The next step is to hire a developer to convert your paper game into software.

Prototypes are messy

The keywords to making a software prototype are “quick and dirty”. It will use ugly placeholder graphics, there is often no sound or just very basic bleeps, the game won’t have much of a menu structure, the source code will be awful. It also requires a bit of imagination to see how it will end up being the final game. But none of that matters: the only purpose of the prototype is to tell you whether the gameplay mechanics will work.

Here is an example of such as prototype:

This is a block-stacking game idea I had a few months back. You have to rearrange the blocks into a tower by dragging and/or rotating them, so that the cute creatures (the red circles) can reach the exits. Not a bad idea, except for one thing: it doesn’t really work well on the iPhone. Your fingers obscure too much of the playing field, so it’s hard to see what you’re doing. Only a prototype will tell you those things!

It took me a few evenings to put this together. I hacked it out as quickly as I could, cutting corners where possible. As you can see, it’s not very pretty. Simple colored blocks represent the game characters. There’s no point in making beautiful artwork if you don’t know yet whether the game is worth building.

Unfortunately for me, the game idea did not turn out to be viable. Well, that’s how it goes. It’s better to know that sooner rather than later.

Prototype, tweak, repeat

If the prototype just isn’t any fun to play — and often the very first version isn’t — then you can tweak it. At this point, changes to the gameplay rules are cheap and easy. You don’t have to throw away expensive artwork, because you didn’t create any yet.

Early in the project is the best time to make big changes. Major modifications to something as fundamental as the game idea will become much more expensive as the project goes on. If the changes end up being way outside of the project scope, it may mean having to renegotiate with your developer. It means throwing away artwork you’ve already paid for and having to pay for new artwork. In any case, it will cost you.

Throw away the prototype

If your game idea works, that is wonderful. Now throw away the prototype and start over from scratch. Prototype code is meant for throwing away, not for publishing. Don’t feel like you have to use this code because you paid someone to write it. What you paid for was the validation of your idea, nothing more.

You don’t want to build the final product on a code base that was slapped together as quickly as possible. Instead, give the developer the freedom to go back to square one and build a proper foundation for the game.

Writing the prototype should already have given the developer a better idea of how to structure the code properly, because he understands the underlying problems now (he already solved them once). As software project management guru Fred Brooks says, “Build one to throw away.”

Reduce your risk

To summarize: first hire a developer to build a prototype, work through several iterations until you are sure that either: a) The game is fun and it’s worth doing it for real, or b) The game just doesn’t work and it’s time to drop the idea and move on to the next.

Certainly, getting a prototype built is a lot cheaper than getting the full game developed. The software business is risky; use prototypes to reduce your risk.

By the way, this goes for apps too. If you’re unsure about the best approach to your app — and this is something I see on a regular basis — then get a prototype done. In fact, that is how I usually treat the first milestone of any client work I do.