(Original Image by Valerie Everett)

It is sometime necessary to move an object in a physics simulation to a specific point. On the one hand, it can be difficult to analyse the exact force you have to apply; on the other hand it might not look so good if you animate the object’s position directly.

A compromise that works well in many situations is to use a spring-damper system to move the object.

The trick is simple: we apply two forces—the one is proportional to the displacement; the other is proportional to the velocity. Tweaked correctly, they combine to give realistic movement to the desired point.

The spring force is proportional to the difference between the current position and the position where we want the object:

Here, is a positive value called the spring constant.

As you can see, the force gets smaller as our object approaches the desired position, and becomes zero when it reaches that position. Unfortunately, in the absence of friction or drag, the velocity is not zero at this point, so the object overshoots the desired position, and moves past it. The force becomes bigger, but in the opposite direction. The object keeps on moving, slowing down, and finally starts moving in the opposite direction towards the desired position. This goes on indefinitely.

When there is friction or drag, we might be lucky enough for the system to slow down the object sufficiently so that its velocity becomes zero when the object reaches the desired position. This can be tricky to accomplish, though, and might impact the simulation environment in undesirable ways.

It is better to add a counteracting force explicitly. We add a damper force that is propostional to the velocity of the object, again opposite in direction. Here is the viscous damping coefficient, also a positive number.

We then apply the sum of the forces to our object:

The trick is to choose to get the behaviour we want.

Fortunately, this is easy. The following table summarizes how the damping constant affects behaviour. Here, is the mass of the object.

	The object oscillates.
	The object oscillates, but the oscillations die down.
	The object moves to the desired position without oscillating in minimum time.
	The object moves to the desired position without oscillating, and takes longer as c increases.

If you want to see an explanation of how this works, see the Wikipedia article on damping.

By choosing , we are left with only one parameter to tweak (the spring constant), with which we can adjust the time it will take for the object to reach the desired spot.

A simple implementation of this idea is given by the following function. The function should be called for every simulation frame, until we are satisfied that the object reached its spot:

private void MoveTo(Rigidbody rigidbody, Vector3 newPosition,
      float springConstant)
{
  Vector3 desiredDisplacement = rigidbody.position - newPosition;
  Vector3 springForce = -springConstant * desiredDisplacement;

  float viscousDampingCoefficient
    = 2 * sqrt(rigidbody.mass * springConstant);

  Vector3 dampingForce
    = -viscousDampingCoefficient * rigidbody.velocity;

  Vector3 totalForce = springForce + dampingForce;
  rigidbody.AddForce(totalForce);
}

This will work even when there is drag or friction, except that the object will move slower (in this case we can decrease the artificial damping, although it is a bit risky). When there is an external force applied to the object, the object will come to rest at some point away from the desired position. By increasing the spring constant, the distance between this point and the desired point can be made smaller. Thus, we can also use this scheme to maintain objects at a certain height, for example, which can give a rather realistic simulation of a hovercraft or even a drifting object.

Update: This is an example of a PID controller (proportional–integral–derivative controller), for which there is a C++ implementation in my Special Numbers Library.

Related posts:

1. Cellular Automata for Simulation in Games
2. Random Steering – 7 Components for a Toolkit
3. Force Field Editor v1.0

(Original image by GoAwayStupidAI).

Below are four C++ implementations of the region quadtree (the kind used for image compression, for example). The different implementations were made in an attempt to optimise construction of quadtrees. (For a tutorial on implementing region quadtrees, see Issue 26 [6.39 MB zip] of Dev.Mag).

• NaiveQuadtree is the straightforward implementation.
• AreaSumTableQuadtree uses a summed area table to perform fast calculations of the mean and variance of regions in the data grid.
• AugmentedAreaSumTableQuadtree is the same, except that the area sum table has an extra row and column of zeros to prevents if-then logic that slows it down and makes it tricky to understand.
• SimpleQuadtree is the same as AugmentedAreaSumTableQuadtree , except that no distinction is made (at a class level) between different node types.

The interfaces of all quadtrees are the same, but I did not want to extend from a base class. (Instead, a compile time check is performed on the classes, using boost concepts).

The results of the performance (on my machine!) of the trees are as follows:

As it turns out, the different implementations do not differ significantly. Constructing the nodes takes long, and not so much the calculations necessary to determine whether a node should split or not, and what data should be in the node. Had I profiled properly before I started I would not have gone through this exercise…

Between these four implementations, the NaiveQuadtree is the one I recommend; I left in the other implementations for anyone interested.

The one good thing that came from this experiment is that I found out that using a zero-augmented summed area table can increase performance quite a bit. This is useful for max-filters and other algorithms that use these tables.

You can download the source code:

Quadtree.zip (44 KB, Visual Studio).

(It requires the boost library for concept checking, but nothing else. Everything will still work if you remove all references to the boost library. If you already have boost, just hook up to the include path in Visual Studio).

…or read the online documentation.

Related posts:

1. Quadtrees
2. Quadtrees
3. A simple texture algorithm – faster code and more results

Many textures used for 3D art start from photographs. Ideally, such textures should be uniformly lit so that the texture does not interfere with the lighting applied by the 3D software. Often, lighting artefacts must be removed by hand. This can be tedious and time consuming.

The tool provided here aims to automate this process. It is still in an experimental phase, so it is very crude. Below you can see some of the before and after pictures.

I will say more about how these work in a later post.

If you want to give it a try, go here to download (caveats: command-line only; Windows only; requires ImageMagick.)

The tool can also improve artefacts in tileable textures:

BEFORE (distracting horizontal striping)

AFTER (reduced striping)

Related posts:

1. How to Turn XSI Mod Tool into a Level Editor for your XNA Games: Example Updated for XNA 3.0.
2. How to Turn XSI Mod Tool into a Level Editor for your XNA Games: Updated for XNA 3.0.
3. Guerrilla Tool Development

This post was a originally published on Luma Labs, now dead.

As old as stimulus-response techniques are, they still form an important part of many AI systems, even if it is a thin layer underneath a sophisticated decision, planning, or learning system. In this tutorial I give some advice to their design and implementation, mostly out of experience gained from implementing the AI for some racing games.

A stimulus response agent (or a reactive agent) is an agent that takes inputs from its world through sensors, and then takes action based on those inputs through actuators. Between the stimulus and response, there is a processing unit that can be arbitrarily complex. An example of such an agent is one that controls a vehicle in a racing game: the agent “looks” at the road and nearby vehicles, and then decides how much to turn and break.

This definition is so broad that it is hard to think of agents that are not stimulus response agents. Some agents base their actions not on inputs, but on their internal state alone. See for example how random steering algorithms can lead to interesting behaviour.

Some agents don’t act. They just digest. The only way they can be useful if we look at what they are “thinking”. In fact, they are often designed with the sole purpose of “telling” us what they think, and they are not usually called agents, but rather decision systems. A face recognition system is an example of this. Of course, if we consider “telling” or “deciding” an action, these decision system become stimulus response agents too – but since we do not think of them as agents, the distinction is useful.

Design

1. Do not design your system around an overly simplistic view

The typical presentation of a stimulus response agent looks like this:

This presentation, while technically correct, is suitable only for flowers blowing in the wind. A real-world stimulus-response agent might look more like this:

Note that there are five factors that influence decisions:

