In my spare time I like to make board games. I’ve made a couple over the years, and have gone to a lot of conventions to teach and playtest them. Most of my hands-on user testing has been at these events, both observing how players interact with the games and gathering positive and negative feedback through discussions and surveys.

Since the publication of my game Camp Pinetop in 2020, I’ve become interested in the digital side, learning object-oriented programming, and making a little puzzle game about trick-or-treaters trying to collect the most candy they can in a single night. Working title: “Sugar Heist 1999.”

There’s a big difference when it comes to learning the rules of an analog game versus a digital game. Tabletop players will read through a multi-page rulebook, but video game players expect the game to teach them, and to do it nearly invisibly. Long gone are the days where a video game player will read the manual that came with their cartridge or CD. The best practice now is to mask your tutorials as game levels and avoid large expository text. To that end, the first “level” of my game starts with just one player-controlled trick-or-treater (eventually there are three), and my hope is to introduce basic movement, the different phases of a turn, and the goal of each level.

Instead of teaching this game to playtesters like I did with tabletop games I made, I’ve opted to just observe them play through this tutorial level to make sure it’s successfully introducing them to the rules.  

The first two tests went great – both players were able to reach the end of the level without needing my help. There were some struggles. One phase requires you to drag a piece of candy from the house to the player’s candy bag, but the player was trying to drop the candy off on top of the player avatar, which meant that the candy snapped back to the house. It was a totally reasonable thing for the player to do, but I just didn’t foresee it. I solved that issue by expanding the invisible drop-off zone to include the player avatar. Now, as long as the candy was released in the general area, it would get dropped in their bag.

The third playtester struggled to get to the end however, and eventually I had to intervene. The problem had to do with movement – for the tutorial there are 3 phases in each turn – “movement,” “treats,” then “tricks.” This player was moving their token, then wanting to move again, but not processing through the other phases which would allow their movement to be reset. They just saw that the “movement” phase indicator was highlighted and didn’t understand why they couldn’t keep moving. Part of the problem was that the player didn’t understand why their movement was limited – in later levels there are other AI-controlled trick-or-treaters that take their move during a fourth “others” phase. Allowing unlimited movement during the player’s movement phase would fundamentally break the game later on. But their confusion was warranted, and something I didn’t anticipate.

One solution I thought of was to automatically move onto the next phase once the player moves. This was in opposition to a design decision I made early in development, which stated that the player should have to commit to their moves by pressing a button to go to the next phase. This would allow them an opportunity to fix any mistakes. My concern was that a mistake would be costly in terms of time lost, as they would need to restart the level. However, between the time of making that design decision and playtesting, I had implemented a “restart turn” button, so a bad decision no longer meant having to restart the level. The player could just undo (at most) a couple of moves they made since their turn started. 

I did make that change, and in addition to reducing that early game confusion (hopefully, anyway – still plenty of playtesting to do), it also saves the player the tedious step of pressing the “Next Phase” button a dozen or more times per level.