In honor of the Global Game Jam this past weekend, I’d like to start a new, irregular series for Drawing Live: Game Design 101.
I talk a decent amount about game design. It’s my passion and profession, after all. However, it’s always in the context of Magic and usually on the design of a particular card or cube. In Game Design 101, I’ll share some of the tricks of the trade I’ve learned. This series is geared towards anyone who’s ever wanted to design their own card, mod a game, or create their own new game. I’m going to try and keep these short and sweet, since these are skills best learned via application rather than waxing poetic.
What is a Prototype?
Broadly speaking, a prototype is any incomplete version of a game (or game component). The easiest way to think of a prototype is an unfinished slice of the game you’re potentially making.
Behind every polished product lies a substantial, if not enormous number of preceding prototypes. Every Magic set goes through a series of revisions, likely changing several times a week between its initial conception and when development starts its final passes. Some prototypes, particularly those near the release of a game, are identical to the game, save some final tweaks and visual polish. Some prototypes are just incomplete slices of the game (such as making a nonfunctional menu system for a video game, trying out various interfaces or art directions, or designing a bunch of commons to see if a particular mechanic works). Some prototypes don’t even resemble the final product—they might have mechanics that were saved for another time or proved to be unfun.
Why Prototype?
It’s not surprising that the majority of designers don’t create a fully fleshed out, balanced, and enjoyable product on the first try. There’s usually some trial and error along the way. That said, this trial and error goes much faster if the designers understand why they’ve made each prototype.
Every good prototype is designed to test or prove something (or potentially several things, if you’re later in the process). Behind every good prototype is a question. This question can be as simple as, “Is this at all fun?” or “does this even work?” It can also be as complicated as “Does this tweak to the game’s economy help balance the first player advantage?” or “does Walking Corpse replacing Headless Horseman give black the bump it needs in Limited, or is it too little/too much?”
If you have a prototype but don’t know what it’s for, consider what has changed between it and the previous prototype. That’s probably what you’re testing, and the question you’re probably asking is whether that particular change is a good one. If so many things have changed that you can’t accurately gauge the effects of what what you’ve changed, then your prototype is probably both too different from its predecessor and asking too many questions at once.
How Do We Prototype?
The biggest mistake I’ve seen amateur designers, professional designers, and myself make is spending too much time on a single prototype. Designers love to add things, polish visuals, and add even more things. The problem is that new content muddles the simple questions a prototype is supposed to answer. Furthermore, early-stage visual polish is unlikely to align with what the game eventually becomes.
The best prototypes contain what they need to test, and no more. They are created quickly. They only have enough visual polish as their questions need in order to be answered. When they’re tested, the designers take copious notes. After testing (possibly several rounds of it), the prototype is logged, modified (or even scrapped). and a new prototype is created. This is called iterative design, and it’s the best method I know to arrive at a satisfactory product.
Fail Fast
This is the best, and most succinct credo I know for prototype design (though I did learn it from improv first). Don’t try to create perfection in your prototypes. You should aim high for your project, but each prototype is not your project, but a rung in the ladder towards the end goal you might still be figuring out along the way.
The goal of every prototype is to test something, and to do it quickly. A prototype that is miserable to play, not at all what you wanted, or just broken isn’t a failure—it successfully demonstrated something. It’s not any better or worse than a prototype which is close to the final product. The only bad prototypes are those which reach too high and fail to produce good, actionable data. The prototypes which spend too much time in the shop, look too nice, and receive too much polish, those are the worst prototypes. It’s better to rapidly create a thousand prototypes which all fail to do what you want than to create one prototype which works. A thousand data points are so much more informative and useful than a single one.
Fail fast and you’ll succeed much faster and more thoroughly than if you’d never failed at all.
And as always, thanks for reading.
—Zachary Barash
Zachary Barash is a New York City-based game designer. He’s played Magic since 1994, but went on a long hiatus, like most folks. He’s currently pursuing his MFA in Game Design at NYU and designs for Kingdom Death: Monster, a game that is most definitely not Magic.