I had just finished working on my latest card game; I was rather chuffed with it: the rules were elegant and nuanced: there was a wealth of strategies you could use in the game. I explained the rules to two friends, and they began to play. I was expecting them to be amazed with the game.

Instead, I was amazed with how one had managed to find a neat little trick to — unexpectedly — win the game: a loophole!

After the discovery, the game was never the same. I eventually decided to change the card game into a board game so that the game could keep my original idea, but without the loophole.

After the change in my game, I became obsessed with loopholes in games. I began to research them and find how they could affect games. In this article, I summarize my research. This article covers what loopholes are, and why they are bad, with a big list of generic types of loopholes that can be found in games. The article also gives some advice on how to find and correct these nasty little game breakers.

What a loophole is

If something can be abused, it will be.

— Hyrop’s Law of Loopholes

A loophole can be defined as a flaw in the system that users can exploit to gain an unfair or unintended advantage.

[Fullerton, Game Design Workshop]

Loopholes are often the result of emergence; two or more rules acting together to make something possible that was not thought possible. Loopholes arise when the game rules don’t completely limit or enforce the legal behaviour.

Players find loopholes when they know the rules very well, or by accident. However they find it, the result is always the same: they will use the loophole, regardless of whether it makes the game more fun. A pointed example of players grinding away instead of having fun is with achievement farming.

When given a task, players will find the optimal solutions, even if it ruins their fun. Finding optimal solutions is part of playing the game — it is the designer’s responsibility to create the necessary challenges for an interesting solution; this burden is never the player’s.

Loopholes lead to unwanted player behaviour; the named loopholes discussed below are all words for things the player can do, but the designer does not (usually) want.

Related Concepts

Loopholes are degenerate strategies to play the game. Among all available strategies, a dominant strategy has the best chance of leading to success. A degenerate strategy is a dominant strategy that always leads to success. (Not all dominant strategies are degenerate: the prisoner’s dilemma is a classical example.)

Loopholes are often bugs, but only bugs that can be exploited by the player are loopholes.

Many loopholes are sequence breakers (that is, they allow the player to experience events in a different order than was intended), but only sequence breaks that benefit the player are loopholes.

Many loopholes are exploits — ways to play the game that goes against the spirit of the game. But not all exploits are loopholes. For example, some exploits require special tools for hacking the game. These are generally considered cheating.

Examples of loopholes

In Bastion, players can deliberately fall off a barge, forcing the game to respawn them in a non-combative state on a moving barge. In this way, players can traverse part of the level without having to engage in combat. A secondary effect of this loophole is that the narrator does not realise what’s happening; he happily talks about combat as if it is still happening.

In an earlier version of Desktop Dungeons, there was three altars in each dungeon. Each of these altars randomly selected one god from a possible nine gods. These gods were unlocked one-by-one through quests. Players realised that if they have only unlocked three gods, they could know which three gods would spawn with certainty. Thus, the randomness of gods was removed. The developers have since fixed this loophole by making only one altar available in a dungeon until the player has unlocked four gods.

In Rock of Ages it is possible for a rock to hit the door, and then bounce off the pathway. The game then places the rock back on the pathway, allowing the player to hit the door twice with only running the course once. This is a detrimental loophole because the game requires the player to traverse a course before they can hit the door.

In Magic The Gathering the Chaos Orb card removes any card it landed on from play. Some players would tear it up and sprinkle it on their opponents cards to remove multiple cards from play. When a player tried this the first time, the judges ruled it legal, since there was no rule against tearing the card up.

Fallout 3 has a loophole where the player may skip a large portion of the game by going straight to one city (The Citadel), and then using any item to jump into the city, instead of completing the quests to get inside.

In The Elder Scrolls V: Skyrim a player can place a bucket on NPC’s head and rob him blind without the NPC realising it.

In Deus Ex players could uses LAMs, a grenade which could be placed as a proximity mine, as a ladder. This allowed players into areas in ways that were not intended.

A ten year old hacker exposed the following generic loophole at DefCon: in social games that run on mobile devices, you can set the time forward and receive reward without having to wait for it.

More examples:

• Loopholes in Sid Meyer’s Civilisation IV
• Loopholes in Skyrim (levelling up)
• Loopholes in The Sims 3
• Playing games in different ways

Image from xkcd.com/115

Why loopholes are bad

According to Adams, gameplay is

•  The challenges a player must face to arrive at the object of the game.
•  The actions the player is permitted to take to address those challenges.

Loopholes interfere with both these aspects of gameplay.

They remove the challenge of the game. As mentioned earlier, players will take the easiest path towards their goal. A loophole introduces a new, easier path, effectively removing the path of challenge the designer intended. Without challenge, the gameplay is ruined.

They remove meaningful choice. Loopholes mess with the balance of the game, and an unbalanced choice is almost always a no-brainer. The existence of a loophole limits the range of interesting actions the player can take..

There are two additional reasons why loopholes are bad.

They remove fairness in multiplayer games. A game that is not fair is not fun, because all players would have to use the loophole to stay competitive. Designers should always strive to make games fair.

They can break the fourth wall. When a player uses a loophole, the game reacts in a way that exposes its limitations and underlying machinery. This can remove the sense of atmosphere and story from the game, because things no longer make sense without looking outside the magic circle. The narrator glitch in Bastion mentioned above is the perfect example.

General types of loophole

The following behaviours can occur in any type of game. Many games rely on these behaviours for their gameplay, but when they were not the behaviours intended by the game designer, they show a loophole.

Memorizing is when the game or game AI follows patterns that players can memorize.

Pac-Man is famous for this — instead of responding to enemy behaviour, the best players memorize sequences of moves they have to make to complete a level.

The easiest way to avoid players from memorizing game events is to introduce a random element in the game, either in AI behaviour, or item and AI placement, or even just in the timing of the AI.

Predicting is when the player can learn the logic of the AI, and easily defeat it by predicting its next action.

Prediction can be avoided by introducing random elements as explained above, or making AI more nuanced (essentially, making it depend on more input variables).

Brute forcing (also called permutation play) is a way of solving certain kinds of puzzles, usually where the player must figure out the correct combination of moves, digits, levers, buttons, or something similar (there are many of these kinds of puzzles in Machinarium, for example).

In some cases, brute force is the intended method of solution. But when the designer intends the player to use logic and clues provided to solve the puzzle, solving it by brute force is a loophole.

There are two ways to fix this:

•  Add more combinations (for example, adding a lever to a puzzle doubles the number of possible solutions), so that brute force techniques become infeasible.
•  Make the logic or clues more transparent.

Pixel hunting is a special form of brute forcing that is common in point-and-click adventure games. Pixel hunting is where the player mouses over (or clicks, depending on the controls) the entire screen until a indicator pops up to show that they had found an interactive point.

Pixel hunting can occur in any game that highlights interactive points only when the mouse hovers over them or they are clicked, such as a FPS reticle turning red when passing over a hidden enemy.

In some cases making the player hunt for pixels is intentional, such as resource scanning in Mass Effect 2.

Hustling is when a player exploits the dynamic difficulty adjustment of a game by player lower than her potential. This makes the game easier, and eventually allows the player an easy victory. This is similar to pool hustling in the “real world”.

Hustling is most common in the single-player mode of racing games. Racing games use dynamic difficulty adjustment, called rubber band AI, which adjusts the AI vehicles’ performance to match the player’s: the faster the player, the faster the AI. A player hustles by keeping in second place until the last lap (even if she can pass the first vehicle). With the player in second place, the game will not increase the difficulty; it thinks that the player is being challenged.

To fix rubberband exploits can be difficult. The racing game Pure uses a sophisticated alternative to the rubber band method. The system dynamically sets the AI some distance ahead of the player from the start. This means that the player is continually playing catch-up throughout the race until the end, where she can narrowly beat the AI. Like with rubber band AI, the player is generally capable of victory, but she can’t hustle.

Fortune hunting occurs in games with random level generation. The player briefly glances around the level to decide if they feel the level is easy enough for them to complete; if not, they simply restart the level in the hope of a more favourable one. Like the hustler, the fortune hunter is playing the game at a difficulty lower than the one that designer intended.

The designer can prevent fortune hunting in several ways:

•  By normalizing level difficulty so that each randomly generated level is about the same level of difficulty (this can be hard, and requires a good understanding of statistics and the game mechanics).
•  By not allowing a new level to be generated until the previous one has been played.This requires that you can guarantee that all your levels are fair. Otherwise, a level may be generated that frustrates the player to the point of quitting the game permanently.
•  To make it more difficult to judge the level difficulty until the player has invested enough time not to want to quit the level.

Loopholes in FPSes

