This session saw us continuing to refine our prototype from the previous weeks, which involved five monsters that each embodied one of the five senses. Our existing prototype had some interesting ideas, but there were still a number of problems with it that we needed to work out. In trying to address these issues, we ended up in a very different place from where we began.

The Starting Point

As readers of the previous posts may remember, the basic concept of the existing prototype was that the player navigated across the game board while avoiding detection by the five monsters that also inhabited that space. The protagonist was a shape-shifter, and had a long list of attributes that they could choose to take on. Each attribute could be perceived by one of the five senses, so the player could choose, say, a taste-related characteristic like "salty" or "savory," or a touch-related characteristic like "rough" or "cold", and so on. The five monsters also reflected the five-senses theme of the game, and each of them had only one sense with which to experience the world.

The game board was overlaid with a grid that was divided into large sections, and each section had a set of characteristics or attributes associated with it. Any objects in a section were supposed to have those associated attributes, and if the player did not have the correct attribute for a given area--for example, if the player had the "bitter" taste attribute in an area designated as "sweet"--they would be detected if a nearby monster had the appropriate sense. A player could only take on three characteristics at any time, and so had to judge which would be the best to choose. In addition, the player had to think of an object which had the three chosen characteristics in order to be allowed to use those characteristics.

In playtests, people found the idea of the five sense-monsters intriguing, and often had a lot of fun trying to think of objects that had a certain set of traits, but the gameplay itself was just too simple. There was very little strategy required, and it was usually very easy to avoid detection. In the event that a player did mess up and was discovered by the monsters, the effects of being detected seemed unimportant or inconsequential.

Fixing the Problems: A First Attempt

Our first try this week at fixing some of these problems involved a complete overhaul of the gameboard layout. Previously, players had found that the layout didn't give them interesting choices about which paths to take, and that it was too easy to tell which monsters would be coming in range and which traits would be required in upcoming turns. In the previous session, we had tried to deal with these problems by adding walls and obstacles to make the player's path more convoluted, but--possibly because of the small size of the board that we were using--we never succeeded in creating a layout that players found interesting or challenging.

So, in this session, we got rid of the walls, and instead of requiring the player to move from one side of the board to the other, we set up the board so that the player had to visit each of the four corners to activate four "switches" and then return to the center. We also changed the monsters' movement patterns to make them a little less predictable and a little more likely to run into the player or each other. Finally, we added the notion of health/HP to the game, so that the player would lose 1 HP each time they were discovered by a monster.

These changes were somewhat successful: the open layout of the board and, in particular, the increased unpredictability of monster movement made the player more likely to end up taking a path they had not originally planned on. Also, since it was harder for the player to predict which monster(s) they would encounter in the next turns, deciding which traits to adopt on each turn was no longer so straightforward. Unfortunately, the changes also had an unforeseen, game-breaking consequence: by the time the player had hit all the switches, the game had reached a state where the player was completely surrounded by monsters at the end of every turn, and thus unable to take on enough different traits to fool them all (because the player was still limited to three traits). Indeed, this was the first playtest where the player was unable to win.

A Dramatic Change

By this point, we were starting to suspect that the issues caused by the overly-simple layout and the system of choosing traits were inherent in the current set up of the prototype, and were unlikely to be resolved as long as we stuck with the idea of a player and monsters running around an abstract space divided up into arbitrary sections with associated attributes.

Thus, the next iteration of the prototype was a huge departure from previous versions. We replaced our large grid with a mysterious house that the player had to explore; we got rid of the extensive list of attributes for the players to choose from; and the monsters no longer wandered around freely. We also added a bit of backstory to the game, with the hopes of creating a more motivating scenario for the player.

The new version played out as follows: at the beginning of the game, the player was told that a friend was deathly ill, and the only hope of a cure lay in a set of six magical artifacts that could be found in a strange house inhabited by bizarre creatures (the five sense monsters). On every turn, the player drew a card from each of five piles of cards--each pile corresponded to one of the senses, and each card had a trait written on it. These five traits would be the only ones that the player could use on that turn.

After drawing the cards, the player then chose which of six rooms to enter (the house contained a bedroom, a kitchen, a workshop, a menagerie, a greenhouse, and a library) and rolled a die to see if they were successful in making it into that room, instead of moving from space to space as in the previous version. Then, a series of die rolls was used to randomly determine which of the monsters would also enter the room, and the player would have to choose which three traits they wanted to take on. As in previous iterations, the player also had to think of an object that had those traits. If the player was successful in convincing the "monsters" (that is, the GM) that the object they had transformed into belonged in the current room (a frying pan, for example, would make sense in the kitchen, but not in the library), then they successfully obtained the magical artifact hidden in that room. If they were unsuccessful in thinking of an object that belonged in the current room, the monsters discovered them and the player lost HP. The player lost the game if all their health was depleted, and won if they managed to acquire all six magical items.