• Game state is the mode of the game. For example, when an agent can be in a PLAY state (actively competing against the player) or a CHILL state (after taking over from the player at the end of the game.
• Global world state is the current conditions of the world, such as the weather or time of day.
• Local world state is what is normally thought of as the “stimulus”. It is the properties of the world around the agent that changes as the agents moves or otherwise acts in the world. For example, the shape of the path near a path following agent is part of the local world state.
• Agent parameters constitute the fixed limits of the agent’s sensory processing, and reactionary systems. For example, how far can the AI see, how quickly will it react, and how high can it jump. These parameters often describe the bounds for a state variable.
• Agent state is the changing parameters of the agent’s behaviour.

Note that all these can be mapped to the simplistic view of our agent. However, it is important to recognise the differences in these groups of variables, because the agent is made aware of them (connected to them) in different ways.

The world state is not sensed, but communicated through passed parameters, or a query to the world state object.

The game state is enforced by the game system, and typically the agent does not query or sense the game state – it is communicated from the outside.

The local world state is sensed by the agent through its sensors. Typically this means the agent must have hooks into the world. This data can be noisy or incomplete, so the agent might use filtering, and hence will store its own processed copy of the data.

The agent parameters are partially hard-coded, and partially generated on construction, or read from a file. These do not change over the agent’s life time.

The agent state is calculated on updates. It has two parts:

• The discrete state is usually implemented as a state machine. In a vehicle driving agent, the discrete states can be PULL_AWAY, NORMAL, WRONG_WAY, and so on.
• The continuous state of an agent is the state determined by a set of parameters. For a vehicle driving agent, these can include “deviation_from_path”, “distance_from_closest_player”, “aggressiveness” and so on. Note that the continuous state for every discrete state can be described by a different set of parameters, possibly overlapping.In general, a different set of response equations will be used for every discrete state. In fact, the sole purpose of the state machine is to select the correct set of response equations for every situation.

The table below summarises the factors that influence a stimulus response agent’s decisions.

2. Clearly distinguish between objects that have state, and those that do not (or should not)

It is easy to build objects that have states when they should not. It is, for example, reasonable to design a path-following object so that it keeps track of an agent’s progress along the path (such as the last node reached), to simplify communication between the agent and the path. In this scenario, the communication looks like this:

There are at least two problems with this set-up:

• every agent must have its own copy of the path; and
• the agent can’t ask any path information that violates the path object’s assumption about where the agent is.

To illustrate the last point, consider the situation where the path keeps track of the last node reached by the agent, and updates that node as the agent reports its position to the path object. It uses this node and the next node to interpolate a suitable position for the agent to move to. All is fine, until the agent needs information about the future, for example, it’s projection one second from now on the path. One second from now, the agent may have reached another node, something this simple system cannot handle properly.

Another way to do this, is for the agent to store the last node reached and pass it along its position in queries:

This does not solve the problem really – must the agent now store a separate node for queries into the future?

The best solution is to have a path manager. It has two responsibilities:

• to store any agent state information relating to the path – the last node reached, in our example; and
• to handle calculations for queries (based only on data from the path).

Now, when the agent asks the path manager about its projection 1 second from now, the path manager can check against the path whether a node will be reached, and perform the correct calculation. [In practise, the agent will transform time into distance travelled in time at its current velocity, so that the path manager only needs to know about distance, not time].

Every agent must have its own path manager, but the path managers can share the same path.

Consider another, slightly different, example. A certain agent has a “angriness” factor, which is randomised every 10 updates between two fixed extremes. Every type of agent has a different set of extremes (a monster will have higher extremes than a cow, for example), which helps determine the agent’s “personality”. It is easy to dump the extremes and the current value in one object (typically, the agent object). This is a poor design for two reasons:

• There is unnecessary duplicated data, with the associated disadvantages (such as making network packets bulkier, making save files of the game state bigger, and so on).
• The distinction between of agent state and agent parameters gets muddy. This makes it easier to make mistakes, overcomplicate the design, and introduce unnecessary inefficiencies.

A better design is to put the extremes into an “angriness profile” object, which can be shared by agents of the same type; in the example there will be two instances, one for cows and one for monsters.

Note that this issue goes hand-in-hand with preferring composition over inheritance hierarchies.

3. Draw pictures to show the ideal response to a given stimulus situation

It is very important to define clearly what you want the agent to do given some stimulus. The following graphs shows a few examples for a vehicle steering agent.

Steering as a function of angular deviation from path.	Nitrous usage as a function of angular deviation from path (reckless driver).	Nitrous usage as a function of angular deviation from path (conservative driver).

Most variables will depend on more than one other variable. Do not worry too much about that when drawing these diagrams. Focus on typical cases, and jot down any requirements or assumptions.

Also, do not try to write down any equations for your graphs. Any relationship can always be represented by a response curve, something that is much quicker to set up and easy to implement. A response curve is essentially a look-up table with linear interpolation. It can be used to approximate arbitrary functions by specifying the input range, and a number of output samples. The idea is discussed more thoroughly in AI Programming Wisdom 1 (The beauty of Response Curves by Bob Alexander).

4. Draw System Diagrams to show how variables relate

In a complicated system, it is easy to lose track of how variables relate. A forgotten relationship can often lead to behaviour that is hard to understand. Having an easy-to-reference diagram will be a great help in debugging faulty behaviour.

The diagram above distinguishes between relationships under AI control, and relationships that are under physics control – i.e. Relationships that cannot be changed by the agent. The diagram also indicates whether a relationship is positive (i.e. more of the one will result in more of the other), or negative (i.e. more of one will result in less of the other).

5. Use a spreadsheet to graph response curves to typical situations

Once you have your equations, you have to make sure that they actually describe the curves you intend. Also, in complicated formulas, it is important to check how these curves behave on typical data sets – especially if you employ filtering (see below).

6. Eliminate unimportant feedback loops.

Feedback is important for proper control in most systems. However, every loop makes it more difficult to analyse and understand the system – something that becomes apparent when things go wrong. If your system is complex, try to remove some of the loops (by removing some of the dependencies). You can always complicate your system once you have it working.

7. Prototype your agent on a computer algebra system

A computer algebra system (CAS) is the perfect environment to prototype a stimulus response agent:

• The high-level syntax, dynamic variables, and fat libraries allows you develop designs quickly, so that you can try out more designs.
• The built-in graph plotting capabilities are useful for debugging (see below) and understanding complex designs.
• You can simulate scenarios that are hard to obtain in the actual game, leading to a design that is much more robust.

Filtering

8. Filtering input, output, and intermediate values can drastically improve behaviour

There are several reasons to use filtering in your agent:

• To reduce noise that might confuse your agent about the state the world (or it) is in.
• To smooth out (and hence fill in) incomplete data. For example, a path made of line segments can be “filtered” so that it appears smooth to the agent.
• To make the actions of the agent seem more determined. An agent that changes it’s mind 10 times a second is not very believable.
• To prevent abrupt reactions to changes in the world that will make the agent less believable.

There are several approaches to filtering. One approach that works well in many cases is to change a variable only by some maximum amount, like this:

updateFilteredX(x)
{
   filteredX += clamp(x – filteredX, -maxIncX, maxIncX);
}

Here maxIncX is much smaller than typical values of x (using a tenth is a good starting point).

When you have many filtered variables, it becomes unmanageable to filter them all in this way – for every variable you want to filter, you need three extra variables, and you need to remember to use the right updating technique whenever the variable changes. It is better to encapsulate the filtering in a special class (as has been done in the Special Numbers Library – see http://code.google.com/p/specialnumbers/).

Other approaches to filtering include:

• statistical filtering techniques, such as least squares and Kalman filtering;
• convolutional filters; and
• PID controllers.

9. Make your filtering technique frame-rate independent, and do it from the start

The rate of updates of filters can have a dramatic effect on resulting behaviour. This rate can either fluctuate naturally (as it goes with frame rate), or be the difference between a Debug and Release versions of your application.

The resulting changes in behaviour makes it hard to:

• debug faulty behaviour; and
• spot problems to begin with (because it always works fine on your machine!).

How you make your filtering frame-rate independent depends on the method of filtering used. For the system explained above, it merely means updating with an amount proportional to the elapsed time (between updates).

updateFilteredX(x, elapsedTime)
{
   filteredX += clamp(x – filteredX,
                -maxIncX*elapsedTime, maxIncX*elapsedTime);
}

The updateFilteredX function above will use a smaller value for maxIncX than the one that does not compensate for time. It is for this reason that you should implement frame-rate independence from the start. Otherwise you will need to re-tweak all your values increment values again.

10. Do not filter the channels of n-dimensional data separately

If you filter a position, for example, by the method described above, you might be tempted to do something like the following:

updateFilteredXYZ(point)
{
   filteredPoint.x += clamp(point.x – filteredPoint.x,
                               -maxInc, maxInc);
   filteredPoint.y += clamp(point.y – filteredPoint.y,
                               -maxInc, maxInc);
   filteredPoint.z += clamp(point.z – filteredPoint.z,
                               -maxInc, maxInc);
}

The above code will lead to strange behaviour. Consider for example,

• filteredPoint = (0, 0, 0),
• point = (2, 1, 0) (for the next 4 updates)
• maxInc = 0.5

The variable filteredPoint will now go through these values on the next four updates:

(0.5, 0.5, 0)

(1.0, 1.0, 0)

(1.5, 1.0, 0)

(2.0, 1.0, 0)

If this filteredPoint represents an agent trying to reach (2, 1, 0). Notice that the points do not lie in a straight line, the agent will first move to point (1, 1, 0), and then turn before moving further. An onlooker will not understand this strange behaviour.

The correct way to implement filtering for multi-dimensional data is to add a clamped amount of difference between the value and the filteredValue to the filtered value.

updateFilteredXYZ(point)
{
   updateAmount = clamp((filteredPoint – point).len(),
                        0, maxInc)
   filteredPoint += (point – filteredPoint) * updateAmount;
}

Now the next four values of filteredPoint lie in a straight line:

(0.316, 0.632, 0)

(0.632, 1.265, 0)

(0.948, 1.897, 0)

(1, 2, 0)

11. Beware of filtering that reduces the range of a variable

Some kinds of filtering can reduce the range of a variable – for example, instead of reaching zero, a variable may merely come close to zero. This is important in checks that assumes variables will come to a have certain value eventually – these checks must be modified to compensate for the range discrepancies.

12. Beware of accumulated latency when filtering variables through various layers of logic

Filtering usually results in some latency. Where filtering is used in a layered system, these latencies can add up, and produce a system that is slow to respond. In many situations these latencies can be reduced or eliminated if you can make accurate predictions about the future.

You can reduce the filtering by using it only where it is really important – not everywhere. You can also exchange smoothness for a quicker response. How you accomplish this depends on the method of filtering you use; in the filtering described above you can increase the value of the increment.

If you feel adventurous, you can try out a system that filters only after it becomes aware that it is necessary. For example, the amount of filtering you apply can depend on the amount of noise measured over the last number of frames. In many situations you can approximate the amount of noise by the amount energy of the measured signal. Systems like these can be hard to make robust without resorting to difficult mathematics or special software.

You can also switch to a more sophisticated filtering approach, such as a Kalman filter or PID controller. PID controllers uses prediction to reduce latency; Kalman filtering uses a system model that makes it more effective in complicated scenarios.

13. Be Careful When filtering combined signals

You might want to add (or combine otherwise) several signals, filter this combination, and work on this filtered combined signal. This is a mistake when the signals have typical data transitions at different frequencies: one signal’s noise is another’s data.

To illustrate the problem, look at the two signals below. Signal 1 is a low frequency signal, with a spike of noise. Signal 2 is a pure high frequency signal. The noise is clearly visible in the combined signal. Also shown are several filtered versions of the combined signal. Notice that the more we filter, the more we reduce the high frequency signal. And if we do not filter enough, the noise is still very present.

The solution is to filter the signals separately – the low frequency signal can be filtered much more than the high frequency signal – and only then combine the filtered sequences. The result is shown in the last figure.

Signal 1	Signal 2	Combined signal
Combined signal filtered (0.1)	Combined signal filtered (0.5)	Combined signal filtered (1.0)
Signals filtered before combined.

14. Avoid if-then logic in response calculations.

If-then logic signifies one of two things:

• a state difference that should be implemented as proper discrete state of the state machine; or
• the need for a step function.

In the first case, your state should be broken up into two states, with proper transitions. A stimulus response agent is complex enough with you having to track trough various conditions to understand behaviour. Every state should have one response that depends continuously on the stimulus. Because state machines scale so badly, introducing more states is not very desirable either. There are of course several ways to organise states properly to alleviate the scaling problem, but this is the topic of another tutorial.

If your if-then logic is against the value of a variable (for example ‘if x > 0′), you can replace it with an appropriately chosen step function. Using step functions instead of if-then logic simplifies the design, and can be replaced with drop-in “smooth” versions when it becomes evident that it is necessary.

Testing and Debugging

15. Rendering the current state-machine state on screen.

It is a small point, but often strange behaviour results not from incorrect response to stimulus, but from incorrect state transitions. When implementing your agent inside the game, having state transitions visible on screen will make that kind of bug that much easier to spot.

16. Graph variables and their internal states on screen.

Graphing variables (filtered and unfiltered) over time on screen will save you hours of debugging time. Whenever your agent does something funny, you can see at a glance if there are variables with unexpected values that could explain the agent’s actions, perhaps using the CAS prototype as a reference.

Unfortunately, this tip becomes less useful as the system gets more complex. Having twenty plots on your screen will do little to spot problems.

17. Use unit tests to ensure correct implementation of formulas.

Stimulus response agents are perfect candidates for unit testing, especially when using the CAS prototype as a reference implementation. Unit testing your assumptions about the system will ensure correctness, and will help to make you aware of changes that break the system early. It will also make it easier to change and optimise formulas, or change them with smoother or sharper versions. Having a constant reference against which you can tweak parameters also allows you to be daring and make aggressive changes.

18. Use generators to mock the agent’s environment.

A generator is a object that generates a sequence of values. Typically it has a getValue() method, which returns a different value every time it is called. Generators are very similar to iterators, except that they usually generate values on the fly, rather than pointing to members of a container (although reading values from a container is one valid way to generate values). Generators are often used to implement iterators.

To implement unit tests and a CAS prototype, you need to mock various aspects of the game, the game world, and other agents. Using generators for this purpose makes mocking unbelievably easy and quick. Use generators to generate streams of

• elapsed times;
• path angle deviations;

• positions and velocities of other agents; and
• state transitions.

You can even mock parts of your agent to test sections in isolation. It helps if you build a library of generators and functions (response curves) that can be stacked together. You will do good to implement at least the following functions:

• step, line, and ramp;
• clamped line and sigmoid (or atan);
• cos, square, and saw tooth;
• exponential and exponential decay;

You should implement the following generators:

• a general generator that generates values from a function;
• a constant generator;
• a sum and product generator (generates the sum or product of two generators); and
• generators that generate random values of various distributions.

Conclusion

A complex stimulus response agent can be a challenge to design and implement properly; every approach has its set of headaches, and every solution brings other considerations to the table. Solving problems is just half the fun – not solving them is the other half!

Related posts:

1. Random Steering – 7 Components for a Toolkit
2. 5 Tips for Prototyping Slow Algorithms
3. Generating Random Numbers with Arbitrary Distributions

In the Dev.Mag article Guerrilla Tool Development, I give some ideas for getting some useful tools on a tight budget. Check it out!

Related posts:

1. About Me
2. How to Turn XSI Mod Tool into a Level Editor for your XNA Games: Updated for XNA 3.0.
3. How to Turn XSI Mod Tool into a Level Editor for your XNA Games: Example Updated for XNA 3.0.

Check it out!

The Python Image Code has also been updated with some of the algorithms explained in the article.

Related posts:

1. Quadtrees
2. Quadtrees
3. Cellular Automata for Simulation in Games

A cellular automata system is one of the best demonstrations of emergence. If you do not know what cellular automata (CA) is, then you should go download Conway’s Game of Life immediately:

Conway’s Game of Life

Essentially, CA is a collection of state machines, updated in discrete time intervals. The next state of one of these depends on the current state as well as the states of neighbours. Usually, the state machines correspond to cells in a grid, and the neighbours of a cell are the cells connected to that cell. For a more detailed explanation, see the Wikipedia article.

Even simple update rules can lead to interesting behaviour: patterns that cannot be predicted from the rules except by running them. With suitable rules, CA can simulate many systems:

• Natural phenomena: weather, fire, plant growth, migration patterns, spread of disease.
• Socio-economic phenomena: urbanisation, segregation, construction and property development, traffic, spread of news.

In games, these can be used as game elements (such as fire and disease), or they can also add some decorative life to a game (such as city development in a simulation game).

The great thing about CA systems is that they are not hard to implement, and they have intrinsic fun value (I mean here, for the programmer!).

Before we get into the details, let me add a small disclaimer here:

• This tutorial is not comprehensive. I only touch on a few ideas in a wide field. See some of the resources at the end for more information.
• This tutorial is not representative. I merely chose topics I found interesting or thought would be useful for game developers.
• I am not suggesting that using cellular automata is the best way to simulate any of the examples given here. For any problem, there might be solutions that are faster, easier to implement, or yield better results.

Implementation

To implement a CA system, you need to do the following:

• Use a suitable system to store states, for example, a 2D array.
• Decide on a suitable neighbourhood shape, and work out some preliminary rules. Decide how you will handle edges.
• Implement a suitable way to describe your rules.
• Implement an update function that hooks into the main game loop.
• Implement a visualisation scheme (for example, drawing tiles depending on states in the array).

Some details of these are described below.

Grid

A typical implementation uses two grids for storing states. One is the current world state; the other is the new world state. Once all cells have been updated for the current iteration, pointers to the arrays can be swapped. This way updating the cells one by one will not have an effect on other cells until the next iteration, and you do not have to create a new array in each iteration.

Using grids with square cells are the easiest to implement, but the concept is also applicable to other grids: hexagonal and triangular grids are also common, and even polar grids have been used to simulate spiral star systems.

It is also possible to use irregular systems, although the implementation then becomes a challenge. One example of an irregular system is a presentation based on a Poisson distribution of points. The trick here is to find an efficient way to locate neighbours. Fortunately, this problem has already been solved in creating the points (see the Poisson Sampling tutorial in Dev.Mag and download code from Luma Labs). It is in fact done by using an invisible grid! Of course, visualising a state is also a bit more difficult.

Neighbourhoods

For 2D cellular automata, the most common neighbourhoods are the Von Neumann neighbourhood and the Moore neighbourhood, shown below (the blue cell’s neighbourhood is shown in red). Other neighbourhoods are also possible.

Von Neumann neighbourhood	Moore neighbourhood	Extended Von Neumann neighbourhood

The cell can be included in the neighbourhood or not. It is advisable to keep the neighbourhoods as small as possible: not only does the neighbourhood size impact performance, it also affects the number of rules to be specified and thus the tweaking complexity.

Specifying Update Rules

Specifying the rules concisely is the most challenging part of implementing CA. With very simple models, you might want to use a few if/else statements. This, however, makes it hard to modify (tweak or extend), and is therefore not suitable for more complicated systems.

It is best to implement rules as a table that can be indexed using the neighbourhood states.

Table as an array. In this method, each row represents the combined state of the surrounding cells. The final entry in the row is the new state of the current cell. Each of the remaining columns represents a state. The entries in these columns represent the number of cells surrounding the current cell in that state.

A cell surrounded with three cells in the Dry Bush state and one cell in the Burning Bush state will go into the Burning Bush state.

This table can be quite large, so that you must take care to implement lookups efficiently. Keep the table sorted, and perform binary search to lookup entries. Below are some improvements on this scheme.

Table as a tree. In the table above, it is easy to see that if there are three dry bush nodes, there are two possibilities for the other states (either 1 0, or 0 1). We can use this to implement a tree. Each level in the tree represents a state. A value in a node represents how many cells in the neighbourhood are in that state. A path from root to leaf fully describes the states of the entire neighbourhood. We do not add nodes for the last state, as it is uniquely determined by the other states.

Below is a tree corresponding to the piece of table above.

BB = Burning Bush

DB = Dry Bush

This is a more efficient implementation; unfortunately, it is also more complicated. It is inconvenient to specify the tree in a tree-friendly format (XML or s-expressions, for example). You still need to specify it in table format (space separated text file, for example) and build the tree from that.

Implementation as a hash table. Here you use tuples of state counts as keys. For example, the third entry in the table above can be accessed with the tuple (3, 0, 1). If your implementation language does not support tuples, you might need to implement them yourself. Be sure to make them immutable!

Implementation as an N-dimensional array. This is a very simple method, although it wastes a lot of memory. N is the number of states, and we use the state counts to index into the array. In our example, we will use a 3D array, so that the third element can be accessed using transition_array[3, 0, 1].

The method above can be used even when the implementation language does not provide N dimensional arrays. Simply use a 1D array, and interpret the state counts as the digits of a base-4 number. Thus, the third row will be located at 3*16 + 0*4 + 1*1 = 49.

Note that since the numbers are restricted by the requirement that they add to four, there will be unused array positions in both these last two methods. You can save memory by not using the last state to index (since it is uniquely determined by the other states). Thus, we can use a 2D array, and access the 3,0,1 rule with 3,0 alone: transition_array[3, 0]. Alternatively, if we need to use a 1D array, we can store the rule in the position 3*4 + 0*1 = 12. Although the same scheme is possible for the hash table implementation, I would advise you to use the full indexing scheme instead, since it will not waste more memory if you do, and it is somewhat easier to understand if you use full indices.

Some rules do not need the detailed tables above. For instance, in a system of only two states, where transitions depend on the count of the states of the neighbourhood, we can use a simple array, indexed by one of the states’ counts. Many other schemes are possible: in general, aim for quick lookups and easy specification.

Edges

The edges of your simulation might present some problems: edges often serve as unwanted sources, sinks or stabilisers.

A source is the origin of outward growth (states change progressively to a specific state in an outward direction).

A sink is the exact opposite:

Sources and sinks are emergent properties of the CA system, and are not physical attributes of the cells.

A stabiliser is a section that keeps neighbouring states fixed. For example, in the fire simulation (described below), there is an unnatural wall of fire around the edges at the end of the simulation.

There are several ways you can handle edges:

Ignore them. When the edge anomalies are acceptable, it is best not to complicate the model. This is only possible if the rules are specified in a way that does not require state counts to sum to the size of the neighbourhood. For example, if there is a rule “if num_states_fire > 1, then …”.

Wrap around. This solution is very elegant, easy to implement, and its effects are easy to understand. However, it is usually easy to see that the world has been wrapped in this way, and hence it is not always a visually a satisfactory solution. It is possible, however, to simulate a grid bigger than displayed area (say about double). This will hide the fact that it is wrapped, but still give you the benefits of having a world without any discontinuities.

In the CA system shown left, we want to calculate the next state of the grey cell. Two neighbours fall outside the edges. If we wrap around, we use the four red squares as shown.

Reflection. Use a neighbouring state to perform calculations.

The CA system shown left is the same situation as above. If we use neighbouring states for the cells beyond the edges, we use the state of the grey cell (twice!), in addition to the two red cells shown.

Fix their states. The edges can be given special, constant states that make the CA behave as intended. Finding the right state(s) for the edges might be difficult.

An implementation trick that applies to the last three edge-handling techniques is to include a border in your simulation. For the Von Neumann and Moore neighbourhoods, this border is only one cell thick.

This border is used for updates like all other cells, but is itself updated differently. The update rules for wrapping and reflection will simply copy states from the right places; the border for fixed states will never be updated.

In the figure, hatched cells are updated according to the special rules of the edge-handling scheme – in this case, wrapping is used, so they are simply copied from the appropriate cells. All other cells are updated normally. Note that here we do not need special logic for updating the grey cell.

A Few Examples

(Also see the downloads at the bottom of the post).

Heat

Here, continuous states (floats between 0 and 1) are used. Every cell is updated to a weighted average of its Moore neighbourhood cells: corners have a smaller weight than other cells. For this simulation, heat sinks and sources have been added: they keep the cell’s temperature at 0 and 1 respectively.

City Roads

This simulation use separate neighbourhoods for creating and destroying a road. The creation neighbourhood is an extended Von Neumann neighbourhood; the destruction neighbourhood is a Moor neighbourhood. Creation and destruction is according to probabilities based on the count of neighbouring roads.

Influence

This simulation models human emotion as influenced by others. A character has an internal state, and an externally visible state. Characters can only observer the external state of their neighbours. The internal state is then a modified: a character surrounded by angry people will itself become angry, and so on. The external state is probabilistically determined by the internal state.

Disease Spread

For our game Epidemic, Chris and I used a simple diffusion model. We used a floating-point number for the state, and represented the number of infected people in a cell. We used different colours for different ratios to visualise infection. At each time step, a cell would become infected by an amount proportional to that of the neighbourhood, with some random scaling.

Visualising States

Versions of tiles

A very effective way of making CA simulations more impressive is to have more than one tile for each state, and display them randomly. This is especially helpful for hiding regularity in off-line simulations. Tile sets with different versions for corners, edges, and central regions can drastically improve the look of the game, although it complicates choosing the correct tile version. In addition, it means you need tiles for various combinations of states. Assuming we can rotate and reflect tiles, in the fire example with three states, we need the following tiles:

3 centre tiles
3 straight-edge tiles
3 diagonal line tiles
3 cross tiles
6 corner tiles
3 half-straight tiles

This is 21 tiles for only three states. It is advisable to automate tile creation.

Tile

States can be animated. Instead of displaying a single tile, display an animation sequence. You will need to think about how to start and stop these animations so that they are seamless. For instance, you can make all animation sequences the same length, and only update states between animation sequences.

You can also increase the seamlessness of the simulation by animating transitions between states. This can be as easy as blending between two tiles over a period of time (assuming that updates are made far enough apart).

No Tiles

Instead of using tiles to represent a state of a cell, you can put objects in a cell. For instance, in a plant growth simulation, you can put a number of trees in the cell depending on the state. The advantages of this are:

• You do not have to create dozens of tiles for variety.
• The player can interact with the objects. For instance, the plant placement of trees can hinder a player’s movement.

This shows a simple forest simulation. Trees grow and die depending on the surrounding trees. This system uses a grid, but not tiles: trees can grow in random positions in tiles. For this simulation, three random coordinates have been chosen for each cell at the beginning of the simulation. Depending on the states, one, two, or three trees will be drawn at these points. Choosing a fixed set of points makes it easier to draw trees at the same coordinates every tick. A somewhat more complicated simulation can choose new points whenever a new tree comes into being.

CA Enhancements

The images below show three frames from a simple fire simulation.

The green is grass (Dry Bush), the orange is fire (Burning Bush) and the brown is burnt grass (Charcoal).

As you can see, the simulation captures some features of a fire:

• fire grows outward,
• grass only burns once,
• grass needs fire to catch fire (there is no spontaneous combustion).

Even so, the symmetry and regularity makes this fire very unconvincing. Below we look at some ideas to enhance a simple CA simulation.

Probabilistic State Transitions

Instead changing to some specific state based on the surrounding states, you can change to any state with some probability. These probabilities depend on the surrounding states, and can possibly be zero.

Adding probability to the mix can have several advantages:

It introduces variability in patterns. This means a specific (perhaps the start-up pattern) will not always produce the same results.

It can enhance the organic look of the system. Cross and squares patterns are common in deterministic CA systems. For many purposes, this is unsatisfactory (have you ever seen a fire spreading as a growing square?) Adding probabilistic state changes will make the patterns more organic and varied.

It can make discreet behaviour more continuous. For example, two common “problems” with CA systems are exponential growth (where all cells go to a certain state outwards very quickly), or sudden death (where all cells go to a certain state very quickly inwards). The problem is often that a single change in the update rules results in a exponential growth system to become a sudden death system, with seemingly no way to get a “sweet spot”. If states can only change with a certain probability, tweaking the probabilities allows you to get intermediate patterns (stable growth, equilibrium, or stable death).

It allows you to control the speed of the simulation. It is especially helpful to slow down a simulation without making it more granular (in the time dimension). It is useful to multiply all your probabilities with a global parameter that you can tweak to control the speed.

Note that in the example above, certain cells did not burn at all – per chance, they did not caught fire when their neighbours were burning. Timers (see below) can reduce or eliminate this effect.

Adding randomness can increase the emergence, and hence also unwanted emergence, so care must be taken that the simulation is always valid.

Tile Interpolation

Normally, you want your simulation to be as simple as possible. However, when such simple simulations are displayed (visualised), the results can be unsatisfactory. One way to get better visual quality is to use tile (cell) interpolation to make the simulation seem more complicated than it really is. When combined with a bit of randomisation, the effects can be very convincing.

The basic idea is to simulate only every nth cell with the CA approach. Other cells are interpolated. The number of interpolated cells can be adjusted, depending on the detail level required (balanced with the combinatorial number of tiles required!)

In the fire simulation, using only three states makes the simulation seem very primitive. Suppose that we simulate only every second row, and in these, only every second column, and fill the remaining cells depending on their neighbours. We have to create a function that will return a tile for each combination of surrounding tiles:

get_center_tile(north, east, south, west)

Interpolation rules are similar to update rules of the simulation, and hence can easily be as complicated. If this is the case, you would do better to implement more states and not do any interpolation. Interpolation should only be used if it significantly reduces the implementation complexity.

Timers

Some interesting effects can be obtained if each cell has a timer, that is, each cell only updates once the timer expires. Some rule determines when the timer is reset. For instance, the timer can be set:

• randomly,
• as a function of the state,
• as a function of the surrounding cells,
• as a function of another property of the tile (*1),
• as a function of some external process (*2).

(*1) For instance, if each cell has an associated “burning capacity” parameter, (simulating material types), a fire state timer can be set in proportion to this parameter.

(*2) For example, we can set timers according to a wind factor.

Timers can have the following effects:

• add some randomness to a simulation,
• slow the simulation down,
• smear the simulation (for example, in the fire simulation, the burning border is much thicker, and no cells are skipped).

Although you can often implement your grid cells as classes (or structs, or whatever aggregating construct your language provides) with states and timers embedded, it is simpler (on more efficient) to have separate integer grids – one for states and one for timers.

Note that if timers do not have the same expiration time, you the CA system is asynchronous and the behaviour can differ dramatically from a synchronous CA system. Thus, you should include timers early in the development process, so that their effect does not force you to re-tweak all the parameters.

If your world is big, you cannot run the CA for the whole world at every time step – it will kill performance. Below are some ideas for improving performance.

Instead of simulating the entire world, you can only simulate the part that is relevant to the game, usually the visible region of the game. A simple technique is to use a wrapped grid, similar to the grids used for the visual port in scrollable 2D games. This grid can be slightly larger than the visible grid, so that it allows cells to update naturally for a few iterations before they become visible, and so increase the illusion of a persistent world.

To hide that fact that you are only simulating a very small piece of the world, you must update “new” cells appropriately. There are several options:

Update cells to a natural starting state. In many cases, this solution is adequate, especially if you simulate a slightly larger grid than is visible.

Copy states from the existing simulation. Here you can copy neighbouring cells, or randomly from a nearby region. Copying from nearby cells promotes spatial coherence.

Initialise states statistically. Based on a neighbourhood of cells, each cell is initialised probabilistically. For example, each cell can be initialised randomly to one of three neighbouring cell’s states.

Use hierarchical modelling. Use another CA system that represents the entire world in very low detail, and use this to initialise the cells of the high detail version. Note that both the states and the update rules will differ for the high and low detail simulations. Use probabilities to prevent homogeneous systems. You can even use several levels of detail, and incorporate them as needed. Beware the extra implementation complexity, though!

This technique does not work when the world is should be changed permanently.

Instead of only simulating a part of the world, you can only update a part of the world. This requires enough memory for the whole world, but only processing power for the cells you wish to update. This method has the advantage of real persistence, thus permanent changes can be reliably simulated. Which cells you update will determine how your simulation will play out:

• Update all visible cells (or a slightly larger region). This is the most natural update scheme, and its effects are similar to partial simulation described above.
• Divide the world into discontiguous regions, and update a different region each time step. For example, divide the world into two sets: one contains every other cell, the other the rest, and update these two sets alternately. To save a significant amount of processing, you need many sets. To hide patterns in the updates that might break the illusion of a continuous world, the sets should be irregular. This method has the advantage that real things happen off screen. On the down side, it slows down the simulation significantly.
• Combine the two methods above.

Partial updating, like the inclusion of timers, lead to an asynchronous system, and hence the behaviour might be very different from that of a fully updated system.

In certain cases, simulations can be baked offline and be used in games. This means you perform the simulation before the time, and record each frame. The game then reads these frames, and plays them back.

Various schemes are possible to get more with less. For instance, you can also interpolate the simulation in time. With some thought, you can simulate events in a way that they can be looped, stacked together, and started and stopped unobtrusively. This means you can blend them with the interaction in a way that will not make it obvious that the simulation has been performed off-line.

Unwanted Emergence

Not all emergence is good, and you might find it hard to prevent certain behaviours. If the unwanted behaviour is only visual, and it occurs only rarely, it might be acceptable. However, if behaviour impacts play negatively, it must be prevented.

As with all tweaking, you should not spend too much time fumbling around. To proceed more “scientifically”, ask yourself the following questions:

• Is there a way to detect (measure objectively) the unwanted behaviour?
• Instead of tweaking your CA, can you detect-and-recover system be used?
• Is the behaviour continuous? In other words, is there a degree of badness, or is it either good or bad?
• If it is continuous, is it feasible to kick in a preventative system? (When the badness goes above a threshold, updates are processed differently).
• Is it feasible to find a set of parameters through an optimisation algorithm (for instance, genetic programming)? It might even be possible to search exhaustively for a solution.
• Is my model too complex? Try to eliminate states and simplify transition rules. You might even consider breaking your simulation into two or more independent CA systems.
• If you find yourself struggling to tweak the parameters for too long, you should perhaps look for a better model that is less sensitive to the exact parameters.

Links

Online Demo

http://blog.soulwire.co.uk/laboratory/flash/2d-cellular-automata Browswer-based demo with ActionScript source code.

General

http://cell-auto.com/ A nice breakdown of various topics related to Cellular Automata. The article on optimisation is especially interesting.

http://www.collidoscope.com/modernca/ Contains many non-traditional variations of cellular automata.

http://www.fourmilab.ch/cellab/ Application for exploring cellular automata.

Applications and Implementation

http://realtimecollisiondetection.net/blog/?p=57 Path finding using cellular automata.

http://www.ibm.com/developerworks/java/library/j-camusic/ Cellular Automata and music (interesting way of creating procedural music).

http://blog.sigfpe.com/2006/12/evaluating-cellular-automata-is.html About using lazy, infinite containers for cellular automata.

http://madeira.cc.hokudai.ac.jp/RD/takai/automa.html Graphics applications for cellular automata – lots of videos!

Game Design

http://www.gamestudies.org/0102/pearce/ An article about game design.

http://www.cp.eng.chula.ac.th/~vishnu/gameResearch/Sweetser_Thesis.pdf A thesis that looks at game design from a emergence perspective.

http://fora.tv/2006/06/26/Will_Wright_and_Brian_Eno#chapter_01 Will Wright and Brian Eno on generative systems.

Downloads

Game Maker Demos

• Requires Game Maker 7.
• Contains 9 demos.

ca_demos.zip (135 KB)

Related posts:

1. Random Steering – 7 Components for a Toolkit
2. A Simple Trick for Moving Objects in a Physics Simulation
3. Estimating a Continuous Distribution from a Sample Set

Last year I wrote a tutorial explaining how to use XSI Mod Tool as a level editor, specifically for XNA. Below is the same tutorial, updated for XNA 3.0. There are only a few minor changes:

• You need not copy compiled assets from the batch file as before.
• A section is included that describes how to use the content pipeline classes for easy reading of XML files (useful for level files, etc.).

I also corrected quite a few typos.

Link

The article Integrating Your XNA Engine With XSI ModTool is very relevant to this tutorial. Among other things, it explains how to make XNA shaders work in XSI.

Download

PDF Tutorial

How to Turn XSI Mod Tool into a Level Editor for your XNA Games v3.pdf (463 KB)

Example

(XSI Plug-in and C# code. Includes the tutorial PDF)

XSIModToolLevelEditor3.zip (5.2 MB).

Related posts:

1. How to Turn XSI Mod Tool into a Level Editor for your XNA Games: Example Updated for XNA 3.0.
2. Google App Engine for Games
3. Guerrilla Tool Development

You might want to have a look at Craig Reynolds’ Steering Behaviour for Autonomous Characters — the wander behaviour is what is essentially covered in this tutorial. The main difference is that we control the angle of movement directly, while Reynolds produce a steering force. This post only look at steering — we assume the forward speed is constant. All references to velocity or acceleration refers to angular velocity and angular acceleration.

Whenever I say “a random number”, I mean a uniformly distributed random floating point value between 0 and 1.

1. Angular displacement, velocity and acceleration

These are the variables we can alter to make the agent steer. For a fuller treatment of these basic quantities, see Basic Rotational Quantities. You might also like to check the Wikipedia article Random Walk.

Angular Displacement

Angular displacement is simply the current angle of the agent (relative to some fixed direction, such as the positive x-axis).

If you decide to make the angular displacement random, you calculate the new angle as:

angular_displacement = 2*max_displacement * (random() – 0.5)

Motion produced by randomly altering the angular displacement.

As can be seen from the graphic above, the result is very erratic, and not very organic. We can get a better impression of intent if we limit the angles in a certain range (by setting the max_displacement to a lower value than 180), as shown below.

Same as above, but with angle limited witin 10 degrees of the original displacement.	Angle limited to 30 degrees.	Angle limited to 90 degrees.

Angular Velocity

Angular velocity is the difference between two displacements (measured in two consecutive simulation steps).

angular_velocity = angular_displacement1 – angular_displacement0

Velocity is changed randomly, but clamped at 10 degrees.	Velocity clamped at 40 degrees.	Velocity clamped at 80 degrees.

Changing the velocity results in smoother behaviour. The smoothness depends on the maximum allowed velocity.

Angular Acceleration

Angular acceleration is the difference between two velocities (measured in two consecutive simulation steps).

angular_acceleration = angular_velocity1 – angular_velocity0

Changing the acceleration is even smoother than changing the velocity. If the acceleration is not clamped to a suitably low value, the agent might go off on a spin for a long time (read the Random Walk article on Wikipedia to understand why).

Acceleration modified randomly. Acceleration clamped at 0.5 degrees. Velocity clamped at 5 degrees.	Acceleration clamped at 1 degree. Velocity clamped at 5 degrees.	Acceleration clamped at 1 degree. Velocity clamped at 5 degrees.
Acceleration clamped at 0.5 degrees. Velocity clamped at 10 degrees.	Acceleration clamped at 1 degree.  Velocity clamped at 10 degrees.	Acceleration clamped at 1 degree. Velocity clamped at 10 degrees.
Acceleration clamped at 0.5 degrees. Velocity clamped at 15 degrees.	Acceleration clamped at 1 degree. Velocity clamped at 15 degrees.	Acceleration clamped at 1 degree. Velocity clamped at 15 degrees.
Shows a situtation where the clamped acceleration is not low enough.

2. Distributions

Changing the distribution of the random numbers we use changes the motion.

Smooth Noise

Smooth noise is generated from uniformly distributed random numbers (white noise) by interpolating values.

For example, the sequence 0 1 0 0 can be smoothed out to 0 0.5 1 0.5 0 0 0, or for smoother result 0 0.25 0.5 0.75 1 0.75 0.5 0.25 0 0 0 0 0.

Perlin Noise

Perlin noise is very suitable for rugged organic types of motion. I won’t cover how to produce Perlin noise — see this tutorial.

Arbitrary Distributions

We can also use a handcrafted distribution curve. See the post Generating Random Numbers with an Arbitrary Distribution.

Discrete Distributions

Instead of allowing all angles, we can limit the angles to a discrete set, for example only angles in the set 0, 90, 180, 270. Motion generated from a discrete set is very mechanical.

We can also map Perlin noise to a discrete set, leading to an agent that follows a direction for a longer time.

Smooth noise.	Perlin noise.
Arbitrary distribution curve used to modify displacement.	Arbitrary distribution curve used to modify velocity	Arbitrary distribution curve used to modify acceleration
Discrete distribution (90 degrees).	Discrete distribution (60 degrees).	Discrete distribution (30 degrees).
Discrete Perlin (90 degrees).	Discrete Perlin (60 degrees).	Discrete Perlin (30 degrees).

3. Vector Fields

Random vector fields can be useful in certain cases. In general, it is impractical to generate a random vector for each pixel. Instead we generate vectors for a sample grid (say every 10^th pixel in every 10^th row), and use interpolation for the other pixels. The lower our sampling rate (i.e. the further sample pixels are apart) the smoother the motion will be.

• When setting the angular displacement from such a field, the agent will retrace a path whenever it visits a pixel that has already been visited. This can sometimes be distracting. It is easily fixed by offsetting the angle with a small random amount.
• Random vector field can have sinks from which the agent cannot escape. This is especially true when the acceleration is set from a vector field. One way of resolving this problem is to switch between two or even three vector field at regular intervals. (It can be difficult to reliably detect when the agent is stuck).

Vector field used to alter displacement.	Vector field used to alter velocity.	Vector field used to alter acceleration.
Shows a sink in the vector field that permanently traps an agent.

Vector fields can also be used to bias random numbers. This is useful when the vector field represents landscape features. Thus the field will only “influence” the behavior of an agent, and not control it directly. One very easy way to do this is to use the following formula to adjust the angle:

displacement = r_1 * vec(x, y) + (1 – r_1) * r_2

Where vec(x, y) is the angle obtained from the vector field (possibly interpolated as described above), and r_1 and r_2 are two random numbers.

4. Functions

Instead of using random numbers, we can use functions that depend on time. These functions can be parameterised with random numbers.

The sine function have properties that makes it very convenient to use for this purpose:

• It is smooth.
• Its range (the amplitude) is limited, and easily adjusted with a parameter.
• The frequency is constant and easily tweaked with a parameter, making it easier to control things such as loops when combining different sine functions.
• Different sine functions can be added to lead to complex motion.
• It is easy to blend two sine functions with another function to simulate frequency changes (for example, A(t) * sin(10t) + (1 – A(t)) * sin(t) without unwanted phase effects. Alternatively, the blending can be done with a Perlin noise sequence.

Saw tooth functions and square wave functions have all these properties, except that they are not smooth.

In the images below, the parameter t is incremented each time step.

sin(t) + sin(10t) + sin(50t)

sin(t)	sin(10t)	sin(50t)
sin(t) + sin(10t) + sin(50t)	0.5sin(t) + 0.3sin(10t) + 0.2sin(50t)	0.5sin(t) + 0.5sin(50t)
	0.9perlin_noise(t)sin(t) + 0.1perlin_noise(T – t)sin(50t)	0.5perlin_noise(t)sin(t) + 0.5perlin_noise(T – t)sin(50t)
white_noise(t) * [0.5sin(t) +  0.5sin(50t)]	smooth_noise(t) * [0.5sin(t) +  0.5sin(50t)]	perlin_noise(t) * [0.5sin(t) +  0.5sin(50t)]

5. Timed Transitions

Instead of changing the angular displacement (or velocity or acceleration) at every time step, we can change it only every “once in a while”. For example, we can change it when a fixed number of time steps have passed. More interestingly, we can change it only when a random number of time steps have passed.

The presence of many circular loops indicate long times of constant velocity. When we adjust the velocity or acceleration, this can happen when the intervals are too long in relation to the max angular velocity. When we adjust the acceleration, it can also happen when the max velocity is too low relative to the maximum acceleration – leading to quick “saturation”.

When combined with angles from a discrete distribution, we get the machine-like behaviour (similar to using Perlin noise mapped to a discrete set as above).

Displacement	Velocity	Acceleration
Clamped velocity (low).	Clamped velocity (medium).	Clamped velocity (high).
Clamped velocity (very high).	Clamped acceleration and velocity (low velocity).	Clamped acceleration and velocity (high velocity).
Discrete set (90 degrees).	Discrete set (72 degrees).	Very regular movement when clamped acceleration is low relative to the clamped velocity.

6. Transition Tables and Functions

Sometimes we would like to change the distribution of a randomly generated angle based on the current steering angle. We can use transition tables for this.

The table above is an example of a transition table. It basically describes the probability that if the current steering angle is within a certain range, it will change to some other range. For example, if the current steering angle is smaller than 15 degrees, there is a probability of 0.9 that the next angle will also be smaller than 15 degrees. If the angle is greater than 30 degrees, the next angle will be smaller than 15 degrees with a probability of 0.1.

To implement this, we convert the probability table above to a accumulative probability table, where we sum over rows, like this:

Now, at each simulation step, we check the current angle, and choose the appropriate row of the table to work with. Now we generate a (uniformly distributed) random number. Then we check it against the values in the row. The left most cell that is bigger than the random number is the one we want to work with – it denotes the range of the new angle. Then we simply generate a random number in this range. In practice we don;t need the last column.

The table above can be interpreted as follows:

• if the current angle is in a certain range, the probability is high that it will be again in that range;
• if the range changes, it will more likely change to an adjacent range; and
• if the range changes and there are two adjacent ranges, the left one is favored.

We can smooth out the results by using a 2D response curve, but this can be tricky. Also, we need to specify many values to get the 2D distribution we want.

In a special case we can follow a two step process instead. We use two tables:

• one to describe the probability that an angle will change (base on the angle size);
• and a simple transition table as above.

This leads to fairly regular movement, as shown in the figures.

Agent using the transition table above.	Agent using the transition table above but only change angles with probabilities 0.1, 0.2, 0.4 for the tree angle ranges.	Agent using the transition table above but only change angles with probabilities 1, 1 0.1 for the tree angle ranges.

7. Paths

It is sometimes easier to steer towards a generated path than to control the steering directly. Using paths have several advantages:

• the agent’s future movement is always known, making it easier to predict; and
• paths can be saved, and transmitted over a network. This can make it easier to keep networked simulations (such as multiplayer games) in synch, and support features that require determinism (such as replay).

Steering on a path is covered in Reynold’s paper – here we look at a two simple random path generating algorithms.

Fractals

A simple path generating algorithm generates fractals:

• Start with a single segment – two points in a list
• For each pair of adjacent points in the list (each representing a line segment), add some intermediate points (based on some algorithm – see below)
• Repeat until the result is suitably detailed.

The algorithm used to generate new points will determine the characteristics of the final path. Here are a few examples:

• For each point pair, generate a random point close to the midpoint.
• For each point pair, generate two points close to the third and two third points, on opposite sides.

Functions

Start with a line, a circle, or some other simple figure, and add sine functions to it. For example, a circle’s equation in polar coordinates is:

r = k

We can now add sine waves, like this:

r = k + r_1*sin(t) + r_2*sin(2t) + r_3*sin(4t) + …

r_i can be chosen constants, or randomly generated numbers.

Again, saw tooth and square wave functions are also suitable for adding to the base path. Other functions can also be used, although you should take care that they stay witin a predefined range.

Download

Random Motion Game Maker File

Most of the principles discussed here have been implemented in the following Game Maker file:

random_movement.gmk 180 KB

Read the README file in the scripts folder (inside the Game Maker file).

Reynolds’ Open Steer Library

This is a C++ implementation of Reynolds’ steering behaviours that can be plugged into a game or simulation.

Links

• Flipping you the Boid (ActionScript swarming behaviour demo – with source code).
• Agents, Behaviour, Emergence and Embodiment (a list of resources).
• Simulating Crowd Dynamics: Flow Lanes and Character Animation.
• Simulation and Visualization of Agents in 3D Environments (PDF 1.61 MB).
• Steering a Virtual Crowd Based on a Semantically Augmented Navigation Graph (PDF 3.96 MB).
• A Microscopic Swarm Model Simulation and Fractal Approach towards Swarm Agent Behaviour (PDF 622 KB).
• The Experiments for Exploring Dynamic Behaviors in Urban Places (PDF 12.83 MB).
• Simulating Crown Behaviour in Computer Games (PDF 621 KB).
• Towards Building an Intelligent Traffic Simulation Platform (PDF 154 KB).
• Tank Wars (PDF 435 KB).
• REACT: Crowd Simulation System for Visual Effects (PDF 846 KB).
• Hybrid Representations and Perceptual Metrics for Scalable Human Simulation (PDF 5.39 MB).

Related posts:

1. Cellular Automata for Simulation in Games
2. Generating Random Numbers with Arbitrary Distributions
3. Tips for Designing and Implementing a Stimulus Response Agent

Vector fields are used in certain AI and simulation techniques. The tool below allows you to paint a vector field. These files can be saved in XML format, that can easily be loaded into another application.

There are five brushes:

• The Set Direction brush keeps the size of the underlying vector the same, but changes the size to a constant value.
• The Set Size brush keeps the size of the underlying vector the same, but changes the direction to a constant angle.
• The Attract brush draws all the vectors closer to the mouse cursor.
• The Repel brush pushes all vectors away from the mouse cursor.
• The Comb brush moves vectors in the same direction as the mouse.

The XML file arranges the field into a quadtree. The quadtree compression can be viewed from the program.

To change the brush size, use the ‘[' and ']‘ keys.

To change the brush options, use the ‘-’ or ‘=’ keys.

This is the first version of this program, so there are many missing features. For example, the size of the field can not be changed yet. If you find it useful, let me know in the comments!

Download

Windows Executable

force_field_editor_v1_0.exe 3.3 MB

Requires Java Runtime Environment.

Related posts:

1. Region Quadtrees in C++
2. Random Steering – 7 Components for a Toolkit
3. Quadtrees