Edging is where the player stands around a corner and shoots a part of the enemy while the enemy can’t see the player. This loophole can be countered by having the enemy AI seek out the source of the damage.

Picking is the same as edging, except that the player hops out from the corner, shoots, and returns to hiding. As with edging, this loophole can be corrected by making the AI move towards the players to attack.

Wedging can be used on enemies with a short attack range: the player lodges an enemy in a place where it cannot attack her from. This allows the player to pick off this enemy with ease.

Ways to counter this loophole are to give the enemy a long range attack, to allow it a means to reach the player by fixing the level design or improve the AI, or to create entities which force the player towards it (using a rope, for example).

Kiting is when the player can move faster or shoot further than the AI. This allows the player to move backwards and attack the AI while not receiving damage.

Camping is when a player stations herself where enemies can’t see her, and attacks enemies from such a place. Camping is normally done from a distance and with a sniper weapon.

Simply making enemies return fire may cause the player to feel cheated. A proper solution is to make the enemies move towards the player. Another strategy (especially useful in multiplayer games) is to carefully design levels without any good camping spots, and give enough feedback so that players can learn the positions of campers, for example, the Heartbeat Sensors, Unmanned Arial Vehicles (UAVs), and KillCam in Modern Warfare 2.

Splashing is similar to camping. The player positions herself far away from the enemy and shoots an object that does splash damage, such as a grenade, at the enemy.

The are two solutions to this problem: first, the AI can be made to avoid splash damage of oncoming missiles with a bit of physics math; second, the AI can be made to seek out the player who launched the attack.

Serializing is when a player kills an entire group of enemies by picking them off one-by-one. This is typically happens in narrow spaces, or if the AI causes enemies to separate from the group. This is a loophole if the intention was to make it more difficult to take out groups, and give the player an opportunity to choose which enemies to take out first.

The simplest fix is for the enemy to trigger an alert state in the nearby enemies which allow them to move off in a group towards the player. The combat space also needs to be designed carefully to prevent serialisation.

Loopholes in multiplayer games

Turtling happens in games with resources — typically strategy games — and there are more than two players. When two players engage in combat, both will consume resources. This puts the combatants at a disadvantage since they both lost resources in the engagement. In the meantime, the turtle is better off than both, since she did not need to spend any resources, giving her an advantage in the next combat against either player.

This effect can lead everyone in the game to play turtle, which of course prevents the game from moving forward. The solution is to encourage aggressive play by awarding the winner of each battle with enough resources to offset the losses suffered in that battle.

Killing the leader occurs in games where a scoreboard is available during play. Players attack the leader, since she is the person most likely to win, often forming coalitions to achieve this goal.

With the multitude of players attacking the leader, it is likely that they may suffer damages to a point where they can’t recover from them, and they no longer have any chance at victory.

A simple solution is to remove scoreboards from the game. A more complex solutions is to prevent players from cooperating with one and other.

Sandbagging is is a form of hustling caused by the killing-the-leader effect. Good players are aware that others are likely to attack them if they are seen to be doing well. To prevent this, they deliberately underperform until they can act to their full potential and win the game. Note that the killing the leader effect serves as built-in dynamic difficulty adjustment.

The solution to this is the same as that for killing the leader: remove the leaderboard. If players don’t know who the leader is, there is no reason to play sub-optimally.

Kingmaking is when the player lower down in the scores is not able to win, but by her actions she can decide whom among the leaders does win. These actions can be in the form of sending resources to another player, or combining the armies in a coalition. This introduces an element of diplomacy into the game, where a player can win based on relationships and not skill. (As always, it is just a loophole if this is unintentional).

The solution to this is the same as the one for sandbagging and killing the leader: remove scorebords.

Experience leeching takes a variety of forms, but the general formula is the same. A player gains benefit of participation without putting in the required effort involved to achieve the outcome.

In games where experience is awarded to the player who lands the killing blow, leechers are passive in combat until the last moment, when they jump in and kill the enemy to get the experience, at little risk of dying.

In games where experience is awarded to all players in range of the kill, leechers can stay passive all the time; as long as they trail behind, they can get experience without having to take any risks.

Power leveling is a special kind of leeching. A player groups with a high level player who also kills enemies of a high level. Because of the level difference, the low level player will gain a wealth of experience causing them to level fast.

Simple solutions are to assign experience to the player who does the most damage, or to assign experience in proportion to the damage dealt.

AFK loopholes are a special form of experience leeching: instead of putting minimal effort, though, the player doesn’t put in any effort (they are, in fact, away from keyboard). The player hides in a place where other players will not notice that they are AFK, or even employs some form of bot.

Boosting or alt farming or alternate-account farming is a method where a player uses an alternate account to enhance the gains of her primary account. This is widespread in MUDs, where the players have a resource that they can attack repeatedly without fear of retribution. Boosting is also common in fighting games, where a player will “fight” against the character of her second account to boost her stats or position in the leaderboards.

A simple solution is to check the IP usage and discipline the user for abusing the game. The problem with this scheme is that the developer may punish a player unfairly, for example, if a player beats her brother at a game that they play together.

A more elegant solution is to implement a system of diminishing returns, where the continued killing of a single entity gives less gains for the attacker until it no longer to make sense to attack. This can further be improved by also making higher level players receive less benefits from attacking lower level players.

Twinking is the opposite of alt farming. It is when a player creates a low-level character and gives it the benefits that are intended for a high level character. The twink is kept at a low-level so that it may defeat opponents of similar level with great ease.

Smurfing is hustling by using a new account and pretending to be an inexperienced player to lure in and kill players that are actually inexperienced easily. This is common in games where there is matchmaking based on metrics tracking player capabilities. Examples include the recent Call of Duty games, the leagues in StarCraft II, and League of Legends.

Matchmaking systems are self-correcting: metrics will move the smurfer to matches with equally skilled players after a few games, so she can only use this technique a few times before having to create another new account. And with pay-to-play games, the smurfer is required to buy the game each time she wants to create a smurf account. In a free-to-play game it is up to the community and dev team to find a solution using social norms and policy (discussed more in a section below).

Ghosting is when a non-playing observer in a multiplayer game communicates to one player, or team, the actions of their opponent.

A sub form of ghosting is called stream sniping this is when highly skilled player broadcast their games live on a streaming service. Their opponents may then watch the stream and counter their opponents actions as they are watching them.

Account Sharing is when multiple people use the same account to achieve a goal that would need a large time commitment by a single player. With account sharing, such a goal can be reached with only a modest time commitment by each player.

Farming is when players focus on a goal that is not the main goal of the game. This can be something such as increasing their stats, or gaining achievements. Each of which would normally prefix farming when in action.

Achievement farming, in a multiplayer games, is when players of opposing teams cooperate with one and other so that players can easily gain achievements that would normally require skill and investment in the game.

Loopholes in racing games

Short circuiting is when the player finds a faster route to complete the race than the intended one. This can be as simple as driving the course backwards, but normally requires the player to find an error in the level design.

Spawn jumping occurs when the player respawns and has gained time. This normally involves the player dying in such a place that it is possible for them to spawn ahead, or dying in such a way that would dramatically increase her speed. An example of this is the rainbow bridge in Mario Kart, where a player could skip half the race by spawn jumping.

Perma boosting is when the player is able to continually use a speed boost that is only supposed to be used seldomly, or in a limited amount. An example of such an exploit is snaking in the Mario Kart games, where players use power slides to always have a boost on the vehicle. Another example is in F-ZeroX, where separate scoreboards are used for players who perma boost and those who don’t.

Loopholes in game physics

Wall jumping is when the player is able to climb up a wall by jumping against it, usually because of inaccurate physics or small glitches in the world geometry.

In World of Warcraft, before the introduction of flying mounts, it was possible to use this loophole to reach places in the game that the player shouldn’t have been able to.

Bootstrapping is when the player jumps onto an object that she ‘holds’. She just moves up and also brings the object up with her. This allows the player to jump up or fly as if she had a jetpack. The Fallout 3 loophole mentioned earlier relies on bootstrapping for the player to get access to the Citadel.

Bunny hopping is when the player uses a series of secondary movements to increase the movement speed. These movements typically involve jumping or crouching. Bunny hopping techniques vary from engine to engine.

Loopholes in saving systems

Duping is when there is a resource that persists through saves — generally a currency the player gains through an in-app purchase. The player gathers the resource; loads and gathers it again, while they are in turn getting richer for not doing any work.

Cloning is similar to twinking, but instead of creating a new account the player copies a saved game into a dummy account, sells the resources of the saved game for currency, and sends the currency back to the original account via a form of social integration where friends can ‘gift’ things to one and other.

The solution is to track the validity of player saves, or to check where the ‘gifts’ are coming from to be sure that they are from a legitimate user.

