Julia Keren Detar

Thinking Fast and Slow

There were many interesting revelations during the development phase of the game. One of my favorites was the solution to a challenge that we struggled with for a very long time.

 

In Mushroom 11, you control a mushroom by deleting parts of yourself. You are sculpting, not pushing or nudging. This concept is extremely hard to understand because it looks like you are pushing, and players who are used to playing platformers have a very different set of expectations. They assume that they are directly in control of their character, and in this game there is no such direct control. Getting this concept across was challenging. We decided to teach this with a puzzle as no amount of communication would affect players' behavior. (We would actually tell early playtesters this concept, they would acknowledge this, and of course this would have zero impact on their performance.) 

​

The Lava Pit

So we crafted a puzzle that would require players to sculpt a bridge to get over the lava. The pit was too far across for players to just push themselves over. We naively thought, they would fail and observe and rethink. Instead, rage quitting happened.

In hindsight, it's clear this would fail. It looks like a tunnel you zoom through and push yourself over. It didn't address what we wanted and worse, it made players frustrated.

​

So then we thought, how do we communicate that they can't push themselves over? Maybe adjusting the tunnel. If the tunnel starts low and then finishes high, maybe players will think then that they need to build up to get to the tunnel. After all, in this version pushing forward would just lead to a wall. It did perform slightly better but it still ended in a lot of rage quitting. I thought we might be on the right track and then had a breakthrough: put the entry tunnel on the top.

​

Placing the entry tunnel on the top made every player slow down, analyze what they were doing, and carefully sculpt their mushroom toward the other side, no rage quitting. This worked! But why? 

​

In Daniel Kahneman's book Thinking Fast and Slow, he makes the case that humans evolved to be fast interpret machines. If we think we know how something will work, we assume so without much questioning. The way to break that is by purposely tripping people up on their assumptions. Give them a scenario that challenges their assumption or schema and they will easily reconsider. In our case the assumption was that players can push their mushroom and it will squeeze over to the other side like playdough. Placing the entry tunnel on top directly challenged this assumption or providing what we call a schema break. Pushing down would land the mushroom right in the lava. Players had to slow down and rethink. Schemas are assumptions that users have about how something will work or a framework of associations for easier recall. Most of the time it is important to use schemas and not break users' expectations on how something works. But doing so when necessary can be very powerful. 

​

We humans are incredibly smart but being smart takes time and resources, and we were designed to conserve both. So we go through life mostly on autopilot, not even aware that we are. 

​

UX Testing on an Indie Budget

Being a small indie team meant that we had little resources to invest in user testing, so we applied to as many shows as we could afford, to get user data in addition to marketing. Shows provided a nice pool of testers because at shows people have limited attention spans. Players would leave immediately once they lose interest, or are struggling, so problem areas are easy to detect. But we also had to be aware of the audience at these various shows and to take into account whether they had a previous vocabulary of gaming conventions. Our game questioned platformers so fundamentally, so avid gamers often struggled more than casual or 'non-gamers'. 

​

Challenges of UX in Mid to Late Levels 

Of course having a limited user testing pool came with its own unique challenges. Most people at shows, even when engaged, will only spend so much time playing. So we crafted a good design experience for the early levels, however we then relied on our fans for feedback on the later levels. Fans tend to skew more engaged and play at more expert levels than the general public. As a result we had a disconnect between early and later levels in terms of challenges, and later had to retrofit problem areas.

​

Hiring and keeping in touch with a pool of users to make sure that we test all the levels might have corrected that or at least given us insight on some of the problems in the difficulty level. But there are also some fundamental design lessons learned by those late level mistakes: 

• The designers will always skew more difficult because of expertise and confirmation bias. When we have a lot of information about a system or field or specialization it becomes harder to remember earlier experiences when we were just mastering these skills. As a result when leveling game systems we tend to think puzzles or levels are easier than they actually are. 

• Lack of control and puzzles are challenging to balance out in a way that feels fun and not frustrating. Puzzles test players' knowledge or their ability to read a situation and find a solution. Knowing the solution to a puzzle and failing on the execution is one of the most frustrating experiences. This is because a player already knows what the solution is and when they can't execute it it feels like the game system is preventing them from playing properly.

​

​