Rapid Prototyping – the Faster, the Better 3

A few weeks back, I did an interview with the Happy Mitten Podcast. They asked me if I had any advice for new designers and I did: Rapid Prototyping. The theory behind rapid prototyping (the way I do it) is that you can test an idea, at it’s core, while it is fresh in your mind. These quick tests will tell you whether or not the idea is viable right from the start, before you spend days and weeks developing it further. I know some designers like to spend that time in advance, working on rule sets, fleshing out the game, and making sure they understand what they want before they start… but that just doesn’t work for me. If it turns out that the core mechanics of the game are a flop, it was all just wasted time discussing theory with yourself.

My method of rapid prototyping is what is known in the software world as “Minimum Viable Product.” The concept is to quickly make the bare minimum needed to test your product, then build on it. An example:

I want to make a card game. In this game, players will draw a hand of cards each turn, then play those cards on their opponents. The cards will predominately feature a number and the goal is to end the round with the lowest score. Eventually, I want to have cards that will allow you to trade numbers, pass numbers, draw more cards, or discard cards in play. Much of the special ability cards will need to be developed later, but for now, I can crack out a few quick ones to test the idea. I know what my end goal is (for now), but I want to test the base system first. With this in mind, I make up my first test deck almost immediately:

+1 – 15 cards
+2 – 10 cards
+3 – 8 cards
+4 – 5 cards
+9 – 3 cards
Draw 2 – 5 cards
Pass 1 (any player) – 5 cards
Discard 1 from play – 3 cards

If you notice, this is a 54 card deck. I tend to work in sets of 18 because most Print On Demand and even offset printers print cards this way. For my first few tests, I grab some blank cards (business cards are my favorite) and just scribble this out in pen. Then I get to testing. Later, if the idea is worth developing on, I start working on card layout and art and all of that.

Does it really save time to hand write cards or should you just start on the computer? – Philip duBarry via Twitter

This question is very subjective. For a quick numbers game like this, my first prototype is always going to be hand-scribbled on cards. It allows me to get a broad overview of the deck as a whole while I’m working on it. If there’s going to be significant text, however, I will spare my poor testers the agony of reading my handwriting. I am pretty competent with Inkscape, so I can actually prototype faster on the computer than I can by hand… this might not be the case for some people. Also, for my first prototype, I don’t bust out the spreadsheets and analyze the math. I do it on gut feeling alone which comes from decades of playing collectible card games. In fact, my design process looks very similar to the way players build their decks.

How I design my first prototype.

What this prototype allows us to do is see how our base mechanics work. I avoid writing rules for these first tests also. I like to keep it fluid. I try to have a low-level understanding in my head, that I can build on as we begin testing. If the game is complex, I’ll write out “back of the napkin” rules that flesh out major components. Keeping things fluid allows me to observe and make changes on the fly:

• how many cards in a players hand?
• how many do we draw a turn?
• how many can we play a turn?
• is the math tedious?
• what’s the game length?
• is it engaging?
• does it need more complexity?
• DOES IT WORK?

What happens after the test? Well, that largely revolves around the answers to those last few questions. Most of my projects die right then and there. They work, but they are terribly boring and take way too long to play… or maybe I missed an obvious flaw in the system that means the game is broken. Most of the time, I scribble some notes, and put the prototype away. If the system shows promise, though, the development begins. This is when I start working on adding bits and pieces to the game to bring up the interactivity or the complexity. Maybe it needs more key decisions. The power of having mostly blank cards is that I can easily rip cards out, add new cards, or change existing cards without having to fire up my computer and start all over.

So, maybe I add “factions” to the number cards and when one player has triplets of a faction, that doubles the total points. I’ve now added a new decision point that ups the complexity, but only slightly. I’ve also added more math to the game which might make it too unwieldly and annoying. The good news is, I can grab my sharpies, scribble some symbols on the cards, and test the idea almost immediately. If it fails, great… now I know. No need to think in that direction any further.

Last year, Daniel Solis wrote an excellent blog post about Rapid Prototyping. In his discussion he talks about how banging out quick prototypes gives him the ability to make huge changes without sacrificing hours of precious work spent on designing something pretty and non-functional. He asked me on Twitter to elaborate a bit on where I draw the line.

I am curious what your line is between rapid and reckless. I go tend go make too drastic changes. – Daniel Solis via Twitter

Well, this is also a tough question. With very little effort in your physical components, it can become very easy to just throw everything out and start over… over… and over again. You’ve got almost nothing invested in this, so why not just go crazy with it? I’ve tried to demonstrate how easy it is to get a playable game out as quickly as possible… but maybe I’ve made it sound glamorously easy? One thing you should strive to do throughout your game design process… from the first prototype to the “finished” product… is remember your initial vision, and design to that. This means, you actually have to have a clear picture in your head of what you want. Haphazardly attacking a box full of components and hoping a playable game falls out the other end is NOT designing. It’s arguably an awesome, fun time… but I consider it more of a design exercise (and do encourage you to try it.)

Prototyping with blank cards.

The pictures above are for an unnamed game that I prototyped while camping last week. This is the first prototype and it was made with a pen and a few sharpies on blank poker cards. This is a rapid prototype, but it didn’t spawn from a thought I had 5 minutes prior. This game has been in my head since around February of this year. In fact, I had the idea just before talking about it on the Building the Game Podcast. It’s stewed around up there for a while because I saw a huge flaw with it before I developed my final vision. While camping, I had the epiphany needed to drive the design forward, so, I made it. I haven’t tested it yet… not even solo… because I’m convinced it’s not very good, but I needed to make it just to get it out of my head. Because I’ve thought on this one for so long, I have no fear of it straying from my original intentions after I begin testing. I’ll try and do everything I can to push this game along just as I had always wanted it without making huge, sweeping changes.

The simple truth is: I should have prototyped this game 6 months ago.

Giving the game it’s first shot, I may have had my epiphany months prior or I may have determined the entire system to be flawed and not worth the effort. That’s the advantage of rapid prototyping. Spinning your wheels on an untested idea may work for some… but I would much rather get it out of my head and try it so I can make a quick decision to discard it or continue. You can’t be afraid of failing at this part. Scribbling out the worst design of your life and giving it a go is an invaluable lesson in design. You simply must fail at designing before you get better. Each terrible prototype you make teaches you about a mechanic or component that does or doesn’t work for you. It helps you build your toolbox of ideas so that in the future, when you are struggling with a different design, you can dip into your box of concepts and pluck out that one thing that didn’t work way back when, but is perfect now.

Every gamer loves to talk about game mechanics and how they can make this or that better by changing something or adding something from another game. They all talk about how their ideal game in genre X would have cool abilities and interesting components. Every gamer I have ever met absolutely loves to theorize about game design… but a very few are actually brave enough to attempt it… and failure is our friend.