Save scumming is when a player makes multiple saves so that they can play a ‘perfect’ game. The player creates a number of saves and simply reloads one until they get the result they want.

A solution is to remove, or disable, a save that is frequently used without the correct condition for the load to happen — player death is typical. This, unfortunately, removes the player’s ability to reload when death is certain even before it occurred. An alternative is to make the games use save points instead of free saves.

Save scumming is similar to fortune hunting — the difference is that a player can progress with save scumming, while a player that merely fortune hunts has to restart the game (or level).

Some games make statistics manipulation a valid game mechanic, for example, in Castle Of The Winds levels are randomly generated on player entering, and players can choose to re-enter the level. This is a kind of fall-back-fix for otherwise broken mechanics (more precisely, broken procedural generation).

Save jumping is when the player uses the game auto-save system to their advantage. The player can do things such as teleporting to a different game point, or run to an autosave point while fighting to load the save and remove the enemies.

How to find game design loopholes

As a designer, finding loopholes is a challenge: you are trying to break the very rules you crafted so carefully to govern the game world. In non-computer games this may be easier because the rules are stated explicitly. In video games, the rules are implicit, and requires a player to learn the rules, mostly, through trial-and-error. Because of the complexity of some games, a loophole may be completely overlooked simply because the “proper way of playing” is ingrained in the designer’s head.

There are four ways to find loopholes in your design.

1. Use your own knowledge, experience and instincts

Look for loophole patterns. With experience, you will start to recognize the patterns that can lead to loopholes, and remove them from the design early. All the FPS loopholes discussed above arises from the interaction between the level design and AI.

Drawing from a large knowledge-base of loopholes in other games in your genre can be very helpful, and it’s a good idea to build such a base for yourself.

Understand player motives. Even in simple games, the possibilities for loopholes are endless. Focus your attention where it matters. Consider what players want to do, and pay attention to the various systems that allows or limits these goals:

• Players want to win.
• Players want more resources.
• Players want to get to every spot in the game.
• Players want to be the first, the fastest, the strongest,the richest, the prettiest, the coolest.
• Players want achievements.

This will not necessarily be the systems with the most loopholes, but it will be systems that players will pay most attention to, and loopholes in these systems are most likely to have important effects (on gameplay, player satisfaction, and even your bottom line).

Don’t Kill Emergence. Trying to predict player behaviour can be tricky, and there is always the risk that your loophole corrections unnecessarily limits the game, and removes the possibilities of positive emergence.

2. Ask fellow game designers to check your design

Fellow designers can be great at finding loopholes. Designers have a good way of looking at a system and its rules and finding where to break them, and they typically have a vast knowledge of various loopholes in other games.

Of course, this method is not perfect:

•  different designers may not agree on what are the loopholes of the game; and
•  even a hundred game designers may still overlook some loopholes.

3. Test

Testing overcomes some of these problems: gamers don’t have designer’s bias, and you can generally find more game players than game designers willing to comment on your game.

Gamers know their game worlds have rules, and that they can break these rules to their advantage. Tournament level players are often used as balance testers and have been extremely important in the making of games such as Starcraft 2 and Counter Strike: Global Offensive.

Metrics are a powerful tool for finding loopholes, especially if you have a large test group. A simple statistic such as number of players that choose a certain character may point to a balance issue: if a disproportionate number of players choose a certain character or combination, you know there is a problem. The course blog Game Balance Concepts gives an extensive overview of the use of metrics in game design.

The Desktop Dungeons team was able to pick up the loophole with the gods by looking at the metrics of their players. A number of players were creating alternative characters on the same account where they unlocked only three gods. This puzzled the developers, until they realised the advantage of only unlocking three gods.

Metrics are also useful to pick up more general exploits: metrics exposed a highly skilled guild of WoW players that used a client side tool to delete a wall during a raid and skip to the last boss, making game events happen out of the planned order.

A heatmap — a visual depiction of a metric on the game map — is another useful tool in finding loopholes. A heat map can show things such as player deaths, shots fired, enemy cover and player exploration. Heatmaps make it visually apparent where there are topographical problems with the map. See for example how this technique was applied in Halo 3, Just Cause 2, Replica Island, Counter Strike: Global Offensive, by BioWare, and even in point-and-click adventure games.

 Player deaths in Just Cause 2.

4. Use feedback from players in the field

Once a game has shipped, and your game is played by a large number of players, even more loopholes will be exposed. Adding metrics to your games can be very helpful to expose loopholes in these circumstances (players may not want to report loopholes as eagerly as testers). Unfortunately, you will only be able to fix with a patch or update.

How to fix loopholes

Change one of the components. Since loopholes arise from the unintended interaction of game elements (rules or systems), a loophole can generally be fixed by making a change to just one of these systems. For example, all the FPS loopholes discussed can be fixed by either changing the level design, or by changing the AI.

Change the interaction. Loopholes can also be fixed at the points where systems that cause them interact. Taking the FPS examples, the AI can be adjusted to take the level design into account, so that alternate behaviours are used based on the topology of the surroundings.

Beware: general versus specific solutions. Some loopholes can be fixed by introducing very specific rules or exceptions. For example, in an FPS game, AI can be developed for specific zones: “if I am close to position (123, 456), I need to move away from the crates”. Alternatively, problems can be fixed with general rules; in an FPS, for example, the AI may be adjusted “if I am between two crates, move away”.

General rules are more elegant and easier to manage. But adding general rules to fix loopholes may introduce new loopholes. Specific rules don’t impact on the overall game, but many may be needed, leading to debugging nightmare. “Why is this AI moving away from crates when he is near the big boss?”

Rely on social norms. In multiplayer games, social norms can make up for broken rules. This is especially useful when a loophole would be too expensive to fix, or a solution is not clear. Online justice systems are an essential part of MMO social systems. Such social norms can be provided by behavioural guidelines — such as the World of Warcraft harassment policy — or rewarding players who positively contribute to the community, such is the plan for Dota 2.

It’s not a bug, it’s a feature

A loophole can destroy a game, but not always.

Some loopholes require considerable skill in themselves, and thus they don’t break the game. In the developer commentary for Portal. The developers said they left trick methods of completing the puzzles in because they required more skill than completing the puzzle normally would.

Some loopholes become new mechanics. If they are rich enough, it can still be a good game, even if it is not the one the designer intended. In Quake 3 players could use a combination of directional jumping and turning to increase her speed. This technique, called strafe jumping, was never planned for, but it soon became an essential part of the game, and the developers decided to leave it in.

The loopholes in a game can even become the main mechanics of the sequel. In Starsiege: Tribes the movement system allowed players to attain very high speeds by using their jetpack to go down a hill. This is referred to as skiing, and is one of the core feature of every tribes game.

Some loopholes have little effect in the greater scheme. They may make one small part of the game easier, but overall don’t change the difficulty. In this case, they may become a source of amusement, such as the bucket-on-the-head Skyrim loophole mentioned earlier.

Some loopholes “fix” broken design. Yes, if you take out the ability to bruteforce puzzles in certain games, they may be totally unsolvable.

Finding loopholes is a sport. The meta game of speed runs use sequence breaking loopholes so that the player can complete a given game or level thereof in the least amount of game time possible.

Conclusion

Loopholes pop up from time to time. Experience and knowledge of loopholes in other games will help you avoid them, and proper testing to find and remove them when they do slip through.

Give us some of the loopholes found in your games in the comments!

References

Many of the terms used in the FPS section and some in the general loopholes section come from John LeFlohic’ article Computer-Game Enemy Design.

Some terms in Loopholes in multiplayer games were taken from Ian Schreiber’s course blog Game Balance Concepts.

Many of the multiplayer game loopholes come from Wikipedia: Exploit (Online Gaming), Cheating in online games, Bunny hopping, Duping, Camping,

Many of the terms and examples come from TV Tropes under various entries: loophole abuses, sequence breaking, gameplay derailment, not the intended use, easy level trick, rubber band AI.

Thanks

My thanks to Jonathan Hau-Yoon for completely breaking my card game. And Herman Tulleken, my editor, who put a great deal of effort into polishing this article.

Related posts:

1. Minimised game design for indies When you sit down to write a book, one of...
2. Video game user interface design: Diegesis theory In this article, the Dave Russell introduces the basic concepts...
3. Board Silly (Tabletop Game Design) Two Dev.Mag writers share their board game design experiences: conception,...
4. Desktop Dungeons: Design Analysis (Part 1) This is the first part of an in-depth look at...
5. Game Design: On Ideas In this article, Julian Pritchard gives us his take on...
6. Desktop Dungeons: Design Analysis (Part 2) In this second part of analyzing Desktop Dungeons, we look...

