Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Rapid prototyping is great for getting a feel of the game - but it's lousy for looking under the hood. There's not enough bothersome clunk to let you see all the flaws clearly. That's why your first prototypes should be rough, ugly and immobile.
With the hordes of rapid prototype tools available today it’s easy to cobble together a rough draft and start playing. It’s agile, lean, scrum, six-sigma and all that, right? We start with something easy, test our way to success and be releasing withing weeks. Hell, we can release a pre-alpha right now.
Hold your horses, pardner. Why would you want to do that?
Why would you want to prototype immediately at all?
See, there’s a value we’re missing here, a way of thinking that is lost in the process of constant, rapid improvement. With all the clunk removed from the prototyping process we’re left with a game where we’re blind to the clunks. We’ll get brainclunks. Yeah, that’s an actual world, as of right now.
There’s an advantage to good ol’ waterfall style game development, at least at the very beginning of the process. If we start out with a clunky prototype, one that takes effort to handle, we must focus on the basic game mechanics, the stuff that’s supposed to make our games fun. That’s what designing on paper does. You can’t script away the boring, broken pieces, can’t smooth out bad game play with motion. No “it’s only ten clicks away, let’s click as rapidly as we can and get over the boring part”. When the boring part’s on paper, and you need to move every paper once for every click, you’ll feel the boring as an un-peeled horse chestnut up your wazoo.
That’s good.
You want to feel the boredom. You want to feel it right through your excitement over your grand new idea. You want to feel it as acutely and as rapidly as possible. Shove those chestnuts in, baby!
That’s the quickest way to break your design.
And break it you will, whether it’s the itsy-bitsy breakages in an agile process or the huge, big ones of “uh-oh, this game stinks”. Get the big ones out of the way first, then start in on the little ones or you’ll end up realizing that every patch is just trying to give CPR to a carcass. The horse was dead before you rode it in, bro. That’s why you had to carry it over. Smell the stink and either start from scratch or get a new horse. Don’t polish the corpse, you’ll only end up with more chestnuts.
No, we’re not telling why the horse died.
But back to business. Designing using clunky tools exacerbates the problems in a design. So playtest using clunky, ugly, smeared materials with coffee stains on them. Playtest using bad colors, blacked out images, unreadable type. If your testers still enjoy the game then you know that you’ve got a winner. Then you can start coding.
Because you’ve got a vision that survived paper playtesting.
Of course you’ll have another problem: who’ll want to playtest a badly executed game idea? The sad answer is: only you. Only you will care enough to actually try it out. If you’re lucky, very, very lucky, you’ll find a friend or two willing to help. Value those friends, and don’t abuse their willingness to do clunky playtests.
So what do you need to do a clunky playtest? Paper, pen, that’s it. Maybe a pair of scissors. Maybe some dice. Think “tabletop 100 years ago”. That really is all you need and you need less than you think you need.
Me, I’m a board game designer. I’ve got lots of nifty miniatures, cool meeples, cubes, life counters, dice in every shade and color imaginable. I’ve even got custom boards and playmats with everything from castles to starscapes on them. I don’t use them. Not in my clunky platests.
The nifty bits are reserved for when I take my game public, for the betatesting when all the problems I can hunt down solo are dead and rotting. When I playtest solo I try to do it with as few elements as possible, with as few mechanics as possible and as little as possible. That’s right. You don’t want to playtest your game a lot. Remember Yoda: break, or break not, and you’d better break if it’s even remotely breakable.
Here’s an example from one of my playtests:
It’s a playtest of a thematic population control wargame. Can’t you see the Mongol hordes sweeping in from the right? Me neither, and that’s the point. As I sat there trying to keep track of invisible armies with only pen and paper (no miniatures, remember?) I realized that my idea for this game wasn’t enough. It simply wasn’t fun the way the design stated it should work.
It took me all of half an hour to figure that out. If I’d had toys to make it more appealing it would have taken me two hours. If I’d have had a full panoply of graphics and minis it would have taken me dozens of playtests. Cool toys can hide a lot. So remove them and get down to basics until you are confident that you can spot the flaws and potential flaws past the pink puffs of your enthusiasm blows in your face.
But when you get to that point you’re pretty much an expert.
More playtesting articles:
This post previously appeared on Wiltgren.com - Game Design, Writing and Personal Development. New updates every Monday and Friday.
Read more about:
Featured BlogsYou May Also Like