As a musical producer, my first impression of the video game industry in Chile was that a lot of video game developers doesn’t know how to communicate with musicians, and that it leads music that the developers did not want or need at all. These are a few tips that come from the audiovisual industry and I adapted them to video games I hope they’ll help you to get an excellent soundtrack!

1. Identify the Purpose of the music

When it comes to music, there are a lot of developers who think “I have a game! I need music for this, let’s call a musician”. The issue is that when you have a game, you don’t necessary “need” music, there are a lot of indie titles out there that have almost nothing musical in the soundtrack (when I talk about soundtrack, I mean every sound that’s on the game, sound effects included). As vague as the first idea is, as vague that the result will be, so the first point of this post at all is for you to recognize what’s the purpose that you are going to assign to your songs and themes.

Here I will show you a list of musical purposes that are used in the  industry and the movie industry as well:

To evoke emotion

Is the musical representation of an emotion that is a part of the game, or a particular scene/stage. This is a very good example, the whole OST of this game works around the emotions of the story.

To identify character

Is the musical representation of a character of the game, commonly the protagonist or antagonist. In this example we can listen how the composer managed to represent the origin of the character in the music.

To convey place

This is the musical representation of a place and its characteristics. This is commonly used in RPG’s to represent cities, woods, deserts, etc. In the example, the music perfectly fits the place uniqueness (a tricky and mystic temple).

To convey time

This is the musical representation of a time or age. Almost every game is placed in another timeline; it could be prehistoric, futuristic or medieval, for example. There’s a beautiful game that turned 20 years old a few days ago, and it features time travel, the example is the prehistoric music of the game, temporal identification at its best.

To convey situation

This represents a specific situation of the narrative development of your game. I hate to use so much RPG examples, but Uematsu is one of my favorite video game composers. In the example, the music represents the character and the situation simultaneously, when the player realizes that what just happened, the music comes immediately to support the situation

To give continuity

Continuity is the music that connects two musical pieces that exist in the same stage, or the same scene. Transition is the music that connects a musical piece with another scene or stage. So, this is a movie/cinematic almost exclusive purpose, in this example there’s a lot of analysis to work with, but there are two things that are important to realize. In 0:38, the music volume goes down, so the dialogues could be the main audio of the mix, and in 1:08, the music became a continuity piece that connects with 1:32, when the new music begins.

To give feedback

When you need to represent an action. In the example, at 4:50, there’s a trigger for the music, the player gets 4 stars and new music appears.

To provide contrast

This is an audiovisual tool that became popular with Quentin Tarantino movies; the music represents a contrast to what is happening in the scene. A movie example would be perfect, but I think this is a nice video game approach to the concept.

To represent mechanics

This is a Video Game specific purpose and a really difficult one to compose, puzzle games music is the most representative but figure this example’s boss, you can’t kill him and you don’t know about it, so the music tries to represent that desperation.

To anticipate events

This is the representation of a future situation of the narrative development, terror movies use it to represent the feeling of “something is going to happen”. At 4:32, the music of the example works as a anticipation of the final boss, and prepares the player for what is to come.

2. Think of Instruments and Genre

When you have the first step sort of defined, you’ll have to start thinking in a style and some instruments that will be the support for the music. It’s not necessary a huge level of detail in this point, in the indie videogame industry no musician will ask you to tell him to work in these terms: “Ok, I need 8 violins, 4 violas, 3 cellos, 2 double basses and a viola da gamba”, but it would be nice if you could tell him that you need “some strings”.

It’s the same thing with genre, it’s enough if you can tell the musician that you need “rock”, or “jazz”, but in the end, it comes for you to know some musical references that can help the musician to find where to start.

3. Compile a List of Keywords

This is a tip that works for almost every artist out there, from concept artist to sound designers. It’s always important to communicate the main concepts of the art that you’re requesting for your game, from emotions, adjectives or even situations, so when the artist makes any progress, they will look the keywords and figure out if they’re missing something important.

4. Identify Sections

For any developer, even experienced ones, it’s always good to remember to be organized with their work, and so it is for visual artists and musicians. A way to make the composers work a lot easier, is that you bring him a list of the “scenarios” from your game, everything that’s in your world, screens, menus, etc. And when you have this list, think in the tracks that you will need for every one of them. There’ll be a lot of situations when a musical piece will be in more than one scenario (the same music could be in the splash, the settings and the main menu, for example), and it’s really important for you and the musician to be aware of this.

5. Find References

As I said before, it is always up to you to communicate clearly with the composer, to let him know exactly what do you want and what do you need for your game. Audio references are an excellent way to do it.

(This article has also been published on Gamasutra. Check it out for insightful comments.)

1. Introduction

At Gamelogic we are obsessed with game rules.

Several weeks ago my colleague Herman Tulleken and I began building a match game tool. We played and analyzed many match games to deconstruct their mechanics. In this article we share our findings as part of a larger research and development project, which will later include an article on match game implementation patterns.

During our research we found many games with similar features to match games. By changing how we define a match rule it is possible to include a wider variety of games for which our scheme can be applied. However, we decided against including match rules that are not intuitively associated with match games to keep our task manageable. How far our definitions can be stretched is something we want to explore in the future.

For this document, we only include match games that are played on a grid, are 2D, and are on a single layer. Some 3D games (for instance Blockout) easily fall into our scheme if certain concepts are adapted for 3D.

In his paper Swap Adjacent Gems to Make Sets of Three, Jesper Juul defines matching tile games as “video games where the object of the player is to manipulate tiles on a grid in order to create matches” (We give a more precise definition below to suit our terminology and structure we use here.)

Juul says that one of the challenges that designers face is that casual gamers want to pick up and play these games immediately. There must be a level of familiarity without a steep learning curve. At the same time, games need to have enough uniqueness to stand out from the competition, and more importantly, enough to keep the player playing their game. Often these differences are subtle, such as Bejeweled introducing a timeless mode to its predecessors.

Because of this, the evolution of match games has occurred more incrementally than some other types of games, and it has resulted in many similar games (often labeled clones). More importantly for us, it makes match games easier to analyze than many other game genres.

We also put the information in a graphical format. Click on Match Game Mechanics Infographic for the full-sized version.

2. Definitions

Grid: A grid is a structured arrangement of cells. Games often use regular grids such as square grids and hexagonal grids.

Cell: A cell is a container that can be empty or full.

Tile: A tile is an object that can fill a cell. Cells cannot contain more than once tile. Except for during state transition animations, tiles are always inside exactly one cell, or completely outside the grid.

Block: A connected group of tiles that is manipulated as a unit. In many games blocks have only one tile each.

Matching tile game: a game where the object of the player is to manipulate blocks on a grid in order to create matches between tiles.

Match: Is a group of tiles that satisfy the game’s matching rules. The most common match rule is three connected tiles with the same color. Matches can contain tiles from more than one block, and matches need not contain all the tiles of a block.

Color: A property to distinguish tiles. This property is often an actual color, but can also be a shape, pattern or number. Not all tiles have a color in this sense.

Gravity: A force that moves all tiles in a certain direction.

Clear: A tile is cleared when it is removed from the game.

Line: For square grids, a line is a row or column. For triangular and hexagonal grids, a line is similarly defined: a group of cells from end to end in a straight line.

Combo: More than one simultaneous match. For example, if two tiles are swapped and this results in both tiles matching with other tiles (Bejeweled).

Cascades: Consecutive matches. For example, a player’s input results in an auto match, and the new or existing tiles fall into empty cells in such a way that another auto match occurs (Bejeweled Twist).

(Bejeweled Twist)

3. Game classification

We classify all match games into three main categories. These main group capture the patterns in game loops and game goals, and affects the implementation of the rest of the game.

Elimination game: Tiles are matched to clear (or partly clear) a grid that doesn’t refill as the player plays. The grid can begin full or partly full (Chain Shot!).

Avoidance game: Tiles are matched to prevent a grid from becoming full or from tiles reaching an edge of the grid. The grid can begin empty or a partly full (Collapse!, Lines).

Farming game: Tiles are matched on a grid that stays full. Every time a match is made and tiles are cleared, new tiles are added, and the goal is to maximize or reach a certain level of a metric (Bejeweled).

4. Grid

Grid topology

A grid’s topology is how the cells are structured – which cells are connected. Commonly used grids include square (Bejeweled, Around the World in 80 Days), and hexagonal (Fractal, Same Hexagon) grids. A special case is 1D grids, which is a single line of cells, possibly curved (Zuma).

(Fractal)

(Zuma Deluxe)

Grid shape and size

A large variety of sizes and shapes are used, both symmetrical and unsymmetrical. A commonly used size and shape for a grid in a match game is an 8×8 rectangle (Bejeweled 3, Puzzle Quest: Challenge of the Warlords).

(Bejeweled 3)

5. Block structure

There are four different block structures. All but the first in this list are multi-tile blocks.

Single-tile: Blocks with a single tile (Bejeweled)

Monochromatic: Tiles of the same type in different shaped blocks (Tetris).

Monomorphic: Same shaped blocks using tiles of different types (Columns).

Mixed: Different shaped blocks using tiles of different types (Groovin’ Blocks).

6. Tile set structure

Tile set properties

We classify tile properties into three categories:

Clearing type: defines whether and how tiles are cleared.

Gravity properties: properties that define whether and how tiles are affected by gravity.

Game action: something that happens when the tile is cleared.

This classification may seem unintuitive from a design perspective, but it is useful for implementation.

Clearing Type

All tiles have a single clearing property. The chart below shows how the different clearing properties relate to each other.

Color tile: A tile that can be matched using matching rules that involve colors.

Wildcard: A tile that can be matched using matching rules that involve colors, except it can substitute any color.

Sinker: A tile that can be cleared by getting it to the bottom of the grid.

Activator: A tile that can be cleared by clicking on it.

Non-clearing tile: A tile that cannot be cleared.

Gravity

• Influence:
  • Falling: affected by gravity
  • Floating: not affected by gravity
• Direction

Game action

Clearing tiles can have any number of game actions that are performed when the tiles are cleared. These actions include:

• Generates a tile
• Gives a reward (see Reward Types)
• Ends the game

Examples

• The colored matching tiles in Bejeweled are falling color tiles with no game actions.
• The Icing (Meringues) blocker tile in Candy Crush Saga is a floating wildcard with no game actions.
• The hypercube tile in Bejeweled 3 is a falling wildcard that gives a reward when cleared.
• The talisman tile in Azkend is a falling sinker that ends the game when cleared.
• The chest tile in Triple Town is a floating activating tile that gives a reward when cleared.
• The number tiles in Threes are floating colored tiles that generate new tiles when cleared.

Tile set additional structure

Sequence: Color tiles arranged in a sequence that is exploited for gameplay or scoring (Triple Town, Threes, Gems with Friends).

Multi-axis: There is more than one match property, for example color and pattern.  Matches can occur with tiles of the same color regardless of the pattern or matches can occur with tiles that have the same pattern regardless of the color (Passage 4 XL).

7. Block Spawning

This section contains a few items marked with (*) for which we couldn’t find an example but for which we are sure one must exist. If you know of any examples, please share them in the comments.

Spawning algorithms

Tiles are selected

• randomly (Tetris)
• in a predefined order (*)
• so as to change the difficulty dynamically (Candy Crush Saga)
• from recently cleared cells (*)
• from a fixed batch with a random order (Threes)

Where blocks are spawned

Blocks are spawned

• at the edge of the grid (Bejeweled, Collapse!)
• in cells where blocks have been cleared (*)
• in an empty cell (Lines)

Number of blocks spawned

The number of cells to spawn can be

• a fixed number (Lines)
• enough to fill all empty cells (Bejeweled)

When blocks are spawned

Blocks are added

• after time (Collapse!, Tetris Attack)
• when a match is made (Bejeweled)
• when a match is not made (Lines)
• after every turn (Ultimate-4)
• after a number of turns (*)
• when the player adds blocks (Stickets)

8. Player actions

This is all the ways the player can change the game state.

Click Match

The player clicks on any tile in a matching group of tiles to clear those tiles (Collapse!, Same Hexagon).

Chain Match

The player clicks on each tile or drags over each tile in a matching group of tiles to clear those tiles (Azkend, Jelly Splash, 4 Elements).

(Jelly Splash)

Place

The player places a new block on the grid.

• There can either be no choice of which block to place next (Columns), or there can be a choice between a number of available blocks to place next (Stickets).
• The block can be placed on either any empty group of cells with the same shape (Lines, Stickets), or on any of a restricted group of empty cells with the same shape (Might & Magic: Clash of Heroes, Columns).

Rotate

