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.
If you’d like a particular aspect of the industry discussed, please do get in touch at bigsheep@7outof10.co.uk and we’ll see what we can do.
I make my living as a programmer at a British games developer. In my spare time I try and spread myself between writing, gaming, drumming, goalkeeping, rolling dice and keeping my hair blue. Somewhere around that my wife fits in.
Disclaimer: the views expressed are my own and do not neccessarily reflect those of my employer. "
4 Comments
The way I understand it though, you still have to have the vertical slice demo as part of the process at some stage don’t you? I’m guessing the prototypes are applicable for proof-of-concept internally, but publishing bigwigs etc will still expect a shiny demo to keep them happy?
My other question would be, if that sort of thing is still expected, does it hinder the development process rather then helping any? Diverting resources and whatnot?
Bigwigs always like shiny demos, they don’t do wireframe, so, yes, at some point things have to be brough together into a more complete demo. Developing each aspect separately initially at least allows developers to see what works and what doesn’t and ultimately which components they should spend their time on bringing up to a high level of polish.
Demos always hinder the flow of a development cycles. If teams had their way then they’d just be allowed to get on with it and just drop a finished disc on the manager’s desk a couple of years down the line. The people who hold the purse strings unsurprisingly think differently and they want to know they’re investment is on track.
I feel this discussion may be worth a whole article in itself.
Peter Molyneux is notorious for falling short when it comes to bringing his orginal ideas to the finished product due to, from what I’ve read, the technology not being there, or at least not being able to perform to the required level. If I’ve understood ‘Prototyping’ correctly should’t have many of Peters ideas been scrapped, or redefined during this stage of the development process, James?
Or is this exactly what happened with say, Fable? Through ‘Prototyping’ it was discovered that many of the ideas became to unrealistically doable and so had to be redefined and re-worked?
You’ll have to excuse my ignorance, I just switch it on and press start and expect to be blown away.
I can’t comment exactly on what happened on Fable, I simply don’t know, but I get the feeling that your second statement is correct. Peter may aim for the stars but the experiences he found through prototyping, or the general evolution of the game, meant that some ideas were curbed and they ended up evolving into something else. “Love” is a tricky one to convey in a game and so the experiences with the dog and family in Fable II no doubt either felt a little strange or just out of place as what he was trying to portray was so abstract. Sadly, in some cases, when it comes to aspects of userbility some things just have to be boiled down.
In my mind, Molyneux is truly one of the greats in the industry because he aims so high. So many people knock him for not delivering but I always think that at least he’s trying. As you say, though, the tech/resources just aren’t always there to get across what his ultimate goal is.