In a previous article, we looked at the diegesis theory of interface design. The theory can also be applied to audio design. This is a look into the design of audio for games, and how diegesis theory can help us structure our thoughts.

So where do we start? Let’s start with an experiment.

1. Turn computer on mute, start-up favourite game and play a bit of it.
2. Now do exactly the same thing, but this time with the audio.

You would have most likely found the game easier, and more enjoyable to play. So what are the functions of audio in games? Sound serve four main functions in a game:

• Sound gives feedback to the player, often in addition to visual feedback. This is most obvious in the interface, where buttons make noises. In the game itself, audio feedback helps the player feel his actions have an effect, an example is the sound played when a gun is reloaded.
• Sound gives the player information about the game and its world itself, for example, the sound of approaching enemies warns to player to get ready. It also helps draw the attention to important game events.
• Sound forms part of the award system of games. The sounds and flashes that go with completing a row in Tetris make the act much more pleasurable. It is a short-term award that supports the long-term award of not dying and beating a high-score.
• Sounds help create realism. They help to immerse the player deeper into the game world and encourages the suspension of disbelief. It helps put the player in the scene, making her part of the action. Explosions without audio are neither believable, nor very dramatic.
• Sound creates mood and pace, most often as background music. The cinematic soundtracks used in strategy games have nothing to do with realism or feedback or information. Instead, glorifies the setting, it makes the events feel epic, and so enhances the player’s feeling that he is doing something important. Similarly, the action-packed feeling of an arcade game is as much a result of the blingy music as it is of the actual gameplay.

This article is going to look at how we can use the concepts of diegesis or narration to help us design audio for a game. We will look at various different games to understand how this approach will help us.
As with the diegesis theory of interface design, we are concerned with two main concepts: narrative and the fourth wall. I repeat the explanations of these two concepts from the interface article:

Narrative

Narrative is a message that conveys the particulars of an act or occurrence or course of events. In simple terms, it is the story the designer wishes to convey; be it the story of blocks falling from the sky which need to land in the right place (Tetris), or a journey through a strange land (Machinarium).

Not all elements of a game are part of the narration. For example, the game menus and the HUD, because the game’s characters are not aware of these elements. This does not mean these components do not support the narrative. For example, a futuristic game typically has GUI elements that also appear futuristic.

The fourth wall

The fourth wall is the imaginary divide between the player and the world of the game. In order for the player to immerse themselves in the game world, he needs to move through the fourth wall. The ease with which the player moves between the real world and the game world depends on the way the interface designer delivers information to the player.

Posting your latest game accomplishments on Facebook is an example of how a game extends beyond the fourth wall. To further delve into this concept, one should read Steven Conway’s interesting discussion of the fourth wall in games: A Circular Wall? Reformulating the Fourth Wall for Video Games.

Sounds in games

We can now ask ourselves two questions about any sound:

• Is the sound of the game story? (Is it part of the narrative?)
• Is the sound of the game space? (Is it behind the fourth wall?)

Depending on the answers, we can classify the sound into one of four classes: diegetic; non-diegetic; spatial; or meta.

The diagram below summarises the four possible combinations.
In talking about audio, meta and spatial representations are often clumped together with non-diegetic and diegetic sounds; we won’t cover go into detail into meta and spatial representations here (they are not very common), but it is still useful to keep the distinction.

Diegetic sound

For diegetic sound, we answer our two questions as follows:

• Is the sound in the game story? YES
• Is the sound in the game space? YES

When we talk about diegetic sound, we are talking about sound that is part of the world that the player is in, any audio produced in your game world. This is includes sound-effects, ambient environmental sound, and game character dialog.

In this trailer of Call of Duty: Black Ops, all the sound is diegetic. The absence of music helps build tension, and helps the player focus on the events as they unfold.

Although diegetic sound is used most often to increase immersion and realism (bigger guns make bigger noise), it can also support gameplay. In Dead Space, the audio (an alien “screaming” from behind) is used to draw the player’s attention to the wave of enemies that is behind him.

Non-diegetic sound

For non-diegetic sound, we answer our two questions as follows:

• Is the sound in the game story? NO
• Is the sound in the game space? NO

Non-diegetic sounds are audio cues provided from outside the world that the player is in. This includes background music (where is this magical omnipresent band playing in the world?) and interface sounds.
Music is incredibly useful to create atmosphere and manipulate the player’s emotions. (Changing the music is the single most effective tool used for genre bender spoofs, such as the recut trailers for Mary Poppins or The Shining).

Robot Unicorn Attack the crazy backing track supplied by Erasure, together with the chirpy graphics, emphasises the ironically chosen title of the game.

In games that use adaptive music, the player’s emotions can be controlled even more tightly. How much more dramatic is a battle when the brass enters as it starts?

Interface sounds give the player feedback on his or her actions. They are vital to show that the interface is responding, and to draw the player’s attention to important events or information.

In Borderlands, the music effectively becomes part of the interface, changing based on your life level, presence of enemies, and their difficulty.

Meta representations

For meta sound, we answer our two questions as follows:

• Is the sound in the game story? YES
• Is the sound in the game space? NO

Meta audio is audio which sits between the world of the protagonist and the player. The most obvious example is a game narrator, which is not part of the game world, but definitely adds to the story. In Bastion this is taken to the limit, where a running commentary is given on the player’s every move.

Spatial representations

For spatial sound, we answer our two questions as follows:

• Is the sound in the game story? NO
• Is the sound in the game space? YES

Spatial audio representations are sounds set in the game space, but is not part of that world. It is not very common in games, mostly because we cannot easily map the source of a sound with a location in the game.

One example is in Anno 1404, where the music changes depending on the location the player is viewing: the music gets an Arabic flavour when the player views locations in the “Orient”; this, together with the visual differences, helps to sets the east part from the west in the game. Another example is the audio-navigation system used in The Path.

Links

• The IEZA framework is another very useful theory of game sound. It also makes use of the diegetic axis.
• Game Sound provides a whole bunch of links to publications on game audio.
• Sander Huibert’s thesis Capitivating Sound [14.6 MB, PDF] provides a wealth of useful information on how game sound contributes to immersion.

Thanks

Thank you Zachary Reese and Devin Moore for giving some of the examples.

Header image from http://www.flickr.com/photos/frostnova/606822557/sizes/z/in/photostream/.

Related posts:

1. Video game user interface design: Diegesis theory In this article, the Dave Russell introduces the basic concepts...

Hi, thanks for doing this Dev.Mag interview. For the record, please state your name, what you do, and your favourite pastry.

Alicia: Heya, my name is Alicia Yeargin. I’m currently a student at DigiPen Institute of Technology in Redmond, Washington, and about to complete my Bachelor of Science in Game Design. My favorite pastry is, without a doubt, the maple donut.

Your degree is a tech degree. Did it include non-technical topics?

Alicia: Yes, my degree had one introductory psychology class, and I took a number of different art classes. There were two sketching / traditional art classes, one 3D art class, an architecture class, an art appreciation class, a film class, and a Photoshop class.

Cool! I like that amount of art in a ‘tech’ degree.

Do you think, as a game designer, that you should have a good grasp, or at least an understanding, of tech, art, and music?

Alicia: Absolutely. Even though I don’t take any more art classes, I continue to use 3D Studio Max and sketch in notebooks. Naturally, all the things I make are crap, but just doing it helps me understand the art process; I think that’s incredibly important.

Music is something that’s always been beyond me, though. It’s not very big at DigiPen right now. (The rumor is that we’re getting an audio degree of some kind.)

I’m happy to hear that. The reason I was asking about music is that when I look at games like Bastion, Amnesia, and even Deus Ex: Human Revolution, I see that music forms an extremely important part of the atmosphere. So it should be something that a designer should have in their arsenal.

Alicia: I agree.

So do you feel you would do anything to expand your knowledge of music?

Alicia: At this point, I’m not sure. It’s unlikely. I’ve just personally never been musically inclined. I have a good ear for things; just not the mind or anything to create it.

What do you feel the relationship between coding and design is like?

Alicia: It should be together, definitely. I can’t imagine even calling myself a designer without knowing how to code. It’s super huge for understanding the tech behind games and how the software actually works.

So what kind of background in coding would you feel someone approaching design from and art side would need?

Alicia: At DigiPen even our artists learn some code -even the BFAs (Ed. note: the BFA referred to is the DigiPen Bachelor of Fine Arts in Digital Art and Animation)  who may never touch a game in their lives do some code-, mostly ActionScript. Even if you’re an artist, I think you should have some ActionScript or something like that in your belt. Technology’s so huge these days; it’s kinda crazy to not.

