Lessons of Rapid Prototyping

I’ve recently found myself back in school again after three years of post-college oblivion.  Due to the compressed nature of the quarter system, I was presented with the challenge of building a unique game prototype every week for several weeks on end.  I’ve been involved in a small amount of this sort of process with 48-hour game jams, but I’ve never truly faced the prospect of repeated rapid prototyping before.  If there’s one thing the experience has shown me, it’s that many of the concepts you can have about the process of designing a full game go out the window when designing a prototype.  In some cases, what seems immensely important in the design of a full game becomes completely trivial in a prototype.  Other elements that seem like trivial additions to a prototype are actually much more important than they seem.  I’d like to share some of what I’ve learned. 

As I sit here reviewing this entry, it all looks incredibly obvious, which makes me feel a bit embarrassed to bother writing about it.  But the deed is done.  Captain Obvious to the rescue! 

The Difference Between Scale and Scope 

One thing we were repeatedly taught in my undergrad program was to limit both the scale and scope of our projects in order keep the workload reasonable.  While I always knew what was meant by this, I never really bothered to figure out the difference between the two terms as I always found them bundled together.  One thing the process of rapid prototyping has shown me is that scope is everything when it comes to keeping your workload acceptable. 

Now, ideally, you want to have a prototype ready to go before you even make a project proposal, thus limiting the time constraints, but there are still instances in which you’ll find yourself rushed to build a working demo of your game.  If you need a prototype and you need it quickly, scale and scope are two vital considerations. 

Scale, as I’ve come to know it, refers to the size of the game.  How expansive of a game space are you going to deal with?  When thinking in terms of scale, a good place to start is thinking of your overall play time.  Is this a three-hour quirky indie adventure, an epic 40-hour RPG, or a pick-up-and-play casual title that someone can get through in ten minutes at a time?  Determining this can serve as a useful guide for how expansive – and how deep – your gameplay experience will be. 

Scope, on the other hand, refers to the sheer amount of material that goes into the game.  Whereas scale (as per its name) represents size, scope represents density.  How many different gameplay elements will you be dealing with?  How many different characters or assets are to be used?  Perhaps most importantly, how many different functions do you need to code?

This last question is key in rapid prototyping.  As is often said, ideas are abundant in the game industry.  In devising a game concept, it doesn’t take long to come up with a wide array of different skills or abilities an avatar can have or an array of challenges and obstacles the player might face.  If you’re making a prototype to demonstrate a game concept, particularly if you’re the one who designed it, you’ll probably want to give a sample of as many of these elements as possible.  That’s all well and good…as long as you’re capable of programming everything in before it comes time to present your game to a publisher.  The trick, as far as I can tell, is to always assume you can’t do this. 

I know, right?  Way to build up the confidence, pal. 

Now I’m not talking about breaking yourself down (or, if you have separate programmers working on the prototype, breaking THEM down).  As with anything in life, the point is to have a plan, and then, failing that, a backup plan, and then, ideally, a backup for your backup plan.  In the case of prototyping, a good plan should have the backup plan already built into it in the form of an incremental increase in scope.  Start ridiculously small and ridiculously simple, then worry about building up from there. 

This means adjusting the entire nature of the project build as you go.  If you’re designing a prototype featuring one level, that level could be designed in multiple ways depending on how many features are going to be implemented. 

Adjusting Scope through a Modular Design   

Let’s say you’re designing a platformer.  It’s got the basic platforming elements of running and jumping, as well as some other fairly standard ones like double-jumping, speed boosting, and wall jumping.  You’d also like to throw in your personal touch with a unique gravity-alteration mechanic.  You’ve designed a prototype level that demonstrates each of these abilities, requiring each one to be used correctly in order to make it through.  Great.  That should give people a good idea of what to expect from your game. 

Next, you work out a plan for building your prototype.  You’re going to start with the basic platforming mechanics to get the basic setup going.  It’s a platformer, so these elements need to be in place before you can move on.  From there, you’re going to implement your gravity-alteration system.  This is the key to your design – this element distinguishes your platformer from the rest of the market. Without this element, you have nothing to show. 

But then, things start to go wrong.  The physics of the existing platformer mechanics are at odds with what you want the gravity system to do.  This is going to take a bit longer than expected.  No problem – you’ll just skip one of the extra features you wanted to implement.  They’re not vital to demonstrate how the game works, after all.  But there’s another problem – the prototype level you’ve designed incorporates all of these elements.  Your gravity-alteration system doesn’t come into play unless you first use your speed boost and wall jump elements to access the appropriate area.  Now you’ll have to go back and redesign the entire structure of the level because you don’t have time to incorporate one of those elements.  This eats up even more time, forcing you to cut out another feature and redesign the level again. 

