Related posts:

1. Funding for start-ups evaporating The recent economic recession, having mostly had little effect on...

Related posts:

1. Latest Game Career Guide challenge results I’m going to assume you know about Game Career Guide...
2. Top skills to become a game developer: what South African developers say South African game developers share what skills they think are...

Related posts:

1. Minimised game design for indies When you sit down to write a book, one of...
2. Your ideas don’t matter … much ...
3. Board Silly (Tabletop Game Design) Two Dev.Mag writers share their board game design experiences: conception,...
4. Video game user interface design: Diegesis theory In this article, the Dave Russell introduces the basic concepts...

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

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

1. Choose a visual theme

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

2. Make a list

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

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

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

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

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

Specific items:

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

General items:

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

3. Make a rough layout

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

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

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

An example of the rough layout of an entire level.

4. Make rough sketches for the specific items

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

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

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

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

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

Examples of rough sketches

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

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

5. Make a detailed layout

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

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

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

An example of a detailed layout.

The locations of the specific items on the detailed layout.

6. Build the initial layout

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

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

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

7. Play the level

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

Changing the layout may include the following:

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

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

8. Decorate the level

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

Further Reading

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

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

Level Design Lessons (Anna Anthropy)

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

Related posts:

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

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

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

Common Errors

Some mistakes that are easy to make:

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

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

Implementation Tips

1. Use a non-square image to test

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

2. Implement linear interpolation first

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

3. Save interim images to file

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

When Things Go Wrong

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

1. Check your smooth noise images

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

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

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

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

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

a. Check the blend factors

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

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

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

For vertical_blend:

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

For horizontal_blend:

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

b. Check your sample points

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

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

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

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

3. Check that your smooth noise is blended correctly

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

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

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

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

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

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

Related posts:

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

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

Calculating curve length

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An example of Bézier interpolation.

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

An example of Bézier simplification.

Bézier interpolation

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

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

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

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

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

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

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

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

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

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

Bézier simplification (Quick and Dirty Method)

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

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

The algorithm to perform step 1 works as follows:

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

Here is the code:

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

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

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

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

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

I based the approximation above on the following reasoning:

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

The final algorithm is this:

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

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

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

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

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

Downloads

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

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

Related posts:

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

Over the last month or so, Dev.Mag has published five interviews with indie developers discussing puzzle game design. In case you have missed the series, here are links to the articles:

• Introduction
• Rob Jagnow (Cogs)
• Guy Lima (Continuity)
• Ted Lauterbach (suteF)
• Dave Hall (Q.U.B.E)
• Teddy Lee (My First Quantum Translocator)

In this article, I give you my take on the info we gathered in our five puzzle design interviews; a kind of distillation of the various ideas the designers presented. The discussion below is terse with almost no examples; to see how these ideas play out in the design of actual games, you will find the original interviews more helpful.

I chose the games for our series to be what I called “combinatorial puzzles” (an ugly term, a colleague informed me in a friendly email. I agree – if you have a better word, please share!). Puzzle games that make it easy to see how the designer takes core mechanics and put them together into a cohesive, compelling playing experience.

In the introduction article I have said that some principles of puzzle game design apply to all games. Replace “puzzle” with “level” (or other suitable game-playing unit), and the advice offered on selecting mechanics, training the player, handling difficulty and progressions, and playtesting can also be used for more general game design.

What is a good puzzle?

“I feel like when we design something clever,
players enjoy it just as much as we do.” – Teddy Lee

Minimally, a good puzzle:

• has clear rules;
• has a clear objective;
• finds the balance between too easy and frustrating, to make an interesting challenge.

On top of this, an interesting puzzle can be a puzzle that:

• stumps the player for a long time, but whose solution looks obvious once found;
• uses the mechanics in unexpected ways;
• has multiple solutions;
• allows a tiered system so that beginners and novices can play at different difficulty levels.

In puzzle games, puzzles can’t be judged in isolation. Each puzzle should be judged taking into account its role in the sequence of puzzles in the game. For example, a training puzzle will only be good if it occurs in the right place in the game. See difficulty and Progression below for more on this aspect.