Did you learn anything about the production side of things?

Alicia: In terms of being a producer and team management?

Yes.

Alicia: That’s kind of an interesting thing here. Every year, we work on a team project, and on every team someone has to be a producer; it’s just a requirement of the class. So, someone will be learning a bit about scheduling. We do have, I think, one or two management-type classes, but it’s not super huge. I personally haven’t taken any of those, and I was a producer on my first-year game team.

Making video games is an applied field. How often did you make projects and such things?

Alicia: First year, we made an individual semester project with the engine provided by the school. (It’s something like GameMaker.) The second half of first year, we worked on a team on an ASCII game.  Second year was a two-semester (one year) long 2D game. Third year was another year-long 3D game. Fourth year has more leeway. It can be 3D or 2D, and we also can do solo projects in order to pursue something more specifically related to our desired fields. For designers, there are also the design courses where you make prototypes of games and other projects as well.

Are those design courses similar to Global Game Jam style of making games?

Alicia: Oh. Hmm, I don’t know enough to make a direct comparison, but I can say it does vary between each class. One class, we had a prototype due every two weeks. One week an RPG, another an FPS, and so on. In my analog class right now, we’re just doing two projects. First half of the semester was a tabletop RPG, and the second is a tabletop simulation game.

Would you have like to do more prototypes or less?

Alicia: Hmm, probably less. I would have preferred to spend more time on projects to get further polish on them.

Do you believe polish is an important aspect of every game?

Alicia: Yes, I think polish matters. That may just be more of a personal thing. I’m kind of a perfectionist. I always notice the little things.

Well, there is a point where you have to let things go, otherwise you end up with Duke Nukem Forever.

Alicia: Definitely.

Do you think there is a difference between a story and a narrative?

Alicia: Yes. I believe pretty much every game ever has a narrative, but I think story requires a little bit more. (I’ve yet to do enough personal research and study to fully define where the “line” of story/not-story is, if it exists.)

Did you try and make games before you started your studies?

Alicia: I actually didn’t really. I went to the ProjectFUN summer program that DigiPen hosts, and I made a game there. Other than that, I really hadn’t even thought much about making games. I’d always just been a writer, but I knew I didn’t want to write novels.

What sort of writing courses did you study? Or have you just always been a natural writer?

Alicia: Writing has always been huge for me, even before I ever started playing games. DigiPen has a decent amount of English classes, though not very many writing classes. I think having actual writing classes is something the school needs.

With your background in writing, what position would you like to end up with in the game industry?

Alicia: At the moment, I’m just digging around to see if I can find any level-design jobs. If not that then playtesting. Ideally, in five to ten years, I’d like to work my way up to a position as a full-time writer for games. Maybe something like a Mass Effect or a Skyrim.

Do you think that Mass Effect and The Elder Scrolls games are good in terms of their story?

Alicia: I think Mass Effect’s story and dialog are both incredible. The Elder Scrolls series is amazing for its lore and depth and uniqueness of universe. (I started with The Elder Scrolls III: Morrowind, so that’s why I say that.) The actual game stories in the Elder Scrolls games are, admittedly, a bit flat, but I’ve always enjoyed the writing in the quests.

Mass Effect, and The Elder Scrolls games are massive, but do you think you could make a complete game by yourself?

Alicia: It’s possible. I’ve technically almost done that with my senior project. However, it’s not easy, and it’s not practical for a professional game. Although, it does give you a REALLY good appreciation for every part of a game team.

Minecraft did start out as a one man project. Do you think it will be more common for game to grow with their community as minecraft did?

Alicia: Yeah, I can definitely see more things popping up like that, especially with the way things seem to be growing for Internet-based products like that.

With regards to your student projects how do the IP-rights for those work?

Alicia: DigiPen owns everything. No question about it. Even access to installers for games, those have to be distributed through DigiPen’s website (unless super special permission is given).

Yeah, I remember downloading The Fourth Wall from the website. Has any full scale game ever emerged out of digipen, or do they end up like Narbacular Drop and Portal?

Alicia: No commercial full scale games can emerge from DigiPen; that’s just the way things are. If the students want to take their ideas and go big, they have to go the way of Portal pretty much.

Now that you have basically completed your degree, are there anything you wish you could have learned, learned more of, learned less of, or even not learned at all?

Alicia: I wish there were classes dedicated to learning specific tools or something, like a class on Unreal, as a design course elective or something. I think that would have been very helpful. Unreal experience is something a lot of companies look for, and I’m one of the few graduating designers who actually has it.

Also, a class in mobile game design might have been great. Not sure how that would have been done, but that’s such a huge thing now; I feel like it would have been nice to get more experience with that.

That is a rather strange concept to me. In South Africa just about everyone makes mobile games, and perhaps even more people make their games with Unity.

Alicia: Yeah, Unity is just now getting into our design courses as a serious thing. I’ve had some prior experience with it, but I’ve talked to very few dev’s who use it (so far). I like it though.

What kind of text books were you given for game design?

Alicia: Not a lot really. The only book that was consistently a recommended/required bit of text between classes was Schell’s The Art of Game Design. We do a lot of learning by doing here.

Thanks for the interview. Anything else you want to say?

Alicia: DigiPen’s done a great job kicking my butt every day until making me into a solid game designer, and it’s been tough–but a really good experience. Looking forward to graduating and finally getting into the industry!

Thanks for the interview!

No related posts.

Looking into the development cycle for video games we look at one of the worst, and almost unavoidable occurrences. Crunch. For a common definition of crunch, or in full crunch time, Wikipedia give us A critical period of time during which it is necessary to work hard and fast . Indeed when we are crunch, for anything, we work as hard and as fast as we can.

But unfortunately crunch has a series of negative effect. In a brief summation of Evan Robinson’s article Why Crunch Modes Don’t Work: Six Lessons. Crunch leads to a short-term productivity boost due to the extended hours the people work. But in a long-term scenario crunch leads to a loss in productivity as the there is a natural peak amount of hours that a person can work and be effective at that work. As such it leads to poor work rushed out to meet deadlines. This happens with video games, writing, and many other things.

Given the apparent nature that a long-term crunch is a bad thing why does it occur? In larger development this occurs due to publishers only giving so much money to the studio to complete certain goals. This leads to the management pushing harder on the staff to be more productive without giving them overtime. Which in often enough they do not have the money for, as it was said above they crunch to meet a deadline so they can get money.

With small-medium sized studios, it comes down to budget. The investors a lot a certain budget to a project. And if they can’t make that deadline they have to let staff go or close. So they crunch to make deadlines to survive. Often if the project is not complete a skeleton staff remains to finish the project to something ship-able – or it is handed over to a third-party developer who get paid once the game is released.

With, unfunded, indie studios it is simple. Since you have no one signing a pay check you need to finish the game so you can eat. If it came down to crunching or starving I am sure most people would be crunching.

It’s not always about the money

Unfortunately the financial losses of crunching are not always the greatest worry, you won’t find many developers who make games purely for the money. One of the most famous cases of the effect of crunch was written almost a decade prior to this article. It was a LiveJournal entry by Erin Hoffman, who used the pseudonym ea_spouse. She highlight the emotional, mental, and physical strain that her family took due to the extended period of crunching in game development.

It is easy to understand how when working over double the number of hours a week that most other people to, and only to be told that you won’t receive over-time, days off, or any compensation for that matter would have a terrible effect. On a person’s mental and emotional state. And given the long hours one can easily see that it would put strain on both a person’s body, and their relationships.

Another infamous, but more recent, case of game development crunch was the developers of L.A. Noire, Team Bondi. Reports of 12 hour 7 day a week work weeks being the normal conditions. This was also expanded upon by the fact that developers who refused to comply with these abhorrent conditions were refused a title in the credits.

What is special about games?

Given the above, people who don’t work in the game development industry may wonder why on earth we go through this.

Well, many don’t. The average time developers stay in the industry is 5 years, and taking that further; according to the IGDA quality of life white paper only 3.4% of people working in the industry have beyond 10 years experience.

And those that put up with this?

Game development is of course not unique in this regard; many other industries also deal with the same problem, software development is infamous for projects going overtime and over-budget. As is always the case, those who do it believe the benefits outstrip the negatives. They do it because it is part of the price to pay. If you want to become a doctor, you have to study for many years, and depending on your country, work for the government for a few years after that. If you want to be a game developer, the chances are that you will have to crunch it is a part of the industry unfortunately, and even more unfortunate is how often it is necessary.

So what are the benefits of being a game developer?

The people who work in video games have a passion and love for games. The best parable is: “If you win the lottery you are happy for a year, but if you love the work you do; you are happy for life.” For those who find the right place in the industry I do not believe that they would do not believe that they would do anything else.

