I’ve signed up to quite a few gyms over time. Some of them I went to very regularly and others I showed up twice and never looked back. What was the difference between them? One simple thing: Distance! When it comes to gyms, I’ve found that the amount of friction of going needs to be as small as possible. The same holds true for prototyping.
I’ve had hundreds of ideas for amazing games that never went further than a light bulb over my head. Because usually I’d be doing something else, not having access to a computer or my other design stuff, and the idea would die a quiet death. Or even worse, I just couldn’t be bothered to actually take the time to create the components; it was just too much work to fire up the computer, create a bunch of cards (in whatever editor), print them out, cut them to size, put them in sleeves (with a playing card for strength) and only then be able to test out my idea.
The above is the first two paragraphs of the guest post I wrote for GameGoodness. Want to read the rest? Go visit them!
Designing a game takes a lot of time. Brainstorming ideas, settling on one, making a prototype, self-testing, adjusting, play-testing, further adjusting, etc.
And at any point in this process you can find out: “No, this isn’t going to work after all”. Meaning you can throw away your hard work and start from scratch.
So anything that can save some time anywhere in this cycle is worth it.
From idea to prototype
After lying awake for a night you get up with a brilliant idea for your next board-game. It’s going to be like Monopoly – but with zombies!
You’ve got the basics of the rules and you know more-or-less what kind of components you’re going to need.
So you start fleshing out a prototype. You grab the pieces from one of your existing zombie games, you draw a board on a piece of paper and you start sketching some cards you need.
Before you know it you’re lost in the minutiae of the work: What’s the equivalent of “Boardwalk” and “Go to jail” for zombies? What kind of rent should you ask for “Zombie-invested-high-school”?
But diligently you push through and after a few hours (days?) you have a prototype, ready for your first play-test. You turn on your schizophrenia and take on four different roles and play your first game.
And guess what? The it sucks! (Because seriously, Monopoly with zombies?!?).
Was there a way of figuring this out earlier?
Ideas are easy
Creating an idea is easy. But most initial ideas won’t stand the test of gameplay. Or perhaps there is something in there, but not enough to actually base your entire board-game on.
Which makes it highly unfortunate that creating a prototype takes a relatively large amount of time. Especially if you need to create 10 before you have one that you feel you actually want to continue with.
If only you could do your initial play-testing without creating a prototype?!
The blank play-test
Recently I’ve been doing “blank play-tests”.
Here you take your vague and un-formed idea and start playing it as soon as possible, without making any components.
There will be a board at some point? Use a piece of white paper.
You’ll be playing cards? Empty ones will do for now.
Need something to represent XYZ? Use tokens borrowed from another game.
With these “blank” components you can play the bare-bones of the game. Every turn you can play a card on a board-space that has some influence on that space? Go ahead and place some empty cards on an empty piece of paper. Imagine what these cards might say. Imagine what could be on the board. Imagine how they interact.
You can place workers on your spaces with cards? Get some cubes from an old game and place them. Take turns doing this for different (imaginary) players.
Of course this won’t tell you everything about your game. But it most certainly will tell you something. And with the minimal investment required it’s a very good way of quickly discarding ideas that don’t work and to preempt problems before making a real prototype.
Let’s take a further look with an example.
I recently started work on a new game, working title: “Pawns of the Gods”. The idea is that you are a fledgling god trying to get people to believe in you so that you can rise in power
In a nutshell, the game has two parts: First there is an “automated” or “AI” part, which controls a number of different groups of people in conflict with each other. Then there is the player controlled part, where you play cards to “help” these groups in their conflicts with each other; help a group be victorious over their opponent and you’ll have gained a believer (or two).
I started out with toying with the AI part. I grabbed a bunch of cubes and had them represent lands, population, food, mercantile power and military might. Land grows food grows population grows mercantile power grows military might. Which would then be used to attack another group.
And just by pushing some cubes around I found that this was way too complicated and took forever (wise lessons: board-game AIs should be very very simple!). So I removed the need for lands and food, still too complicated. Remove population and merchants, but put the lands back in. Lands give military might. If you win a battle you get more lands, which give more military might. Simple and effective. This will definitely need more work in the future (how to stop one group from winning once they start?), but it was good enough to start with.
The second step was the player bit: Playing cards to “help” different sides of a conflict. I imagined generally two types of cards: One type to directly influence the conflict (“give +2 strength to one side of a conflict”) and deck manipulation (“look at the top 5 cards of the deck, put three on the bottom and the other two on top in any order”).
So I played, giving each “player” a hand of blank cards and at a whim deciding whether they would be of one type or another.
Results were quick to come in: Yes, this worked. Adding strength was much more interesting than manipulating the deck (though that might just be because it was a stack of white cards? 🙂 ). There wasn’t a lot of excitement because it was pretty obvious what was happening and who would “win”.
A next “iteration” allowed you to play a card face-down, hiding what you played from the other players (yes I was playing on my own, knowing full well what the other “I” just played, which was a “face down” card that was completely white on both sides. I’m glad nobody was there to observe me!). With this there seemed to be a decent amount of tension in the game.
In total I spent a few hours, working on several “virtual” iterations. After which I had sufficient feeling for the game to say that it wouldn’t be dead on arrival of the first (real) prototype.
Advantages of blank play-testing
I hope the previous paragraphs already made clear some of the advantages of blank play-testing, but let’s go into this a bit more.
The first advantage of blank play-testing is that you can start as soon as you have a game idea. You’re saving time on prototyping until you’re at least a bit sure that there is something worth pouring time into making.
I’ve also found that without anything written down, it’s much easier to make changes. “This blank card is now a face-down modifier to the battle, that will get turned face-up when we resolve the conflict”. You try that for three rounds and find that it indeed makes the game much more tense (or that it absolutely doesn’t work as intended, in which case you can easily try something else). No need to make actual changes, just a different mindset.
Because once I have a prototype there is an internal resistance to making changes: They take work, require new printouts (when you get to printed prototypes), etc. No such resistance when everything is empty anyway!
Finally there is the tactility of playing with “actual” pieces. I can play a game in my head reasonably well, but it’s far from really holding a card and playing it. Only then do you notice that this means you have a card less in your hand and that your deck will run out. Or that you need to figure out what happens when you play two cards at the same location.
Blank play-testing will not be for everybody. You’ll need to be able to keep some stuff in your head and you need to be able to do solo play-tests (could you do this with a group?!).
Also blank play-tests are a single step and in no way the entire process. At some point you’re going to need a real prototype, to pin down exactly what your componentst do.
Having said that, I find blank play-tests useful and I hope you will as well! If you try this, let me know what your results are and if you have further suggestions?
I’m very open to your ideas and thoughts, let me know in the comments or on Twitter if you agree or where you think I completely missed the point?!
Hi, I’m Bastiaan. The goal of this blog is to learn about game design. That’s hopefully for you as the reader, but just as much for me as the writer.