Four Aspects and Interpretation

Dec 31, 2010

Does instructing the player to hurry mean they’ll go faster? Would simply showing a time limit on the screen change behavior? What if the environment the avatar is in appears to be only moments from collapse?

Importantly: if the above are included, does there even need to be severe gameplay consequence for failing to go fast enough?

There are many ways that we communicate through the games we make. Among those ways are instruction, impression, interface and implementation.

Origin of the Question

Games with a Message

In a game purely for entertainment, flexibility in interpretation does not pose a problem. If everyone has fun in a different way, or imagines different details behind the play experience, that’s fine. However for a game with a planned message, understanding how the experience will be interpreted is essential to avoiding miscommunication.

Symbolism in Gameplay

I designed Alice in Bomberland, in part, to suggest through its gameplay various ways of thinking. In an effort to emulate the sort of symbolism common in children’s literature, I buried the intended meanings in the gameplay relationships, reserving the audio/visual impression for playful content. Textual instruction and in-game interface served utility only.

I tried to convey information in the implementation – in the interactions between gameplay elements – without making it explicit on the surface. Consequently, I believe that the meaning was largely lost, inaccessible until an uncommon amount of practice with the game, and even then invisible compared to the simpler, more literal forms and explanations accessible to every first-time player.

Instruction Apart from Implementation

More broadly, in the Newsgames group, we have both studied games designed to have a deliberate messages, and attempted to identify how rhetorical meaning might be read from games created for entertainment. Finding a way to better articulate and reason about player interpretation has practical application for our group, since we’re aiming to create a tool allowing others to make games of this type through the Cartoonist project.

One of the games we’ve studied that aims to convey a specific message is Kabul Kaboom, in which the player is instructed to catch hamburgers and dodge bombs. In terms of gameplay, collision with a falling bomb is an instant loss, whereas collision with a falling hamburger has no effect – no score counter, no boost to speed nor health, and no progress toward a goal.

At first it struck me as a problem that catching hamburgers has no consequence. The game instructs the player to collect them, yet the gameplay is indifferent to their collection. The meaning, consequently, is not in the gameplay, but instead in the text and visuals, leaving the playable portion to function as little more than a brief, illustrative animation supporting the text. (As opposed to expressing something through a videogame which only a videogame could express.)

If Piranha Plants in Super Mario Bros. didn’t harm Mario, and coins didn’t offer points leading to lives, but the game instead explicitly instructed the player to avoid plants and collect coins, would players obey?

Perhaps initially.

Four Aspects

There’s an important difference between the two games being compared: playing time. Someone’s entire experience playing Kabul Kaboom likely lasts a few rounds, each less than 10 seconds long, which altogether is less time than someone spends in one level of Super Mario Bros.

Someone’s first experience playing a game – especially one in which they do not know what to expect – is likely to be greatly influenced by initial instruction. Were the only instruction provided, “Reach the exit,” then as soon as the game began we’d scan for an exit.

Secondly, the player behaves in response to the impression given by the game’s audio and visuals. If something looks like a falling bomb, people will assume it ought to be avoided, and will move away from it. If it looks like food (or money), people will assume it ought to be collected. Similarly, in our hypothetical “Reach the exit” scenario, if a player saw fire between themselves and the exit, they would be unlikely to walk through the fire on the way to the exit, due to prior associations from real life and/or other videogames.

When teaching game design to middle schoolers at summer camp, one of the most frequent design errors they would make is to add a huge room full of coins, with no significance associated with the coins – no extra lives, no special bonus, or progress advancement, etc. Their idea was that coins are fun to collect, without recognizing the need for them to be associated with something. (Even real money would not be useful or desirable to collect, if it did not represent incremental progress toward exchange for something else.)

Around the same time, or a little after, the interface is checked for additional information to supplement the instructions and impressions. Is there some indicator of multiple health points, lives, score, possibly a timer? In assessing the interface, players are looking not only for information, but clues about what information is important. In Kabul Kaboom, no such supplementary information is available. However were the player shown a countdown clock on the screen that starts at 30 seconds, it would likely cause the player to rush. Were the player shown an empty spells meter on the screen, they would infer that magic can somehow be acquired and performed.

Although behaviors are initially suggested by instruction, impression, and interface, someone experienced with a game bases their behavior on how it actually works – not on how it says it works, how it seems like it works, or how it looks like it works. Through experience, whether by accident, exploration, or outside tip, the player is likely to discover what instructions were overstated, what rules are unenforced, and how the system can be exploited to maximize success. Expert play is adapted to implementation.

Whereas instruction, impression, and interface are all directly designed, the implementation for anything even remotely playable (all the way back to 70’s Atari games) is rich with emergent complexity, creating potential for inconsistencies between the initial expectation, which was designed, and the actual gameplay, which is a ungraspable product of cognition and computation.

Examples of this unintended complexity include running diagonally in Doom or Goldeneye 007 (N64), or bunny hopping in more modern shooters, to move with greater speed. Combos in the original Street Fighter II were an accidental side effect of how the game handled input. Unit superiority in many RTS games is affected not only by their stats, but also by how long their animations take to finish. Such features are undocumented, unintentional on the part of the gameplay (emergent from other programming details), and cannot be derived from the interface.

