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
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.
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 original
Monkey 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.
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.
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
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
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
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
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