Unlike composition, which doesn’t have to be established but can only influence the player, a language can very clearly communicate things to him but is made up of vocabulary that needs to be established, either within the game or in the real world/other games. For instance: “Fire burns wood” is something that players inject into the game from their real life experiences. “Red barrels explode” is a convention that players understand in the context of action games. And “Yellow paint on a ledge means I can drop without taking damage” is one you’d have to establish in your game.
Vocabulary gets associated with a meaning or expectation, which can be used to generate goals and intentions. For instance, placing a door on the other side of a deep hole may lead to players thinking “that path is blocked, I need to find another one” but adding a recognizable element near the door (e.g. a light that follows the convention for save rooms throughout the game, or an interactive device to open the door that the player has used multiple times before) turns it into a case of “how do I get to that door?” and pushes players to look around the room and spot the climbable ledges they can use to go over the gap.
Since games can be fairly short and weak tutorial sections frustrate players, it’d be a good idea to tap into what the player already understands if your game shares any resemblance to our world or your characters to humans. It could make your environments more intuitive to navigate without any teaching or reminding from your part. The tricky part however is that a lot of things in our world do not translate so well to all games and can create too many golden strategies and such. For instance, if players can push any reasonably-sized crate, climb through any small broken window or on any tree or hedge, it could seriously limit how much you can gate them in your environments and how you can use those features.
So designers have to pick and choose what they take from our world carefully, to not give players wrong expectations (this ties back to the part about perceived affordance.) Like, players understand how elevators are supposed to work, what a staircase sign can look like, that an automated door needs power to open, that ropes can be cut, etc. But if you want to use bulletproof glass then you have to figure out how to make that non-breakable glass somehow look different than standard glass so players do not apply real-world logic to it.
Not surprisingly, going against real-world conventions can also be tricky, and may require you to establish early on where your game differs from real-life. For instance, if fire does not hurt the player in your game and he can walk through it, you’ll have to do a damn good job at communicating that, or players may think a path is blocked when it’s actually the way forward.
The good news though is that other game developers before us have slowly but steadily built conventions that are well-understood by players today, and players have learned not to bring too many expectations from the real-world into games, preferring to focus on the conventions they bring in from other games of the same genre.
Very dense vegetation blocks navigation, rock cliffs cannot be climbed on unless they look special, sparks mean that a device is broken or malfunctioning, red barrels explode, fences with barbwire on top prevent any climbing even in games where you have an armored suit, explosions can break weakened walls, green glowing liquids are harmful, falling into water from any height does not cause damage / or you cannot enter deep water or you instantly drown, a purple card reader needs the purple access card, locks can be broken by melee attacks or bullets, electric arcs on water means it causes damage if stepped in…
All of those are just examples of what we can build upon when creating modern games. It never hurts to re-introduce them briefly, especially since there are always a few games that toy with those conventions, but most of the work is still cut out for you, and for the most part your responsibility then will be tying the convention to the exact look and behavior of the mechanic in your game.
But of course, if you just stick to conventions you’ll end up with a conventional game, so you will probably want to tweak the conventions or invent a new language for your game. The whole set of techniques on how to teach players a new vocabulary would belong to another article about teaching and tutorials, but here are some quick tips:
Leave the player room to experiment and understand the language on his own. I would advocate in general that something the player feels like he has figured out on his own will leave a bigger mark on him than something he’s been told. Of course you should use all sorts of tricks to hit that sweet spot in which you’ve said it so subtly that he thinks the credit goes to him, but so clearly that you can be sure he gets it. That also usually means introducing that vocabulary in a somewhat safe environment, with low time-pressure and threats so that the player attention can be focused on the element being introduced.
Test the player’s understanding of the language. This is a common trick when it comes to introducing new mechanics to the player. For instance if you want to communicate which parts of the environment are climbable and which aren’t, place the player in a pit he has to climb out of. The first climb is the introduction, the 2 or 3 subsequent ones are to verify that the player gets it. Once he’s out of that pit, you can safely re-use that vocabulary anywhere.
Refresh that vocabulary regularly so the player can’t forget about it. It’s not that uncommon in games to run into cases of vocabulary being introduced, but used so sparsely for a while that players just plain forget this was a thing and do not notice when it is used later on. This applies more often to gameplay mechanics (e.g. the underwater-base level teaches you that the shock-rifle can electrify pools of water, but pools are used very rarely in other levels) but keep that in mind also for navigation language. Sometimes it’s worth testing the player’s memory of a mechanic before challenging him with it for instance (e.g. go through all types of contextual climbs before getting to a boss battle where you need to keep climbing up as lava rises)
Make the vocabulary flexible instead of specific. It’s usually better to introduce a vocabulary that can be shared by multiple mechanics/setups rather than very tailored to one instance. For instance, in Mad Max a bright yellow color is used to indicate any contextual navigation the player can do: ladders are yellow, yellow paint highlights where you can climb, the contour of doors is yellow… Even if you would not run into a rope for a while, just spotting the yellow paint at the spot where you can grab it does the job. Other games do this with the red color on anything that burns or explodes, be it a barrel, jerrycan, gas tank, valve on a heat pipe… Assassin’s Creed puts an eagle at every synchronization spot, be it a tower, tree, mast…
Reserve the vocabulary, distinguish it from the rest. It’s obviously quite important but worth mentioning that if you want the player to spot and understand a certain vocabulary, it needs to be used exclusively for communicating one thing. If you introduce a color as a way to say “this is breakable and you can go through it”, avoid using a similar color anywhere else in the game, or you’ll confuse players and lessen the power of the language. This can be tricky sometimes, and the design and art departments need to work hand-in-hand to pull it off. For instance, if the player can explode certain walls that have cracks on them, there needs to be a clear differentiation between those cracks and any other damage texture used in the game, or players will be confused as to what is breakable and what isn’t.
So let’s take a look at general tools that can be used to improve the player’s navigation, giving him confidence that he understands the environment, and highlighting critical elements in scene. Every game is different in regards to how it uses those tools, but they are so common in AAA development that they’re worth mentioning from a high-level perspective, and can be a good start to defining the vocabulary in your own game.
In general, giving certain elements a unique look is key to establishing a visual language with players.
Color is very common to communicate the use of an element. Red can mean hot, or dangerous, or locked. Blue can mean cold, or safe. Green can mean healing (since that’s the color used in many countries for hospital and pharmacy signs) but also acid, or access granted. Since so many games have used so many different colors over the years, it’s tricky to use conventions for colors, and it’s up to the developers to figure out how to use color in a game and to establish that early on to the players. It’s also important to be consistent with colors, so red used on different objects should not alternate between meaning danger and health.
The aspect/texture of an element is also critical. For instance, many games that allow players to break wooden objects also need to rely on non-breakable wood sometimes, and then they define a specific tint and texture for breakable wood that stands out from any other use of wood in the game, in any lighting situation, so that players remember “I can break wood that looks moldy” instead of “I can break wood”. Bulletproof glass is usually differentiated from non-breakable glass by adding a semi-transparent pattern into the glass texture, and sometimes labels or border decals to the glass so even from further away it looks different.
In general, lighting is used more as a composition tool, but you can certainly establish rules for it too. For instance, maybe your game only uses blue lights around save points and players can never be attacked while in those areas, so they become drawn to any hint of blue light they see. Lighting is also one of the subtler methods available, and it’s really quite interesting how it can be very effective and yet unnoticeable.
The number of light sources can also be important in how it affects player navigation. One light will highlight an object or spot, two lights will create an axis or a frame that draws the attention to what’s between them, three lights create a path…
One key aspect of using lighting for navigation in your game though is that you have to figure out if light will attract or repulse the player. Games like Thief or Splinter Cell make players feel safer when in darkness so light sources actually push them away, whereas games like Metro 2033 , Left 4 Dead or Alan Wake have the player feel safer when they can see their surroundings, so they are drawn to well-lit places. That will change the way you can use lighting as a guiding mechanism.
This heavily depends on the game you’re making, so I’ll keep it high-level. Basically, the theory is that it’s critical to define vocabulary to draw players to gameplay mechanics or push players away from them, and to communicate what those mechanics do. This will allow players to consider their options, form their intentions, react to challenges intuitively, and navigate with confidence.
When that’s done, the placement of those mechanics has the effect to push and pull the player around game spaces, and so it’s up to the level designer to lay those out appropriately for each scenario.
In games like Assassin’s Creed or Uncharted , birds are often used to highlight spots that can be jumped off from safely or where you need to climb. They use sound and movement to catch your attention, but in and of themselves they don’t mean anything. However, players quickly learn in those games to identify a valid navigation path by looking for those birds (as well as poles sticking out of buildings, piles of crates, pipes…) On the other hand, gas coming out of a pipe usually means a blocked corridor unless you find a way to deal with that leak.
A common issue in design is to be able to foresee the outcome of an action. If there’s a single switch in a room, I can assume it controls the lights of that room: if there are four switches, I no longer am able to map actions to clear consequences without first trying them out, or providing extra clues like labels, icons, placing the switches in a pattern that fits the geometry of the room, etc.
So anything you can do to link elements together is welcome. Often that’s achieved by physically connecting them (e.g. a cable running from a control panel to a door) or by mentally connecting them (e.g the color of the button matches the color of the door), but parkour games show that placing mechanics along in close proximity and along lines is also a great way of defining a path through the environment (this goes back to continuity, but this time with established game mechanics.)
It’s important for players to understand the metrics of the game, so they know where they can climb up, drop off without taking damage, what is a blocker and what is cover they can vault over, whether a gap is an impassable barrier or they can climb over it, if they can go through a vent/window or not, etc.
It can be tricky though, since perspective does not always make for accurate depth-perception, so it’s often a good idea to: 1) make those navigation spots inviting so players can assume it’s also safe/usable (e.g. a gap in the railing with lines leading downwards); 2) make the blocked paths repulsive (e.g. fire on a blocker, spikes or acid under a ledge, bottomless pit beyond a railing…); 3) build a visual language to communicate which spots are okay and which aren’t (e.g. yellow paint means you can drop safely); 4) provide a point of reference to help gauge the situation (e.g. two boxes that the player is used to dropping off of piled next to it a high drop point.)
Integrating physical barriers into the game’s language is also crucial to maintain suspension of disbelief and to spare the player the frustration of having to try every door or path to differentiate the valid and invalid ones. This is obviously related to the point I made earlier about justifying dead-ends and blockers, the point here being that those explanations can become patterns that players learn to recognize. Barriers don’t even have to be physical: mine fields, endless oceans with sharks, sniper zones… can also be understandable boundaries.
Invisible walls are often a necessary evil but an evil nonetheless, and your role should be to try and make them really invisible to the player by relying in most cases on understandable barriers rather than invisible ones. Ideally, players should only notice invisible walls when they actively try to break the game.
For example, in the school level of F.E.A.R.2 , there are a lot of doors and only a few can be opened. The game introduces 2 different ways to tell that a door is locked: doors with windows have furniture piled against them, visible through the windows (which is clear enough in itself to not have to be introduced); doors without windows have scorch marks on them to show that the enemies have wielded them shut (which is introduced by a scripted event and dialogue.)
Modifiers are part of the language that change the meaning or effect of another part of the language when they are combined. For instance, in Mad Max the standard doors can be opened by kicking them, but there is also another type of door with spikes that requires explosions. Or you could make certain elements non-breakable by default, but in cold environments they use a special shader to indicate that they are frozen and can be shattered. Or an enemy that requires low-light conditions to sneak up to and execute, and acts as a blocker when placed in well-lit environments. Or devices being usable or not based on whether the building has any electrical power. Or glowing butterflies around anything that’s enchanted…
Consider locked vs. unlocked doors: designers have come up with a lot of different ways over the years to allow players to tell whether a door is usable or non-usable, both by establishing a difference between those doors (e.g. usable doors have a door knob, non-usable doors have a red light on them…) but when that’s easy to overlook, providing feedback when a player attempts to use a door (e.g. a UI icon, a “locked” sound effect, a flashing red light…) is critical. It can also naturally teach players the vocabulary, by matching a clear feedback signal with a visual aspect/element on the door for instance.
Feedback is important because it is part of the interaction process between the player and the game, the dialogue that cycles between the player telling something to the game, the game processing it, and telling something back to the player (e.g. acknowledging the action, denying the action, triggering a consequence to the action…)
Things like different states of damage on breakable elements with lots of health, reactions to trying to open or use or break elements that don’t allow it… help make a visual language effective and forgiving.