[This is a repost from my blog, doolwind.com]

Since the release of Flick Buddies, I’ve been prototyping game ideas for our next game. The best of these prototypes we’re taking to GDC to show publishers. Today I’m sharing my list of tips for creating prototypes.

1. Set Your Goals

It’s important to decide exactly why you’re making the prototype, and what you hope to achieve. These goals show you where to focus your time while developing the prototype. For us it’s about testing gameplay mechanics and proving the core concept of the game. A secondary goal is having playable prototypes we can show potential publishers to quickly get across the feel of the game.

Without these goals, it’s difficult to know where your time is best spent. Is this about testing a mechanic on a particular platform or finding whether certain gameplay is fun? Could the game better be served by a pen and paper prototype first? It’s worth spending some time before you begin, deciding the best use of your resources.

2. Timeboxing

I always set a specific limit on how long I can afford to spend on the prototype. It’s easy to get carried away once I start and I can easily lose a lot more time than is necessary. Timeboxing forces me to focus on the most important elements of the prototype as I can’t do everything.

The actual length of time allocated depends entirely on your situation. I allocate 20 man hours per prototype which fits nicely into two work days for me. I find two days is the perfect length for completing the core elements while keeping time short so I am forced to focus.

3. Throw It Away

This is a tough one for some people, but I always recommend planning to throw the prototype away. This has a number of core benefits:

1. Pragmatic – This stops me from doing any big design up front and forces me to do just enough to get the task done. It puts me in a completely different mindset while developing as I just want to get it done as quickly as possible.
2. Lessons learned – When you begin work on the real game you will have previous experience in implementing the same features and solving the same problems. This will help improve the design of the game, both at a software and gameplay level. With some particularly complex problems (“wicked problems” according to McConnell) we must try solving the problem first, before we can fully understand it and find the optimal solution.
3. Less Constraints – If you’re throwing away the prototype there’s less constraints on how you build the prototype. You can use whatever technology is best for prototyping, rather than the best for creating complete games. If you don’t follow company (or personal) guidelines during the development it’s less of an issue, as it’s a completely separate act.

Rather than laying the foundations for your game your doing the opposite, investigating the best way to build it so that when the time comes to lay the foundations you’re in a better position.

4. Key Gameplay Only

I only focus on what’s different about the current game. If I’m making a clone, then really, what’s the point in prototyping? I pick out the gameplay elements that make the game stand out and test those to make sure they work and tweak them. One of our prototypes is a new twist on the platformer genre. I spent as little time on the platformer elements and focussed on “the twist”.

Another way of looking at this is to test the highest risk elements of the game. Gameplay that will make or break the game is important to test as early as possible. Often I find some ideas simply don’t work, and it’s much better to find this out in the first few days of development.

5. Allow Tweaking

I expose as much as possible to my designers and even play testers so they can tweak the gameplay. The game will be in a very rough form and allowing rapid changes to core gameplay can help steer the game in the correct direction.

Another of our prototypes is an asynchronous strategy game. I’ve exposed the start and win conditions and all unit stats. Small changes to these completely change the way the game plays. This is perfect for a prototype as it lets anyone play with the values and suggest changes to the originals. This pushes the burden of experimenting, balancing and tweaking off the prototype team and onto anyone else that plays the game.

6. Divide The Game Up

If I’m working on a large game I’ll divide the different elements up into separate prototypes. For example in the “Total War” series I would make the strategic and battle maps completely different prototypes. This has a number of core benefits:

1. Separate teams can work on each prototype if needed
2. Different technology and tools can be used if helpful
3. Each individual part of the game can be judged independently. Perhaps some areas are less fun than others? You can look at each part as its own game and easily see its strengths and weaknesses.

7. Run On Target Platform

I always find that to get the full user experience of a prototype it’s best to run on the target platform. This is core to the gameplay experience and for certain platforms will completely alter the reaction to the prototype.

The only time I don’t do this is when it will blow out the schedule to do so or if there are other constraints that make it impossible (e.g. platform owner restrictions). In this case I do my best to imitate the platform it will run on to get the user experience as close to the real platform as possible.

8. Have External Material

Some things are better completed outside of the prototype itself to save time. I often write tutorials and help screens as a series of screenshots of the game with instructions overlayed. This is far quicker to do in Photoshop than implementing within the prototype. While having screenshots as a tutorial isn’t as good a user experience it saves time that can be spent implementing other features of the prototype.

Another time saver is to walk people through the prototype personally, replacing the tutorial. I like to watch people playing the prototype as much as possible and explaining the game to them is the perfect way to open up a dialog about the prototype.

Conclusion

What are your tips for prototyping? How long do you like to spend and do you throw them away once finished?