The player rotates tiles of two or more cells, usually by clicking or dragging over the cells. The most common use of this action is swapping – rotating two cells (Bejeweled 3). Other examples include rotating the tiles in three cells (Hexic) or four cells (Bejeweled Twist).

(Bejeweled 3)

Line Swipe

The player moves a whole line of tiles in the direction of the line. Lines are wrapped, so that tiles that go out the one end of the grid re-enters the grid on the opposite side (Chuzzle, Metronous).

(Chuzzle Deluxe)

Grid Swipe

The player swipes the whole grid, and all cells move as long as there is space available, or a match can be formed (Threes).

Manipulate Block

Block manipulation is defined by:

• how the block is manipulated: for example rotating the block (Tetris) or changing the position of tiles within a block (Columns), and
• when the block is manipulated: before placement (Tetris) or after placement (Chain Shot).

(Columns)

Manipulate Gravity

Changes in gravity include:

• The player turns it on or off (Gravity Switch Puzzle Match)
• The player changes the direction of gravity relative to the grid, possibly by rotating the grid (Vizati, Spinzizzle).

Remove

The player clicks on a tile to clear it.

Shuffle

The player moves some or all tiles into different randomly selected cells (Candy Crush Saga).

9. Automatic Actions

These are all the ways the game state changes automatically.

Block spawning

This automatic action adds new tiles to the game. We have already discussed various aspects of block spawning in a previous section.

Auto-match

In games where matching is not a player action, auto-match occurs as result of every player input. If the player input results in a group of matched tiles, auto-match will clear the tiles from the grid.

Auto-match can also occur without player input as a cascade.

Gravity

Gravity can influence generated blocks which enter the grid or cause tiles to move into empty cells created from clearing tiles (Bejeweled).

The direction of gravity can change during the game depending on how tiles are cleared (Collapse!).

(Super Collapse!)

Repulsion

Placing a block pushes all neighboring tiles away from it. The pushed tile create a chain whereby all tiles in that line move one cell away from its previous position (Fractal). Empty cells may or may not break this chain.

(Fractal)

Attraction

Cleared tiles are replaced by tiles in neighboring cells (Trigon).

10. Matching conditions

Number of tiles needed to make a match

The most common number of tiles needed to make a match is 3 (Bejeweled); however, there are games that do not use three tiles as the minimum requirement for a match. Here are some examples:

• 2 (Threes)
• 4 (Lumines, Gem Huntz)
• 7 (Fractal)
• 10 (Tetris)

Orientation and shape of tiles needed to make a match

Common shapes include:

• Horizontal or vertical lines
• L-shape
• T-shape
• Cross
• Square
• Triangle
• Hexagon

Special cases

There are other less common rules for matching. Here are some examples:

• Matching tiles can be separated by empty cells but must be on the same axis and have no non-matching tiles in between them (Totemo, Color Tiles).

(Totemo)

• Match tiles to create a closed shape, which clears those tiles and all of the tiles within the cells of that closed shape (Quarth).

(Quarth)

11. Rewards

Reward types

Examples of reward types include:

• Score
• Special tiles
• Special actions

The outcome of a special tile or special action are interchangeable. Examples include

• Extra time
• Time reset
• Extra moves
• Clear lines
• Clear neighbors
• Clear all tiles of a particular color

Reward conditions

Rewards can occur due to a single condition or as a combination of conditions.

12. Game-end conditions

Games have one or more conditions for ending the game. Below are typical ones.

Win conditions

The player wins the game when

• the grid is clear (Puzznic)
• the player makes a specified number of matches or reaches a specified score (Bejeweled)
• the player makes a specified set of matches (Jewel Fever)
• the player clears a specific tile (Azkend)

Lose conditions

The player loses the game when

• the grid is full (Stickets)
• a tile reaches an edge of the grid (Tetris, Collapse!)
• the player runs out of resources (Fractal)
• the player has no more possible moves (Threes)

In November 2013, two colleagues* and I made 30 games. Although I have done some game prototyping before, working on so many games in such a short period gave me some insights I did not have before. As I said to a friend, it’s like watching a television series in a few days, instead of watching each episode week by week – you just see different things.

In this article, I collect some of these observations in the form of a set of tips. I kind-of assume you are already familiar with the classical How to prototype a game in 7 days, which describes prototyping from a more general point of view. In some ways, this is a programming-specific extension to the ideas presented there.

(*Their names are Jonathan Bailey and Eduard Beukes. If you want to read more on our protoyping endeavour, see How we made 30 games in 30 days.)

A. Rapid is a State of Mind

Making something very quickly is a lot of fun. Day-to-day (“proper”) development can be slow progress, with the final products months (or years) away. Tinkering with an idea in your spare time gives you insight, but its outcome is vague.

Building a rapid-prototype gives you immediate satisfaction. It gives you focus; it allows you to channel energy, and gear up.

But you need to get out of development mode, and out of tinkering mode. You have to know you will throw work away, and waste some effort. You have to know that sometimes you don’t need the best decision – you just need to make it straight away. You have to let go of perfection and details.

You have to get to the core.

Know and remember the goal

The reasons for building a prototype are varied. Here are a few examples:

• To have a finished game at the end of a fixed time (such as in a jam).
• To have the core of a game that is fun (such as in a pre-preproduction phase of a project).
• To select the best idea from a set of alternatives.
• To test the technical feasibility of an idea (where the idea can be anything from a full game to a graphics technique or AI algorithm).

The best way to work and make decisions depends on this goal. Be clear about what the goal is, and remind yourself frequently.

If a task is not moving you closer to your goal, don’t do it.

Find the essence of your idea, and schedule enough time for it

An essence can be a mechanic, a style, a theme, a setting, an emotional experience. Find it, and, separate it from the supporting elements.

When you schedule, assign time accordingly. If your essence is a new mechanic, you want to have enough time to explore it; you don’t want to spend all your time building levels or coding atmospheric shaders.

Take creative risks, but avoid technical risks

If a game prototype fails, it should be because it’s boring, not because of a technical problem. (Except of course when the goal is technical prototyping). You want your prototypes to be finished, and allow you and your team to explore the essence, and pass this on to players.

• Avoid tricky, sophisticated data structures and algorithms.
• Avoid sophisticated systems and architectures.
• Avoid trying to make things too fast.
• Avoid technical feats that do not improve gameplay.

B. Planning and Process

Think about content

Ask yourself a few questions about the content your game will need to get a feel for its scope.

• How much do you need to build?
• How will you inject variety?
• At what stage during development should it go in?
• What fallbacks can be used? If you run out of time, have a plan to get essential content in. Will it work to make the boss simply a pink version of the level-enemies? Could boxes work instead of characters?

Plan

• Work out a rough plan, and put down some time estimates.
• Check your plan against the goal, and remove things that do not take you closer to your goal.
• Check your plan against the essence of your idea, and verify that you allocated enough time to explore the essence.
• Identify the sections where your estimates are likely to be out. Keep fallbacks in mind; consider reducing their impact / role / complexity. Think of placeholder strategies (see below).

Follow an implementation strategy, but adapt it to follow the ebbs and flow of the creative process

Here is the order I would suggest you follow. It puts the most important things first, keeping in mind (typical) dependencies.

1. Get something on screen
2. Implement top level game
3. Get user controls in
4. Implement a minimalist level
5. Implement toy logic
6. Implement game goal
7. Implement AI
8. Implement feedback
9. Refine

Prototyping is not coding a specification, though. Remember that there will be false starts, and that you will have to adapt. When necessary, change the plan and update the schedule.

Know and avoid time drains

Certain things just suck up a disproportionate amount of time. It’s useful to recognise these, and make sure you schedule enough time, have fallbacks, and keep it even simpler than you would other parts of the game. (Typical time drains depend of course on the type of game; the examples below are just to give you a sense of what I mean).

Controls. In actions games, controls can take a long time to get playable (never mind to get nice).

Balance. In simulation games, balancing takes a long time. Keep the number of systems low; keep the number of variables low. And leave enough time to balance them out.

GUI. In information-heavy games, the GUI can suck up all your time. Finding audio can take a long time – don’t add it unless it’s essential, or you already know where the sounds you need are.

Animation. Animation can slurp up a lot of time: consider using snap poses, or gliding when appropriate.

Procedural content generation. Tweaking algorithms for content generation can be time consuming. Unlike other algorithms, the specifications for content generation algorithms are hard to make objective.

Consider using serial development (programming pipelines)

For teams with more than one programmer, it’s common to divide a project up in components, and dish each one out to a separate programmer, so that everyone works in parallel.

There is another method, and it is worth trying it out once or twice and see if it works for your team.

With this approach, most of the code passes through all the programmers, in a staggered fashion. The first programmer will implement the broad strokes of the project; the next one will start filling in details, and so on. Instead of owning a piece of the code, each programmer owns the entire project for a time slice (these slices may overlap somewhat, of course). It works especially well if you use a lot of placeholder code.

The nice thing about the approach is that it reduces discussions about interfaces. In your time slot, if you need an interface change, you make it. It won’t break other programmers’ code because you are the only programmer. (It still works with overlapping slices, but you need more care, and a plan.)

The down side is of course the design you end up with may be quite bad. It does not matter, though, because the design is not important. It seems a bit wasteful, since there are times where some programmers don’t program.

(Of course, this is meant to split off programming tasks; it would be a shame if you do this with other creative activities. In many prototyping projects programmers are also game designers; this does not apply when you have your design hats on!)

Don’t get stuck

Several things can make you feel stuck: bugs, tricky-to-implement code, unusable and fiddly controls, sheer amounts of content, level design.

When you are in the mud, get out of it, and move on. Here are a few things you could do when stuck:

• Ignore tricky bugs that do not ruin gameplay.
• Cut culprit features; reduce content.
• Use a simpler placeholder algorithm or approximation.
• Use brute force with lookup – a handy technique to design correct, fast algorithms quickly at the expense of memory and some extra time spent outside the main loop (maybe even outside the game altogether).
• Fake it. Monsters that respond to players look more intelligent than monsters that don’t, regardless of how intelligent they actually are.
• Hard-code it. A long array of monster sequences is much easier to code than a sophisticated wave generation algorithm.
• Hide it.

C. Code Design and Implementation

Use placeholder code

Use placeholder code wherever you can so that you can move onto core gameplay earlier. Once you have that nailed, you can systematically replace placeholder code with code that does a better job. What is nice about this approach is that once you have all the systems in and working with your core gameplay, it is much easier to prioritize tasks according to their gameplay impact.

Here are some typical candidates for placeholder code.

Controls In some games, controls are extremely important. But if second-rate controls won’t cripple the player’s experience, and it’s faster to implement, implement that first. For example, in many sliding puzzle games, the best controls allow you to use the mouse (or finger) to slide around objects. This can be a difficult scheme to implement. On the other hand, mouse selection with arrow keys or buttons can be quick to implement, allowing you to get onto other gameplay elements faster.

Feedback Feedback is important, it provides information and improves the experience. But first do something simple: dialogs and messages, colour changes, flashes or beeps.

AI AI is difficult: it’s hard to predict whether any given strategy will work. The following can be use for AI placeholders before you start implementing the final algorithm:

• Random AI.
• AI using simple heuristics can stand in for look-ahead AI, or vice-vera, whatever is easier.
• Greedy algorithms.
• AI that cannot play all possible moves.

Procedural Content If your game relies on procedural content; you can use the following types of stand-ins:

• Fixed content.
• Purely random content.

Approximation Crude approximations can often be very useful. Here are some examples:

• Using collision spheres instead of collision meshes.
• Using linear approximations for curves.

Use design Shortcuts

[USE WITH CARE] You should avoid god-like classes in production code, but in prototypes, they can save a large amount of time. Instead of having a monster and player that extends from actor, dump all the code in actor, and use the familiar switch-atrocity instead of polymorphism.

Mistrust any data structure that is more sophisticated than a dynamic list, especially if you need to implement it yourself. Focus on simple, safe, and easy to understand data structures and algorithms.

Avoid false design shortcuts

• Rules for naming and organisation in prototypes don’t change.
• Unnecessary exposure of data (using public fields) can bite you even in the short span of a day or two. It’s simply not that easy to remember whether setting health to zero will kill a monster, or whether you also need to destroy it yourself.
• States machines (or anything that keeps track of states) almost always need more states than you think. If you try to use a shortcut instead of an appropriate abstraction, there is a big chance that you will get entangled in a buggy if-else mess.

Manage your tweakables

• Make the game easier to fine-tune by keeping tweakables in one place.
• Not every value needs to be tweaked; don’t be afraid to make them constants. But put them in a central place. Do not use magic numbers.
• Carefully name your tweakables.
• When you design a tweakable system, make sure that the exposed variables have clear and linear effects. Subtle tweakables are best hidden away (or left until the end). It’s better to make a system that is clear to understand, but cannot be controlled completely.

