Keep Things Clear: Don't Confuse Your Players

Playing a game can be a complex task. Some games, like Snakes and Ladders, are pretty straightforward—but some games, like SpaceChem or Factorio, can be incredibly complicated affairs that test our brains to the very limit.

For every game, from simple to complex, it's important that the player knows how to play. If it's just throwing dice or doing complex mathematical equations, it doesn't matter—as long as the player knows how the game works.

But for some games, we make things unnecessarily difficult. For most games, there are very clear sets of rules, and any actions the player takes should have expected outcomes—but sometimes, things can get muddled. Let's have a look at some of the common pitfalls regarding this, and how we can try to avoid them.

Clear Rules

The first thing is to keep the rules consistent. Games are generally built around the idea of challenges and progress, and we use rules to determine how well the player is doing. A player should generally have a clear idea of what they want to accomplish, because a game without challenge isn't a game—it's a toy. There's nothing wrong with making toys—Minecraft is pretty successful—but games need rules, and it's not fun for the player if the rules keep changing every ten seconds.

One way that games change the rules is by making some characters immortal. RPGs are most often guilty of this, giving certain NPCs “plot armour”—because if they die then the player is stuck, unable to complete important quests. 

Having immortal NPCs breaks immersion, and while you don't want the players to be unable to finish the game, you do need to try and keep the rules of your world consistent. 

Often, immortal NPCs won't even be clearly marked, meaning that sometimes the player can be wailing on an enemy that can't even take damage. If you want to have immortal NPCs, try to have them clearly marked—or just let them be killed. 

There's nothing wrong with that (Planescape: Torment did it, and is one of the best RPGs ever made), and you can just tell the player that they screwed up and can't win.

Invisible walls are another "rulebreaking" design aspect that seems to pop up time and time again. It's not fun to be exploring and come up against a barrier that prevents further progress. Sometimes, these barriers serve no purpose other than to force players into taking long detours, artificially increasing playtime. 

In some cases, invisible barriers can be necessary: there does need to be an upper limit to how far off the map the players can move, and an invisible barrier can achieve this. But when players find these invisible walls in normally accessible areas, too often it feels like poor design and lazy planning.

And lastly, don't unexpectedly change the rules halfway through the game. Choices in games are based on information, and having bad information means bad choices. One example of this in video games is in Deus Ex: Human Revolution, where players who had been playing as stealth characters suddenly hit brick walls in the form of bosses that were only beatable via combat. 

Later patches fixed this, but if you give a player the option to play a non-combat character, you can't act surprised when they pick it. Cutscene quick-time events are also susceptible to this, as most cutscenes are non-interactive, meaning that when a quick-time event does happen it breaks the player's expectations.

Interestingly, this rule was subverted in South Park: the Fractured but Whole. When fighting against Cartman, he breaks established rules during the fight—ignoring damage, taking extra turns, warping around, and so forth. South Park fans will realise that this sort of blatant cheating is entirely consistent with Cartman's character, and while the fight can initially be frustrating, it makes you hate the character that little bit more and adds to the overall game experience.

Clear Goals

When we make our game, we design objectives for the player and ways for the player to reach that objective. When the rules are clear, then it's also clear how the player achieves their goal. But what if the goal isn't clear? What if the player has clear rules, but isn't sure what they're actually supposed to do?

For some games, this “fuzzy objective” approach is fine—Minecraft has little in the way of an overarching plot, but the player is still able to make clear goals. Whether slaying an elder god, reassembling a key or building a pickaxe, games are defined by goals, so it's important that the player understands these goals well.

For puzzles, don't hide puzzle pieces from the player. Of course, it's fine to make them work for it, but if a player spends 20 minutes trying to work out how to open a door and then you say “Haha, there was a key hidden here all the time”, the player might feel a little ticked off. In some older games this was referred to as “pixel hunting”, a process which hid important game elements in tiny screen locations, forcing stuck players to weave the mouse back and forth over every single game location hoping to pick up something they had missed.

Ensure that game elements are clearly displayed as game elements. This applies to all games, but doubles for puzzle games. If a player can't solve a puzzle, you show them the solution, and then they say “Oh, I didn't realise you could interact with that” then you have failed the player as a designer. 

We accept that not all game elements can be interacted with, so it's bizarre when an important game element is hidden as background imagery. Several games have managed to avoid this by allowing the player to hold down a key to highlight items you can interact with, which is a simple addition that works nicely.

Graphic clues can be incredibly useful for setting goals. When a player has an objective, it makes sense for it to be something they can mentally connect with. The reason Mario collects coins is because coins are an obvious object to collect. 

