Being a relatively new game designer -- I'm still learning and have not published any games yet -- it seems to me that if I'm going to start writing a blog, I ought to write about what I've been learning, and either be proven wrong via scathing Internet comments, or else end up with something that other budding designers might find useful.
Since I've been relentlessly play testing my latest game, SysHack, and have only recently come to the conclusion that it is Good Enough (more on that in a moment), then it makes sense to start with my experiences testing that game.
So, without further ado, here are some things I've learned while play testing SysHack.
Your Game is Never Almost Done
This is paraphrased from advice that a friendly publisher told me when I first started moonlighting as a designer. If I think back on it, I used to be overconfident when estimating where I was in the design process, and I probably still am to some degree. But at some point you realize that, 10 play tests ago, you were absolutely certain you were almost done, but obviously that wasn't the case. That kind of estimate does you no good now, either.
In other words, it's done when it's done. And even then, you'll probably think of some changes to make.
For SysHack, when I say that it's Good Enough, I'm basing it on a few indicators:
- The gameplay feels right to me. Mostly.
- The tweaks I'm making are becoming smaller and smaller. Currently the changes I want to make are so small that they would be a waste of time.
- Most importantly, play testers are more frequently asking me, after finishing the game, if they can play again.
All of this comes together to lend the picture that SysHack is reaching the point where it becomes a game people play for fun, rather than a work-in-progress that people play to test.
But even now, I'm terrified of calling the game Done without the risk of getting ahead of myself and eating my words later. But it's like the original Star Wars Trilogy. George Lucas kept on thinking of new changes he could make, and then he actually made them. But everybody knows that in the best version (before the needless fiddling), Han Shot First.
People Like Pretty Prototypes
There are two types of play testers: people you know, and people you don't know.
The people you know have the advantage of (hopefully) being more willing to play a game you made ad infinitum. This is especially handy during the first few play tests, when your game -- only just becoming a physical manifestation of the downright brilliant idea inside your head -- will most likely suck. Heck, SysHack started life as a game only a mother could love. But my friends were good sports about putting up with it and giving me the harsh feedback I needed.
For the suck-tastic first version of your game that will never leave the dark dank corner of your basement, scrawling some text on some index cards or using some very basic print-outs is probably fine.
But what about when you're ready to present the game to the public, say, at an Unpub event? The public is full of people who may later decide to give you money in exchange for your game once it's published (or during its Kickstarter campaign). So, it's kind of handy if they see the value of the game while they're helping you improve it.
Evolution of the Courier Role
To this end, there is a handy set of guidelines for prototypes courtesy of my favorite play testing group, Break My Game.
These guidelines come down to two things: Make it presentable; make it functional.
You can often find some very cheapass ways of getting your game there with little more than some printable sticker sheets and a decent paper cutter.
There's a good reason to do this. In a way, a public play test is like an internship. Your game is new. With any luck it's got a bright future ahead of it. But for now it's here to gain experience and help it toward that future. It could be a brilliant multi-faceted jewel of a game, but if it shows up looking like flimsy paper cutouts and bad hand writing, then the public may be less inclined to give it the chance to bloom that it so greatly deserves.
Finally, if you want to make your games look pro, consider checking out Drive Thru Cards, The Game Crafter, or Print and Play Games. For SysHack I've been using Drive Thru, and I've heard good things about both of the other two. Which one you use comes down to personal preference. But I've definitely seen some great looking prototypes that use the cheapass methods, so it's your call.
Write Everything Down
Speaking of the public, there's a lot of those guys. Like, really a lot. When they sit down to play your game with the understanding that afterwards they will have an opportunity to critique it, you're going to get so many opinions, man!
The trick to handling all those opinions is to recognize who to listen to, and who to actually listen to. You are listening and writing everything down, right? I mean, literally recording every suggestion you get into a notebook, no matter how good or bad the idea?
Think of it like panning for gold. You scoop all the mud and the sand into your pan, and then you sift it all out until only the gold remains. If you don't scoop the mud, you don't get the gold.
You won't find gold every time, but there are a couple good ways to make sure you do find it when it's there:
- Did you get the feedback from somebody in your target audience?
If a euro gamer plays your party game, and suggests ways of rebalancing the point system, it may not be the most appropriate point system for your game. - Are you getting the same feedback separately from lots of people?
In SysHack, there is a role card called the "Overseer" which for quite some time was the center of many a tester's feedback. So I focused on that until eventually nobody was complaining about that role anymore.
I should also mention gameplay charts. This is the other part of writing everything down.
I met another designer who had a spreadsheet he would print out and bring with him to play tests, which he would use to chart exactly what choices players make during his game. This would allow him to notice trends, or be able to pick up on things that players did but never thought to mention when giving feedback. Having recently assimilated that practice myself, I can say I'm glad I did (when I remember to do it, anyway).
This might not be practical for all games, but I think most games would benefit from some kind of chart or another.
Experiment Massively
This is what inspired this post, and is one of the most interesting things I've learned through experience. It's all about letting your game fall hard so you can rebuild the pieces into a stronger whole.
New designers (myself included) have a nasty habit of holding their game ideas sacred. We place our idea on a pedestal and look at it from behind a velvet rope, like it's a valuable Resaissance sculpture in a museum. Maybe every once in a while we'll notice an unsightly smudge on the design, so we'll take our washcloth and wipe it down with a non-abrasive solution. But no big changes; that would ruin the art of the piece. So our alarms will blare the moment somebody takes it out from under the glass, pulls out a hammer and chisel, and starts chipping away.
Except...
Right now, your game is a lab experiment, not a show-piece.
That guy just play tested your game the right way. Maybe he just played in a way that he thought he ought to be able to play, or he made an assumption where your rules didn't fully account for the situation, or he played completely by the rules and just used an unorthodox strategy. Pay special attention to these kinds of things, because if you catch them, your game can become so much better.
Be willing to rip apart any and all elements of the design.
A while ago, at the recommendation of a particularly astute tester (a fellow designer I have never personally met but who blind tested a PnP of my game), I made a completely experimental version of SysHack where, instead of having data cards start in the center of play, everybody started with one in their possession.
For context, I should mention that data cards are things you have to acquire and hand to another player (who is hopefully on your team) in order to win the game. Having one at all times was just not something I considered viable, but I decided to give it a go anyway.
In order to accommodate this one change, I had to increase the number of data cards (including adding a new type of data card), I had to completely change everything that dealt with data cards in the center, I had to update some of the core elements of the game... basically, it was a small suggestion that required big changes. I had to smash the game to pieces and rebuild it.
By doing so, I ended up refocusing the game on better player interaction. This in turn got people more invested in the game. And best of all, the spirit of the game was still completely intact, if not improved.
Of course, that wasn't the final piece of the puzzle. There have been essential changes since then that made the game even better. But that one change made a lot of things click into place. And I can thank my play testers for that.