Write readable code

Throwaway code should not be engineered to the highest standards possible.

However, it still needs to serve the purpose of communicating your intention, especially if you work in a team. A muddle of code can waste a lot of time. The most useful things to do when writing code for rapid development:

• Name things properly.
• Be organised.
• Avoid deep hierarchies and complicated dependencies.
• Keep methods damn short.
• Limit the number of “smart” classes. A smart class is anything that handles game logic. In smaller, volatile projects, it’s better to centralise logic and reserve helper classes for presentation. It makes it easier to make drastic changes. As long as you keep methods short.

Use implementation patterns

An implementation pattern is a standard way of doing things. As an example, here is the implementation pattern of a game’s main file:

public void Start()
{
   Reset()
}

public void ResetGame()
{
   currentLevel = 0;
   ResetLevel();
}

public void ResetLevel()
{
   DestroyObjectsFromPreviousPlay()
   InitialiseVariables()
   BuildLevel()
   InitGameState()
}

public void Update()
{
   ProcessGameFlowInput(); //Reset or next level

   if(gameOver) return;

   ProcessGamplayInput(); //player controls
   UpdateContinuousGameState(); //movement, AI, etc.

   gameState = GetGameState();

   if(gameState == GameState.Win) WinGame();
   if(gameState == GameState.Loose) LooseGame();
}

private void NextLevel()
{
   currentLevel++;
   ResetLevel();
}

private WinGame()
{
   ShowMessage("You win");
   EndGame();
}

private LooseGame()
{
   ShowMessage("You loose");
   EndGame();
}

private EndGame()
{
   gameOver = true;
}

By using standards, you will reduce the time you need to spend on thinking, and then quibbling over alternatives. Implementation patterns are useful for production code too, but prototyping patterns are different: they emphasise simplicity and clarity, rather than OOP re-use and efficiency.

You can often set up patterns as templates that you can use during prototyping. If you can, do it!

(You collect or design these standards between prototyping stints – see below).

As another example, here is an implementation pattern for changing a variable’s value smoothly over time.

