Acorn Heroes

Beg.  Borrow.  Steal.

Got an existing game, and you feel comfortable with the code?  Take a copy, rip out the guts of it, and start prototyping.  Need to perform a Fourier transform?  Do a Google search and mash the code you find into your prototype.  Know that a friend has solved a given problem before?  Ask them if they can send you the relevant code.

So you’ve found some useful code, but it doesn’t represent vectors the same way you do?  Don’t go through the borrowed code doing a search/replace – it’ll take too long and may introduce errors.  Instead, simply convert vector data on the way in and out with a simple piece of wrapper code.  Remember, CPU and memory are free.

Rapid prototyping is about getting results fast.  Sometimes the fastest way to get a result is to use working code from somewhere else.

Have a plan.  Refer to it frequently.  Update it as needed.

I don’t know how I managed to get to Rule #8 without mentioning this one before.  If you’re going to spend, say, 1-5 days putting together a prototype, do yourself a favour and sit down with pen and paper and plan out what you want to do.

Writing tasks down and then ticking them off as you go is a powerful motivator.  Keep it simple, a list of 5-10 tasks is fine.  Try to make the tasks well defined and achievable in less than a couple of hours.  Crossing items off a list is good for the soul, so make sure you can do it frequently!

Making a plan is great.  Sticking to it is even better.  But the real key to success is to revisit and refine a plan on a regular basis.  Keep in mind your goal and add, delete or re-prioritise your list of tasks once or twice a day.  And always, ask yourself “What’s the minimal set of things I can do to get the prototype working?”.

Iteration is instant.

Thanks to Noel Llopis for this one.  Anything that slows you down is your enemy.  The faster you can iterate through the think – code – test cycle the more effective you’ll be.  Complex / slow build steps (e.g. converting png images to PVRTC format), preprocessing data files and asset generation have no place here, it’s all about code turn around.

Notepad and Photoshop make great level editors.

[edit] : See the comments below – there’s a good argument for not even going this far.  Defining these things directly in code is a viable, and useful option.

One area where you often want a lot of flexibility, even during prototyping, is the ability to quickly tweak add a new elevator to the cafeteria level or make the slurpo-bot twice as fast.  Text, XML or image files make great data file formats for this sort of prototyping.

There’s plenty of standard code out there for loading text configuration files, XML data or pixel values from images.  And what’s more, your data is represented in a human readable form and comes with powerful tools for editing – including the IDE you are editing code in – how convenient is that?

Memory is free.  CPU is free.

Prototypes don’t have to run at 60 fps on low end machines.  Chances are your dev machine is more powerful than the final minimum spec platform.  This is especially true on the iPhone, where the iPhone simulator is backed by more memory and faster graphics hardware than any iPhone / iPod Touch. 

Don’t worry about optimal formats or optimisations, chances are you’ll never see any benefit from them.  They may speed up your code, but more importantly they can seriously slow down your think-code-test cycle.  Save the efficient coding for production, right now is a time for rampant hedonism.

Be comfortable – old T-shirts and track pants are actively encouraged.

Although I’m working on iPhone development, I’m far more comfortable making a quick prototype using Windows and C++ or .Net.  There’s just a bunch of experience there that lets me throw together something quickly and easily.  

Use a simple framework (or your own code base if you have one) that lets you throw simple primitives on screen and get mouse / keyboard input with the minimum of fuss.

The last thing you want to be doing while prototyping is hunting through API references, tracking down memory leaks, figuring out project settings or writing texture loading code.

The obvious exception to this rule is if you’re prototyping a feature that requires specific platform support (say a tilt control for an iPhone app).

Keep a handy-dandy starting template.

When you’re starting a prototype, you shouldn’t be messing around with setting up OpenGL, or render loops or anything extraneous.  You should be writing ‘game’ code in the first five minutes.  

Most IDEs support user defined project templates, and this is an option.  However, if you’re anything like me, you’ll be constantly tinkering and adding to a template, trying to maintain the ‘perfect’ template which ends up being more of a chore than anything.  

A simpler option that’s just as effective is to copy an existing project, and rip the ‘specifics’ out of it, leaving just general purpose stuff behind.  When needed, grab code from other projects and drop it in.  Give it a data/resources directory with a sample sound file and image file in it.  It is worth ensuring that this project will compile and run (seriously!), and it can also be handy to leave in useful snippets of sample code – getting UI events, loading images, setting up cameras etc.  

Then all you need to do is copy the project, open it in your IDE and start prototyping…

Sprites and textures are not your friends.

The purpose of a rapid prototype is to answer a question.  That question is not often “How pretty can I make this prototype?”  If you’re like me, and you know enough photoshop to be dangerous, it can be very tempting to play around creating a texture for a character, or scouring the Internet for the best X-wing sprite you can find (yes, I have done this).  Small squares for grunts, large squares for tanks.  Green for yours, red for an enemy.  White dots for bullets.  Distractions are dangerous.

Everything is global.  Everything is public. Everything.

In code that will never see production, and shouldn’t have a life span of more than a week or two, ‘proper’ encapsulation is pointless. Fight your inner software engineer and focus on the goal at hand, which is testing an idea as quickly as possible.

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.