Teaching vs Testing: How to explain your game.
Recently, To The Death! attended a (very insightful) developer's workshop. While there, we received quite a bit of useful feedback, but one experience stood out the most, and I would like to share it.
We had just finished presenting at Just a Game Con, a board game convention where we had showed Mort-A-Mania all weekend. After having shown and demonstrated the game for several months, including two such conventions and countless other impromptu sessions at game nights around town, we felt very confident in our ability to teach Mort-A-Mania to new players.
So, when we sat down at the developer's table and were asked to playtest our game, we launched into the same speech we had practiced so frequently. We started with a short description of the goal of the game, followed by a rundown of the phases of the games and the uses of each card as we played the first hand. From there, we continued to teach and play simultaneously, always providing additional information so the new players never felt lost.
It wasn't until about halfway through the game that one of the developers mentioned, "You know, its difficult to tell how easy it is to learn this game when you tell us about everything. Just explain the bare minimum, and let us work out the rest on our own." I was dumbstruck, but I took his advice and kept quiet the rest of the game. It was clear to see, however, that the damage was already done; the whole table was already primed to see the game through our eyes, rather than give their own perspective. By elaborating on every mechanic, we prevented ourselves from getting truly unbiased feedback from a valuable resource.
The root of the problem is a fundamental misuse of our audience. The speech we had prepared was designed to teach the game as quickly and painlessly as possible, while getting players excited about the most interesting parts of the game. We sought to pull players through the awkward learning stages of the game, so as to experience the full flavor of Mort-A-Mania in a single play session. In short, our standard approach was a sales pitch -- designed to highlight the coolest and best parts of the game from the start.
This pitch worked great for us with general audiences: every session, we would get excited inquiries about release dates and newsletters. However, for a testing scenario, it was more of a hindrance than a help. Our playtested had fun playing, but were unable to tell us if any rules were too complicated to understand or if there were any unusual interpretations of rules on cards, because we always explained everything the moment it came up.
We were very fortunate to have someone aware enough to point this out to us; in fact, if they hadn't, we certainly would never have noticed. This kind of oversight can be dangerous, as it can lead to serious problems down the road for players when you aren't there to mention something. Issues like unclear conflict resolution or propagating misunderstandings tend to crop up in areas you don't think about (usually because you aren't thinking about them); these are the reasons you should always blind playtest your games without being in the room. But, even before blind tests, it is good to play some games where you give as little information as possible to allow players to find the faults. Testing isn't about making the testers have fun, it's about finding problems with the game so the buyers can have fun.
So, when you are testing your games, be sure to use a different pitch than when you sell. Believe it or not, it's much harder to find good testers than good customers, so be sure not to waste those opportunities!
--Dakota W Winslow