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.

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.
• With suitable parameters, 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.

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

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.

That’s great! You’ll be flinging digital paint and shooting vertices, and making the game art world more beautiful as you go! But wait — a word of advice before you jump on the realtime rendering railway: you need three pieces of essential kit!

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

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

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

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

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

What a loophole is

If something can be abused, it will be.

— Hyrop’s Law of Loopholes

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

[Fullerton, Game Design Workshop]

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

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

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

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

Related Concepts

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

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

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

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

Examples of loopholes

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

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

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

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

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

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

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

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

More examples:

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

Image from xkcd.com/115

Why loopholes are bad

According to Adams, gameplay is

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

Loopholes interfere with both these aspects of gameplay.

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

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

There are two additional reasons why loopholes are bad.

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

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

General types of loophole

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

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

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

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

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

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

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

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

There are two ways to fix this:

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

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

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

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

Hustling is when a player exploits the dynamic difficulty adjustment of a game by 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.

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

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

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

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

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

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

Narrative

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

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

The fourth wall

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

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

Sounds in games

We can now ask ourselves two questions about any sound:

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

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

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

Diegetic sound

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

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

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

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

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

Non-diegetic sound

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

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

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

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

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

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

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

Meta representations

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

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

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

Spatial representations

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

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

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

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

Links

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

Thanks

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

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

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

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

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

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

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

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

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

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

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

Alicia: I agree.

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

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

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

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

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

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

Did you learn anything about the production side of things?

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

Yes.

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

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

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

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

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

Would you have like to do more prototypes or less?

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

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

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

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

Alicia: Definitely.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks for the interview!

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

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

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

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

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

It’s not always about the money

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

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

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

What is special about games?

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

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

And those that put up with this?

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

So what are the benefits of being a game developer?

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

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

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

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

What to do about crunch

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

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

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

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