Process

“I’ll tweak and tweak until it feels… right.” – Ted Lauterbach

Different designers follow different (although similar) processes to design their games. Here are a few general notes about the design process:

• Design lots of puzzles, and don’t be afraid to throw some away.
• Focus on gameplay, not engine design.
• Designing puzzles before building them (using paper, Excel, or Photoshop) can help to make levels tight and focussed. Designing on paper might not work for all games, in which case prototyping in the engine is a better strategy.

Design using a prototype.

Design using Excel.

Design using Photoshop.

• It’s a good idea to start with the goal, and then insert the elements the player will need to get to the goal, and obstacles that will make it more difficult.
• Consider whether you should add decoys in your game. Decoys can make puzzles more challenging, but can also become unnecessary filler.
• Remove misleading paths (such as the impossible jump that looks possible).
• Test and iterate (see below for notes on playtesting).
• Polish and refine your gameplay.

Mechanics

At the heart of a puzzle game (any game) is the basic rules of the game, the basic actions a player can take.

• Limit the number of mechanics. This lets you focus on:
  • level design;
  • interesting uses for mechanics;
  • polishing mechanics to extract the maximum amount of fun from them.
• Choose flexible mechanics. A handy rule of thumb of Teddy Lee: if you can initially think of five puzzles with a mechanic, chances are you will be able to think up a lot more later on. If you can’t, it probably means the mechanic is too brittle for making many interesting puzzles.
• Use them in the maximum number of ways: explore all their aspects and consequences. You need to know your mechanics inside out.
• Combine mechanics to get emergent gameplay (tricks).
• Reuse mechanics and tricks, but don’t reuse puzzles, otherwise you risk boring the player.
• Stagger themes and techniques to make the overall experience more interesting.

Training the Player

To solve a puzzle, the game must teach the player the rules and the strategies available.

• No one reads, or wants to read, a tutorial.
• Introduce core mechanics in isolation. Teach hard-to-see techniques by making it the only thing the player can do.
• Anticipate misunderstandings and encourage the player to fail and so clear up these misunderstandings early in the game.

The player is encouraged to jump of the ledge to discover the infinite loop that will require a level restart.

The only thing the player can do is jump, and then freeze mid-jump while re-arranging the tiles.

• Control difficulty (see below).
• Ensure the things the player will use to solve the puzzle are easy to see – reduce visual clutter.
• One technique that is especially helpful for illustrating manoeuvres in platform puzzlers is a helper character (perhaps a ghost) to illustrate the actions.
• In cases where dexterity is required, provide visual markers to help the player take precise jumps and other actions.

Difficulty and Progression

The theory of difficulty is straightforward:

• Start with simple puzzles, and make puzzles progressively more difficult and complex.
• Use staggering difficulty or “breather” puzzles to help build confidence and keep the player motivated. After a difficult puzzle, give the player an easy puzzle or two to allow a mental break.
• Let the player know when they are close to the end, especially when the entire playfield is not visible.

Examples of different difficulty profiles for a sequence of 12 puzzles.

The practice of difficulty design is harder.

• The only sure way to judge the difficulty of a puzzle is to playtest it.

Playtesting

“Sometimes players will not realise something that I thought was quite obvious.” – Dave Hall

“You’d think after failing, people would try a different approach,
but they often don’t.” – Guy Lima

“It’s not because they’re stupid;
it’s because you’ve lost perspective.” – Rob Jagnow

This is possibly the most important step in creating a good puzzle.

• Playtest early and often.
• Playtest with people who have not played the game before.
• Keep quiet, or you won’t find out whether a puzzle is really too difficult:
  • don’t offer hints;
  • don’t ask questions.
• When player behaviour makes you cringe, it means there is a design problem you need to fix. Here are some ways to fix a problem:
  • provide more cues in the level;
  • remove distractions that mislead;
  • insert more levels before that puzzle to illustrate concepts;
  • remove steps from problem to solution;
  • cut the puzzle.
