Tiny Inc. Repair Shop Learnings: Correcting bad level design

I added analytics to my LD game and noticed that big amount of players close the game on level 4. Fun fact: level 4 supposed to be a chill level to give player a break between challenges and a tutorial to a new mechanic at the same time. It was created to hook player's interest to play further, but instead had an opposite effect. How did that happen? Let's have a look! Screenshot 2024-10-13 191559.png

When I started working on Tiny Inc. Repair Shop at the beginning of the first day, I set my self a goal: the game should have at least 5 levels and all of them should be finished by the end of Day 1, leaving Day 2 for polish only.

For those of you who didn't play, Tiny Inc. Repair Shop is a puzzle game, where you need to arrange differently behaving creatures on a grid board so that they bring a charge to a battery.

fjNVQ6.gif

If you want to play it to understand better what I am talking about consider playing the game here

https://ldjam.com/events/ludum-dare/56/tiny-inc-repair-shop

Context

From the beginning I had 3 creatures in mind:

  1. The first will go left and right only
  2. The second will go only up or down
  3. The third will stay idle unless it sees a red color thing either vertically or horizontally. If it sees one it will charge to it and push it until meets the wall

Combining them along with placing some blocks on the grid opened some space to design a few interesting puzzles. But I got exhausted pretty quick (after the 3rd level) and decided I need a new mechanic: a button that will open a door. To introduce this mechanic I needed an easy tutorial level, something that should show the player that:

  1. There is a door
  2. There is a button
  3. If the creature steps on a button the door opens

So I created this:

Screenshot 2024-10-13 192225.png

The idea is simple: you place a creature that goes from left to right (the green one) near the button and then another one near the charge. The one near the button will open the door and the one with the charge will go inside and finish the level. In fact, this was what most of the players who played in front of me did. But what happened instead was this:

button_bug.gif

The green guy presses button, encounters the wall, turns back and then presses the button again, closing the door right in front of the other green guy, carrying the charge!

Obviously I saw this during the development and tried using other creatures to see if the level is passable. In the end it was and at the time I though it might be a good idea to leave this as is, so that the player tries the most obvious solution and the game says "Gotcha! Try again!". I thought that maybe this will require the player to think a bit more and then once they realize how to pass it they'll get this "Aha!" moment which all puzzle designers strive for.

However what I observed from people playing this level, it was completely unobvious how to pass it. Some people randomly found the solution, some people exploited a bug (which I fixed later) and some people (majority) just gave up, abandoning the game.

One big mistake this level did for players was violating the rule of the puzzle genre. Instead of making a player feel smart it made them feel stupid. And no one likes feeling stupid!

Fixing the bad level design.

The best fix for this level I think is bringing it back to the original idea: just introduce the new mechanic in the easiest way possible so player understands how to interact with it. If I just move the button one tile right, the green creature just doesn't have time to come back to it and toggle the door.

buttonembug/emfix.gif

Yes, the level will be much easier and it doesn't show that the button closes the door as well as opens it, but it's okay. I can expose togglable behaviour on a different level and create this "Aha!" moment once player realizes how to overcome it.

However I didn't use the fact that button toggles the door state in any of the other puzzles, so the other fix could be to just disable it and use button to only open the door.

buttonembug/emfix_2.gif

Conclusion

If I will do puzzle games for future jams here are the crucial things to take care of:

  1. The puzzle should make the player feel smart, not stupid
  2. When the solution feels unobvious at the development stage it is unobvious for players
  3. When designing a certain mechanic (e.g. toggling the door state) consider if I will use it at all in future or if it is unnecessary complicates things. Whatever makes things unnecessary difficult should be thrown away.

What puzzle design advices could you give to new puzzle designers? Would love to hear!