Acorn Heroes

The illicit thrill of rapid prototyping

by on Jul.13, 2009, under Coding

With every key stroke, I feel dirty.  Pure ideals are being distorted though a mind warped by the seductive lure of Brute Force and Ignorance.  My flying fingers mash code together in a way that would make any sane developer run screaming into the night.  I can hear the raptors trying to get in.

And I’ve never been happier while coding.

I’m in a rapid prototyping stage – trying out an idea to prove its merit before devoting any significant time to it.  The code I’m writing isn’t production code, in fact it’s the dirtiest, grubbiest hack I can put together.  But it’s also coming together fast.  Really fast.

Here’s what I’ve achieved in only 3-4 hours:

  • Basic gameplay loop
  • A simple ‘level’ design
  • Enemy AI
  • Unit production and basic economy
  • Combat resolution

Sound like a lot?  With a few more hours, I’ll likely have a couple of ‘special’ attacks, some different types of unit and end game conditions.  It’s ugly programmer art, with hard coded stats and logic and would most likely crash if I attempt to run it anywhere but in the debugger on my dev machine.

I could never write good code like this.  But I don’t have to.  I’m trying to answer the fundamental question for any game design:

Is it fun?

It’s really that simple.  Everything else is insignificant.  So I’m writing the quickest, nastiest code I can to answer that question.  I’ll never let that code anywhere near a ‘production’ environment.  It’s really simple – put together a prototype as quickly as possible to demonstrate that your idea is a good one, or not.  Iterate until you’ve answered the fundamental ‘Is it fun?’ question or you realise that maybe ‘Tax Hero’ isn’t quite as great an idea as you thought it was.

That voice in the back of your head that says things like “you should expose the screen resolution in a config file” or “you should refactor that class into an abstract interface” has to be squashed mercilessly.  Ignore all of your hard won industry experience for a few days.  Best practices are there to save you on big projects where bad design decisions can cost you money, clients or your job.  Rapid prototyping code will have been thrown in the trash long before then.

So don’t let your inner perfectionist get in the way.  All of us have great ideas for games.  The hard part is turning them into reality.  Rapid prototyping is one way to explore a bunch of good ideas, weed out the chaff and focus on the real gems.  Code like a teenager for a bit, it’s a wonderful, illicit kind of freedom that’s also incredibly productive.

Related posts:

  1. Rapid Prototyping Rule #1
  2. Rapid Prototyping Rule #3
  3. Rapid Prototyping Rule #5
  4. Rapid Prototyping Rule #6
:

3 Comments for this entry

  • Elliot

    I think I’m pretty good at imagining a game in my head, and determining that way whether it would be fun. When I write code, I’m usually somewhere in the middle; I’m coding really fast, but not so fast that the code must all be thrown out before production. The code is usable, but it will need to be gone over at least one more time to make sure the hacks are ironed out. But much of the code does make it into the final version, so I can feel happy and productive all along.

  • Noel

    Rapid prototyping is crucial to any good game (because you’re going to make 10 prototypes before you find a good idea). I also love the thrill of programming really fast and getting lots of stuff done.

    And frankly, I’ve learned a lot from programming that way. It made me realize that a lot of the things I thought I needed in “production” code, I really don’t. And if I do, I can always refactor them.

    Have a blast! This is one of the most fun parts of the process!

  • George

    Noel – I agree that building the prototype helps avoid writing unnecessary ‘real’ code. It really is time well spent, even though it’s designed from the outset to never see production.

    Hi Elliot, thanks for the comment. Obviously it’s a case of choosing the right method of attack for a given problem. I find that even my best ideas normally end up changed and improved after being given to other people for feedback – and that’s why I try to prototype as fast as possible.

    And as Noel says, it’s great fun. The Global Game Jam (http://globalgamejam.org) was a great example of this – our team of about 12 people built 3 games in 48 hours – it was a blast.

2 Trackbacks / Pingbacks for this entry

Leave a Reply