Nov 1 2010

Lessons learned from rapid prototyping

One of my favorite things to do is rapid prototyping — of anything really — but especially of games. There’s something inherently thrilling about hitting the ground running as hard as you can and aiming for done rather than perfect. I think, if you want to be good at making games, you absolutely have to do this.

The key to having good ideas is to have a lot of ideas, and similarly, I think the key to making good games is to make a lot of games.

The trick is to not dwell on any one game for too long.

I’m far from perfect at this, but having done it a few times, I think I’ve learned a few lessons.

Lesson #1: Measuring “Done” is easier than Measuring “Good”

The hardest part of creating something, for me at least, is dealing with the constant inner critic telling you that what you’re making isn’t close to what you were expecting.

The critic is right, but he’s not useful.

Ira Glass describes this way better than I can:

Personally, I like to view my games as experiments rather than products. I find an idea I want to explore, and explore it, then come to a conclusion about it. Sometimes the experiment results in something great, and sometimes it results in something that sucks, but it allows for the possibility of constructive failure.

Lesson #2: Deadlines matter, pick one that’s absolute.

Ideally you should have a time scale that’s long enough to get to the core of the idea, but not so long that you have the luxury of padding the game. Work always expands to fill the allotted space, as the saying goes.

I like one week.

One day is probably too short, unless you’re well practiced. One month can work, but it can be hard to not get distracted. One week seems to be long enough to get to the core of the idea while being constraining enough that you don’t wander too far from the goal.

Lesson #3: You aint gonna need it

You aint gonna need it. Times a million. You should get this tattooed on your forehead.

Lesson #4: The biggest time sink is polishing things

You are going to be constantly tempted to polish features that don’t matter. You have to avoid this temptation. Polish the gameplay, absolutely, but if you find yourself spending a lot of time on the menu screen, you’re polishing the wrong thing.

Lesson #5: Minimalism is your best friend

Try to find an art style that’s interesting or attractive but doesn’t take a lot of effort. Most indie games go with a “retro” look for this exact reason. Vector art can work well too, although it can be difficult to render, so be careful.

Darwinia is really visually interesting even though it’s mostly stick figures and polygons:


Minecraft is all squares, but the consistency of it is what actually makes the gameplay possible:

Lesson #6: Try to focus on a few core mechanics

I think this is a good design principle in general, but it applies even more here. It’s tempting when you’re designing something to think in terms of what you’re adding, but sometimes, the best ideas come from subtracting things.

One Response to “Lessons learned from rapid prototyping”

  • anne hughes

    Ian, this is a well-written article and I soooooo agree. I use the same principles in writing. A couple of the writing groups I follow online do an annual write-a-thon where one has to pump out a certain number of pages of script or novel in 30 days. The stories and dialogue stink for the most part as does the plot most of the time. The point is to get one writing to the finish line so as not to be daunted by what seems an interminable task. Well said good man!

Leave a Reply

Your email address will not be published. Required fields are marked *