Implementation is where unintended meanings are most likely to crop up, but it’s also the least accessible to new players, since it’s revealed by experience. It’s where I tried to bury the meaning for Alice. Although implementation is where Kabul Kaboom‘s gameplay separates from its instruction, this works fine for Kabul Kaboom since it isn’t intended to be played long enough for the player to gain sufficient expertise to care about the disparity.

Because There is a Timer…

Behavioral Heuristic

Behavioral heuristic refers to a shortcut for decision making, which is applied because there is not sufficient time for evaluating ideal decisions in every circumstance.

An example of a non-videogame behavioral heuristic would be a novice chess player acting by the rule, “sacrifice any piece to protect the queen.” Although such a rule of thumb is better than being reckless with the queen, an experienced player would recognize when to violate such a simple consideration as part of a strategy to win the game.

“Because there is a timer, I should rush,” is an example of a behavioral heuristic for videogame players; behavioral because it changes player action, and heuristic because it disregards or simplifies details and relationships (how much time is left? what’s the penalty if it runs out? etc.). Notably, the behavioral heuristic may be the wrong priority in a given situation, but is applied anyway because it’s the habit or best rule of thumb available to the player.

Let’s take a look at decreasing timers, as they can be suggested through the four aspects, including cases where they don’t succeed in suggesting the behavior heuristic to rush.


A game may give the player a sense of urgency by telling them, through text or in-game dialog, to rush. Then, despite the advice, nothing is done to enforce it, neither to reward going faster nor to penalize taking too long.

This solution is particularly common in games targeted for younger players, who may be more likely to take at face value the legitimacy of the game’s tip, but could find a strict time limit confusing and frustrating.

One example of this is at the end of Zelda: Ocarina of Time on Nintendo 64, in which the sages urge the player to hurry to save Zelda. The game could be left running, unpaused, for any period of time without moving, and nothing unfortunate would happen.

When an experienced player sees through the unenforced claim, additional advantage is afforded by being able to approach encounters with greater care, or by using the extra time to complete secondary objectives that a player feeling rushed would bypass.


In Medal of Honor: Pacific Assault there is a scene at Pearl Harbor in which the player escapes from a battleship under attack. Explosions, flame, alarm bells, dead bodies, and high intensity music all stress that the player needs to get going.

As is the case for this sort of scene in many war games, there is no actual time pressure in this situation. There is no instruction given in advance to evacuate as quickly as possible, and there is no gameplay consequence for dallying, yet the player is urged to rush through dramatic elements.

As in the prior case, a player that sees through the aesthetics of the scene is typically at an advantage. Again the player is not coerced into playing along with the game’s fiction, leaving room for two different interpretations: the imaginary situation the game’s character is in, and the skill/constraint reality that the player is in.


During the escape from Planet Zebes scene in Super Metroid, in addition to using impression elements in the form of strobing red lights and explosions, a large readout of the time left for escape appears on the screen. When the timer first appears, it is drawn in the middle of the screen to call extra attention to it.

In the case of Super Metroid, running out of time causes the player to lose. However, just as the instruction and impression aspects can produce a behavioral heuristic to rush, without the support of gameplay consequences, it seems probable that a decreasing time readout could be displayed to make the player rush. When time runs out, rather than delivering the drastic punishment assumed, little or no consequence could take place.

This trick, in the form of light punishment, is common for drowning mechanics. This gives players an exaggerated sense of panic about needing to breathe, without needing to make the water as dangerous as the enemies. When the air timer is used up in such games, the player only loses a small amount of health, very slowly, until air is again reached. Lack of up front information to the player about the consequence of allowing that air timer to run down leaves open the possibility that running out of air will cause instant drowning, which is likely to prevent players from ever testing that boundary (alternative, overriding behavioral heuristic: “Because I have limited time to breathe underwater, I should spend as little time as possible underwater”).

The idea that, “adding a timer will promote rushed behavior,” is a sort of behavioral heuristic for the game developer, rather than the player. Contrary to that simplified guideline, displaying a timer does not necessary cause the player to rush. Although Alice in Bomberland included an on-screen timer – which was also explained in the instructions – it used a secondhand on a slow, continuous movement to show time passage, which turned out to be too subtle to earn the player’s acknowledgment. Here, a failure to account for how visual attention works preventing the displayed timer from having its intended effect on player behavior.

Interface presentation is a comparatively complex aspect, incorporating visual design, information design, and user experience design. Factors that may be varied for interfaces include (but are by no means limited to):

  • Form: text, circle, bar…
  • Animation: pulsing, color flashing, discrete/continuous…
  • Style: color, font…
  • Geometry: placement, size, transformations…

In other words, there are many ways to present something like a timer, health bar, or ammo count. The decision is not only whether to include such information, but how best to include it.


In Zelda: Majora’s Mask, also on Nintendo 64, the moon is constantly falling toward Termina, causing a game over if it reaches ground before the player completes all objectives (or, performs a trick to reset time). There is a definite consequence for the player running out of time.