In Plants vs. Zombies, the player's turrets are plants because they can't move, and you defend against zombies—a horde of slow-moving enemies. If a game element is causing trouble for a player, ask yourself why. If it's because of a logical disconnect, consider redesigning the enemy, ability, or whatever it is.

And try to ensure that if the player is on the correct track to solving something, you don't throw them off the track just because they didn't get it exactly correct. An old example of this comes from the originalMonkey Island game, where the player had to retrieve a jug of alcohol from a sleeping pirate using a feather. 

Tickling the pirate elicited: “I can't find a ticklish spot on his body.” Tickling the pirate by specifically clicking on this foot, however, did work. The response the game gives not only isn't helpful, it makes the player think that a completely different solution is needed.

Clear Action

Finally, we need to make sure that the player's actions are clear. We have rules, and we have goals, so the player should understand what happens when they try to apply the rules to reach those goals.

To simplify this, let's say you're making a Mario clone. When you press the jump button, you normally jump, but there is a 1% chance that the character ducks instead. Hopefully, you're thinking to yourself: “That sounds pretty stupid.” So why do we keep seeing this sort of design in games?

One of the biggest culprits for this is context-sensitive commands. Sometimes it works, and sometimes it doesn't. But when you play a game like Diablo 3 on a console, you notice quickly that the “basic attack” button is also the “interact with” button, meaning that fights near portals can end up with some unintentional warping around. Prince of Persia had the “jump” and “wallrun” commands on the same button, which worked for the most part, but you'd occasionally activate the wrong one and run straight into a death trap.

Trying to take an action at the wrong time can occasionally be frustrating to players as well. Because computers run at thousands of commands per second, it can be difficult to press the right button at exactly the right millisecond. If the player needs to jump over a series of pit traps, then missing a single jump because you pressed the jump button a fraction of a second too early can be another frustrating factor. 

What some games have done to combat this is use something called “input buffering”, which means “holding” a command for a set period of time—say, 5 frames—and hold it for the next free action. It's also possible to allow the user to take actions after it's too late. If a player runs off a ledge and then hits the jump button, it's not unreasonable to allow the player a frame or two of leeway. This isn't necessary for all games, but for games that rely on quick reaction times, it can often be much more enjoyable than simply punishing a player who just missed that reaction window. Just don't overdo it.

Another point, and perhaps one of most important, is to make sure that the player can actually see what's happening on screen. It's very tempting to add lots of cool sparkly effects and particles, but if we add so much to the screen that the player has no idea what's going on, then it makes it pretty difficult for them to play. 

One of the worst offenders for this is The Binding of Isaac, in which it's not terribly hard to get so many weapons upgrades or followers that it becomes literally impossible to see what's happening on screen. But other than that, the game seems to take a perverse delight in making things artificially hard at times—the “curse of darkness” makes everything on screen darker, making it more likely that you'll run into an enemy or trap that you didn't even know existed. 

Similarly, some enemies produce “creep”, which is a dangerous substance left on the ground that causes contact damage. While on most levels the creep is clearly visible, on some levels it blends in with the red background, becoming nearly invisible.

And finally, slightly looping back to an earlier point, try to make sure that when the player takes an action, they are not surprised by odd results. Specifically, we're going back to talking about invisible walls, but a specific type of invisible wall: namely, blocking objects. Some games treat the player like a rectangular pillar, meaning that the only way past a tiny object—say, a small pebble—is to avoid or jump over it. 

Of course, in real life a pebble can make us stumble, but it's not something that needs to be modelled in game. So when a player is moving around a 3D environment, consider making the player slide past small objects, or don't give them physical bodies at all. The old Half-Life engine games (such as Team Fortress 2) were notoriously bad for this, and players could get stuck on all sorts of objects in game.

Bringing It Together

Although it seems as if a lot of these points might only be tangentially related, they're all really just the same point expressed in different ways: there should be clarity between the user and the game. If the player doesn't know what's happening, then they can't make good choices.

Of course, some games make a sort of meta-game out of trying to understand the rules—setting the player a puzzle, but not telling them the objective. Sometimes this works, and sometimes it doesn't. The Witness did this, and while it's pretty highly rated, it's also quite a divisive game. Those that like it seem to love it, and those that don't… probably won't get more than five minutes into it before getting bored. 

Regardless, this obscurity doesn't hurt the game because it is the game. There's still plenty of room out there for games where players have to explore and find out how things work—and besides, telling the players how everything works can take away some of the fun.

Overall, like anything else, just make sure the player is having fun. When the player is confused, they're probably not engaged. When a player dies because of something they couldn't have predicted, then they'll quickly become frustrated. But when a player makes a choice, and that choice pays off, then they'll feel rewarded and will want to play more.