Introduction
In Part I of this series, I discussed some examples of types of games that benefit from the lack of what I’ve termed “nudges,” which is an instance of some player input X that typically yields output Y instead yielding output Z, where Y would potentially undermine narrative consistency and Z preserves narrative consistency. For clarification on this term’s formal definition I would suggest reading the introduction to Part I before reading this article. And I would definitely suggest reading Part I before reading this article if you have yet to do so, as this article will assume knowledge of the ideas covered in Part I.
In Part II I will discuss games that have narratives that benefit from nudgy gameplay. There are two principal ways to think about how a game’s narrative may incorporate nudges. First, it may incorporate nudges that help the player, allowing them to perform feats that are potentially outside of their skillset without the helpful nudge. I will term these sorts of nudges “player aids.”[1]
Second, a game may incorporate nudges that cause the player to perform worse than they would on their own. I will term these sorts of nudges “player hindrances.” Importantly, a player hindrance is not simply a lack of a nudge. It is an active change in output from what the player expects that makes the player perform worse. It is not like the examples of Banjo Kazooie or Dark Souls given in the previous article, in which the player likely fails frequently exclusively as a result of their actions, rather than the corrective measures of the game engine.
A nudge can be either a player aid or a player hindrance. I’ll start with a discussion of games with player aids and then move on to a discussion of games with player hindrances.
Games with Player Aids
Player aids exist to make certain potentially difficult aspects or portions of a game easier for the player to accomplish. They are most effective when a task that might be difficult for the average player is not difficult for the avatar the player is controlling. The player aid turns this task into something trivial to accomplish, maintaining the narrative consistency of a game by continually establishing the competency of the character. There are many games that have done this over the past years, notably the Batman Arkham games as well as the Assassin’s Creed games, so many readers are likely familiar with the gameplay I’ll be describing. I will go over two examples of player aids, and then discuss an example of something that potentially looks like a player aid, but is not.
The first example of a player aid hearkens back to the introduction of Part I, discussing the antics of bridge-crossing between Banjo Kazooie and Assassin’s Creed. I’d like to take a moment to look at a related set of circumstances in Assassin’s Creed: whenever the player is making Altair jump off of a building. Usually, the city of an Assassin’s Creed game is such that there is a convenient building to jump onto, or an even more convenient cart full of hay to dive into (and somehow stay completely uninjured, but we’ll ignore that complaint for now). For the sake of example, let’s imagine that the only safe landing space when jumping off a building is one cart full of hay on the ground. If the player runs directly toward the cart, Altair will reliably jump off of the building and land in the cart. However, if the player misses the mark slightly, Altair will jump off of the building and somehow steer his course, mid-fall, toward the cart, even though by the laws of physics in the real world he should have missed and landed with a nice splat on the hard ground. Each of these instances in which the player misses the path toward the cart of hay is a player aid: an enforcement on the part of the game mechanics of Altair’s status as an expert assassin who could not have made such silly mistakes—otherwise, he would have been dead long ago.
Altair jumps into a hay barrel.
One will note that the pattern I described in the previous paragraph holds for an uncooperative player as well as for a less-than-competent player. If the player intentionally attempts to miss the safe landing, the game’s engine corrects the player’s actions to be more narratively consistent. I have personally attempted to cause disasters in Assassin’s Creed, and can note from experience that one must actively attempt to cause harm to Altair in order to do so, as the game liberally aids an uncooperative player to a safer output than the one she was attempting to incur. In this case, input X is forcibly shifted from output Y, the output in which Altair is hurt, to output Z, in which Altair is not injured, even though the player did not want this to occur.
Another example of a player aid is seen frequently across shooters on consoles: aim assist, which is any instance of a game engine helping the player to shoot at enemies, rather than shooting into thin air. While aim assist often exists simply for the purposes of making multiplayer shooting games balanced across skill levels, or just making a shooter game more approachable for beginners, aim assist (lack thereof) often serves an important purpose in narrative consistency as well.
To see how aim assist can act as a player aid, first note that it fits the mechanical model described in Part I. The player can try to move her targeting in any particular direction, and when an enemy target is not on screen, the engine consistently moves the targeting in the direction of the player’s input. However, when an enemy target is onscreen, the game engine aids the player by making an output that differs from the direction of the player’s input, so as to make the player aim at the enemy target. In this way, in some circumstances input X, which often yields output Y, yields output Z instead.
What we need now to see how aim assist can be a player aid is motivation for why aim assist may preserve narrative consistency. Rather than point out a particular game for which this is the case, I will construct a category of games in which aim assist preserves narrative consistency. Imagine any game in which the protagonist is a well trained, expert marksman. For any game in which this is the case, aim assist will preserve narrative consistency, because expert marksmen rarely, if ever, miss. Aim assist works to prevent, to a degree, an incompetent or uncooperative player from undermining the expert status of the marksman.
In contrast, if a game features a protagonist with little-to-no training with guns, it would not make sense narratively to include aim assist. Aim assist would actually make the protagonist too competent, and would thereby undermine narrative consistency.
To further understand what player aids are, it will help to see an example of something that one might initially think is a player aid, but actually is not. Many games with action-filled cutscenes, such as Resident Evil 4, Uncharted, and even Final Fantasy XIII-2, have sections that demand user input in the form of action commands. These are sections of gameplay in which the player acts by pressing a button in response to a visual input on-screen. In response to a single button press, a player may run up the arm of a goliath while dodging bullets, do a backflip over an Indiana-Jones-style boulder rolling down a hill, or deliver a finishing blow to an enemy. These sections are usually designed to allow for player involvement during sections of gameplay in which the actions being performed by the protagonist are too actiony and cinematic for normal gameplay. Initially these seem like they may be player aids, in the sense that the game engine is making it almost atrociously easy for the player to perform incredible feats.
Leon prepares to dodge a boulder.
However, cutscenes with action commands do not thereby contain player aids, because these sections always have one specific output for the player’s input. If a player presses ‘B’ in response to some prompt, for instance, this button press is mapped to a specific output, there is no potential other output that might occur. Because of the one-to-one mapping of player input to game output, there is no nudge taking place. A nudge requires a shifting of output that is not occurring in this case. Simply making some complicated avatar action easier for a player to accomplish is not equivalent to a player aid. A player aid fundamentally changes how a player controls her avatar by shifting the output of some input to something that better fits the narrative than the usual output. To use an analogy, one could think of player aids as a proofreading system akin to error-correcting on a smartphone. A game with player aids corrects the player’s output to what is more correct for the story, rather than simply making it easier to give the correct input to yield said output.
Games with Player Hindrances
A player hindrance exists to disrupt a player’s actions, making simpler tasks more difficult to complete. A game may include a player hindrance to show that a character has difficulty with or is unable to do something, regardless of player ability. They are most effective when the player is controlling a character who is in some way less able than some standard (as defined by the game) regardless of player ability. There is a variety of potential reasons for the gap in ability, usually having to do the current bodily status of the avatar—in particular, when a character is inebriated, in some way physically injured, or close to death. The difficulty in diagnosing a player hindrance, then, comes in correctly identifying what standard it is that the character is failing to live up to. I will go over two examples of a player hindrance, both from NieR: Automata, in which the standard being compared to is the normal functioning state of the avatar. Then I will go over one example from Resident Evil 4 that is more difficult to diagnose. Finally, I’ll discuss one crucial example of a situation that initially appears to be a player hindrance, but actually is not.
At several points in NieR: Automata (a game with multiple avatars), the player’s avatar, an android, is hacked, EMP’d, or injected with a computer virus. When these events occur, various capacities of the avatar get removed, from the ability to attack, to the ability to jump, to the ability to see shapes with edge detection. While there are several instances of this throughout the game, I will focus on one in particular: when 2B, one of the avatars in the game, is infected by a virus that is threatening to control her entirely, leaving her unable to operate normally, on the verge of death. Thus player hindrances are warranted in order to make clear that 2B is no longer able to control her own body sufficiently, regardless of the actions of the player.
2B losing functionality from a virus.
In particular, when attempting to walk in a straight line, 2B will suddenly stop in her tracks, and sometimes when attempting to stop, 2B instead just keeps running forward. In this way, the player’s usual input can yield one of two outputs, either stopping or continuing moving forward, in a way that is not predictable to the player. The simple task of moving from one spot on the map to another becomes significantly more difficult, regardless of player ability, and so we can say that this section of the game contains player hindrances so as to preserve the narrative of 2B losing control of her body.
Again in NieR: Automata, the avatar is at times a robot with only very limited maneuverability, in contrast to the usual android avatar, who is very agile. The agency of the robot is much less than that of the android, evidenced by the robots’ slow movement speed, simple attack patterns, and a camera angle close to the robot that doesn’t allow for much peripheral vision. While the player is “hindered” in that she is less able to act through the avatar than before, these are not player hindrances: they are simply instances of the player being given fewer options, or simply fewer effective options, in accomplishing any particular task. They are akin to an avatar getting into a car: the control scheme and abilities of the avatar change, but that does not constitute a nudge in the gameplay. Changes in control scheme are not instances of player hindrance.
One particular way in which the player will be hindered by the gameplay when playing as the robot is when attempting to carry a bucket of oil. Usually, the robot can walk over pipes on the ground without falling over, but this action causes the robot to fall over when carrying a bucket full of oil on its head. In this way the output for the player’s input has shifted, meeting the first requirement to call this gameplay a player hindrance. Initially, the shifting output is surprising for players, who do not expect carrying a bucket of oil to be sufficient reason for tripping and falling over a pipe. But, the gameplay reinforces the narrative conceit that many of the robots are weak and relatively incapable individually. In this way the shift in output is narratively impactful: it shows that carrying a bucket of oil is a sufficient hindrance for the robot that even skilled player inputs cannot lead to success at walking over a pipe. The robot’s status as a pathetic being is at least maintained, if not more forcefully asserted, by this moment.[2]
In both of the examples given above, the avatar is not able to operate at their usual standard, in the case of 2B because of her near-death state, and in the case of the robot because of carrying a bucket on its head. But the “standard” that a character is not living up to does not actually have to be inherent to the character themselves. To see this let’s consider another example. Those who have played Resident Evil 4 may remember that the protagonist Leon Kennedy’s aim with a gun is often not great. When the player pulls out a firearm, even when giving no input, the location that Leon is aiming can move in any direction: up, down, left, right, and any diagonal mixture of these. So one can see that the first part of the definition of a nudge has been met: when the user is giving an input (in the form of no input), any of many directional movements of the gun is possible.
Leon (attempts) to aim at an enemy.
There are three potential ways in which this gameplay could maintain narrative consistency. One might initially think that perhaps Leon is not trained in using a firearm, and thus it would not make sense for him to have rock-steady aim. But this theory does not seem correct, since Leon was trained first as a police officer and then as a special forces agent. So his aim should in theory be very good. One might then be tempted to think that the explanation for his terrible aim is the frightening situation that he is in, fighting for his life against parasitically controlled people and monstrosities wielding chainsaws. But again, this theory isn’t coherent plotwise, as Leon must have been trained to manage his fear in combat situations as part of his training as a special forces agent.
Many players do not consider the third potential reason for Leon’s terrible aim, which I will explain in the following paragraph; as a result, these people believe that either Leon must be either a terrible shot or a coward. The lack of explanation for Leon’s terrible aim has plagued the impression that people have of him since the game’s release. Many people explain the existence of the nudge as being indicative of Leon’s actual incompetence, even though his attitude and demeanor appear competent. I recognize this as a weakness for the game: it’s easier to embrace the idea that Leon is incompetent than to recognize the larger theme that Leon’s shaky hand speaks to.
In the Resident Evil series as a whole, there is an idea that, in order to improve humanity and win wars, one must create biological enhancements for people as well as biological weapons. Many of the game’s villains describe normal humans as inept and/or weak. Leon’s shaky hand speaks directly to this theme, and grounds the player in the body of a human person (albeit a very well trained human person), who is subject to imperfections and up against biologically enhanced enemies. The fact that Leon’s aim is bad maintains the consistency of the idea that Leon is physically inferior in various ways to his enemies, and only stays alive through clever use of weapons, supplies, and his own smarts. The gameplay has less to do with Leon as a person, and speaks more to the world in which he is embedded. The standard that Leon does not live up to ends up being the standard of the ideal military combatant, which in the world of Resident Evil must be biologically mutated/enhanced.[3]
One may worry that this analysis is problematic in that presumably every character in a story has uncountably many arbitrary standards to live up to, and since these standards don’t all align, the character must be failing to meet at least one of these standards. In this way it would appear that all gameplay should be instances of player hindrances. But this is clearly not the case, since intuition tells us that most gameplay is not a player hindrance. This is where narrative consistency comes into play. The narrative should define the specific standard out of the uncountably many out there that the character is not meeting, so as to justify the use of a player hindrance.
In the case of Resident Evil 4, this standard is created through dialogue with a character named Lord Saddler in particular. At one point Saddler shoots down a helicopter arriving to rescue Leon and says “Don’t tell me you’ve never swatted a bothersome fly! In essence, it’s the same thing… When you’ve acquired this power, you too will understand.” Through this line, Saddler communicates to Leon that humans are no better than insects, and that there is a power greater than humanity out there to subscribe to. Leon does not meet the standard of this greater power. Leon’s shaky hand keeps this narrative consistent to make it believable that a power greater than humans—greater than Leon—could conceivably exist out there.
Lord Saddler.
As evidenced by the example of Resident Evil 4, player hindrances can be tricky to diagnose, for it isn’t always clear whether there is a standard within a narrative that an avatar is failing to meet. Further, player hindrances are uncommon: outside of characters who are in some way gravely injured, intoxicated, or afraid, or simply incompetent, it is difficult to imagine when a player hindrance might be used. This is especially true since players tend to find player hindrances frustrating, and so developers have a tendency not to design them, as evidenced by the number of players who bitterly complained about Leon’s aiming in Resident Evil 4, followed by the subsequent removal of this feature from the studio’s future games.
Now that we’ve considered some games that incorporate player hindrances, let’s nail down exactly what player hindrances are by considering a game that initially might appear to be one in which player hindrances are warranted, but actually is not. One may be tempted to think that the example of Octodad, from Part I of this series, may be a game that would benefit from player hindrances. As a reminder to the reader, Octodad is a game about an octopus masquerading as a normal human suburban father and somehow succeeding. The game has intentionally very difficult controls, so as to put the player in the shoes of the octopus. The player’s experience navigating the difficult controls mirrors that of an octopus trying with only minimal success to be a human father. However, there is a crucial reason that Octodad does not fit in the schema of games that benefit from player hindrances.
The games with player hindrances discussed above all drive home that the avatar is unable to perform some particular action regardless of the input of the player. In the case of Octodad, however, a key part of the narrative is that somehow the octopus manages to successfully act in the role of the human father, even though there are numerous physical difficulties present in doing so. Unlike the example of 2B given above, the octopus father actually does manage to accomplish his goals so long as the player succeeds, even with all of the obvious obstacles in his way.
Octodad shrugs.
The intrigue comes from the hilarious attempt of the player to succeed at being a normal human father even with the intentionally difficult controls. As mentioned in Part I, to introduce nudges into this gameplay would take the player out of the shoes of the octopus. Like the octopus, the player must fail of their own merit, rather than being forced to fail by a player hindrance. If the player were forced to fail, the nature of the story would be very different.
A Non-Obvious Similarity Between Player Aids and Player Hindrances
The reader may notice an apparent discrepancy between player hindrances and player aids. It initially appears as though player hindrances are always relative to some standard, whereas player aids are more “absolute” in that they do not seem to be tied to any particular standard. This is actually not the case. Both player aids and player hindrances are relative to standards. But with player aids there is not much need to specify the standard in question, since it is relatively easy for most people to recognize an avatar with superhuman capabilities (notice the implicit standard of “human” in the word “superhuman”). In contrast, in order to understand a player hindrance, especially those similar to the Resident Evil 4 example where the standard is something the character ought to meet, it tends to be necessary to more explicitly identify the standard. So while identifying a standard seems to be less pertinent in analyzing a player aid than a player hindrance, the difference does not arise out of the theoretical grounding of these terms, but rather just the process of analysis.
Conclusion
In Part I and Part II of this series, we’ve defined nudgy controls, considered games that importantly do not use nudges, and considered how some games use nudges in one of two forms, player aids and player hindrances. In Part III, we will explore how this paradigm of game controls allows us to better understand the challenging control scheme of The Last Guardian.
[1] Thank you to my good friend Luke Wellington for the suggestion of this term as it applies to helpful nudges, as well as providing criticism to my first article which led to its theoretical grounding.
[2] As an aside, from a game design perspective, this particular choice is designed to be frustrating. The designers know that the player has no way within the game itself of knowing that the robot will trip in these contexts. When the player takes these actions to save time (as the environment is set up in a way that encourages these actions to make traversal faster), the player will spill the oil and waste time. This sort of design decision is frustrating for players, and many developers avoid it so as to keep their players from quitting playing the game. The designers of NieR: Automata likely designed this section intentionally with the goal of frustrating the player in mind so as to put the player in the shoes of the robot.
[3] Thanks to Brendan Gallagher for pointing out that this analysis is not canonical or based on the author’s intent. My analysis is agnostic to author intent, and with that disclaimer the argument presented should hold.
