Originally written for www.7outof10.co.uk
One of the more interesting and exciting parts of developing video games is the prototyping stage. It’s here that new ideas are tested before being banked or binned depending on their success. But why prototype in the first place?
Simply launching into a new project blindly can be a risky strategy. When entering into such a venture, the unknown can be an expensive business, both in terms of finances and resources. Even with the most well-meaning and well-informed developers, they can unearth stumbling blocks or make poor decisions which ultimately lead to a dead end and the possible conclusion that the project should be canned. This could be anything from the core game concept simply proving unworkable; to a seemingly innocent design choice at the offset has meant that the software infrastructure fails to scale with the needs of a full game.
One of the many ways to prevent this (or at least finding the grim truth out sooner) is through prototyping. Prototyping is a proof of concept, there to quickly trial your ideas before committing a larger number of resources to it. In the same way that an artist will sketch in the back of a pad before placing brush to canvas, game prototypes are there to make sure that initial thoughts on the project are backed up by a working example.
Years ago, I used to think of a game prototype as the ubiquitous “vertical slice” that is forever mentioned in the video game press. This nasty term describes a demo that has usually been custom built to show off as many of the final features as possible. The truth is that prototypes should be the exact opposite and adhere to a number of set rules:
- Prototypes should be as small and as basic as conceivable possible.
- Prototypes should ideally test one aspect in isolation.
- Prototypes should always ask a question.
The last point is the most important. If your prototype isn’t asking a question, what is it trying to prove?
For the sake of an example, imagine that we are trying to create a Kinect Frisbee game where a character is throwing you Frisbees and you have to catch them before throwing them at a series of targets. That may not sound like an incredibly complex concept but there are a number of possible prototypes that it can be broken down into.
Within our mandate to ask a question, prototypes revolving around what the scoring system should be or testing the collisions with the targets are unnecessary: scoring is not an unknown, we know that it is just a matter of numbers and can be decided at a later date; collision detection is nothing new and so does not warrant a dedicated prototype.
Instead, we could come up with at least three:
- Can you write a believable simulation of a Frisbee in flight?
- Can you detect when a player has caught a Frisbee?
- Can you create a satisfying and natural gesture to throw a Frisbee?
Develop all three in tandem in the setting of the final game and it may be hard to distinguish just what effect each minor change has. It’s far easier to strip them down and prototype each shard individually, before bringing them all together.
Though it may seem somewhat of a faff to strip apart each major element and prototype it, the small scope means that ideas can usually be trialled in just a matter of days. Then the iterations begin. Nothing is going to be perfect the first time and so programmers and developers work in a tight feedback loop trying to bring the prototype up to a functioning standard where it can definitively answer the question set for it. Positive answers are quicker to come by than negative ones, and so if a prototype goes particularly badly, it may be attempted in a different manner or style one or more times more before, depending upon its importance, being set to one side.
These times, particularly ones spent iterating with design, are moments that can spawn new ideas or avenues of exploration. Seeing their concept in isolation allows both coders and designers to consider ways in which they can improve, streamline or expand on it that they may not have done if it were dropped into the main game straight away.
To speed iteration up further, many of my own prototypes attempt to forgo as many art assets as possible so that they can be changed as quickly as possible. This does lead to a great number of wireframe cubes and spheres littering my prototypes rather than spiffy high-res characters, but I like to think that they add a little charm to proceedings. It also has the added advantage that the focus can purely be put on the matter in hand and not be distracted by superfluous visual elements; they can be added when the concept is proven.
Of course, this is just one of many ways to prototype systems and there are entire bookshelves full with theory on the best way to do things. The one thing they all have in common, however, is that they all set out to minimise the risk for the developer. Proofing the concepts extremely early on allows developers to have a good handle on what works and what doesn’t, whether what they’re aiming for is ultimately possible, and indeed whether it will get out of pre-production.
Next time we’ll take some time to examine some practises that allow designers access to the inner core of a programmer’s world without ever requiring them to know a line code.