Ten tests isn’t really a lot when it comes to gathering data on a game, but this one’s still very new. I’d actually come up with the enemy AI (not the digital kind, it’s just what an automated system in a co-operative board game is generally referred to) a few weeks ago and liked how it performed. That gave me a leg up on creating a similar system for the players, but with actual decisions to be made by actual humans. This helped me hit pretty close to the mark for creating a functional play loop in my earliest builds. The big questions after that were

A) Is it fast,

B) Is it accessible/intuitive, and

C) (Most importantly) is it fun?

Right now, I’ve been dual-pathing my prototypes. I have a physical prototype — shown in yesterday’s post — with bags and cards and other simple bits (yup, vague) that I can take to my Friendly Local Game Stores or other real-world places to test it in person. I’ve also built a version of it in Tabletopia, an online, web browser-based virtual tabletop. The latter lets me host guests from anywhere in the world, and is actually faster to make edits and updates to than the real paper-and-bits version. Cheaper too, since I don’t need to buy supplies. I’ve tested Disco Candybar both ways, and I’m happy with the way it demos in either platform.

Right away, my testers and I have seen a consistent pattern in how quickly players pick up how to play. Any given combat sequence is designed to last 4-6 rounds. As I want the game to appeal to, well, my kid with a limited attention span, I went in from the start knowing that these sequences couldn’t run any longer than a few minutes. Anything longer than 10 minutes without a significant tonal shift was too much. To that end, I was thrilled to see that after the first round of teaching the basic player routine, most rounds after that generally take the entire team of players less than two minutes to resolve. It plays fast. Question A answered.

My combat system passes the speed trial.

Within that, I also was able to answer Question B, the accessibility gate. In every single demo I’ve run so far, players got the hang of what to do — and how to try to optimize their turns — in, at most, two rounds. Intuitive? Check.

The last question is the one game designers can languish about for days/weeks with any given game concept. Lots of ideas lead to functional and even interesting or novel play patterns. The catch is that those patterns aren’t always fun. Fun is the number one goal; without it, there’s no reason to play most games again, and without a strong emotional response to a game (ideally a positive one), that game will invariably be forgettable. If you can’t make it fun, you’re probably dead in the water.

So far, my testers have all found something or things plural that they’ve genuinely enjoyed. I can’t express how relieved/proud/happy I am with passing just that part of the tests. If the speed and accessibility still needed a bunch of work, I’d at least know I was on the right path. Now I know I’m not just moving in the right direction, I know I can start confidently expanding on all the ideas I have for the game.

As negatives go, I’ve heard complaints that the balance is off. Sometimes the fights are far too easy or hard to win. Other times, the balance of the player roles feels off. In one game, the Wizard character was outpacing the Warrior for sheer damage output by leaps and bounds, showing that the adventurer with the sword who just wants to slice up baddies just wasn’t aggressive enough. Thankfully, all of these are comparatively easy to fix with some adjustments to numbers, and in nearly all of those places, have easily identified knobs to turn.

Some of you reading this are already seasoned designers with a process for playtesting and gathering data. Some of you are starting out as game designers, or are simply interested in the process. For all of you, I have some advice in how to get the post-play conversation with testers going. It goes back to my kid again, and it’s something my wife started with him after each day of school when he was around six years old.

High/Low/Buffalo.

The name sounds silly enough that it’ll almost always put testers in the right headspace to give candid responses. Candid responses are usually pretty meaningful, and that’s what you as a designer need. The brevity of the system gets you right to the talking points you’re looking for, and takes a lot of pressure off of the person reviewing your game.

HIGH
“What was the best part of the experience for you?” If they can’t answer this at all, you know it’s time to recalibrate. If they can, you know where not to mess with success, or what to steer into as you make other adjustments.

LOW
“What stood out to you as the least enjoyable aspect?” Brace yourself. Not necessarily because someone else’s truth can hurt, or that you’ll disagree with what they suggest, but because getting an answer to this can often be like pulling teeth. It’s vitally important that if there’s something to get, you get it here though, so unless they’re asking to play again right away, try to listen carefully for any loose thread they begin to describe.

BUFFALO
“What surprised you or stood out about this game? What will you remember in particular about it?” This is either going to feel great and validating, or it’ll give you some of the most precise and actionable feedback you can use. Like the previous question, it can be hard for players to find an easy answer for, but once that faucet turns on, you’ll get a great dialogue going. It can also give you some great talking points for when you start pitching the game to publishers.

These three questions (and the three earlier) will get you valuable feedback, I guarantee.

With that, I’ll leave you to whatever project you’ve got that needs someone else’s attention or feedback. I hope it helps you get what you need to make whatever you’re working on even better.

---