• Ask players afterwards about the puzzle and their experience.
• Gather statistics to help measure of difficulty.

What do you say?

If you have additional puzzle game design tips, please share them in the comments!

Related posts:

1. How are puzzle games designed? Ted Lauterbach Ted Lauterbach, creator of the eerie puzzle game, suteF, answers...
2. How are puzzle games designed? Rob Jagnow As part of our series of interviews on puzzle game...
3. How are puzzle games designed? Teddy Lee Teddy Lee (maker of My First First Quantum Translocater and...
4. How are puzzle games designed? (Introduction) This article gives some background information on puzzle games, and...
5. How are puzzle games designed? Dave Hall In this puzzle game design interview, Dave Hall from Toxic...
6. How are puzzle games designed? Guy Lima Dev.Mag talks to Guy Lima, one of the founders of...

More and more games are using dynamic physics to add to the gameplay or as a core element of the gameplay. Box2D is a popular and powerful physics library that is considered to be one of the best 2D physics libraries around. It is used by high profile games like Angry Birds and Crayon Physics Deluxe. This tutorial will focus on the Flash version of Box2D and assumes that you have basic experience with Flash and ActionScript 3. If you are new to Flash, check out Nandrew’s excellent Flash tutorial.

Getting Started

Box2D has been ported to a number of languages, and to make things confusing, there are a number of different Flash ports available on the Web. In this tutorial we’ll be using version 2.1a of Box2DFlash which is considered the most official Flash port of Box2D. Download Box2DFlash 2.1a for Flash 10 from the Box2DFlash website.

Extract the download, and copy the Box2D folder into the src folder of your project, like this:

Box2D Overview

There is a fair bit of terminology in Box2D that you need to know to understand how things work. The following diagram shows a top-down view of Box2D.

At the core we have a world that holds our entities and manages the dynamic physics simulations. These entities in our world are known as bodies, and a world can have 0 or more bodies. Each body consists of 0 or more shapes. A shape, such as a rectangle or a circle, is used for collision detection. Each one of these shapes is connected to the body through a fixture definition and adds properties such as density and friction.

Every body has a body definition to define properties such as position, type (dymanic, static or kinetic) and more. To create a body, you need the body definition and a reference to the world. The world has a convenient helper function to create bodies.

Hello Physics World

In this tutorial we are going to create this:

We will generate random shapes and let them free-fall. Some walls, a floor, and a few blocks will make up the environment. Let’s jump into the code.

package
{
  import flash.display.Sprite;
  import flash.events.Event;
  import Box2D.Common.Math.*;
  import flash.events.TimerEvent;
  import flash.utils.Timer;
  import Box2D.Dynamics.*;
  import Box2D.Collision.Shapes.*;

  public class Main extends Sprite
  {
    private var world:b2World;
    private var timestep:Number;
    private var iterations:uint;
    private var pixelsPerMeter:Number = 30;
    private var genBodyTimer:Timer;
    private var sideWallWidth:int = 20;
    private var bottomWallHeight:int = 25;

    public function Main():void
    {
      this.initWorld();
      this.createWalls();
      this.createStaticBodies();
      this.setupDebugDraw();

      this.genBodyTimer = new Timer(500);
      this.genBodyTimer.addEventListener(TimerEvent.TIMER, this.genRandomBody);

      if (stage) init();
      else addEventListener(Event.ADDED_TO_STAGE, init);
    }

  //...function definitions will go here

  }
}

To make things simple we’ll keep all our work in the Main class.

Our program will flow as follows: We initialize our Box2D world, we create some walls and a few static blocks with which our objects can interact, then we set up the debug drawing mode, and we add a timer for generating random bodies. Finally we initialize our game loop after the Box2D world has been added to the stage.

private function initWorld():void
{
  var gravity:b2Vec2 = new b2Vec2(0.0, 9.8);
  var doSleep:Boolean = true;

  // Construct world
  this.world = new b2World(gravity, doSleep);
  this.world.SetWarmStarting(true);
  this.timestep = 1.0 / 30.0;
  this.velocityIterations = 6;
  this.positionIterations = 4;
}

The world is the core of our Box2D environment. It holds all of our bodies and manages the physics simulations. We set the gravity, and we state that the world can stop calculating physics for bodies that have come to rest. A ‘warm starting’ tells the world that bodies must start off active. If this was false, the bodies would have stayed put until they were woken up or until something collided with them. The timestep variable specifies how often the world should calculate the physics (in this case, every 1/30 seconds, or 30 Hz – thirty times a second). The iterations determine how many times per time step to calculate the position and the velocity of a body before moving on to the next one in the queue, the trade-off being performance versus accuracy.

private function createWalls():void
{
  var wallShape:b2PolygonShape = new b2PolygonShape();
  var wallBd:b2BodyDef = new b2BodyDef();
  var wallB:b2Body;

  wallShape.SetAsBox(
    sideWallWidth / pixelsPerMeter / 2,
    this.stage.stageHeight / pixelsPerMeter / 2);

  //Left wall
  wallBd.position.Set(
    (sideWallWidth / 2) / pixelsPerMeter,
    this.stage.stageHeight / 2 / pixelsPerMeter);
  wallB = world.CreateBody(wallBd);
  wallB.CreateFixture2(wallShape);

  //Right wall
  wallBd.position.Set(
    (this.stage.stageWidth - (sideWallWidth / 2)) / pixelsPerMeter,
    this.stage.stageHeight / 2 / pixelsPerMeter);
  wallB = world.CreateBody(wallBd);
  wallB.CreateFixture2(wallShape);

  //Bottom wall
  wallShape.SetAsBox(
    this.stage.stageWidth / pixelsPerMeter / 2,
    bottomWallHeight / pixelsPerMeter / 2);
  wallBd.position.Set(
    this.stage.stageWidth / 2 / pixelsPerMeter,
    (this.stage.stageHeight - (bottomWallHeight / 2)) / pixelsPerMeter);
  wallB = world.CreateBody(wallBd);
  wallB.CreateFixture2(wallShape);
}

Now we create walls, so that our objects stay within the desired area. If you remember the diagrams above, we need to follow a number of steps to create a body.

The values and calculations in the code sample may look a bit verbose, but I designed it that way to show you how things work.

To use distance units in Box2D, you need to understand these key points:

Measurements are in metres. However, beware: a 1 pixel : 1 metre ratio will be very computationally intensive, and there will be no way to represent the distance from one pixel to the next on screen, since pixels are directly next to each other. It’s best to use the following equations:

box2DMeters = pixels / pixelsPerMeter
pixels = box2DMeters * pixelsPerMeter

The origins of Box2D bodies are in their centres. This means that the distance between one body and another is actually the distance between their centres. This also means that we need to pass half of the width and half of the height as the dimensions of the shape, because the shape is created from its centre outwards.

Now that that’s cleared up, let’s break down the creation of the left wall.

wallShape.SetAsBox(
  sideWallWidth / pixelsPerMeter / 2,
  this.stage.stageHeight / pixelsPerMeter / 2);

To set the dimensions of the wall shape, we divide the desired width of the wall by pixelsPerMeter to convert it into metres, and then we divide that by 2 to get half of the width. We use the same idea for the height.

wallBd.position.Set(
  (sideWallWidth / 2) / pixelsPerMeter,
  this.stage.stageHeight / 2 / pixelsPerMeter);

The next step is to set the position of the body. The wall is on the left, so the base x co-ordinate will be 0. We then add half the width of the wall – remember that the origin is in the centre – and then we convert the coordinate into metres. We want the y co-ordinate of the wall to be in the centre of the world, so we halve the height of the stage and then convert to metres.

wallB = world.CreateBody(wallBd);
wallB.CreateFixture2(wallShape);

The body is created and added to the world. We then attach the shape to the body using a fixture.

private function createStaticBodies():void
{
  var blockBody:b2Body;
  var blockBd:b2BodyDef = new b2BodyDef();
  var blockShape:b2PolygonShape = new b2PolygonShape();
  var rectHeight:int = 30;  

  //Create a stack of static rectangular bodies for our randomly
  //generated bodies to interact with.

  blockBd.position.Set(
    this.stage.stageWidth / 2 / pixelsPerMeter,
    (this.stage.stageHeight - this.bottomWallHeight - (rectHeight / 2))
          / pixelsPerMeter);
  blockShape.SetAsBox(320 / pixelsPerMeter / 2, rectHeight / pixelsPerMeter / 2);
  blockBody = world.CreateBody(blockBd);
  blockBody.CreateFixture2(blockShape);  

  blockBd.position.Set(
    this.stage.stageWidth / 2 / pixelsPerMeter,
    (this.stage.stageHeight - (this.bottomWallHeight + rectHeight)
          - (rectHeight / 2)) / pixelsPerMeter);
  blockShape.SetAsBox(240 / pixelsPerMeter / 2, rectHeight / pixelsPerMeter / 2);
  blockBody = world.CreateBody(blockBd);
  blockBody.CreateFixture2(blockShape); 

  blockBd.position.Set(
    this.stage.stageWidth / 2 / pixelsPerMeter,
    (this.stage.stageHeight - (this.bottomWallHeight + 2 * rectHeight)
          - (rectHeight / 2)) / pixelsPerMeter);
  blockShape.SetAsBox(140 / pixelsPerMeter / 2, rectHeight / pixelsPerMeter / 2);
  blockBody = world.CreateBody(blockBd);
  blockBody.CreateFixture2(blockShape);
}

The function above creates a few static rectangles that the randomly generated bodies can bounce off of. Again, the equations are verbose to help you remember that that a shape’s origin is in the centre. We use half the width and half the height, and we need to pass the values through in metres.

private function setupDebugDraw():void
{
  var debugDraw:b2DebugDraw = new b2DebugDraw();
  var debugSprite:Sprite = new Sprite();

  addChild(debugSprite);
  debugDraw.SetSprite(debugSprite);
  debugDraw.SetDrawScale(30.0);
  debugDraw.SetFillAlpha(0.3);
  debugDraw.SetLineThickness(1.0);
  debugDraw.SetFlags(b2DebugDraw.e_shapeBit | b2DebugDraw.e_jointBit);
  world.SetDebugDraw(debugDraw);
}

This tells our Box2D world to draw debug information on the bodies. This allows us to see the joints and shapes of the bodies. It also shows us when a body goes to sleep by changing its colour; the colour changes back again when it wakes up.

private function init(e:Event = null):void
{
  this.removeEventListener(Event.ADDED_TO_STAGE, init);
  this.addEventListener(Event.ENTER_FRAME, update);
  this.genBodyTimer.start();
}

Our setup is almost complete! We start the game loop and start a timer to generate random bodies.

private function genCircle():void
{
  var body:b2Body;
  var fd:b2FixtureDef;
  var bodyDefC:b2BodyDef = new b2BodyDef();
  bodyDefC.type = b2Body.b2_dynamicBody; 

  var circShape:b2CircleShape
     = new b2CircleShape((Math.random() * 7 + 10) / pixelsPerMeter);

  fd = new b2FixtureDef();
  fd.shape = circShape;
  fd.density = 1.0;
  fd.friction = 0.3;
  fd.restitution = 0.1;
  bodyDefC.position.Set(
    (Math.random() * (this.stage.stageWidth - sideWallWidth - 20)
         + sideWallWidth + 20) / pixelsPerMeter,
    (Math.random() * 80 + 40) / pixelsPerMeter);
  bodyDefC.angle = Math.random() * Math.PI;
  body = world.CreateBody(bodyDefC);
  body.CreateFixture(fd);
}

private function genRectangle():void
{
  var body:b2Body;
  var fd:b2FixtureDef = new b2FixtureDef();
  var rectDef:b2BodyDef = new b2BodyDef();

  rectDef.type = b2Body.b2_dynamicBody;

  var polyShape:b2PolygonShape = new b2PolygonShape();

  fd.shape = polyShape;
  fd.density = 1.0;
  fd.friction = 0.3;
  fd.restitution = 0.1;
  polyShape.SetAsBox(
    (Math.random() * 16 + 20) / pixelsPerMeter / 2,
    (Math.random() * 16 + 20) / pixelsPerMeter / 2);

  rectDef.position.Set(
    (Math.random() * (this.stage.stageWidth - 2 * (sideWallWidth + 20))
         + (sideWallWidth + 20)) / pixelsPerMeter,
    (Math.random() * 80 + 40) / pixelsPerMeter);

  rectDef.angle = Math.random() * Math.PI;
  body = world.CreateBody(rectDef);
  body.CreateFixture(fd);
}

These functions create randomly sized and positioned circles and rectangles. All the bodies we created before (the walls, the floor, and the blocks) were static. This means that they have zero mass and zero velocity, and that we can move them only manually. For the rectangles and circles, we want dynamic behaviour. We want these bodies to bounce around and be all physics-like, so, we set the body type to dynamic, which means that it has a positive mass and that it has a non-zero velocity that is determined by forces in the world, such as gravity.

private function genRandomBody(e:TimerEvent):void
{
  var bodyType:Number = Math.random();
  (bodyType < 0.5) ? this.genCircle() : this.genRectangle();
}

We randomly generate a circle or a rectangle in the air (see the code above) that will free-fall.

private function update(e:Event = null):void
{
  world.Step(timestep, velocityIterations, positionIterations);
  world.ClearForces();
  world.DrawDebugData();
}

And finally, we have the game loop. We tell the world to take a step, with values for the simulation frequency and the number of times per time step to calculate the velocity and the position of each body. Box2D requires us to clear the forces after every step so that things are cleaned up for the next step of the simulation. Then we draw the shapes and other debug information.

That’s it! We now have a world filled with bodies that exhibit dynamic, real-time physics. Now that we have all the basic pieces together, there are a number of things to try next. How about setting up a stack of dynamic blocks you can shoot balls at? Or how about creating a number of shapes and attaching them to the same body? Have fun experimenting, and share your ideas and thoughts in the comments.

Download

The source code for this project: Box2D_DevMag_Tut.zip (370 KB).

Further reading

• There are some useful nuggets in the Box2DFlash FAQs, and a heap of useful information can be found in the API Documentation.
• Also read an interesting and in-depth tutorial on how to create a Peggle clone in Box2D.
• The World Construction Kit is a powerful toolset for creating Box2D games in the Flash IDE.

Related posts:

1. Bézier Curves for your Games: A Tutorial A Bézier curve is a type of curve that is...

Teddy Lee (from Cellar Door Games) created several popular flash games, among them the platform puzzler My First Quantum Translocator (MFQT), the infamous adventure puzzle game Don’t Shit Your Pants, and recently I Have 1 Day, an adventure puzzle game with an interesting meta task-scheduling puzzle on top.

In My First Quantum Translocator the player is trying to escape from a building, assisted by the mysterious Steve and of course a quantum translocator. The translocator can be used to teleport instantly from one position to another one previously set up, while maintaining momentum. Impassable, moving lasers and platforms that are too high to reach by jumping make up some of the difficulties the player has to overcome. In addition to brainpower, the game also requires some skill in performing the jumping and timing actions to execute solutions.

My First Quantum Translocator was one of Indie Games’ selection of top 10 free puzzle games of 2010.

Below, Teddy Lee responds to our questions (part of our puzzle game design interview series).

Dev.Mag: What are the qualities of a good puzzle?

A good puzzle to me is when the designer uses the core mechanic in ways players don’t expect. I feel like when we design something clever, players enjoy it just as much as we do.

Dev.Mag: What process do you follow to design puzzles?

When we made puzzles for My First Quantum Translocator (MFQT), we had a few guidelines which we tried our best to follow.

1. Never re-use puzzles

If two stages were too similar, we would can one of them. It makes things difficult since you’re always trying to do something new, but the end results are always worth it. We found that starting with the solution and then going backwards worked well for us.

A lot of our stages were originally designed in an Excel doc before being put into the game.

2. Each room highlighted one trick, or mechanic

If you add too many steps to a puzzle you lose the player because you can’t always assume the player is following your train of thought.  We also removed any filler/time wasters/red herrings in order to keep this visual clutter to an absolute minimum (unless the puzzle itself was a red herring).

3. Do not have any “Misleading Paths”

This means that if our player is doing a puzzle incorrectly, they should immediately know they are doing it wrong.

For example, if you are playing a platformer, and the user is always just millimeters away from making a jump, then the user might keep trying to make that impossible jump. So we spent a lot of time trying to remove every possible instance of a “Misleading Path”.

4. The joy in solving a puzzle games is in the success, not the attempts

The core mechanics for MFQT required a certain amount of dexterity on the player’s behalf, but we tried our best to keep it to a minimum while still retaining the core feel of the stages.

For example, we added the “tele-jump” later in the game which automatically jumped and teleported the player. That way they no longer had to pull off that difficult maneuver.

In one of our more skill-based levels, we revamped the bottom right junction and stretched the upper platforms.

Old level.

New level.

Dev.Mag: In a sequence of puzzles based on a small set of mechanics, how do you make sure the puzzles stay interesting?

The misconception is that having a small set of mechanics means you’ll be very limited in the things you can do. That’s not necessarily the case though.  As long as you can keep wringing out new puzzles from the core mechanics, then the game will stay interesting.

A rule of thumb I follow is if I can think up five or more puzzles on paper with a single mechanic, then there’s a good chance I can come up with plenty more later on.

Dev.Mag: How do you judge whether a puzzle is fun, and how difficult it is to solve?

It’s impossible to know off the bat whether a puzzle is fun or not.  The only thing you can do is playtest it, and if you like it, have someone else playtest it and see if they like it.  If we don’t enjoy completing a level though, we usually look at it and see what’s not fun about it. That way we won’t make the same mistake again.

As for difficulty, we generally base that off of how much dexterity is required to complete a stage, and how much of the stage’s puzzle is built off of previous knowledge.  Of course, extensive playtests from other people help us isolate the trouble spots.

When designing MFQT, we also staggered puzzles which had a similar theme (such as modifying trampoline bounce height) so that players wouldn’t get similar puzzle types in a row. We also staggered the difficulty, so that after a particularly difficult stage, a player might bump into a few easy ones to sort of keep their morale high. Small things like that helped to keep the game fresh.  We had to tweak the stage layout for our game a couple of times to get it to where it is.

One of our regrets with MFQT was the second last level (the rotating squares with the red cross). I really liked the level, but in the end a lot of people couldn’t complete it.  Even though we had a skip button, nobody really wanted to use it, especially when they were so close to the end.

This image shows how levels have been re-arranged over time. Click on it for a larger view.

Dev.Mag: Do you use strategies in your design to guide the player towards the solution, and help them understand the logic of the puzzles?

When we design a puzzle, we try to keep visual clutter to minimum so as to not distract the player from the actual goal.

Also, when the solution requires a certain amount of dexterity, we sometimes leave visual “markers” so that players know where to position their attempts. For example, in our “elevator” stage in MFQT, we used 2 background assets as indicators to show the player when to jump, and when to set a shadow.  That way, when a player knows the solution, they have some type of marker they can compare themselves to in order to refine their solution.

Level with markers to help the player time actions.

Dev.Mag: Do you have any advice for those who want to design their own puzzles?

Make sure to iterate, refine, and polish your stages off. I feel like many designers making puzzle games think they can skip these steps since their games may require little to no dexterity. So you end up with all these physics based puzzle games, where the solution always end up being more about pixel perfect placement and less about clever solutions.

Oh, and if you run into problems with a level and things aren’t working out, don’t be afraid to cut. It’s always better to have someone beat your game than not.

Related posts:

1. How are puzzle games designed? Ted Lauterbach Ted Lauterbach, creator of the eerie puzzle game, suteF, answers...
2. How are puzzle games designed? Dave Hall In this puzzle game design interview, Dave Hall from Toxic...
3. How are puzzle games designed? Rob Jagnow As part of our series of interviews on puzzle game...
4. How Are Puzzle Games Designed? (Conclusion) A distillation of the five puzzle game design interviews, taking...
5. How are puzzle games designed? Guy Lima Dev.Mag talks to Guy Lima, one of the founders of...
6. How are puzzle games designed? (Introduction) This article gives some background information on puzzle games, and...

Dave Hall is one of the founders of Toxic Games, the studio that created the compelling first-person 3D platform puzzler Q.U.B.E. As part of our series of puzzle designer interviews, we asked Hall about the methods he used to design Q.U.B.E.’s puzzles.

In Q.U.B.E. (Quick Understanding of Block Extrusion), players find themselves trapped in a mysterious facility where the walls are made from countless white cubes. Through a weird device attached to the players’ arm, some coloured cubes can be extruded, and with a bit of thought, the player can arrange these to form a route to escape each level. The game was inspired by the student film The Room.

Q.U.B.E. was a nominated for the Best UDK Singleplayer indie of 2010, and it was a finalist in the non-professional category of the Indie Game Challenge.

http://www.youtube.com/watch?v=s21rMdmM0VA

Dave Hall answers our questions below.

Dev.Mag: What are the qualities of good puzzle design?

In a good puzzle the objective is always clear and it is easy for the player to understand the rules that the puzzle is based around. It should also be easy for the player to get started.

Dev.Mag: What Process do you follow to design puzzles?

I always start with the objective for the puzzle. For example; ‘how can I reach that platform?’ From there I think of the different ways that the player could reach that objective. In the early stages of development I would create a plan for each level on paper before creating anything in-engine.

However, it can be difficult to plan out every aspect of a puzzle because it doesn’t always work the same way in-engine. Now the first thing I do is create a prototype, then I test it and iterate on it until it works.

Solving a prototype puzzle.

Dev.Mag: How do you design a series of puzzles based on a small set of mechanics that keep the players interest?

When we introduce a new mechanic, we introduce it on its own so that the player can learn how different objects behave without having everything explained to them. Every puzzle in the game is based around the same set of rules. As the player progresses through the game they gain a better understanding of these rules, which allows them to complete more complex puzzles.

Dev.Mag: How do you judge whether a puzzle is fun, and how difficult it is to solve?

This is where playtesting is important. If a player gets stuck on a puzzle, then they may become frustrated and quit. Sometimes players will not realise something that I thought was quite obvious.

In other cases a puzzle will be designed to be completed a certain way, but some players will find another way to complete it. If you watch someone playing your game or ask them about it after they finish playing, you can find out what they enjoyed and if they were ever stuck, as well as other important information.

Dev.Mag: What devices do you use to guide the player towards the solution?

The objective should always be clear and the player should understand how each object functions. I always try to make it easy for the player to see everything they need to complete a puzzle. It is also good if the player knows when they are getting close to completing the puzzle.

Many of the puzzles in Q.U.B.E. are in stages. They start out simple so the player understands what they have to do. As they progress, each stage gets more complex, but is still based around the same rule-set.

Dev.Mag: Do you have any advice for those who want to design their own puzzles?

When thinking of new ideas for puzzle, always start simple and then build out from there. Make sure the objective is clear and the player understands the rules. It is also important to start testing as soon as possible. You may think you have a good idea , but you don’t really know until someone else plays it.

Related posts:

1. How are puzzle games designed? Ted Lauterbach Ted Lauterbach, creator of the eerie puzzle game, suteF, answers...
2. How are puzzle games designed? Teddy Lee Teddy Lee (maker of My First First Quantum Translocater and...
3. How are puzzle games designed? Rob Jagnow As part of our series of interviews on puzzle game...
4. How Are Puzzle Games Designed? (Conclusion) A distillation of the five puzzle game design interviews, taking...
5. How are puzzle games designed? Guy Lima Dev.Mag talks to Guy Lima, one of the founders of...
6. How are puzzle games designed? (Introduction) This article gives some background information on puzzle games, and...