Implementing Lessons Learned from Paper Playtests
The first playtest was scary. I knew that I would find a world-shattering bug that would throw the whole game out of whack. Sure enough, during the very first session of Menagerie we couldn’t even get past a single turn. I had spent hours and hours working this out in my head, even running playtests by myself, controlling all the characters. I had a clear picture of the player behavior I was hoping for and I’d designed a system just for it. What went wrong?
My biggest mistake was forgetting that people don’t stop to consider all the elements of a system before beginning. They just jump right in and do anything they can to win, regardless of whether it betrays the fiction of the game. I should’ve been prepared for this, interaction design teaches you that users will do whatever it takes to get to their goal, even if it’s not the intended solution. We even have a fancy made up word for it: satisficing.
Fortunately my playtesters were all smarties so we quickly hashed out some potential solutions. In under an hour we had solved all the game-breaking problems. Next time we met to play? Finished a whole game without any major incidents. That was a huge milestone for me.
The second lesson I learned from testing is to come with your rules written down, like in complete sentences and shit. I had it all in my head or as fragments in a notebook. Inherent flaws became immediately obvious as soon as I said them out loud. I definitely could’ve done that process by myself.
Another reason to have written rules is that you have something to work against when coming up with revisions. Being able to look at the whole system makes a big difference when you’re wondering about the effects of a potential change.
Now that I’ve ironed out the major game-breaking flaws, my attention has turned to balance. I’m making sure the game still adheres to my design goals and constraints, or revising my goals/constraints in the case of conflict. After the second playtest I created a short list of the biggest problems in the game, based on my own observations and player feedback:
No compelling reason to break from the group
Breaking from the group seems too hard to try
Wrangler has a weak competitive advantage/ability
Combat is too complex and mathy
Turn order gives advantage to last player to go
It’s important to acknowledge that these issues may be due to non-mechanical problems. I could’ve explained the rules poorly, or perhaps the outcome of a single session was exceptional. I’m not putting too much stock into these until I can confirm that they’re reproducible.
That said, I did sketch out a few solutions for each of these issues that I can bring out during the next session. This loop of identifying imbalance and testing solutions will be my main activity for a while.
There’s no way to know when I’m done, but eventually I’ll be focusing on issues so granular that they’re only appearing in a small number of games. That I’m designing this to be an iPhone game, not a board game, gives me a huge advantage. iPhone games can be constantly evolving through patches, while board games need to be done by the time they’re shipped. On the other hand, I don’t yet have a plan for getting the resources to code this, so the paper prototype might just be the only implementation that ever exists. We’ll find out!

Implementing Lessons Learned from Paper Playtests

The first playtest was scary. I knew that I would find a world-shattering bug that would throw the whole game out of whack. Sure enough, during the very first session of Menagerie we couldn’t even get past a single turn. I had spent hours and hours working this out in my head, even running playtests by myself, controlling all the characters. I had a clear picture of the player behavior I was hoping for and I’d designed a system just for it. What went wrong?

My biggest mistake was forgetting that people don’t stop to consider all the elements of a system before beginning. They just jump right in and do anything they can to win, regardless of whether it betrays the fiction of the game. I should’ve been prepared for this, interaction design teaches you that users will do whatever it takes to get to their goal, even if it’s not the intended solution. We even have a fancy made up word for it: satisficing.

Fortunately my playtesters were all smarties so we quickly hashed out some potential solutions. In under an hour we had solved all the game-breaking problems. Next time we met to play? Finished a whole game without any major incidents. That was a huge milestone for me.

The second lesson I learned from testing is to come with your rules written down, like in complete sentences and shit. I had it all in my head or as fragments in a notebook. Inherent flaws became immediately obvious as soon as I said them out loud. I definitely could’ve done that process by myself.

Another reason to have written rules is that you have something to work against when coming up with revisions. Being able to look at the whole system makes a big difference when you’re wondering about the effects of a potential change.

Now that I’ve ironed out the major game-breaking flaws, my attention has turned to balance. I’m making sure the game still adheres to my design goals and constraints, or revising my goals/constraints in the case of conflict. After the second playtest I created a short list of the biggest problems in the game, based on my own observations and player feedback:

  • No compelling reason to break from the group
  • Breaking from the group seems too hard to try
  • Wrangler has a weak competitive advantage/ability
  • Combat is too complex and mathy
  • Turn order gives advantage to last player to go

It’s important to acknowledge that these issues may be due to non-mechanical problems. I could’ve explained the rules poorly, or perhaps the outcome of a single session was exceptional. I’m not putting too much stock into these until I can confirm that they’re reproducible.

That said, I did sketch out a few solutions for each of these issues that I can bring out during the next session. This loop of identifying imbalance and testing solutions will be my main activity for a while.

There’s no way to know when I’m done, but eventually I’ll be focusing on issues so granular that they’re only appearing in a small number of games. That I’m designing this to be an iPhone game, not a board game, gives me a huge advantage. iPhone games can be constantly evolving through patches, while board games need to be done by the time they’re shipped. On the other hand, I don’t yet have a plan for getting the resources to code this, so the paper prototype might just be the only implementation that ever exists. We’ll find out!