Running out of time does not necessarily need to translate to instant loss. In Bubble Bobble and Joust, taking too long to complete a level sent out additional, nearly unstoppable opponents to harass the player. In both cases, there is no timer displayed on the interface, and this threat is not explained in the instructions, bad things just begin to happen if the player takes too long to complete the level (though Bubble Bobble does offer a brief “Hurry Up” warning briefly before it’s too late).

Simply rewarding leftover time is not necessarily enough to affect behavior, so long as something else is rewarded in a potentially conflicting way. A recent case of this is my recent rush project UAV Game, which displays a timer in the corner for 300 seconds. Because such a long time is given, players are able to complete the objective before feeling any time pressure. Here, tuning in the game’s design was the reason for the time not initiating a rushed behavioral heuristic. The designer intended for the scoring system to encourage prompt action, by rewarding time, but due to how the scoring and non-target characters are designed, the optimal behavior is to wait for considerable time before attacking. The interpretation of such behavior, within the game’s fiction, is giving the enemy time to recruit as many civilians as possible before attacking the region, so to minimize civilian casualties – a coherent but disturbing and unintended message.

Properly tuned, however, a timer can suggest certain behavior without overriding other incentives. Behavioral heuristics are not mutually exclusive – they can be thought of as crudely weighted. Many 80’s and 90’s-era console games rewarded completing a level with bonus points for the amount of time left on the clock. Sonic the Hedgehog is one such game that offers a time bonus at level completion. In this case, the expression used to compute score based on kills and time bonus isn’t apparent, rendering it non-obvious to most players whether it’s better to confront easily passed enemies or skip past them to maximize the time bonus. This ambiguity produces a mixed behavioral heuristic ideal for Sonic: “Rush through, but quickly defeat any enemies not far from the path.”

Effect of Unclear Length

For a straightforward task which can be fully visualized all at once and completed in some optimal number of moves or with a fixed strategy – such as a jigsaw puzzle – setting a timer is a matter of tuning challenge. Give me 1 hour to solve a 500 piece jigsaw puzzle, and I’ll be stressed; give me 1 minute and it’s hopeless; allow 1 day and it’ll effortless.

Tuning invites its own context-specific complexity, making implementation aspects among the more difficult to simply toggle.

A 2D scrolling platformer allows for a level where it’s unclear how much time is needed. Maybe the end is less than 1 screen away, or maybe it is 300 screens away, the player has no way of knowing (though perhaps some vague expectation, if they have played similar games). Without prior knowledge of the level, either could be true, meaning the player is not equipped to guess whether 45 seconds counting down is tuned to be easy or nearly impossible. Conceivably, this flexibility could be used to artificially create the effect of rush enforced by implementation, regardless of how well the player performs, by putting up procedurally selected filler sections until time is low enough to offer the ending.

A boss fight in which no health bar is displayed for the opponent is another example where it’s unclear whether the time provided is adequate. It might be 1 hit from defeat, or at nearly full health, the only feedback the player is given in this case is confirmation of whether damage is being dealt. This could be used to artificially force the sensation of last second save, by creating some function associating the boss’s death with the amount of health or time left to the player.

(Of course, a player picking up on the implementation trick would then be working at a different level of interpretation, recognizing that they could game the system to win with minimal effort. This part of the idea clearly needs more attention and experimentation.)

Distractions or optional objectives/encounters are needed which can put additional time pressure on the player by tying up progress. In Super Mario Bros., enemies and coin/power-up blocks provided this type of distraction. These provide an alternative to completing the level as efficiently as possible, and if recorded, give an objective measure of how rushed a player behaved. That is, someone oblivious or unconcerned with the timer smashes many standard bricks along the way, and confronts enemies that would be easily passed; someone sensitive to the time bonus effect on score skips anything that isn’t not beneficial to going faster.

Aspects Other Than Timers

Time running out was only chosen as an example, mostly because it’s a case with plenty of contradictory examples and mixed successes out in the wild. However the study of these aspects – instruction, impression, interface, and implementation – on interpretation and behavioral heuristics is not about timers in particular.

An example of a non-timer area of study relates back to the Kabul Kaboom example the question began with: when the instructions clearly state some objective (“collect as many red squares as possible”), or when the impression promotes some action (“red gems seem valuable, I should collect them”), or when the interface shows a count for collecting an object type (“13 reds so far… no counter for blues or yellows, I’ll try getting more reds”), even though there is no actual gameplay consequence to performing or not performing those actions besides an implementation that removes them upon collision with the player (no points/lives).

In A-10 Thunderbolt II – Costs Edition, my aim was to change the meaning of the game simply by displaying 1 new number on the interface – no new instruction, no new impression (in terms of audio/visual changes), and the only change to implementation was to compute that number to be displayed. Here again is a non-timer aspect, being changed independently from other aspects, to suggest different meaning. Toggling the display of that information could be thought of as an early form of the software for user trials, as a way to test one effect of interface on interpretation and behavioral heuristics (I suspect that players start to drop bombs a little bit differently, once they realize which one is cheapest and which is most expensive).

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2018 Chris DeLeon.

Site production by Ryan Burrell.