I recently attended all 3 days of the inaugural PAX Unplugged in my home town of Philadelphia. It was great showing off my home city to people (especially Reading Terminal Market). It was also way bigger than I expected, and there were people I never even ran into all weekend. Possibly because I spent a lot of my time Friday and Saturday in the Unpub/Alpha Build room, working on prototypes. It was a good weekend for prototypes, if not for the players.
Friday, I was getting feedback for a new game, Pirates on Board, and learned I needed to rework an entire subsystem, but it got a good reaction, so I guess I can keep working on it. I also got Mike Mullins to try out Onium, another Buttonshy Nanodaption based on his Pentaquark, and it went very well, so people can expect to see that soon in a Boardgame of the Month package.
Saturday, I had 3 games with me to test, including two brand new designs. But I chose not to set them up in favor of getting a few more tests of Iceburgh. Most of the playthroughs went as expected for a game I’ve been tweaking for a while. Players had fun, and I worked out solutions to several different design problems I had been having. But one collapsed before it was halfway done, and it might have been my most valuable test.
I could tell the test was going to be a bit of a challenge early on. It was two individuals, and the game tends to play better when players know each other. During the rules explanation, one of the players had a harder time with the movement/action selection system, and I ended up running through that part twice. The first few turns were typical for new players, as I usually help players see what buildings are available. But then it seemed like every turn I was pointing out a rule that was missed, using a trading action incorrectly, or paying the wrong price to build.
Finally, the player cheerfully upgraded the Town Hall, but there weren’t enough upgraded buildings yet. I hesitated, sensing that this would be the last straw for the player. And when I pointed out the restriction listed on the card, the player pushed back from the table and said “I’m sorry, I’m just not getting this, and I don’t think I can continue.” So we stopped the game about 1/3 complete.
No designer ever wants a player to quit in the middle of the game, but it’s also a great opportunity. The first thing I did was apologize. If the game isn’t working for the player, that’s the designer’s fault. (I mean that part of the game isn’t functioning for them. Not just failing to resonate because of theme or mechanics.) It takes a lot of courage for a player to admit that a game isn’t working, rather than struggling through, so I wanted to be clear that it didn’t ruin the playtest. In fact, it is exactly what playtesting is for because it highlights a problem with something I’m doing, whether it’s how I was teaching it, or how I present the information, or something mechanical that doesn’t make sense.
I asked the player if they would mind giving me a little feedback, so I could help pinpoint my problem, and they kindly answered a few questions about how they were visualizing the board, and how they were interpreting various icons. Part of the problem was how I was teaching the game, which directly impacts the rulebook. Visual explanation is absolutely critical for Iceburgh, since the shifting movement is pretty unique and hard to put into words. I immediately implemented changes to how I was explaining the game over the next few tests.
Another part of the problem was how I was presenting information. The player suggested having the rules nearby, so they could reference them. That means that I’m trying to front load a little too much, and more information needs to be visible on the board. They also suggested making it easier to see what actions were available. That’s a harder problem, but I took this with some other feedback and reworked the presentation of the ship card, which will hopefully make the possible actions clearer.
It’s worth pointing out that I had provided information to solve all of the issues. But simply presenting the information isn’t the same as making it accessible. You don’t get to feel smug as a designer by pointing out “Ah, it says so right here in the small text”. But at the same time, I felt while teaching, that I was pointing out a lot of exceptions. You can’t do this because of X. That’s almost right but here’s this other thing. Oh, here’s this one rule that only applies here. But if I really want the game to flow, I need to change how I present these rules so that they feel like a natural pathway, and not like walls being thrown up in the player’s face.
I thanked the player and apologized again, and tried to reassure them that it was a very helpful test, despite not finishing the playthrough. I also apologized to the other player, because I’m sure it’s no fun to have a game end when you’re doing well. I could have jumped in to complete the game, but that wasn’t the goal. I got a ton of great feedback out of the test, and that’s what counts.
It’s really easy to blame players for a bad test (and sometimes bad tests will be due to the players). But blaming players instead of treating the test like a problem to be solved won’t help your game get better. Especially when you’re aiming for a more lightweight audience, you need to find every rough edge and do everything you can to prevent the bad playthrough from happening on a player’s table. Having a game go smoothly is a great feeling, but having a game that doesn’t is an opportunity for improvement. It’s only a failed playtest if you don’t gain anything from it.