There were a few glitches in our first playtest--for example, it was unclear how the dice rolls determined which room the player ended up in, and some of the aesthetic elements were a little confusing (like our forgetting to include doors leading into the various rooms of the house, which didn't help the player's confusion about movement). Minor hiccups aside, though, it appeared that the dramatic changes we had made had had the desired effects, as the player seemed to enjoy the challenge and we didn't get any comments about the game being too simple.

The addition of drawing attributes from decks was also a success: not only did it avoid overwhelming the player with a huge list of possibilities (something that multiple players of previous versions had commented on), our playtester liked that it gave him the chance to think of possible objects ahead of time and then make a strategic choice about which room to enter.

This new version was not perfect, of course. One big problem our playtester had was that he was unable to tell what determined whether an object he came up with would be accepted by the GM. He couldn't figure out what, if any, criteria were being used to judge the ideas, and he felt like anything he came up with would be accepted, which eliminated all tension. There was also still one nagging problem from previous versions that we hadn't fixed, namely, the consequences of being discovered. Losing 1 HP was not interesting to the player, particularly in the scenario we had concocted, where (the playtester felt) there were opportunities for more compelling, narrative-based consequences.

An Unexpected Suggestion

Based on the feedback from the first playtest, we made a number of tweaks to our new version of the game. First, we fixed some of the obvious glitches, like putting in doors (we learned a good lesson about how even seemingly inconsequential design decisions can have significant effects on players and player expectations). We also made the player's movement simpler--now they could just choose which room to go to next, instead of having to roll to determine if they made it to their intended destination. However, we did add another hurdle for the player by concealing the names of the rooms at the beginning of the game, so that the player would not know the identity of a room until the first time they entered it. We also tried to simplify the framing fiction of the game.

We also added to the consequences of being discovered, since the first playtester had felt that just losing 1 HP wasn't enough. This time, when the monsters found the player, the player would be tossed from the house and one of the magical artifacts that they had acquired would be taken from them and randomly placed in one of the rooms of the house, requiring the player to do more exploring to find the artifact again.

Finally, we tried to work out a more concrete system for deciding whether to accept or reject a player's choice of object, but this was difficult--indeed, the problem of how to create an objective set of rules to govern this part of the game was something that had worried us from the very beginning. While it was fine to have a human being doing the judging during the paper prototyping phase, we couldn't see how we would adapt that for a digital version of the game.

In an unexpected development, our final playtester came to our rescue by pointing out that the prototype we had would probably work best as a multiplayer or party game. The players themselves could take on the role of the GM or judge, and decide among themselves whether a certain object should be accepted as appropriate for a certain room or not. In addition, competing against other players to be the first to collect six artifacts would add tension and make the game a lot more interesting than just trying to find those artifacts before you lost all your health.

This idea had never crossed our minds during development, but our tester was definitely onto something. It might mean abandoning our original idea of this prototype as a precursor to a digital game, but it would resolve so many of our issues--it would even allow us to get rid of the problematic health mechanic, since the win/loss state would just be whether it was you or one of your opponents who collected the six items first. By the time we finished that last playtest, it was time to go and we didn't have time to work on the multiplayer aspect that day, but it was definitely an intriguing concept and opened up a lot of new avenues for us to explore.

Final Reflections

We made good progress during this session, and although we were by no means finished with the prototype by the end of the day, we had a fun, playable game and a good idea of possible future paths.

In addition, this week's prototyping also brought home a lesson that was probably good for us to learn: sometimes when there's an aspect of a game that's really giving you trouble, the best thing to do may be quite drastic--you may have to just get rid of it. We were attached to the idea of having the player move their token from square to square across the play space, but keeping that mechanic meant that we were unable to get around the problem of overly simple navigation that it caused. However, it turned out that the ability to choose the character's exact path through the space was not as important as we had believed, and getting rid of that aspect improved the game dramatically. Removing the grid system also freed us from the system of associating a specific set of attributes with each section of the board, a system that all our playtesters found too obvious. It took us two weeks and a certain amount of desperation to reach the point where we were mentally able to scrap these broken mechanics, but it ended up being worthwhile.