Of course, you can’t entirely prevent this from happening, but it’s a much easier problem to avoid in the prototyping stage than it is in production.  This is what I’m talking about when I mention having an adjustable scope and a modular design.  I’m a big advocate of building cohesive game experiences, but a prototype isn’t so much about this careful meshing of elements that you would hope to find in a full game – it’s a demonstration of how your game works.  As a result, a prototype can (and I would argue, SHOULD) be built with many of its key mechanics operating independently of each other.   

For instance, you might craft a level segment that specifically demonstrates the speed boost mechanic, another which specifically demonstrates your gravity-alteration mechanic, and so on.  Ideally, you’ll just be building your level sequence as you go.  If you want to mix things up a bit, you can generate each module and then, as you near the end of the prototyping period, put together what you’ve built to generate a full sequence of events.  This latter approach will likely produce a more connected and cohesive prototype, but it requires an additional design stage. 

Visuals are More Important than You Think 

This isn’t to suggest that you should bring in the professionals to give you fancy character models and visual effects for the sake of a ten-minute tech demo, but keep in mind that the term “video games” contains the word “video” for a reason.  The important thing in a prototype is that you prove the viability of your game mechanics, but the whole point of a video game is to translate all of the mind-boggling numbers and symbols of your code into a format that can be understood without years of training.  If the code works, the player needs to see it working on the screen.  If you shoot a gun, you should at least hear a “Bang!” of some kind.  If you’re charging up for your super-mega-special-energy attack, you should see yourself…I don’t know…glowing brighter and brighter or some such thing.  If you use your “drink milk” function, you should see milk disappear before your eyes. 

The word here is feedback.  It seems obvious when you think about it, but in a way, it’s so obvious that it’s easy to forget about it and simply leave it out.  If the player does something, it needs to be witnessed happening in some way.  It’s important in a prototype for the same reasons it’s important in a full game – to demonstrate that the meticulously-written code is actually doing its job.  The code makes your mechanics run, but the player doesn’t know that without the audio-visual element.  And no, a debug screen is not a viable audio-visual feedback mechanism for the typical player. 

In short, don’t ignore feedback elements in your prototype.  While it’s true you may not need a head to explode in a hyper-realistic shower of gore at this stage, your player will still want to know that the afflicted victim isn’t going to be a threat anymore.  Incidentally, a hastily-placed text box reading “Boom! Headshot!”, may technically be a viable feedback mechanism, but if I see this more than once, I’m going to stop playing your game with immediate effect. 

Drawing the Line Between “Engaging” and “Practical” 

After the experience of completely redesigning a game halfway through its production cycle during my undergraduate program, I hoped I wouldn’t have to go through that process again.  But, silly me, I apparently forgot that I was getting into an industry in which this kind of thing happens without warning.  When you make the discovery that a game simply isn’t fun, bad things happen. 

Ultimately, I’m not sure how common the practice of rapid prototyping is within the industry.  I will say this, though – the day before you’re pitching a project to the higher-ups is not the time to make a fundamental change to the design.  Generating a viable prototype in one week is challenging enough.  Doing it in less than 24 hours is just asking for trouble.  Sure, your game might not be accepted if your prototype isn’t fun, but if you change that prototype at the last minute, it’s still not going to be fun. 

Why do I mention this in reference to prototyping?  The prototype is the first stage of the project where you’ll start to see that your concept isn’t enjoyable.  As a result, it’s probably the stage at which you’re most likely to decide that a massive change is called for.  In general, I would say it’s not something to worry about…if your prototype doesn’t sell the concept, you should have the opportunity to make another one in the future. 

I also mention this simply because I just so happen to have been involved with a prototype that was redesigned from the ground up 12 hours before it was due.  Don’t do this, okay? 

Closing Down 

Whatever the situation may be, it’s better to let your mistakes shine BEFORE you start making a full game.  This is the true purpose of the prototype.  A prototype is a test run, allowing you to give your concept a chance before risking the world.  Sometimes, it can hurt to know that your prized design doesn’t work, but it hurts a lot less to discover that before you’ve invested the time to develop the game. 

Incidentally, prototyping also allows you to imagine, however briefly, that a typical crunch period only lasts for a few days.