But unfortunately many companies propagate the mentality of: “This is game development be grateful you have your job here, and get used to crunching.”

That is a very unfortunate reality, and one that is not true. Work is like life there are periods when things are good, and there are periods where you have to get things moving and give it all you have. The thing that is being opposed is a system of continual overtime without compensation.

But there are places, like Valve, which emphasise an open-work environment, and collaborative work mentality. Perhaps this is an ideal for game development? On the other hand Extra Credits did a piece on EA marketing* in which they covered an old advertisement, which I found transcribed here. I cannot do it justice by paraphrasing, but I will say it talks about issues which I believe are at the heart of video games but are so often forgotten.

What to do about crunch

As a developer there are some things you can do to avoid crunch. The first is understand the ethic of the studio that you work at. If it seems wrong how it works speak to your lead and producer. Producers are in charge of scheduling so if there is a reason for crunching they are definitely the ones to speak to. Some times you with your fellow workers can open negotiations so that you receive the appropriate benefits for the crunch, or have a reduction in the amount of time spent crunching, but keep the reasons for why studios crunch in mind when you do this.

In the end if it seems like the studio is abusive towards its employees then that is not a good place to be at. I would suggest finding somewhere else to work. Since if you believe that game development is the job for your then there is most likely a studio that is the right place for you.

Or you can write an article about crunch which abuses the English language so hard that grammar nazis cry in an attempt to give people an example of why crunch does not work.

*If you want to just watch the segment of video related start at 5:15.

No related posts.

No related posts.

Related posts:

1. Latest Game Career Guide challenge results I’m going to assume you know about Game Career Guide...

Related posts:

1. Your ideas don’t matter … much ...
2. Minimised game design for indies When you sit down to write a book, one of...
3. Loopholes in Game Design I had just finished working on my latest card game;...

In a previous article, I gave you 11 Tips for making a fun platformer. That article had general tips that covered a wide range of game design tasks. This article looks specifically at the process of designing levels for a platformer. The process is a guideline and covers the steps from the initial idea to the final playable level.

The article does not focus on scheduling. However, you do need to keep scheduling in mind when designing levels. The size of a level and the amount of resources it contains depend on the number of people working on it, and the time available to complete it.

1. Choose a visual theme

Choose a visual theme for the level. You can go with a predetermined, game-wide theme, such as ‘Forest’, ‘Ice’, ‘Lava’, or ‘Castle’. Or go for something more creative, such as ‘Steampunk Cloning Facility’, ‘Psychologist’s Nightmare’, or ‘Cupid’s Ice cream Parlour’. Ask everyone in the team for theme ideas.

2. Make a list

Make a list of everything you want the player to experience in the level. This includes what the player does, sees, learns, hears, and encounters. The list should include specific items and general items.

• Specific items usually occur once in a level.
• General items occur more than once in a level.

Throughout the article the term ‘item’ is used to refer to the items of a list. These items not only include game items (power-ups, keys, and doors), but also events (finding the first locked door), enemies, and game mechanics (double-jumping).

Write down how many times each general item occurs (for example, there could be 50 coins to collect in the level, or the player might need to defeat 10 swordsmen). These numbers are estimates, and they help you to determine the level’s difficulty. For example, there could be two Tough Trolls in level 1, but four Tough Trolls in level 2. Let everyone in the team contribute to the list.

The following examples are also used in the images later in this article:

Specific items:

1. Meet first enemy.
2. Find first power-up.
3. Learn about double-jumping.
4. Learn about destructible environments.
5. Find first locked door.
6. Find first key to open the locked door.
7. Pull lever to activate the moving platform.

General items:

1. Foot soldier enemies (x30)
2. Gun turret enemies (x10)
3. Power-ups (x30)
4. Moving platforms (x3)
5. Locked doors (x2)
6. Keys (x2)

3. Make a rough layout

Draw a very rough layout of the entire level. This layout should show the path that the player will take through the level. Think of it as designing the street layout of a city, but ignoring the buildings.

You may end up doing several layouts before you have one that you’re happy with. Usually, the reason for changing the layout is one or more of these:

• Some areas are too big or small.
• Some lines are too straight and too long (i.e. boring).
• The overall layout is too simple or too complex.
• The overall layout looks uninteresting.

An example of the rough layout of an entire level.

4. Make rough sketches for the specific items

Players will need to find each item in the list that you created in step 2 somewhere in the level. They might also find some items in the same area. Make rough sketches of each area in which the player will find the specific items in the list.