private IEnumerator ChangeSomething(, 
   , )
{
   float timePassed = 0;
   Set(thingToChange, originalState);
   bool finalStateReached = false;

   DoThingsAtStartOfChange();

   while(!finalStateReached)
   {
       timePassed += Time.deltaTime;

       if(timePassed >= time)
       {
          timePassed = time;
          finalStateReached = true;
       }

       Set(thingToChange, Lerp(originalState, finalState, 
          timePassed / totalTime);

       yield return null;       
   }

   PlayArivalSound();

   DoThingsAtEndOfChange();
}

D. Before, After, In-between

If you build prototypes regularly, you can put yourself at a great advantage by doing some stuff in-between prototyping stints.

Reflect

After you finish with a prototype, do a post mortem, and identify the good and the bad. Review your notes shortly before your next prototyping project.

Build a library of code that enables rapid prototyping

This is different from your library that’s shared between production projects. You can use techniques that are a bit slow, or make some platform assumptions, or uses other technology that you cannot normally use for production code.

As an example, we rendered the grid in many of our games by drawing on a texture pixel-by-pixel, instead of using sprites. This method is fine for prototyping, but too slow for the final product.

Identify implementation patterns, bug patterns and time sinks

After a few prototypes, you may begin to see some patterns emerge. Make a list, and use this to inform what to put in your library.

Can you codify implementation patterns as templates in your library? Could you design better data structures to avoid some bug pattern? Can you give yourself a head start on a time sink by adding to your library?

Further Reading

• Common Game Prototyping Pitfalls
• Rapid Prototyping: Tips for Running an Effective R&D Process
• Quick and Dirty Prototyping: A Success Story

There is surprising little information available on hex-coordinates, despite how many games use hex grids. In this article I will explain some of the math so that you can do basic geometry in a hex grid, and design more elegant algorithms for your hex-grid games.

There are different coordinate systems for hexes of course. (For a very informative explanation, with many interactive examples, see Amit Patel’s wonderful guide Hexagon Grids.) We will work with an axial coordinate system, which is illustrated in the figure below.

From time to time we will use an extra coordinate. This coordinate can be calculated from the other two, like this:

$$z = -(x + y)$$

So in fact \(x + y + z = 0\). Any equation using the \(z\)-coordinate can be rewritten using \(x\) and \(y\)-coordinates alone. However, some equations are much cleaner (and the symmetry much more obvious) when we use the \(z\)-coordinate.

Here I will use both notations \([x, y, z]\) and \([x, y]\) to denote the same point. A point or vector will be displayed in bold, like this: \(v\), and integer and real values like this: \(k\).

• The \(x\)-axis is where \(y = 0\). It’s the horizontal orange axis in the figure.
• The \(y\)-axis is where \(x = 0\). It’s the skew vertical orange axis in the figure.
• The \(z\)-axis is where \(z = 0\). It’s the skew vertical yellow axis in the figure.

Coordinates work like (integer) vectors

We can view each point as the offset from the origin and from there treat points as vectors. These vectors work just like point vectors in the Cartesian coordinate system. It is useful to name the unit vectors that align with the axes with the directions they represent:

• \(\bv {e} = [1, 0, -1] \)
• \(\bv {ne} = [0, 1, -1] \)
• \(\bv {nw} = [-1, 1, 0] \)
• \(\bv {w} = [-1, 0, 1] \)
• \(\bv {sw} = [0, -1, 1] \)
• \(\bv {ew} = [1, -1, 0] \)

If we start from a point, and go 3 units east, we arrive at a new point, which we can now calculate as follows:

$$\bv v + 3\bv{e} = [x, y, z] + 3 \times [1, 0, -1] = [x, y, z] + [3, 0, -3] = [x + 3, y, z – 3]$$

If we instead move 2 units ne, we calculate the new point as follows:

$$\bv v + 2\bv {ne} = [x, y, z] + 2 \times [0, 1, -1] = [x, y, z] + [0, 2, -2] = [x, y + 2, z – 2]$$

Any point can be reached from another point by moving a certain amount of units east (possibly negative), and a certain amount north-east. So we can always find integers \(m\) and \(n\) sothat for any two points u and v, we have

$$\bv u + m \bv e + n\bv {ne} = \bv v$$

Using a little algebra, we rewrite the above as

$$\bv u + [m, n, -m – n] = \bv v$$

Or

$$[m, n, -m – n] = \bv v – \bv u$$

In other words, the offset (translation) from \(\bv u\) to \(\bv v\) can be found by subtracting \(\bv u\) from \(\bv v\).

Distance and magnitude

The hex-distance between two cells is the number of cells you have to traverse if you move from cell to cell from one point to the next. This is generally different from the Euclidean distance between the points; it is similar to the taxicab distance for rectangular coordinates.

The hex distance from any point to the origin can be calculated as half the sum of the absolute values of the coordinates:

$$d([x, y, z], [0, 0, 0]) = \frac{|x| + |y| + |z|}{2}$$

The distance between any two points \(\bv{v}_1\) and \(\bv{v}_2\) is the same as the distance of \(\bv{v}_1 – \bv{v}_2\) from the origin:

$$d([x_1, y_1, z_1], [x_2, y_2, z_2]) = d([x_1 – x_2, y_1 – y_2, z_1 – z_2], [0, 0, 0])$$

$$ = |x_1 – x_2| + |y_1 – y_2| + |z_1 – z_2|$$

It is convenient to define the magnitude of a hex vector as the distance of that point from the origin:

$$|[x, y, z]| = d([x, y, z], [0, 0, 0]) = \frac{|x| + |y| + |z|}{2}$$

We can then rewrite the distance equations as:

$$d(\bv{v}_1, \bv{v}_2) = |\bv{v}_1 – \bv{v}_2|$$

The equation of a line

Lines in hex-coordinates work similar to lines in Cartesian coordinates. We will only consider the “proper” lines, that is, were there are no holes in the lines, and all points in the line have exactly two neighbors.

There are only three proper lines through any given point.

The three lines through the origin are given by the following equations:

• \(x = 0\)
• \(y = 0\)
• \(z = 0\)

If we change the equations slightly, we get lines through arbitrary points:

• \(x = k\)
• \(y = k\)
• \(z = k\)

The figure above shows tree lines: \(x = 2\) in orange, \(y = 2\) in yellow, and \(z = 2\) in green.

The value \(k\) corresponds with the number of unit cells the line has been translated in the positive direction from the axis to which it is parallel. This makes it very easy to write the equation of a line with inspection.

Note a few things:

• Lines of the form \(x = 0\) are all parallel to the \(y\)-axis. Thus, all lines of the form \(x = k\) are parallel to each other.
• Lines of the form \(y = 0\) are all parallel to the \(x\)-axis. Thus, all lines of the form \(y = k\) are parallel to each other.
• Lines of the form \(z = 0\) are parallel to neither the X nor Y axis. Thus, all lines of the form \(z = k\) are parallel to each other.
• We can rewrite the equations of lines \(z = k\) as \(x + y = -k\).
• Two distinct points on a line always have exactly one coordinate in common. If the line is of the form \(x = k\), then they have the \(x\)-coordinate in common, and so on.

These facts make it very easy to write the equations of a line by inspection:

• Determine whether the line is parallel to the \(x\)-axis, the \(y\)-axis, or neither. From this determine whether the form is \(x = k\), \(y = k\), or \(z = k\)
• Now calculate the (signed) distance \(k\) from the origin along the axis (the same as the variable in the equation).

The intersection of lines

To determine the intersection of two lines in hex space is extremely easy. As always in geometry, we have several cases:

• The lines are coincident. In this case, the solution is of course all the points on the two lines (which are really one line).
• The lines are not-coincident, but parallel. This is of course when the lines have the same form of the equation: both are \(x = \ldots\), or \(y =\ldots\) , or \(z = \ldots\). In this case, there are no solutions.
• The lines are not parallel. In this case, the equations have different forms. The solution is a single point.

The last case is the one we are really interested in. As an example, let’s find the intersection of the lines \(x = 3\) and \(y = 5\). The intersection is simply \([3, 5]\). The augmented point is then \([3, 5, -8]\) — remember, \(z = -x – y\). More generally, we can just fill in the two coordinates from the corresponding equations:

• If we have \(x = k\), the \(x\)-coordinate is \(k\).
• If we have \(y = m\), the \(y\)-coordinate is \(m\).
• If we have \(z = n\), the \(z\)-coordinate is \(n\).

In general we have two equations, so we have two coordinates of the point. The third can be calculated from \(x + y + z = 0\).

Here are two more examples:

\(x = -3\), \(z = 3\). The intersection is \([-3, \ldots, 3]\), or after we calculated the \(y\), \([-3, 0, 3]\).

\(y = -2\), \(z = 2\). The intersection is \([\ldots, -2, 2]\), or after we calculated the \(x\), \([0, 2, -2]\).

Half-planes

A half-plane is all the points that fall on one side of the line, and includes the line itself as well.

Since there are only three types of proper line, there are also only six types of proper half-planes (one on each of the two sides of each line).

Their equations are given below:

• \(x \geq k\) and \(x \leq k\)
• \(y \geq k\) and \(y \leq k\)
• \(z \geq k\) and \(z \leq k\)

Half-planes are useful to form polygons. Any convex polygon is the intersection of half-planes. This is true for normal Cartesian coordinates, as well as hex-coordinates.

$$x \geq 2$$

$$x \leq 2$$

Triangles

Triangles are bound by three lines, no two of which are parallel.

The equation for an up-triangle is the following:

$$(x \geq k) \cap (y \geq m) \cap (z \geq n)$$

And for a down-triangle, we have

$$(x \leq k) \cap (y \leq m) \cap (z \leq n)$$

The figure above shows two triangles. The up-triangle has this equation:

$$(x \geq 0) \cap (y \geq 1) \cap (z \geq -3)$$

and the down triangle has this equation:

$$(x \leq 0) \cap (y \leq -1) \cap (z \leq 3)$$

By taking the equations of the lines of the triangle sides two at a time, we can easily calculate the three vertices of the triangle:

• \([k, m, \ldots] \rightarrow [k, m, -k -m]\)
• \([k, \ldots, n] \rightarrow [k, -k – n, n]\)
• \([\ldots, m, n] \rightarrow [-m – n, m, n]\)

The length of the sides can now be calculated. The distance between the first two vertices above is:

$$d([k, m], [k, -k – n] = \frac{|k – k| + |m + k + n| + |-k – m – n|}{2} = |k + m + n|$$

In fact, the other two sides have the same length.

• In hex-space, all triangles are equilateral.

We can just as easily get the equations of a triangle from the vertices. But there is a catch:

• not any three points form a (proper) triangle.

Three points form a triangle only when each pair of points have a coordinate in common, and the common coordinate is a different one (from x, y, or z) for each pair. In other words, two points must have their \(x\)-coordinate in common, two points must have their \(y\)-coordinate in common, and two points must have their \(z\)-coordinate in common.

To write the equation for the triangle, simply find the common \(x\)-coordinate \(k\), the common \(y\)-coordinate \(m\), and the common \(z\)-coordinate \(n\), determine whether the triangle is up or down, and then write the appropriate equation:

$$(x \geq k) \cap (y \geq m) \cap (z \geq n)$$

or

$$(x \leq k) \cap (y \leq m) \cap (z \leq n)$$

The triangle is up if the \(y\)-coordinate of the vertex not on the line \(y = m\) is bigger than \(m\). The \(y\)-coordinate of that vertex is \(-k -n\). So the triangle is up if \(-k -n > m\); otherwise, it’s down.

Quadrangles

Quadrangles are bounded by four lines, and thus can be written as the intersection of four half planes. As with triangles, it is easy to determine the vertices from the equation, and vice versa, although you need to take a bit more care because at least one pair of lines will be parallel.

All quadrangles in hex-space are trapezoids (for people outside the US: trapeziums).

I give a few examples:

Trapezoid:

$$(x \geq -3) \cap (z \geq -3) \cap (y \leq 2) \cap (y \geq 0)$$

Parallelogram:

$$(x \geq -3) \cap (x \leq 3) \cap (y \leq 2) \cap (y \geq 0)$$

General convex polygon

In hex space, convex polygons can have up to six sides. The general equation for any convex polygon is the intersection of six half-planes:

$$(k_1 \leq x \leq k_2) \cap (m_1 \leq y \leq m_2) \cap (n_1 \leq z \leq n_2)$$

Note that we can also use this form of equation to represent triangles and quadrangle, although the equations then are not unique. For example, the following two equations represent the same triangle:

$$(-4 \leq x \leq 100) \cap (-4 \leq y \leq 100) \cap (-4 \leq z \leq 100)$$

$$(-4 \leq x \leq 200) \cap (-4 \leq y \leq 200) \cap (-4 \leq z \leq 200)$$

From the general equation we can make the following observations:

• Pentagons have two pairs of sides that are parallel.
• Hexagons have three pairs of sides that are parallel.

The figure above shows an irregular hexagon with the equation (the shape includes both orange and yellow points, I made the borders yellow so that it is easier to see the lines that form the sides):

$$(-4 \leq x \leq 3) \cap (–1 \leq y \leq 2) \cap (-1 \leq z \leq 4)$$

Regular Hexagons

The equation of a regular hexagon with centre c can be written in a very simple form:

$$|\bv v – \bv c| \leq r$$

In the hex world, all points within a distance r of some point form a regular hexagon. The image above shows a hexagon with centre \([1, 1]\) and radius \(r = 2\).

Rotation

Using three coordinates, there is an easy trick to rotate a point by 60 degrees around the origin: rotate the coordinates left, and change all the signs:

$$[x, y, z] \rightarrow [-y, -z, -x]$$

(From here it’s easy to remove the \(z\)-coordinate, as usual, to find:

$$[x, y] \rightarrow [-y, x + y]$$

By applying the trick above repeatedly, we can find similar expressions for points rotated by 120, 180, 240, and 300 degrees.

It is also easy to see immediately whether a point is another point rotated by some multiple of 60. The two points must have the same coordinates (or the same negative coordinates), in the same order, but potentially shifted:

• \([2, 3, 4]\) and \([3, 4, 2]\) (Yes)
• \([2, 3, 4]\) and \([2, 4, 3]\) (No – not in same order)
• \([2, 3, 4]\) and \([-4, -2, -3]\) (Yes)
• \([2, 3, 4]\) and \([-4, 2, 3]\) (No – signs not consistent)

We can rotate a point \( n \times 60\) degrees around any point \(\bv {c}\):

$$R_{60n}(\bv {v} – \bv {c}) + \bv {c}$$

Reflection

Reflection about \(x = 0\) (\(y\)-axis)

• Flip \(x\), keep \(z\), recalculate \(y = -x – z\)

Reflection about \(y = 0\) (\(x\)-axis)

• Flip \(y\), keep \(z\), recalculate \(x = -y – z\)

Reflection about \(x + y = 0\) (\(z\)-axis)

• Flip both \(x\), \(y\), and \(z\)

With suitable translations, we can reflect a point about any line.

For example, to reflect point about the line \(x = 1\), we translate the point by \([-1, 0]\), reflect it about the \(y\)-axis, and then translate it back by \([1, 0]\).

$$R_Y(\bv {v} – \bv {e}) + \bv{e}$$

Changing the colours of art can be a great way to increase the amount of content in your game, and add variety and richness. It is relatively easy to implement. What is not always as easy is to get a set of colours that looks nice. This article gives some ideas for choosing colour palettes that look nice.

A few things about colour

Colour is surprisingly complex. How colour works is determined by the physics of light and materials, the biology of our eyes and brains, mixed with a bit of psychology.

Although you don’t need to know all about the physics, biology, and psychology of colour vision, it is useful to have some background information (which you can find references to at the end of this article).

For palette choosing, there are a few important points.

Digital colour theory differs considerably from theories based on pigments (or chemicals, or metals in crystals). In fact, no system of colour mixing can produce all colours that occur in nature. You can buy a dark very bright green from a paint shop, but the closest colour your screen can reproduce will look desaturated (just look at images of painted colour wheels). When you research colour for algorithms, make sure that they apply to digital RGB colour.

Vector distances in RGB and many other colour models don’t correspond to differences in perception.

Edit: Turns out I have fallen prey to the very thing I talk about. The descriptions below are true on my monitor, but need not be on your monitor. The main point stands though – RGB values and perception are different (especially when you throw in the variability of display devices).

Brightness

These greys are equally spaced. But notice how much easier it is to distinguish between lighter greys.

Hue differentiation.

In each row, the hue differs by 5%. Notice that certain colours cannot be distinguished. Also notice that it is different depending on the brightness. Lighter blues is more distinguishable than darker blues, while darker magentas are more distinguishable than lighter ones.

This fact becomes important when you try to select colours that look “equally” far apart; in general, it cannot be done without using a perception-based colour space (such as LAB colours), or making appropriate adjustments in other colour spaces.

Here is a bit more on the matter:

• http://en.wikipedia.org/wiki/Color_difference#Tolerance

Here is an a way of computing a useful colour distance that may come in handy later:

• http://www.emanueleferonato.com/2009/08/28/color-differences-algorithm/
• http://www.emanueleferonato.com/2009/09/08/color-difference-algorithm-part-2/

Lab colour spaces are intended to be perceptually more uniform, and may be the basis of colour selection algorithms that give visually more pleasing results. (Photoshop gurus will know that hue adjustments have fewer artefacts when manipulating LAB channels and not RGB channels).

Colour perception is not absolute. Colours appear differently depending on surrounding colours. This is an important factor when selecting colour palettes that work with existing palettes, or combining more than one palette.

Here is more information on colour contrast effects:

• http://www.uxmatters.com/mt/archives/2006/01/color-theory-for-digital-displays-a-quick-reference-part-ii.php#colorContrastEffects

Colour harmony theory. Although why certain combinations of colours look better than others is somewhat of a mystery, theories of colour harmony is a good place to start understanding many good-looking palettes.

See for example:

• Basic overview http://www.malanenewman.com/color_theory_color_wheel.html
• An overview of different theories http://colour-emotion.co.uk/harmony.html

Uses of procedural palettes

Procedural palettes can be used to:

• Get more variety in successively generated scenes,  such as in Tiny Wings.
• To get more variety from a single asset, as shown below.
• To get automatic colours for interface components, such as in the (notoriously ugly) graphs of earlier versions of Microsoft Excel or and Open Office Calc.

Considerations

When selecting algorithms, you must think about what you need:

• How many colours do you need? A few, or many? A fixed number, or an arbitrary number?
• How should the colours in the palette relate to one another? For example, should the colours form a harmonic triad?
• Do you need a high contrasts palette or a palette with a minimum vector distance between colours?
• What colours will be used with the procedurally selected colours?
• Will you colour convey meaning? Do they need to match real-world elements? Are they used symbolically to distinguish between different types of elements?
• What type of variety do you need? Variety in successive generations? Variety in a scene?

7 Algorithms

1. Choosing random colours from a handpicked pre-set

This very simple algorithm gives the most control, and is easy to implement. It is only useful for smaller palettes, and of course all palettes are limited to the original set. However, it can be combined with other algorithms to give bigger sets of colours.

2. Uniform Random RGB

The simplest algorithm for selecting colours procedurally is to simply choose random values for each of the three RGB channels.

color = new Color(Random(), Random(), Random())

This algorithm gives sets of colours the are usually quite ugly. There is no structure, no relationship among colours in the palette, no pattern that pleases the eye. All the algorithms below attempt to constrain the colours generated so that there are relationships or coherence among colours.

3. Random Offset

This algorithm computes a palette by computing a small random offset from a given colour.

An easy implementation simply calculates random offsets for each of RGB components. An alternative is to just change the value of the colour by a random offset.

float value = (color.r + color.g + color.b)/3;
float newValue = value + 2*Random() * offset – offset;
float valueRatio = newValue / value;
Color newColor;
newColor.r = color.r * valueRatio;
newColor.g = color.g * valueRatio;
newColor.b = color.b * valueRatio;

Changing the value randomly can in certain cases simulate shadows (see the middle row below), so that a scene looks like it has more depth than it really has.

In general, this algorithm is:

• Not good for small palettes where high contrast is desired.
• Good for enriching a scene where the base colours are defined and repeated many times.
• Good for colouring tiles with seams (to get more variance with seamless tiles requires a bit more work. See the section Dynamic Colouring in Getting More from Seamless Tiles).

The effect of the maximum offset you choose is different based on the base colour:

• The less saturated the base colour, the more colourful the result is perceived.
• Different hues will have different perceived variance. For example, if the base colour is yellow, the result will be perceived as more colourful than if the base colour was green.

4. Selecting from a gradient

In the code examples below, Gradient.GetColor takes a parameter between 0 and 1 and generate the corresponding colour on the gradient.

Uniform Random Randomly select values between 0 and 1, and map this to the gradient to select colours. This gives little structure, except for that already inherent in the gradient.

Grid This is useful for selecting a known number of colours, with the assurance that no two colours will be closer to each other (along the gradient) than 1/n.

This is useful for colour which convey information, if the number of colours is small.

Jittered Grid This is useful to get more variety with a small number of colours, where you know the number of colours up front. (The variety is not among the colours, but among different generations).

for(int i = 0; i < n; i++)
   color[i] = gradient.GetColor((i + Random.NextFloat()) * intervalSize)

Using a jittered grid works well for a small selection of colours, so that multiple generations give different results. One disadvantage of using a jittered grid is that colours in the sequence are not guaranteed to be equally distinct from each other. You can address this by limiting the amount of jitter to guarantee a minimum distance between colours:

maxJitter = ...//some value between 0 1nd 1

for(int i = 0; i < n; i++)
   color[i] = gradient.GetColor(
      (i + 0.5 + (2 * Random.NextFloat() - 1) * maxJitter) * intervalSize);

Golden Ratio This is a scheme to select a sequence of colours, not necessarily up front, so that consecutively selected colours are always far from each other. Colours never repeat (although, over time, colours become close to previously chosen colours).

offset = Random.NextFloat();

for (int i = 0; i < n; i++)
   color[i] = gradient.GetColor(offset + (0.618033988749895f * i) % 1);

This algorithm is useful for selecting colours for contrast in an interface, where high contrast between successive colours is guaranteed.

Here is an article explaining why this works:

• http://martin.ankerl.com/2009/12/09/how-to-create-random-colors-programmatically/

5. Selecting random channels in other colour spaces

For example, good results can be obtained using the HSL colour space.

Random Hue

Random Saturation

Random Luminance

Random Saturation and Luminance

6. Standard Colour Harmonies

http://www.websiteoptimization.com/speed/tweak/color–harmony/

Methods for choosing random colours for standard colour harmonies all work basically the same: limit the possible choices of hue, and control saturation and luminance. We can use a generic triadic algorithm with suitable parameters to generate a variety colour harmonies:

The algorithm takes a few parameters; the important ones are two offset angles, and two angle ranges.

The simplest form of the algorithm works as follows:

• Select a random reference angle.
• Select a random angle in the total of the range (the three range angles added together)
• If the angle is smaller than the first range, keep it
• Otherwise, if the angle is bigger than the first range, but smaller than the sum of the first Two ranges, offset it by the first offset angle
• Otherwise, offset it by the second offset angle
• Add this angle to the reference angle
• The colour with this angle as hue is a colour generated with the triad harmony

Here is a C# implementation of this algorithm that generates a given number of colours with controlled saturation and luminance.

public static List GenerateColors_Harmony(
   int colorCount,
   float offsetAngle1,
   float offsetAngle2,
   float rangeAngle0,
   float rangeAngle1,
   float rangeAngle2,
   float saturation, float luminance)
{
   List colors = new List();

   float referenceAngle = random.NextFloat() * 360;

   for (int i = 0; i < colorCount; i++)
   {
      float randomAngle = 
         random.NextFloat() * (rangeAngle0 + rangeAngle1 + rangeAngle2);

      if (randomAngle > rangeAngle0)
      {
         if (randomAngle < rangeAngle0 + rangeAngle1)
         {
            randomAngle += offsetAngle1;
         }
         else
         {
            randomAngle += offsetAngle2;
         }
      }

      HSL hslColor = new HSL(
         ((referenceAngle + randomAngle) / 360.0f) % 1.0f,
         saturation, 
         luminance);

      colors.Add(hslColor.Color);
   }

   return colors;
}

The algorithm can be made a bit more intuitive by centring the reference and offset angles in corresponding ranges.

• Select a random reference angle.
• Select a random angle in the total of the range (the three range angles added together)
• If the angle is smaller than the first range, reduce it by half the first range.
• Otherwise, if the angle is bigger than the first range, but smaller than the sum of the first two ranges, offset it by the first offset angle minus the second range.
• Otherwise, offset it by the second offset angle minus the third range.
• Add this angle to the reference angle.
• The colour with this angle as hue is a colour generated with the triad harmony.

More varieties

• With the centred version of the algorithm, it is easy to supply (instead of generating) the reference angle, making it possible to chain the algorithm with other colour selection algorithms.
• More variety can be added by selecting random saturation and random luminance (possibly within a range from given parameters). This can potentially change the harmonic scheme by fringe colours being emphasized by their saturation / luminance. In many cases this is ok.
• The hue can be selected uniformly instead of randomly across the total range. This will insure colours are a minimum hue-distance apart.
• Withsuitableparameters, we can generate common colour schemes:
  • Analogous: Choose second and third ranges 0.
  • Complementary: Choose the third range 0, and first offset angle 180.
  • Split Complementary: Choose offset angles 180 +/- a small angle. The second and third ranges must be smaller than the difference between the two offset angles.
  • Triad: Choose offset angles 120 and 240.

7. Triad Mixing

This algorithm takes three colours, and mixes them randomly to create a palette.

The standard algorithm produces many grey colours. If this is not desired, the amount of greyness can be controlled by limiting the contribution of one of the three colours. This version of the algorithm is given here (if the greyControl is 1, it is equivalent to the standard algorithm).

public static Color RandomMix(Color color1, Color color2, Color color3, 
   float greyControl)
{
   int randomIndex = random.NextByte() % 3;

   float mixRatio1 =
      (randomIndex == 0) ? random.NextFloat() * greyControl : random.NextFloat();

   float mixRatio2 = 
      (randomIndex == 1) ? random.NextFloat() * greyControl : random.NextFloat();

   float mixRatio3 = 
      (randomIndex == 2) ? random.NextFloat() * greyControl : random.NextFloat();

   float sum = mixRatio1 + mixRatio2 + mixRatio3;

   mixRatio1 /= sum;
   mixRatio2 /= sum;
   mixRatio3 /= sum;

   return Color.FromArgb(
      255,
      (byte)(mixRatio1 * color1.R + mixRatio2 * color2.R + mixRatio3 * color3.R),
      (byte)(mixRatio1 * color1.G + mixRatio2 * color2.G + mixRatio3 * color3.G),
      (byte)(mixRatio1 * color1.B + mixRatio2 * color2.B + mixRatio3 * color3.B));
}

Different mixing algorithms can be used, for example subtractive mixing, or hue interpolation.

Low Grey Value

Medium Grey Value

High Grey Value

Below you can see the effect of setting the grey value. On the left it is 0, on the right it is 1.

Monochromatic Textures are Boring

Unlike hand-painted textures, textures altered procedurally can look flat and uninteresting.

There are several ways to deal with this issue. All of them require intensive artist input, but it is important to understand the techniques and how they work (and how they will affect the art pipeline).

Use coloured textures. The base textures need not be totally greyscale. Painting them with colours will offset the final colour, and can be used for local colour variations.

Channel independent colour correction. Sometimes a good effect can be obtained by adjusting values for channels independently, for example, by a post-effect. In the example below, for example, shadows have been made a bit redder. (The image without any colour correction is shown on the left).

Using coloured lights. By using coloured lights at slightly different angles, flat textures become more nuanced. Below, the scenes below are lit with the same three lights, but on the right the lights are coloured red, blue and green (and 3 times the intensity to compensate for the missing channels in each light).

Preparing Art

Preparing the art requires careful planning. The biggest challenge is figuring out how to consistently separate textures. To give you an idea of what is involved, here is how I prepared the images for this article:

• The ferns use a single material. Each fern randomly selects a colour from the currently set up scheme, so I could just plunk the script on the colour selection script.
• The flowers use different materials for each part. Only the petals must change colour, so I had to modify the script to link to a part of the mesh (the petals) to adjust the colours.
• The room scene again uses separate materials for each part of the mesh. In this case I used a global script that sets the colours of all submeshes.

You can see that it can become complicated, especially if you colour different elements using different algorithms, and have complicated objects.

There are a few other tips when it comes to preparing the art:

• If you multiply your grey textures with procedural colours, textures that covers a wide grey spectrum are more flexible. Your colour application algorithm or the colours you choose can always reduce the final contrast, but it’s much harder to put it back in.
• Carefully plan how you will tweak the final result, to minimise back and forth. (This is a general art principle, but becomes even more important if you use this technique). For example, to there are at least four ways to make something darker: change the texture, change the input of the colour selection algorithm, or change the lighting, or change the post effects. You can easily land in a tweaking loop that can waste a lot of time. One strategy is to get base levels for all these, and then tweaking them in this order: texture, algorithm, lighting, post effects.
• In some cases it may be useful to use index colours, where each index corresponds to a colour from the palette, instead of using separate materials for each colour.
• To gain performance at the expense of disk space, you can pregenerate your textures.

Download

C# source code with all the algorithms explained here.

Related

(Plug) We (at Gamelogic) have implemented these algorithms as a Unity plugin.

Thanks

• Jarred Lunt made the art for the desert scene.
• Ciaran Prince made the art for the room and flower scenes.

Thanks guys!

This article is a follow-up of a previous article I wrote, 11 Tips for making a fun platformer. Once again, this article focuses on platformers, but the philosophy behind each idea can be applied to any type of game, whether 2D or 3D. This time there are a few more practical tips.

1. Keep the camera simple

The most simple (and best) camera is the one that always keeps player in the middle of the screen. This gives the player equal time to react to objects appearing from the left and right edges of the screen. The camera stops moving when the player reaches the edge of the level. For example, if the player reaches the left edge of the level then the camera stops moving left. It will continue to follow the player horizontally when the player moves away from the left edge of the level.

An optional addition is to make the camera look ahead in the direction the player is moving. For example, when the player runs right then the camera shows more of the level on the right side of the player, so he can see ahead. When he stops moving then the camera slowly moves to position the player in the middle of the screen.

Ideally, the player should not be aware of the camera.

2. Allow the player to move in the air when jumping

The player should have at least the same manoeuvrability when he is jumping through the air, as he has when he is running on the ground.

This means that he should move left or right at the same speed, and be able to shoot or use items with the same ease as when he is running.

3. Make it easy to climb ladders

	The player can grab onto the ladder when he is in the green rectangle, even if he is in the air. The character grabs onto the ladder when the player presses up*. The rectangle is slightly bigger than the ladder to make it easier to grab onto the ladder.
The player should be able to move up, down, left, right and diagonal when he is on a ladder.
	When the player moves up and bangs his head against collision (red rectangles), automatically move him towards the middle of the ladder (while he is pressing up). This will make it easier to get through narrow gaps.

Allow the player to be able to shoot or use items while he is on a ladder.

At any time the player should be able to jump off the ladder by pressing the jump button. He can also fall off the ladder when he moves all the way to the left or right and no longer touches the ladder.

* To start climbing the player can press up, jump or a grab button, depending on the other mechanics of the game. Generally, pressing the up button to start climbing is the easiest and most intuitive. But it may not be ideal if your character has a gun which can aim up, so pressing up will aim the gun up to shoot upwards. In this case the jump button or an extra grab button can be used to start climbing up. Prototype it to find what is the easiest and most fun. (This also applies to vines and swinging ropes. See below.)

4. Make it easy to climb vines on the side of a wall

Ideally, climbing ladders and climbing vines will use the same code. Therefore climbing vines will be the same as climbing ladders, except, usually vines are wider and encourages more horizontal movement.

5. Make it easy to swing on ropes

The player can grab onto the rope when he is within the green rectangles and he presses up. Like the ladder earlier on, the green rectangles are slightly bigger than the rope to make it easier to grab onto the rope.

When the player is swinging on the rope, allow him to move up or down the rope when he presses up or down, no matter what angle the rope is swinging at. For example, if the rope is swinging at a 45 degree angle, pressing up still moves the player up the rope.

Allow the player to be able to shoot or use items while he is swinging on a rope.

At any time the player should be able to jump off the rope by pressing the jump button.

6. Let the player double jump whenever

Usually the player is only allowed to do the second jump of a double jump when the first jump reaches a certain state (for example, specific height, within a certain time limit, or when she is moving up).

Allow the player to do the second jump at any time while he is in the air. It makes the game feel more responsive and fun. The only limit should be that he has to release the jump button and press it again to do the second jump.

7. Avoid using inertia

When the player stops pressing left or right then the character should stop moving immediately. Avoid giving the character inertia which causes him to move forward a short distance before stopping. Inertia is acceptable in an ice level where it adds to the challenge of the level. But avoid having it throughout the game. Inertia can lead to the player falling off ledges or running into enemies or hazards, therefore making the game feel unresponsive.

8. Make moving platforms friendly

The first moving platform the player encounters should be easy to use and not have a big penalty for falling off or missing it (for example, the penalty can just be climbing up a short ladder to get back to where the platform is). The first platform makes the player aware there are moving platforms in the game.

Avoid making moving platforms travel far. If the platform travels far and the player misses it then he has to wait a long time for the platform to return. When he has to travel via moving platforms over a large area (for example, over spikes) then have multiple moving platforms.

If you have a platform that constantly moves back and forth to take the player between two ledges, then only start moving the platform when the player clearly sees it. When he gets to the ledge and does not see the platform (because it is off screen) then he may not know there is a platform there, and leaves to explore the rest of the level. Alternatively, if you want to make sure the player does not miss seeing the moving platform, let the platform only start moving when the player climbs on it. Another option is to make the platforms move along rails, so that when the player sees a rail he knows there is a moving platform nearby.

9. Avoid adding leaps of faith

Generally, the player should see what lies at the bottom of the platform he is currently standing on. So that he knows if it is safe to jump off or not.

If the player cannot see what lies past the bottom of the screen’s edge, then add clues so the player knows what lies at the bottom.

Examples:

• Skulls, flies or blood indicates there are spikes or rotating blades at the bottom.
• A red glow indicates there’s fire or lava at the bottom.
• A power-up in mid-air is an invite to jump off safely.
• An enemy’s head sticking out the bottom of the screen, and moving horizontally will give the player an idea of where there is ground to land on.

If there are no clues, then most of the time the player should be able to jump off and land safely at the bottom.

If there is an enemy at the bottom and off screen, then position the enemy in such a way that the player will have time to react to the enemy when he lands on the ground (for example, the enemy may be in an idle pose and delay for about 2 seconds before he starts attacking the player).

Avoiding leaps of faith removes the sense that the game is unfair. The player will feel it is unfair for him to make decisions when he cannot see the possible outcomes.

Some platformers have a main ground. Usually when the player falls out the bottom of the screen, past the main ground then he dies instantly. This is quickly learned by the player when it happens the first time. The leaps of faith generally apply to platforms above the main ground.

10. Remove frustrating elements

By removing frustrating elements your game will become more fun.

Here are some examples of frustrating elements:

• A cut scene which you cannot skip before the boss fight. When the boss kills you then you are forced to watch the cut scene again.
• Extremely difficult jumps that you have to retry countless times to get right.
• Spending large amounts of time collecting items to achieve a goal (for example, collect 100 stars to get a special weapon) then losing all the items when you die.

Complicated button combos which take too long to do a special attack and is interrupted when an enemy punches you.

• Losing health when you fall from a high height.
• Being attacked by enemies who are still off screen.

11. Keep the background in the background

Make sure the background does not interfere with the foreground. This will help the player see which platforms he can stand on and makes it easier to identify items and enemies.

Some tips on how to push the background backwards:

• Use less contrasts in the background (for example, reduce the background image’s contrast setting in GIMP or Photoshop).
• Use cool colours in the background, such as shades of blues (for example, place a semi-transparent blue layer over the background image in GIMP or Photoshop).
• Have less, slower or less frequent animations in the background. The animations should not distract the player.
• Use parallax scrolling (that is, the background scrolls slower than the foreground).

Here it is easy to see what is in the background and it does not interfere with the foreground.

12. Emotion is more important than reason

You can have the most brilliant, genius, unique, awesome ideas and mechanics or systems for a game. But what does it feel like when you play it?

In other words: prototype and let your emotions be the final judge.

13. A fun game has a good user interface

There are various definitions of what a user interface is, but most of them include the following:

• Information that allows a user to make a decision.
• The user input system.
• The feedback generated by the user input. This leads back to the first point: information to make the next decision.

Examples of non-game user interfaces:

• The controls and dials of a car.
• The LED, buttons and beeps of a washing machine.
• The remote control of a television.
• The buttons and highlighted floor number of a lift.

What makes a good, non-game user interface?

• Clear information.
• Easy to use.
• Clear and instant feedback.

These are also an important part of making a fun game.

References

• http://searchsoa.techtarget.com/definition/user-interface
• http://www.pcmag.com/encyclopedia_term/0,2542,t=user+interface&i=53558,00.asp
• http://en.wikipedia.org/wiki/User_interface

Discuss

Some more discussion of these tips on Make Games SA.

About these tips

(Edit: August 2016. I have revised these tips. You can find the new list here.)

These tips are not all applicable to every project.

• They are based on my experience with projects with small teams from 3 to 20 people.
• There’s is a price for structure, re-usability, clarity, and so on — team size and project size determine whether that price should be paid.
• Many tips are a matter of taste (there may be rivalling but equally good techniques for any tip listed here).
• Some tips may fly in the face of conventional Unity development. For instance, using prefabs for specialisation instead of instances is very non-Unity-like, and the price is quite high (many times more prefabs than without it). Yet I have seen these tips pay off, even if they seem crazy.

Process

1. Avoid branching assets. There should always only ever be one version of any asset. If you absolutely have to branch a prefab, scene, or mesh, follow a process that makes it very clear which is the right version. The “wrong” branch should have a funky name, for example, use a double underscore prefix: __MainScene_Backup. Branching prefabs requires a specific process to make it safe (see under the section Prefabs).

2. Each team member should have a second copy of the project checked out for testing if you are using version control. After changes, this second copy, the clean copy, should be updated and tested. No-one should make any changes to their clean copies. This is especially useful to catch missing assets.

3. Consider using external level tools for level editing. Unity is not the perfect level editor. For example, we have used TuDee to build levels for a 3D tile-based game, where we could benefit from the tile-friendly tools (snapping to grid, and multiple-of-90-degrees rotation, 2D view, quick tile selection). Instantiating prefabs from an XML file is straightforward. See Guerrilla Tool Development for more ideas.

4. Consider saving levels in XML instead of in scenes. This is a wonderful technique:

• It makes it unnecessary to re-setup each scene.
• It makes loading much faster (if most objects are shared between scenes).
• It makes it easier to merge scenes (even with Unity’s new text-based scenes there is so much data in there that merging is often impractical in any case).
• It makes it easier to keep track of data across levels.

You can still use Unity as a level editor (although you need not). You will need to write some code to serialize and deserialize your data, and load a level both in the editor and at runtime, and save levels from the editor. You may also need to mimic Unity’s ID system for maintaining references between objects.

5. Consider writing generic custom inspector code. To write custom inspectors is fairly straightforward, but Unity’s system has many drawbacks:

• It does not support taking advantage of inheritance.
• It does not let you define inspector components on a field-type level, only a class-type level. For instance, if every game object has a field of type SomeCoolType, which you want rendered differently in the inspector, you have to write inspectors for all your classes.

You can address these issues by essentially re-implementing the inspector system. Using a few tricks of reflection, this is not as hard as it seems, details are provided at the end of the article.

Scene Organisation

6. Use named empty game objects as scene folders. Carefully organise your scenes to make it easy to find objects.

7. Put maintenance prefabs and folders (empty game objects) at 0 0 0. If a transform is not specifically used to position an object, it should be at the origin. That way, there is less danger of running into problems with local and world space, and code is generally simpler.

8. Minimise using offsets for GUI components. Offsets should always be used to layout components in their parent component only; they should not rely on the positioning of their grandparents. Offsets should not cancel each other out to display correctly. It is basically to prevent this kind of thing:

Parent container arbitrarily placed at (100, -50). Child, meant to be positioned at (10, 10), then placed at (90, 60) [relative to parent].

This error is common when the container is invisible, or does not have a visual representation at all.

9. Put your world floor at y = 0. This makes it easier to put objects on the floor, and treat the world as a 2D space (when appropriate) for game logic, AI, and physics.

10. Make the game runnable from every scene. This drastically reduces testing time. To make all scenes runnable you need to do two things:

First, provide a way to mock up any data that is required from previously loaded scenes if it is not available.

Second, spawn objects that must persist between scene loads with the following idiom:

myObject = FindMyObjectInScene();

if (myObjet == null)
{
   myObject = SpawnMyObject();
}

Art

11. Put character and standing object pivots at the base, not in the centre. This makes it easy to put characters and objects on the floor precisely. It also makes it easier to work with 3D as if it is 2D for game logic, AI, and even physics when appropriate.

12. Make all meshes face in the same direction (positive or negative z axis). This applies to meshes such as characters and other objects that have a concept of facing direction. Many algorithms are simplified if everything have the same facing direction.

13. Get the scale right from the beginning. Make art so that they can all be imported at a scale factor of 1, and that their transforms can be scaled 1, 1, 1. Use a reference object (a Unity cube) to make scale comparisons easy. Choose a world to Unity units ratio suitable for your game, and stick to it.

14. Make a two-poly plane to use for GUI components and manually created particles. Make the plane face the positive z-axis for easy billboarding and easy GUI building.

15. Make and use test art

• Squares labelled for skyboxes.
• A grid.
• Various flat colours for shader testing: white, black, 50% grey, red, green, blue, magenta, yellow, cyan.
• Gradients for shader testing: black to white, red to green, red to blue, green to blue.
• Black and white checkerboard.
• Smooth and rugged normal maps.
• A lighting rig (as prefab) for quickly setting up test scenes.

Prefabs

16. Use prefabs for everything. The only game objects in your scene that should not be prefabs should be folders. Even unique objects that are used only once should be prefabs. This makes it easier to make changes that don’t require the scene to change. (An additional benefit is that it makes building sprite atlases reliable when using EZGUI).

17. Use separate prefabs for specialisation; do not specialise instances. If you have two enemy types, and they only differ by their properties, make separate prefabs for the properties, and link them in. This makes it possible to

• make changes to each type in one place
• make changes without having to change the scene.

If you have too many enemy types, specialisation should still not be made in instances in the editor. One alternative is to do it procedurally, or using a central file / prefab for all enemies. A single drop down could be used to differentiate enemies, or an algorithm based on enemy position or player progress.

18. Link prefabs to prefabs; do not link instances to instances. Links to prefabs are maintained when dropping a prefab into a scene; links to instances are not. Linking to prefabs whenever possible reduces scene setup, and reduce the need to change scenes.

19. As far as possible, establish links between instances automatically. If you need to link instances, establish the links programmatically. For example, the player prefab can register itself with the GameManager when it starts, or the GameManager can find the Player prefab instance when it starts.

Don’t put meshes at the roots of prefabs if you want to add other scripts. When you make the prefab from a mesh, first parent the mesh to an empty game object, and make that the root. Put scripts on the root, not on the mesh node. That way it is much easier to replace the mesh with another mesh without loosing any values that you set up in the inspector.

Use linked prefabs as an alternative to nested prefabs. Unity does not support nested prefabs, and existing third-party solutions can be dangerous when working in a team because the relationship between nested prefabs is not obvious.

20. Use safe processes to branch prefabs. The explanation use the Player prefab as an example.

Make a risky change to the Player prefab is as follows:

1. Duplicate the Player prefab.
2. Rename the duplicate to __Player_Backup.
3. Make changes to the Player prefab.
4. If everything works, delete __Player_Backup.

Do not name the duplicate Player_New, and make changes to it!

Some situations are more complicated. For example, a certain change may involve two people, and following the above process may break the working scene for everyone until person two finished. If it is quick enough, still follow the process above. For changes that take longer, the following process can be followed:

1. Person 1:
   1. Duplicate the Player prefab.
   2. Rename it to __Player_WithNewFeature or __Player_ForPerson2.
   3. Make changes on the duplicate, and commit / give to Person 2.
2. Person 2:
   1. Make changes to new prefab.
   2. Duplicate Player prefab, and call it __Player_Backup.
   3. Drag an instance of __Player_WithNewFeature into the scene.
   4. Drag the instance onto the original Player prefab.
   5. If everything works, delete __Player_Backup and __Player_WithNewFeature.

Extensions and MonoBehaviourBase

21. Extend your own base mono behaviour, and derive all your components from it.

This allows you to implement some general functionality, such as type safe Invoke, and more complicated Invokes (such as random, etc.).

22. Define safe methods for Invoke, StartCoroutine and Instantiate.

Define a delegate Task, and use it to define methods that don’t rely on string names. For example:

public void Invoke(Task task, float time)
{
   Invoke(task.Method.Name, time);
}

23. Use extensions to work with components that share an interface. It is sometimes convenient to get components that implement a certain interface, or find objects with such components.

The implementations below uses typeof instead of the generic versions of these functions. The generic versions don’t work with interfaces, but typeof does. The methods below wraps this neatly in generic methods.

//Defined in the common base class for all mono behaviours
public I GetInterfaceComponent<I>() where I : class
{
   return GetComponent(typeof(I)) as I;
}

public static List<I> FindObjectsOfInterface<I>() where I : class
{
   MonoBehaviour[] monoBehaviours = FindObjectsOfType<MonoBehaviour>();
   List<I> list = new List<I>();

   foreach(MonoBehaviour behaviour in monoBehaviours)
   {
      I component = behaviour.GetComponent(typeof(I)) as I;

      if(component != null)
      {
         list.Add(component);
      }
   }

   return list;
}

24. Use extensions to make syntax more convenient. For example:

public static class CSTransform 
{
   public static void SetX(this Transform transform, float x)
   {
      Vector3 newPosition = 
         new Vector3(x, transform.position.y, transform.position.z);

      transform.position = newPosition;
   }
   ...
}

25. Use a defensive GetComponent alternative. Sometimes forcing component dependencies (through RequiredComponent) can be a pain. For example, it makes it difficult to change components in the inspector (even if they have the same base type). As an alternative, the following extension of GameObject can be used when a component is required to print out an error message when it is not found.

public static T GetSafeComponent<T>(this GameObject obj) where T : MonoBehaviour
{
   T component = obj.GetComponent<T>();

   if(component == null)
   {
      Debug.LogError("Expected to find component of type " 
         + typeof(T) + " but found none", obj);
   }

   return component;
}

Idioms

26. Avoid using different idioms to do the same thing. In many cases there are more than one idiomatic way to do things. In such cases, choose one to use throughout the project. Here is why:

• Some idioms don’t work well together. Using one idiom well forces design in one direction that is not suitable for another idiom.
• Using the same idiom throughout makes it easier for team members to understand what is going on. It makes structure and code easier to understand. It makes mistakes harder to make.

Examples of idiom groups:

• Coroutines vs. state machines.
• Nested prefabs vs. linked prefabs vs. God prefabs.
• Data separation strategies.
• Ways of using sprites for states in 2D games.
• Prefab structure.
• Spawning strategies.
• Ways to locate objects: by type vs. name vs. tag vs. layer vs. reference (“links”).
• Ways to group objects: by type vs. name vs. tag vs. layer vs. arrays of references (“links”).
• Finding groups of objects versus self registration.
• Controlling execution order (Using Unity’s execution order setup versus yield logic versus Awake / Start and Update / Late Update reliance versus manual methods versus any-order architecture).
• Selecting objects / positions / targets with the mouse in-game: selection manager versus local self-management.
• Keeping data between scene changes: through PlayerPrefs, or objects that are not Destroyed when a new scene is loaded.
• Ways of combining (blending, adding and layering) animation.

Time

27. Maintain your own time class to make pausing easier. Wrap Time.DeltaTime and Time.TimeSinceLevelLoad to account for pausing and time scale. It requires discipline to use it, but will make things a lot easier, especially when running things of different clocks (such as interface animations and game animations).

Spawning Objects

28. Don’t let spawned objects clutter your hierarchy when the game runs. Set their parents to a scene object to make it easier to find stuff when the game is running. You could use a empty game object, or even a singleton with no behaviour to make it easier to access from code. Call this object DynamicObjects.

Class Design

29. Use singletons for convenience. The following class will make any class that inherits from it a singleton automatically:

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
   protected static T instance;

   /**
      Returns the instance of this singleton.
   */
   public static T Instance
   {
      get
      {
         if(instance == null)
         {
            instance = (T) FindObjectOfType(typeof(T));

            if (instance == null)
            {
               Debug.LogError("An instance of " + typeof(T) + 
                  " is needed in the scene, but there is none.");
            }
         }

         return instance;
      }
   }
}

Singletons are useful for managers, such as ParticleManager or AudioManager or GUIManager.

• Avoid using singletons for unique instances of prefabs that are not managers (such as the Player). Not adhering to this principle complicates inheritance hierarchies, and makes certain types of changes harder. Rather keep references to these in your GameManager (or other suitable God class )
• Define static properties and methods for public variables and methods that are used often from outside the class. This allows you to write GameManager.Player instead of GameManager.Instance.player.

30. For components, never make variables public that should not be tweaked in the inspector. Otherwise it will be tweaked by a designer, especially if it is not clear what it does. In some rare cases it is unavoidable. In that case use a two or even four underscores to prefix the variable name to scare away tweakers:

public float __aVariable;

31. Separate interface from game logic. This is essentially the MVC pattern.

Any input controller should only give commands to the appropriate components to let them know the controller has been invoked. For example in controller logic, the controller could decide which commands to give based on the player state. But this is bad (for example, it will lead to duplicate logic if more controllers are added). Instead, the Player object should be notified of the intent of moving forward, and then based on the current state (slowed or stunned, for example) set the speed and update the player facing direction. Controllers should only do things that relate to their own state (the controller does not change state if the player changes state; therefore, the controller should not know of the player state at all). Another example is the changing of weapons. The right way to do it is with a method on Player SwitchWeapon(Weapon newWeapon), which the GUI can call. The GUI should not manipulate transforms and parents and all that stuff.

Any interface component should only maintain data and do processing related to it’s own state. For example, do display a map, the GUI could compute what to display based on the player’s movements. However, this is game state data, and does not belong in the GUI. The GUI should merely display game state data, which should be maintained elsewhere. The map data should be maintained elsewhere (in the GameManager, for example).

Gameplay objects should know virtually nothing of the GUI. The one exception is the pause behaviour, which is may be controlled globally through Time.timeScale (which is not a good idea as well… see ). Gameplay objects should know if the game is paused. But that is all. Therefore, no links to GUI components from gameplay objects.

In general, if you delete all the GUI classes, the game should still compile.

You should also be able to re-implement the GUI and input without needing to write any new game logic.

32. Separate state and bookkeeping. Bookkeeping variables are used for speed or convenience, and can be recovered from the state. By separating these, you make it easier to

• save the game state, and
• debug the game state.

One way to do it is to define a SaveData class for each game logic class. The

[Serializable]
PlayerSaveData
{
   public float health; //public for serialisation, not exposed in inspector
} 

Player
{
   //... bookkeeping variables

   //Don’t expose state in inspector. State is not tweakable.
   private PlayerSaveData playerSaveData; 
}

33. Separate specialisation configuration.

Consider two enemies with identical meshes, but different tweakables (for instance different strengths and different speeds). There are different ways to separate data. The one here is what I prefer, especially when objects are spawned, or the game is saved. (Tweakables are not state data, but configuration data, so it need not be saved. When objects are loaded or spawned, the tweakables are automatically loaded in separately)

• Define a template class for each game logic class. For instance, for Enemy, we also define EnemyTemplate. All the differentiating tweakables are stored in EnemyTemplate
• In the game logic class, define a variable of the template type.
• Make an Enemy prefab, and two template prefabs WeakEnemyTemplate and StrongEnemyTemplate.
• When loading or spawning objects, set the template variable to the right template.

This method can become quite sophisticated (and sometimes, needlessly complicated, so beware!).

For example, to better make use of generic polymorphism, we may define our classes like this:

public class BaseTemplate
{
   ...
}

public class ActorTemplate : BaseTemplate
{
   ...
}

public class Entity<EntityTemplateType> where EntityTemplateType : BaseTemplate
{
   EntityTemplateType template;
   ...
}

public class Actor : Entity <ActorTemplate>
{
   ...
}

34. Don’t use strings for anything other than displayed text. In particular, do not use strings for identifying objects or prefabs etc. One unfortunate exception is animations, which generally are accessed with their string names.

35. Avoid using public index-coupled arrays. For instance, do not define an array of weapons, an array of bullets, and an array of particles , so that your code looks like this:

public void SelectWeapon(int index)
{ 
   currentWeaponIndex = index;
   Player.SwitchWeapon(weapons[currentWeapon]);
}

public void Shoot()
{
   Fire(bullets[currentWeapon]);
   FireParticles(particles[currentWeapon]);   
}

The problem for this is not so much in the code, but rather setting it up in the inspector without making mistakes.

Rather, define a class that encapsulates the three variables, and make an array of that:

[Serializable]
public class Weapon
{
   public GameObject prefab;
   public ParticleSystem particles;
   public Bullet bullet;
}

The code looks neater, but most importantly, it is harder to make mistakes in setting up the data in the inspector.

36. Avoid using arrays for structure other than sequences. For example, a player may have three types of attacks. Each uses the current weapon, but generates different bullets and different behaviour.

You may be tempted to dump the three bullets in an array, and then use this kind of logic:

public void FireAttack()
{
   /// behaviour
   Fire(bullets[0]);
}

public void IceAttack()
{
   /// behaviour
   Fire(bullets[1]);
}

public void WindAttack()
{
   /// behaviour
   Fire(bullets[2]);
}

Enums can make things look better in code…

public void WindAttack()
{
   /// behaviour
   Fire(bullets[WeaponType.Wind]);
}

…but not in the inspector.

It’s better to use separate variables so that the names help show which content to put in. Use a class to make it neat.

[Serializable]
public class Bullets
{
   public Bullet FireBullet;
   public Bullet IceBullet;
   public Bullet WindBullet;
}

This assumes there is no other Fire, Ice and Wind data.

37. Group data in serializable classes to make things neater in the inspector. Some entities may have dozens of tweakables. It can become a nightmare to find the right variable in the inspector. To make things easier, follow these steps:

• Define separate classes for groups of variables. Make them public and serializable.
• In the primary class, define public variables of each type defined as above.
• Do not initialize these variables in Awake or Start; since they are serializable, Unity will take care of that.
• You can specify defaults as before by assigning values in the definition;

This will group variables in collapsible units in the inspector, which is easier to manage.

[Serializable]
public class MovementProperties //Not a MonoBehaviour!
{
   public float movementSpeed;
   public float turnSpeed = 1; //default provided
}

public class HealthProperties //Not a MonoBehaviour!
{
   public float maxHealth;
   public float regenerationRate;
}

public class Player : MonoBehaviour
{
   public MovementProperties movementProeprties;
   public HealthPorperties healthProeprties;
}

Text

38. If you have a lot of story text, put it in a file. Don’t put it in fields for editing in the inspector. Make it easy to change without having to open the Unity editor, and especially without having to save the scene.

39. If you plan to localise, separate all your strings to one location. There are many ways to do this. One way is to define a Text class with a public string field for each string, with defaults set to English, for example. Other languages subclass this and re-initialize the fields with the language equivalents.

More sophisticated techniques (appropriate when the body of text is large and / or the number of languages is high) will read in a spread sheet and provide logic for selecting the right string based on the chosen language.

Testing and Debugging

40. Implement a graphical logger to debug physics, animation, and AI. This can make debugging considerably faster. See here.

41. Implement a HTML logger. In some cases, logging can still be useful. Having logs that are easier to parse (are colour coded, has multiple views, records screenshots) can make log-debugging much more pleasant. See here.

42. Implement your own FPS counter. Yup. No one knows what Unity’s FPS counter really measures, but it is not frame rate. Implement your own so that the number can correspond with intuition and visual inspection.

43. Implement shortcuts for taking screen shots. Many bugs are visual, and are much easier to report when you can take a picture. The ideal system should maintain a counter in PlayerPrefs so that successive screenshots are not overwritten. The screenshots should be saved outside the project folder to avoid people from accidentally committing them to the repository.

44. Implement shortcuts for printing the player’s world position. This makes it easy to report the position of bugs that occur in specific places in the world, which in turns makes it easier to debug.

45. Implement debug options for making testing easier. Some examples:

• Unlock all items.
• Disable enemies.
• Disable GUI.
• Make player invincible.
• Disable all gameplay.

46. For teams that are small enough, make a prefab for each team member with debug options. Put a user identifier in a file that is not committed, and is read when the game is run. This why:

• Team members do not commit their debug options by accident and affect everyone.
• Changing debug options don’t change the scene.

47. Maintain a scene with all gameplay elements. For instance, a scene with all enemies, all objects you can interact with, etc. This makes it easy to test functionality without having to play too long.

48. Define constants for debug shortcut keys, and keep them in one place. Debug keys are not normally (or conveniently) processed in a single location like the rest of the game input. To avoid shortcut key collisions, define constants in a central place. An alternative is to process all keys in one place regardless of whether it is a debug function or not. (The downside is that this class may need extra references to objects just for this).

Documentation

49. Document your setup. Most documentation should be in the code, but certain things should be documented outside code. Making designers sift through code for setup is time-wasting. Documented setups improved efficiency (if the documents are current).

Document the following:

• Layer uses (for collision, culling, and raycasting – essentially, what should be in what layer).
• Tag uses.
• GUI depths for layers (what should display over what).
• Scene setup.
• Idiom preferences.
• Prefab structure.
• Animation layers.

Naming Standard and Folder Structure

50. Follow a documented naming convention and folder structure. Consistent naming and folder structure makes it easier to find things, and to figure out what things are.

You will most probably want to create your own naming convention and folder structure. Here is one as an example.

Naming General Principles

1. Call a thing what it is. A bird should be called Bird.
2. Choose names that can be pronounced and remembered. If you make a Mayan game, do not name your level QuetzalcoatisReturn.
3. Be consistent. When you choose a name, stick to it.
4. Use Pascal case, like this: ComplicatedVerySpecificObject. Do not use spaces, underscores, or hyphens, with one exception (see Naming Different Aspects of the Same Thing).
5. Do not use version numbers, or words to indicate their progress (WIP, final).
6. Do not use abbreviations: DVamp@W should be DarkVampire@Walk.
7. Use the terminology in the design document: if the document calls the die animation Die, then use DarkVampire@Die, not DarkVampire@Death.
8. Keep the most specific descriptor on the left: DarkVampire, not VampireDark; PauseButton, not ButtonPaused. It is, for instance, easier to find the pause button in the inspector if not all buttons start with the word Button. [Many people prefer it the other way around, because that makes grouping more obvious visually. Names are not for grouping though, folders are. Names are to distinguish objects of the same type so that they can be located reliably and fast.]
9. Some names form a sequence. Use numbers in these names, for example, PathNode0, PathNode1. Always start with 0, not 1.
10. Do not use numbers for things that don’t form a sequence. For example, Bird0, Bird1, Bird2 should be Flamingo, Eagle, Swallow.
11. Prefix temporary objects with a double underscore __Player_Backup.

Naming Different Aspects of the Same Thing

Use underscores between the core name, and the thing that describes the “aspect”. For instance:

• GUI buttons states EnterButton_Active, EnterButton_Inactive
• Textures DarkVampire_Diffuse, DarkVampire_Normalmap
• Skybox JungleSky_Top, JungleSky_North
• LOD Groups DarkVampire_LOD0, DarkVampire_LOD1

Do not use this convention just to distinguish between different types of items, for instance Rock_Small, Rock_Large should be SmallRock, LargeRock.

Structure

The organisation of your scenes, project folder, and script folder should follow a similar pattern.

Folder Structure

Materials
GUI
Effects
Meshes
   Actors
      DarkVampire
      LightVampire
      ...
   Structures
      Buildings
      ...
   Props
      Plants
      ...
   ...
Plugins
Prefabs
   Actors
   Items
   ...
Resources
   Actors
   Items
   ...
Scenes
   GUI
   Levels
   TestScenes
Scripts
Textures
GUI
Effects
...

Scene Structure

Cameras
Dynamic Objects
Gameplay
   Actors
   Items
   ...
GUI
   HUD
   PauseMenu
   ...
Management
Lights
World
   Ground
   Props
   Structure
   ...

Scripts Folder Structure

ThirdParty
   ...
MyGenericScripts
   Debug
   Extensions
   Framework
   Graphics
   IO
   Math
   ...
MyGameScripts
   Debug
   Gameplay
      Actors
      Items
      ...
   Framework
   Graphics
   GUI
   ...

How to Re-implement Inspector Drawing

1. Define a base class for all your editors

BaseEditor<T> : Editor 
where T : MonoBehaviour
{
   override public void OnInspectorGUI()
   {
      T data = (T) target;

      GUIContent label = new GUIContent();
      label.text = "Properties"; //

      DrawDefaultInspectors(label, data);

      if(GUI.changed)
      {         
         EditorUtility.SetDirty(target);
      }
   }
}

2. Use reflection and recursion to do draw components

public static void DrawDefaultInspectors<T>(GUIContent label, T target)
   where T : new()
{
   EditorGUILayout.Separator();
   Type type = typeof(T);      
   FieldInfo[] fields = type.GetFields();
   EditorGUI.indentLevel++;

   foreach(FieldInfo field in fields)
   {
      if(field.IsPublic)
      {
         if(field.FieldType == typeof(int))
         {
            field.SetValue(target, EditorGUILayout.IntField(
            MakeLabel(field), (int) field.GetValue(target)));
         }   
         else if(field.FieldType == typeof(float))
         {
            field.SetValue(target, EditorGUILayout.FloatField(
            MakeLabel(field), (float) field.GetValue(target)));
         }

         ///etc. for other primitive types

         else if(field.FieldType.IsClass)
         {
            Type[] parmTypes = new Type[]{ field.FieldType};

            string methodName = "DrawDefaultInspectors";

            MethodInfo drawMethod = 
               typeof(CSEditorGUILayout).GetMethod(methodName);

            if(drawMethod == null)
            {
               Debug.LogError("No method found: " + methodName);
            }

            bool foldOut = true;

            drawMethod.MakeGenericMethod(parmTypes).Invoke(null, 
               new object[]
               {
                  MakeLabel(field),
                  field.GetValue(target)
               });
         }      
         else
         {
            Debug.LogError(
               "DrawDefaultInspectors does not support fields of type " +
               field.FieldType);
         }
      }         
   }

   EditorGUI.indentLevel--;
}

The above method uses the following helper:

private static GUIContent MakeLabel(FieldInfo field)
{
   GUIContent guiContent = new GUIContent();      
   guiContent.text = field.Name.SplitCamelCase();      
   object[] descriptions = 
      field.GetCustomAttributes(typeof(DescriptionAttribute), true);

   if(descriptions.Length > 0)
   {
      //just use the first one.
      guiContent.tooltip = 
         (descriptions[0] as DescriptionAttribute).Description;
   }

   return guiContent;
}

Note that it uses an annotation in your class code to generate a tooltip in the inspector.

3. Define new Custom Editors

Unfortunately, you will still need to define a class for each MonoBehaviour. Fortunately, these definitions can be empty; all the actual work is done by the base class.

[CustomEditor(typeof(MyClass))]
public class MyClassEditor : BaseEditor<MyClass>
{}

In theory this step can be automated, but I have not tried it.

Firstly, you need Artist Goggles. These art-tinted lenses directly affect the quality of your work by allowing you to look at your own and other people’s work and see what could make it more beautiful. They are also what all other artists will judge you by, and have a direct and overwhelming influence on your art portfolio — the key to getting yourself a job in the front lines! A sound knowledge of art principles, a great visual library, and having a thousand pieces of art to your name will keep your Goggles crystal clear.

You’ll also need the Map of Contraints. This map allows you to check whether your art can fit into a game on a technical level. As a game artist, your work needs to run in a game engine where lots of things need to be shown in real-time. Knowing how to optimize your art for games means freeing up resources that can be used for even more art, special effects, and other eyegasmic goodness.

Lastly, you’ll need Design Slippers, gained from the experiences of playing, studying and building game worlds. You’ll want to have thought about design, and how your art can help to craft great game experiences.

I want me those Art Goggles!

You upgrade your Art Goggles by gaining Art XP, which you earn by making art. It doesn’t really matter what kind of art you’re making, in any medium, as all art will improve your Art Goggles. However, some activities will earn you an XP BOOST. The most basic and most powerful one is drawing. Drawing teaches many art fundamentals that are vital to your XP growth, including (but not limited to!): gesture (the energy!), value (contrasts of light and dark), texture (what materials things are made of), form (describing things you’ve observed in the real, 3D world, on a 2D canvas, and using lighting and shading to get things looking good) and composition (how these all tie together).

Painting‘s also a great thing to learn, as it requires all of the above, but adds the concept of colour: how they work together, and how they (together with lighting) control the mood of your game.

Photography‘s also a great skill, often undervalued. Everything we see is made up of light, so studying how light behaves, different light setups for different situations and for bringing out the best of your subject matter, and how lighting can be used in composition are especially vital for environment work.

Sculpting is also a great skill, particularly if you’re interested in being a 3D game artist.

While you may want to jump right into learning software, it’s a good idea to learn art independently to (and before) learning software. Learning software can be frustrating and slow your Art XP growth. You may find yourself spending more time trying to figure out how to do things using digital media than polishing your Art Goggles, so your work may end up looking shoddy, and you may not know why. While you’ll probably need to learn some software somewhere along the line, it shouldn’t be the focus of your efforts. Traditional media provide a more direct way of upgrading your Art Goggles.

Lastly, you’ll also want to grow your visual library. This means watching documentaries, reading books and being interested in the world around you. These are akin to allowing your Goggles to see a wider spectrum of colours. If you’ve studied anatomy, you can use that knowledge in your characters. If you’re a fan of WW2 weapons, you’ll make much more convincing guns. Having a great visual library means you don’t need to search for reference images as often (because you’ve got them in your head), and you’ll have lots of ideas to draw from (lolpun) when you’re making your game art.

I want to make digital work!

The software you learn should match the studios or teams you wish to join. In South Africa, Softimage (also called XSI) has a massive hold in the vast majority of 3D studios in film and advertising. If there isn’t enough game art work (our industry is still small, although growing) it will be really easy to transition to offline rendering jobs. (It’s generally quite easy to move from games to another 3D industry, because you’re working with fewer constraints; it’s generally harder to move the other way around. There are exceptions.) 3ds Max is very popular in the visualization industry (product viz, arch viz). Maya has rapidly grown into an immensely popular package overseas because of it’s great toolset and extensibility in character animation, but only a handful of studios use it locally. Blender is free, and competent. ZBrush and Mudbox are widely used for sculpting and texture painting. You’ll also need a 2D app for painting textures for your 3D assets.

For 2D, Photoshop is by far the dominant software. However, most 2D programs can also handle Photoshop files, and there are far fewer issues with file compatibility in 2D than there is in 3D programs. You can probably get away with using whatever you’re comfortable with.

Many of the above software have educational versions (some of which are free) if you’re registered at a recognized school. If not, the free, open source stuff is great for learning, and once you’ve mastered them, switching to one of the others only takes a couple of weeks.

However, realize that if your Art Goggles are poorly maintained, your work will suffer tremendously regardless of what software you use. Although teams may build their own tools specific to the games they’re working on, there are only ever “magic buttons” for working faster — there are none that will make your art look better. It’s a good thing to be familiar with several packages, but it’s a great thing to be a specialist with at least one. Learning another package when one is already highly proficient with one already is a breeze.

I want to study!

There are a few things you should think about before signing up to any ol’ 3D/art course. Firstly, realize that no school (to my knowledge) will teach you everything you’ll need to know when you’re working. It’s important to take an honest look at yourself, and see what you really want to get help with, and then look at what it is each school offers. Is it important to have a degree? (While this helps with work visas and emigration, the degree itself matters very little compared to your portfolio. Having options is nice though.) Are you looking for software training? Are you looking for help with upgrading your Goggles? (Most 3D courses seem to focus on the former, although a handful of courses do emphasize the importance of drawing.) Look at breakdowns of courses and see which needs they’re meeting.

Look at who’s lecturing the course. While you can get some mileage out of someone who’s really good at lecturing but has no real industry experience, I believe you can get much more out of someone who’s got industry experience but is a poor lecturer. You’ll have to work harder to get all the information you want, but at least the answers you’re getting are tried and tested. If a course description doesn’t mention who the lecturer is, that should be a big red flag.

Look for past students’ work, and consider whether their work is better than you could do on your own. Ask about past students finding work in the game industry. (If you’re given names and names of studios, think about tracking down their details and asking them about the course.) Ask them, out of interest, how much of what they know came from the content the school covered, and how much they had to teach themselves.

Look for opportunities to intern. If it’s a good studio with artists that have been making game art for a few years, simply watching them work for 15 minutes a day will teach you countless methods of making assets faster, using not-so-obvious tools you may not have noticed before, workarounds to problematic software problems, how artists and programmers interact and how you would fit in in a game dev environment, and many other gems that you’re extremely unlikely to learn about in a school environment.

Finally, it definitely is possible to teach yourself everything you need to know without spending a fortune (if you spend some  time interning too). Tutorials and software training given by globally respected industry pros can be purchased from many online stores. (Some good ones include The Gnomon Workshop, Eat3D and, if you’re an absolute beginner, DigitalTutors.) Realize that polishing your Goggles daily should be something you crave (I must draaaaw! Something like the MakeGamesSA Sketch group may encourage you).

Feedback from industry veterans is also vital. (I highly recommend getting feedback and seeing what other people do on Polycount, where large number of members are working professionals, and there’s a culture of honest critique.) Even if you do attend a school, all of these self-teaching tools will help to push you even further, and are highly recommended.

That said, schools are useful though, for networking, for having deadlines that encourage discipline, for traditional art classes (if they offer this), and for being pushed to do things you wouldn’t normally be comfortable with that ultimately improve your versatility as an artist (mileage also varies per school). Having your own “style” is great if you’re pursuing fine art. However, having your own style because you can’t do anything else limits your usefulness as a production artist enormously. Good art schools don’t allow you to make the “but that’s my style” excuse. If you’re going the self-taught route, recognize these weaknesses and find ways to make up for them.

I want a game art job!

You nee a portfolio! Every employer, whether they’re an indie group or a giant corporation needs to see evidence that you can pull off the work that they’ll need you to be able to do. Make sure your portfolio matches the kind of studio you’re heading to, whether it’s pixel art, digital paintings or 3D. Some quick and dirty tips about putting together a portfolio:

• Only include your best work. It’s better to have one truly stellar piece of work than a lot of mediocre work.
• If you know which studio you’re trying to get into, make work that is relevant to them. You should be able to hold your work up next to a shot of one of their games, and honestly tell yourself that your work would easily fit there, and look just as good, or better.
• Answer questions with your work. (Example questions might include: Does this person understand lighting? Does this person understand anatomy? Will this person be able to create good quality work on a tight deadline? Does this person understand the constraints of getting her work into a game engine? Answers to these questions might include full environment pieces, anatomy studies, competition entries and captures from a real-time renderer, respectively. Which questions you prioritize depends on what kind of artist you want to be.)

Also realize that the majority of positions are filled by referrals or word-of-mouth. It’s a really good idea to be involved in game communities, to show work regularly, to take feedback and critique professionally (regardless of how savage the feedback might be), and to be the person that people think of when a position pops up. Don’t be isolated, or nobody will even know you’re keen for a job.

Further reading

• The Polycount wiki.  Many of these FAQs are answered there in more detail.
• The ConceptArt wiki. Awesome for those wanting to improve their Art Goggles.

Local schools

A comprehensive list of art/3D/animation schools in South Africa can be found at AnimationSA. I’m making no recommendations — but it’s probably a good idea to filter them using the stuff in this article before you sign up.

Header image

http://ambassadormann.deviantart.com/art/Steampunk-Goggles-11-1-166924592

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 playing 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.

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/.