Making a hard game isn't easy

Our game Squatbot is, by design, very difficult.  We created a fast-paced platformer built for touch screens, and we wanted to spotlight our responsive controls. To do that, we needed to push the player to use the controls to their fullest.  That said, we also wanted players to enjoy themselves, and ultimately beat the game. We needed our challenges to teach the player, and inspire them towards mastery, so that they could see the depth and finesse of controls.

It’s incredibly easy to make a game that no one will beat - It’s much harder to make a game that players will push themselves to beat.  A difficult game needs to teach players how to gain mastery over it, and the following five rules aid in that teaching process:

1. The player needs a clear goal

2. The player needs clear steps to take towards their goal

3. The player needs to learn from every failure

4. There should be no punishment for failure

5. Keep each challenge short - There should be no busywork!

Let’s take a look at these points in detail.

Rule #1:  The player needs a clear goal

Before the player can tackle a challenge you put in front of them, they need to know what they’re trying to do at a macro level.  If the player has no idea what their goal is, they have no reason to push forward when an obstacle gets in their way. At their first failure, they’ll walk away, a little more confused and a little more frustrated than they were before starting your game.

Different games motivate the player in different ways - Some have a story that the player wants to see played out, and others encourage the player to go for a high score.  In every case, however, the player knows what they’re trying to accomplish.

Rule #2:  The player needs clear steps to take towards to their goal

It might seem odd to make an obvious path for your player when you’re trying to test them, but players need to understand what they’re supposed to be doing, in order to understand what they’re doing wrong.  Without knowing the step that they were trying to take, a player cannot accept a game’s feedback (usually in the form of death), telling them that they did it wrong.

In Squatbot, we accomplished this by giving the player a breadcrumb trail of coins, always encouraging them towards their next step.  They know what they’re supposed to be doing, even if they aren’t quite able to do it yet.

The challenge should be the execution, not figuring out where to go.  If a player collects the coins, they’ll make it through this tricky series of jumps.

Rule #3:  The player needs to learn from every failure

Now that the player knows what they’re supposed to do, we can start telling them what they’re doing wrong.  Whenever the player fails at a challenge, we want it to be a learning moment, and for them. This helps a player feel as though success is achievable, and prevents them from opaquely writing off a challenge as “too hard” to beat.

When a player knows exactly how they messed up, they can see how close they were to success, and that knowledge makes them want to try again.  It’s the difference between “That was bogus! This game is impossible!” and “I was so close! Okay, just one more try...”

Rule #4:  There should be no punishment for failure

At this point, you should have the player hooked: They know what they did wrong, and they’re excited to try again.  Let them! Don’t mess things up by punishing the player’s mistake. All that will do is break the lovely feedback loop that you’ve so carefully built.

There’s a really simple reason not to punish players for their failure:  You’re building a hard game, and you know players are going to fail at it quite often, just by nature of what your game is.  If failure is tied to punishment, you’re building a game which punishes players for engaging with it! That’s obviously not a good idea!

Be careful:  You don’t have to actively build a punitive system for players to feel punished by death.  In Squatbot, we were careful to make each death as painless as possible - Checkpoints were abundant, and players never lost resources when they died, but early playtesters told us that the game punished death too heavily.  Upon investigation, we discovered that players with slower devices were dealing with a few seconds of loading between deaths, which felt like punishment when they wanted to try again.  We fixed the performance issue, but it was a good reminder that nothing should stand between an eager player, and another attempt.  Keep your death animations short, keep your loading times shorter, and let them jump right back in.

Rule #5:  Keep each challenge short - There should be no busywork!

Games are not made harder by length, just more tedious.  A long level means that death forces the player to slog through a section that they’ve already mastered.  In some respects, this rule is really just an extension of the rule above - Forcing a player to repeat something that doesn’t challenge them feels like punishment.

Because busywork is not engaging, but necessary for a player to get to where they want to be (The next challenge), it puts them into a state of what I’ve dubbed “boring stress”.  It’s the feeling you get when you’re doing something crucially important, but trivially easy - Think filling out an important form. It’s easy to do, but the whole time you’re doing it, you’re slightly on edge.  I first coined this term as a way of disparaging the minigame Shy Guy Says in Mario Party, but you see the phenomenon crop up anywhere that the stakes are higher than the player’s engagement level.

“All the thrills of typing an email address correctly!”

That’s all, folks!

Thanks for reading.  Hopefully this you'll tune your own games into well oiled teaching machines.  If you liked this article, consider following our studio @ildgames on Twitter, we’re happy to talk design all day long!