Use symbols to identify the various objects in the level, for example, E for ‘Enemy’, P for `Power-up’, and K for ‘Key’. Also make notes on the sketches.

Distinguish clearly between negative and positive space when you do the sketches. The negative spaces (white in the sketches) are the areas where the player can move, and the positive spaces (diagonal lines in the sketches) are things like floors, walls and platforms where the player cannot move.

These sketches help you focus on the layout of each small area, without having to worry about where they fit in the overall layout of the level. Think of it as focusing on designing a building and ignoring its location in the city.

You may make sketches for some or all of the general items, but it is not necessary. The general items are usually moved around when you design the detailed layout or play test the level, so they may end up in completely different areas than you originally planned.

Examples of rough sketches

Specific item 1: Meet first enemy.	Specific item 2: Find first power-up.
Specific item 3: Learn about double-jumping.	Specific item 4: Learn about destructible environments.
Specific item 5: Find first locked door.	Specific item 6: Find first key to open the locked door.

Specific item 7: Pull lever to activate the moving platform.

5. Make a detailed layout

Draw a detailed layout of the level. The detailed layout uses the rough layout (from step 3) as a guideline. It includes all the specific items (copying the rough sketches from the previous step) and the general items. When you copy the rough sketches of the specific items, you may need to change them slightly (for example, change the size, flip it horizontally).

Place as many of the general items in the detailed layout as you can. You can add the remaining general items when you build the level using a level editor.

When you place the items, keep in mind the path that the player will take through the level. Certain items may need to be placed in a specific order, such as a weapon being placed somewhere before the player encounters the first enemy.

An example of a detailed layout.

The locations of the specific items on the detailed layout.

6. Build the initial layout

Use a level editor to build the level’s initial layout, using the detailed layout (from the previous step) as a blueprint. You may need to change the sizes of some areas when you build the level. This happens because the layout sketch is usually not drawn exactly to scale. Also use the editor to add all the outstanding general items to the level. For example, your list might contain 20 enemies, but the detailed layout has only 15 enemies. Add the remaining 5 at this stage.

First build the initial layout before you add the visual details. In other words, use limited graphics for the initial layout, to make it easy to change things if you need to. For example, if you have five grass images, use only one for the initial layout. You can add the other four in step 8 when you decorate the level.

At this point the final graphics for the level may be incomplete, in which case you can use placeholder graphics. It is a good idea if the placeholder graphics have similar colours to those of the final graphics, because the colours affect the feel of the level.

7. Play the level

The initial layout is for playing the level, so that you can determine if it is fun and how long it will take to play through the level. Play the level and change the layout until is it fun and balanced. Let other people play it as well.

Changing the layout may include the following:

1. Move, add. or delete platforms to make jumps easier or more challenging.
2. Move, add, or delete power-ups to balance the amount available.
3. Move, add, or delete enemies to make the level easier or more challenging.

Important note: By the time you design and build your first level, you should already have prototyped and finalized the gameplay mechanics using temporary test levels. If your gameplay has not been finalised by this time, then you risk having to change your levels when the gameplay changes. For example, if you decide to make the player jump higher, then you will have to move many platforms to accommodate the new jump height. Changing fundamental gameplay usually has a ripple effect.

8. Decorate the level

Once you’re happy with the level’s layout and once it’s fun to play, then add the details. This includes adding all the final graphics and audio. Play the level again to make sure that it still feels the same – or better – after all the graphics have been added. There’s a good chance that the level will feel different. It should feel better with the final graphics, but sometimes it may feel worse. For example, the placeholder background might have been a single colour, but the final background might be a detailed image that makes it difficult to see the enemies, in which case you will have to tone down the background or change the enemies, whichever will be quicker.

Further Reading

Super Mario Brothers 3 – Level Design Lessons (Radek Koncewicz)

• http://www.significant-bits.com/super-mario-bros-3-level-design-lessons
• http://www.significant-bits.com/super-mario-bros-3-level-design-lessons-part-2

Level Design Lessons (Anna Anthropy)

• Low Overhead
• To the Right, Hold on Tight
• In the Pyramid

Related posts:

1. 11 Tips for making a fun platformer This article gives handy tips for designing and building a...
2. Desktop Dungeons: Design Analysis (Part 1) This is the first part of an in-depth look at...
3. Desktop Dungeons: Design Analysis (Part 2) In this second part of analyzing Desktop Dungeons, we look...
4. Video game user interface design: Diegesis theory In this article, the Dave Russell introduces the basic concepts...
5. Board Silly (Tabletop Game Design) Two Dev.Mag writers share their board game design experiences: conception,...

One of the most visited articles on our site – How to Use Perlin Noise in Your Games – also caused the most problems. The pseudo-code contained an alarming number of bugs (one of the nastier ones is depicted above), which made it difficult to implement. Readers pointed out these in the comments, and so helped to make the pseudo-code progressively more correct. But even so, some operations remained unclear, so that I finally decided to replace the pseudo-code with real and tested code. I really hope that all bugs have now been squashed!

In the spirit of this extermination effort, this article gives some pointers to get a version of the algorithm up and running as quickly as possible. It is an extension of the original Perlin noise article, and refers to the code now presented there.

Common Errors

Some mistakes that are easy to make:

• Swapping rows and columns, and widths and heights.
• Confusing floating point values (in the range 0 to 1) with byte values (in the range 0 to 255). One symptom of this is black images.
• An error in the interpolation.
• Sampling the wrong points.
• Inverting octaves (highest for lowest, and so on).

The following tips will help you avoid these errors, and help track them down faster when they occur.

Implementation Tips

1. Use a non-square image to test

One of the easiest mistakes to make is to swap around widths and heights, or x and y coordinates. Using non-square images will help you detect these errors faster.

2. Implement linear interpolation first

Only once you have this working, you can try other interpolation schemes (such as cosine interpolation). This way there is less risk that the interpolation algorithm is wrong and throws you off the track.

3. Save interim images to file

The smooth noise images are a valuable aid in finding bugs. If they don’t look the way they are supposed to, you know something is wrong. (Below I give some typical examples).

When Things Go Wrong

If you get different results from what you expect, here are some things you can try to help you find the error faster:

1. Check your smooth noise images

Here is how they are supposed to look for different octaves and linear interpolation:

Octave 0	Octave 1
Octave 2	Octave 3
Octave 4	Octave 5
Octave 6

Here is how they are supposed to look for different octaves and cosine interpolation:

Octave 0	Octave 1
Octave 2	Octave 3
Octave 4	Octave 5
Octave 6

2. Check other variables of the smooth noise function by writing them into images

a. Check the blend factors

Modify the smooth noise algorithm to save the vertical and horizontal blend factors to an image, like this:

float[][] GenerateSmoothNoise(float[][] baseNoise, int octave)
{
   ...
 
   for (int i = 0; i < width; i++)
   {
      ...
 
      for (int j = 0; j < height; j++)
      {
         ...
 
         ////////////////////  Changed for debugging
         //smoothNoise[i][j] = Interpolate(top, bottom, vertical_blend);
         smoothNoise[i][j] = horizontal_blend;
      }
   }
 
   ////////////////////  Added for debugging
   SaveImage(smoothNoise, "horizontal_blend" + octave + ".png")
 
   return smoothNoise;
}

For different octaves, you should get a series of ramps from black to white.

For vertical_blend:

Octave 0	Octave 1
Octave 2	Octave 3
Octave 4	Octave 5
Octave 6

For horizontal_blend:

Octave 0	Octave 1
Octave 2	Octave 3
Octave 4	Octave 5
Octave 6

b. Check your sample points

Save sample points in an image, by modifying the same line as above to this:

////////////////////  Changed for debugging
//smoothNoise[i][j] = Interpolate(top, bottom, vertical_blend);
smoothNoise[i][j] = baseNoise[sample_i0][sample_j0];

Do the same for baseNoise[sample_i1][sample_j0] and baseNoise[sample_i0][sample_j1], then compare them (it is only necessary to compare one octave – choose one that is easy to see). They should all be the same, except that they are translated by the sample period, as shown below:

i0 j0	i1 j0 (The same as i0 j0, but translated to the left)
i0 j1 (The same as i0 j0, but translated to the top)

3. Check that your smooth noise is blended correctly

• Change your base noise to pure white. The resulting image should also be pure white.
• Change your base noise to pure black. The resulting image should also be pure black.
• Check your resulting Perlin noise for different persistence values.

Here is how the images look for different persistent values and linear interpolation.

Persistence = 0.1	Persistence = 0.3
Persistence = 0.5	Persistence = 0.7
Persistence = 0.9

Here is how the images look for different persistent values and cosine interpolation.

Persistence = 0.1	Persistence = 0.3
Persistence = 0.5	Persistence = 0.7
Persistence = 0.9

If you have any more implementation or debugging tips to share, please let us know in the comments!

Related posts:

1. How to Use Perlin Noise in Your Games (Originally appeared in Dev.Mag Issue 20, released in February 2008.)...

In the article Bézier Curves for your Games: A Tutorial, I introduced Bézier curves and Bézier paths. In this tutorial I provide some algorithms useful for working with Bézier curves: determining the length of a piece of curve; interpolating a set of points with a Bézier path; and reducing a large point set to a smooth Bézier curve. (Image by snuffyTHEbear).

Calculating curve length

Assuming that the line segments we use for drawing are a reasonable representation of our curve, we can estimate the curve length by summing the lengths of the segments. These can be added together to get the length of a Bézier path.

A more complicated strategy is necessary when we need the length of only a part of the curve, and not the complete curve.

First, we must cache the accumulative length of segments when we update the drawing points. For example, if the lengths of the first three segments of a curve are 2, 3 and 1, the accumulative lengths are 2, 5, and 6.

Then, we can use a simple subtraction to find the length of the piece of the curve (assuming, for a moment, that we need it only between points that coincide with the drawing points). For example, to find the length of curve between drawing points 5 and 8, we do the following calculation:

accumulativeLength[8] – accumulativeLength[5 – 1] //wrong

Note that we subtract 1 from the smaller index. To prevent us from having to handle a special case, we can start the accumulative lengths with 0. The accumulativeLengths array is then one larger than the drawingPoints array. With this scheme, we calculate the length between drawing points 5 and 8 as follows:

accumulativeLength[8 + 1] – accumulativeLength[5] //correct

If we need to calculate the length between arbitrary points (not just drawing points), then we need a slightly more complicated scheme, as in the following function:

//Calculates the length of curve between two points on the curve
CalculateLenth(segmentIndex0, t0, segmentIndex1, t1)
{
    //assert(segmentIndex0 <= segmentIndex1)
    if(segmentIndex0 == segmentIndex1)
    {
        assert(t1 >= t0);
    }
 
    p0 = getPoint(curveIndex0, t0);
    beginningLength = (drawingPoints[segmentIndex0 + 1] – p0).Length;
    p1 = getPoint(curveIndex1, t1);
    endLength = (drawingPoints[segmentIndex1] – p1).Length;
    length = beginningLength + endLength;
 
    if(segmentIndex0 != segmentIndex1)
    {
        midLength = accumulativeLength[segmentIndex0 + 2] –
          accumulativeLength[segmentIndex1];
 
        length += midLength;
    }
 
    return length;
}

The code in red above samples the curve directly to calculate the two points. However, this will give results inconsistent with our approximation using line segments of the midLength. It is often not a problem, since the difference might be small. If it is a problem, you can use points on the line segments instead of points on the curve to calculate the approximation.

This technique is consistent with the approximation of the interior segment, and is somewhat faster. All you have to do is use the following method to calculate p0 and p1, instead of using the getPoint method as above.

GetPointOnSegment(curveIndex, t)
{
  return (t – 1) * points[curveIndex] + t *  points[curveIndex + 1]);
}

Constructing a smooth Bézier path from a set of points

Two related problems arise frequently when working with paths. Both problems require us to find an aesthetic, smooth curve for a set of points.

The first problem occurs when only a few points of the curve are given, and we have to find a smooth curve that passes through all the points. One example of this is the paths given to AI agents. A walking character looks very funny when abruptly turning to follow the path laid out by the AI designer or algorithm. Using a bit of smoothing greatly enhances the believability of the character’s movements. This is interpolation.

An example of Bézier interpolation.

The second problem occurs when a vast number of points are given, and we need to simplify the curve without distorting the overall shape. This, for example, is useful to make a curve in a line drawing game more pleasing to the eye, and easier for the AI to follow. This is simplification.

An example of Bézier simplification.

Bézier interpolation

The challenge is to find a nice, smooth curve passing through all the points given in order. We can think of this as smoothing a curve made out of line segments. A Bézier path is smooth if each endpoint and its two surrounding control points lie in a straight line. In other words, the two tangents at each Bézier endpoint are parallel.

These figures show two Bézier paths, each made out of two Bézier curves. The yellow line segments are tangents to the left and right of the orange Bézier endpoint. When the tangents are parallel, as on the left, the connection between the two Bézier curves is smooth. If they are not parallel, as on the right, there is a cusp where the curves connect.

For now, let us assume the segments are roughly of the same length.

The basic idea is to calculate control points around each endpoint so that they lie in a straight line with the endpoint. We make this line parallel to the line formed with the neighbouring Bézier endpoints, and we make the control points the same distance from the endpoint that they surround (for now). We use a scaling parameter to control curvature of the curve at the Bézier endpoint. Curves for different scale values are shown below.

We are given the orange points. The algorithm calculates the yellow points, which in this case are the control points around the Bézier endpoint in the middle. We do it so that the yellow points that surround a Bézier endpoint lie in a straight line. We can tweak the distance of the control points from this Bézier endpoint with a parameter. The larger this parameter, the smaller the curvature at that Bézier endpoint. In these images, each of the three Bézier paths has two Bézier curves.

The basic steps to calculate the two control points around a point p1, are the following, where p0 and p2 are the endpoints around p1:

tangent = (p2 – p0).normalized;
q0 = p1 - scale * tangent;
q1 = p1 + scale * tangent;

The tricky bit is handling the first and last control points of the path. These are calculated as before, except that we use the two first or two last endpoints to do the tangent calculation.

We can now iterate through all the segment points, and calculate control points depending on the correct case.

List<Vector3> Interpolate(List<Vector3> segmentPoints, float scale)
{
    controlPoints = new List<Vector3>();
 
    if (segmentPoints.Count < 2)
    {
        return;
    }
 
    for (int i = 0; i < segmentPoints.Count; i++)
    {
        if (i == 0) // is first
        {
            Vector3 p1 = segmentPoints[i];
            Vector3 p2 = segmentPoints[i + 1];                
 
            Vector3 tangent = (p2 - p1);
            Vector3 q1 = p1 + scale * tangent;
 
            controlPoints.Add(p1);
            controlPoints.Add(q1);
        }
        else if (i == segmentPoints.Count - 1) //last
        {
            Vector3 p0 = segmentPoints[i - 1];
            Vector3 p1 = segmentPoints[i];
            Vector3 tangent = (p1 - p0);
            Vector3 q0 = p1 - scale * tangent;
 
            controlPoints.Add(q0);
            controlPoints.Add(p1);
        }
        else
        {
            Vector3 p0 = segmentPoints[i - 1];
            Vector3 p1 = segmentPoints[i];
            Vector3 p2 = segmentPoints[i + 1];
            Vector3 tangent = (p2 - p0).normalized;
            Vector3 q0 = p1 - scale * tangent * (p1 - p0).magnitude;
            Vector3 q1 = p1 + scale * tangent * (p2 - p1).magnitude;
 
            controlPoints.Add(q0);
            controlPoints.Add(p1);
            controlPoints.Add(q1);
        }
    }
 
    return controlPoints;
}

Bézier simplification (Quick and Dirty Method)

If we would also like to reduce the number of points in our curve, it is much harder to construct a suitable Bézier curve, especially if we want the best possible fit given constraints on the number of control points and degree of the curve. There is a quick and dirty method that works well in many cases. Here is the broad outline:

1. Add points to a list so that successive points are as far apart as possible, within a specified minimum.
2. Use Bézier interpolation discussed above.

The algorithm to perform step 1 works as follows:

1. We add the first point from our list of source points to the list sample points.
2. We set the next potential sample point as the second point in the list of source points.
3. We then iterate through the remaining source points (starting at the third point). For each point, we check whether the last sample point added is outside a minimum square distance of that point. If it is, we add the potential sample point to the list of sample points. The current point becomes the new potential sample point (regardless of whether the last test failed).

Here is the code:

samplePoints.Push(sourcePoints[0]);
 
Vector3 potentialSamplePoint = sourcePoints[1];
 
int i = 2;
 
for (i = 2; i < sourcePoints.Count; i++ )
{
    if(((potentialSamplePoint - sourcePoints[i]).sqrMagnitude > minSqrDistance) &&
       ((samplePoints.Peek() - sourcePoints[i]).sqrMagnitude > maxSqrDistance))
    {
        samplePoints.Push(potentialSamplePoint);
    }
 
    potentialSamplePoint = sourcePoints[i];
}

The last bit of the curve is a bit messy to handle. We can either throw the last point away, and lose a small piece of the curve; or add the last point as a control point, and keep the full curve.

If we decide to add the last point, the last two points in samplePoints may lie very close to each other. If this is the case, you might either discard the second last point, or move it a bit further from the last point, closer to the third last point. The exact best new location for this point is a bit tricky to calculate. The following is an approximation scheme:

Let p0, p1 be the last two sample points, and p2 be the last potentialSamplePoint (which is also the last point from samplePoints). We want to calculate a new position for p1.

tangent = (p0 – p2).normalized;
d2 = (p2 – p1).magnitude;
d1 = (p1 – p0).magnitude;
p1 = p1 + tangent * ((d1 - d2)/2);

I based the approximation above on the following reasoning:

The vector t is an approximate tangent vector for the curve at p1. This is the same tangent as would be calculated by our smoothing algorithm. We then want to move p1 so that it lies on this tangent, (passing through the original p1), and lies roughly the same distance from p0 and p1. Instead of calculating exact intersections, we approximate the desired distance as half the sum of the original distances, that is, the new distance from p1 to p0 (and p2) is given by (d1 + d2) / 2. Now p1 is already d2 from p2, so we subtract that from (d1 + d2) / 2 to obtain (d1 – d2) / 2. This is exact only when all three points lie in a straight line, but it is close enough in other cases.

The final algorithm is this:

public List<Vector3> SamplePoints(List<Vector3> sourcePoints,
        float minSqrDistance, float maxSqrDistance, float scale)
{
    if(sourcePoints.Count < 2)
    {
        return;
    }
 
    Stack<Vector3> samplePoints = new Stack<Vector3>();
 
    samplePoints.Push(sourcePoints[0]);
 
    Vector3 potentialSamplePoint = sourcePoints[1];
 
    int i = 2;
 
    for (i = 2; i < sourcePoints.Count; i++ )
    {
        if(((potentialSamplePoint - sourcePoints[i]).sqrMagnitude > minSqrDistance) &&
           ((samplePoints.Peek() - sourcePoints[i]).sqrMagnitude > maxSqrDistance))
        {
            samplePoints.Push(potentialSamplePoint);
        }
 
        potentialSamplePoint = sourcePoints[i];
    }
 
    //now handle last bit of curve
    Vector3 p1 = samplePoints.Pop(); //last sample point
    Vector3 p0 = samplePoints.Peek(); //second last sample point
    Vector3 tangent = (p0 - potentialSamplePoint).normalized;
    float d2 = (potentialSamplePoint - p1).magnitude;
    float d1 = (p1 - p0).magnitude;
    p1 = p1 + tangent * ((d1 - d2)/2);
 
    samplePoints.Push(p1);
    samplePoints.Push(potentialSamplePoint);
 
    return Interpolate(samplePoints.ToArray(), scale);
}

Once we have reduced the points, the final step is to make the curve smooth, by using Bézier interpolation. We simply pass the list returned by SamplePoints to the Interpolate function.

The algorithm is easily converted to an online algorithm. If the curve is drawn while the sampling is being done, the potential point should be included for drawing to make the curve building smooth. If it is not, the curve end will jump as the curve is extended. The end of the curve will also adjust itself as the curve is extended; unfortunately, there is not much that can be done about this.

If the last samples being too close present a problem, we can perform the end-of-curve calculations where the curve is drawn. We also need to do the calculations once the last sourcePoint has been given.

void SamplePointsOnline(Vector3 newSourcePoint, float minSqrDistance)
{
    //samplePoints and potentialSamplePoint are now fields
 
    if(samplePoints.Empty)
    {
        samplePoints.Push(newSourcePoint);
    }
    else if(samplePoints.Count == 1)
    {
        potentialSamplePoint = newSourcePoint;
    }
    else
    {
        if((samplePoints.Back() – newSourcePoint).sqrMagnitude >= minSqrDistance)
        {
            segmentPoint.Push(potentialSamplePoint);
        }
 
        potentialSamplePoint = sourcePoints[i];;
    }
}

Downloads

(WARNING: The code fairy stole all the comments in these files!)

• Bezier Curves (64 KB, Unity 3D Project, zipped)
• BezierPath.cs (C# source code file)

Related posts:

1. Bézier Curves for your Games: A Tutorial A Bézier curve is a type of curve that is...
2. The Path demo is out! The Path is one of those videogames that just keeps...