1. 8.1. Steering Behaviour III
Steering behaviours in game AI

2. Steering Movement Algorithms
Execution Management
Movement
Strategy
Decision Making
World Interface
Animation
Physics
...
Steering Movement Algorithms
Forms of dynamic (or steering) movement algorithm

3. Aside: Separate is also known as the Repulsion Steering behaviour
targets holds all Objects to consider for separation
Separate( Vector source, Array targets,
float separateThreshold, float separateDecay,
float maxAcceleration ) {
Vector acceleration = [0,...];
foreach( Object target in targets ) {
Vector direction = target.position - source;
float distance = direction.length();
if( distance < separateThreshold ) {
float separateStrength =
min( separateDecay * distance * distance,
maxAcceleration );
acceleration +=
direction.normalise() * separateStrength; }
if( acceleration.length() > maxAcceleration )
acceleration =
acceleration.normalise() * maxAcceleration;
return acceleration;
Separate
separateThreshold controls separation distance drop-off
The separate behaviour tries to stop game objects from becoming too crowded. An accelerative force is introduced to move away from any object that is too close.
Determine separation strength
Net acceleration
Individual repulsion
Update net acceleration
Aside: Separate is also known as the Repulsion Steering behaviour

4. Path following
FollowPath will attempt to steer a object along some defined path. It is a delegating behaviour, i.e. a target position is calculated on which to Seek.
The first step is to determine the object’s nearest location on the path (this may be hard). Next, a target location further along the path is determined and used as the Seek target.
Aside: Arrive may be used to navigate to the final point (if the path does not loop).
Path location here is a single-valued measurement, i.e. measuring the ‘distance’ from the start of the path. This might be bounded to the range [0,1] or [0,N] if the path is defined as a sequence of N points. If the path is complex, e.g. highly curved, then it can be a complex process to map the object’s location onto the ‘correct’ path location.
Seek output
Closest path point
Target path point

5. Path following (non-predictive)
The basic delegating behaviour can be defined as:
FollowPath(
Object source,
Path path,
float pathOffset ) {
float pathPosition = path.getPathPosition(source.position);
float targetPathPosition =
pathPosition
+ pathOffset;
Vector target =
path.getPosition( targetPathPosition );
return Seek( source.position, target ); }
path holds the Path object
pathOffset controls how far along the path the target position will be set
Determine the current position on the path
Move along the path and determine the world position of the new path position
Aside: It may be useful to remember and pass the last path position, i.e. getPathPosition( Vector currentPosition, float lastPathPosition) as this can help to determine the closest path position.

6. Path following (predictive)
lookAheadTime controls how far ahead the position will be predicted
Predictive path following operates by firstly predicting where the object will be in a short time and then mapping this onto the path.
This can result in smoother path following, but can introduce skipping when the path points are close together.
In order to reduce skipping the last path location can be used to help determine the correct position (based on the principle of coherence)
FollowPath( Object source, Path path,
float pathOffset,
float lookAheadTime,
float lastPathPosition )
Vector futurePosition = source.Position + source.velocity * lookAheadTime;
float pathPosition = path.getPathPosition(futurePosition, lastPathPosition);
float targetPathPosition = pathPosition + pathOffset;
Vector target = path.getPosition( targetPathPosition );
return Seek( source.position, target );
lastPathPosition holds the last determined path position
Predict the future location

7. Path following (predictive problems)
Seek output
Predicted location
The example below shows a potential problem with predictive path-following.
By using the last path position and the principle of coherence the skip can be avoided.
Last path position
Coherent path locations
Aside: Enforcing coherence is not always desirable (e.g. the object have may ‘teleported’, etc.).

8. Path following (paths)
Different means of defining a path can be used (including parametric curve functions).
A list of points provides a straightforward and effective path representation. Point spacing can be varied using the degree of curvature.
The integer path position is defined as the index of the closest point to the source.
An array of point-N-to-point-N+1 distances can be maintained to test for coherence.
Array<Point> pathPoints;

9. Collision Avoidance
Where there is a lot of independent game objects moving in the same space it will likely be necessary to provide some form of collision avoidance.
One approach to collision avoidance is to trigger an evade or separate steering behaviour if a predicted collision is detected.

10. Collision Avoidance (collision detection)
A future collision can be detected by determining the future path of two objects based on current velocities.
The closest distance of approach can be calculated and action triggered if the distance is less than some threshold (e.g. combined bounding radii × comfort factor)
Object 1
Object 2
Point of closest approach
Closest distance
Note: The point of closest approach may not be where the trajectories cross as different object velocities may mean objects reach an intersection point at different times.

11. Collision Avoidance (collision detection)
The time of closest approach can be calculated as:
Object 1
Object 2 v1 v2 p1 p2 dv dp
The points of closest approach are then given by:
Note: If the time of closest approach is negative then the objects are moving away from each other, and no future action is needed.

12. Collision Avoidance (detection response)
For best results, if a possible collision has been detected, then the predicted future locations are used to derive the evade or separate behaviour (and not the current positions)
For multiple predicted collisions, the object with the closest predicted time of collision should be reacted to first.
Note: If the point of collision will occur at the centre of both objects (unlikely, but maybe possible) then evade, etc. will be unable to operate. A special case would be needed to handle this situation, e.g. evading on the current positions, etc.

13. Collision Avoidance foreach( Object target in targets ) {
Vector relPos =
target.position – source.position;
Vector relVel =
target.velocity – source.velocity;
float relSpeed = relVel.length();
float relDistance = relPos.length();
float timeToCollide
= Math.dot(relPos, relVel)
/ (relSpeed * relSpeed );
float minSep =
relDistance – relSpeed * closestTime;
if( minSep < source.radius + target.radius )
if( timeToCollide > 0 AND
timeToCollide < closestTime ) {
// Store closestTarget, closestTime, ... }
Collision Avoidance
targets holds all Objects to consider for avoidance
CollisionAvoidance(
Object source, Array targets) {
Object closestTarget = null;
float closestTime = float.max;
float closestSep, closestDis;
// Determine closest target
if( closestTarget == null ) return;
if( closestSep <= 0 || closestDis < source.radius + closestTarget.radius )
return Evade( source.position,...);
else {
return Evade( source.position +
source.velocity * closestTime, ... ); }
If already in collision, or exact centre hit then steer away from current position, else use predicted location.
Determine time to collide using provided formula
If collision detected and closest so far, then store

14. Collision Avoidance (walls and large objects)
The previous algorithm assumes a circular/spherical bound (applicable to lots of objects).
For large irregular objects or rectangular objects (e.g. walls) a bounding sphere can offer a poor bound (a large volume around the object will be needlessly avoided).

15. Collision Avoidance (walls and large objects)
A suitable approach for walls, etc. involves casting one or more rays in the direction of travel. The rays will have a defined maximum length.
If the rays collide with an object then a movement target is created to avoid the collision, and a Seek made towards the target.
Cast ray
Point of collision
Normal to collision
Seek target to avoid collision

16. Collision Avoidance (walls and large objects)
ObstacleAvoidance(
Object source, CollisionDetector detector ) {
float avoidDistance;
float lookaheadDistance;
Vector ray = source.velocity;
ray.normalize();
ray *= lookaheadDistance;
CollisionInfo collision = detector.getCollision(
source.position, ray)
if( collision == null ) return;
Vector targetPosition = collision.position
+ collision.normal * avoidDistance;
return Seek( source.position, targetPosition )
A CollisionDetector is assumed to be an object that has awareness of the level geometry and can test for object/ray intersection – returning at least an intersection point and normal vector.
CollisionInfo is assumed to hold information on any detected collision(s).
Note: Developing a fast and efficient collision detection system can be a sizeable undertaking. For more information see:

17. Central ray, side whiskers
Collision Avoidance (walls and large objects)
A single cast ray may not avoid an obstacle as shown opposite.
Other common configurations include:
Parallel side rays – good for tight passages, susceptible to the corner trap.
Central ray with short whiskers – need to cast three rays, not good for very tight passages.
Whiskers only – ‘blind spot’ close to object, not good for tight passages
Collision not detected
Corner trap – collision avoidance cancels out
Central ray, side whiskers
Parallel side rays
Whiskers

18. Constrained movement (motor control)
Steering behaviours provide movement requests, i.e. acceleration vector.
Some objects may not be able to immediately realise the request, e.g. a car can only accelerate forward/backward (with different rates) and has a turning rate that varies with movement speed, i.e. different objects can have different behaviours.
In order to realise movement requests, a motor control layer can determine how best to execute a request, a process known as actuation.

19. Achievable linear and angular acceleration
Constrained movement (filtering)
The simplest actuation approach is to remove all components of the steering output that cannot be currently realised.
Running the filtering algorithm every update tick (the steering output may remain constant) the object will move to match the steering target.
This approach is easily implemented, fast and reasonably effective, however, it can result in much smaller than requested accelerations (which can be detected and avoided if desired).
Achievable linear and angular acceleration
Requested
linear acceleration
angular acceleration

20. Maximum reversing distance
Constrained movement (cars and bikes)
Vehicular movement can be constrained using decision arcs.
A forward arc in which the vehicle will turn towards the target without braking.
A rear arc (with a maximum range) in which the car will reverse towards the target.
The arcs shrink based on movement speed and amount of grip. At low speeds the forward and rear arc must touch (to prevent breaking deadlock at low speed).
If the target lies between the two arcs, then the vehicle will break and turn towards the target.
Maximum reversing distance
Rear arc
Front arc
Front arc
Rear arc
Breaking arc
The reasons for these arcs are due to the movement constraints of cars/bikes – i.e. they cannot turn if stationary, they can’t move sideways (unless you count skidding). The turning ability is determined by the grips of the tires and is effect by travel speed. Acceleration typically varies based on the gear and degree of acceleration. Bikes typically are constraints by now being able to move backwards.

21. Summary
Today we explored:
More advanced steering behaviours including path traversal and collision avoidance
Constrained movement using actuation
To do:
If applicable to your game, test and explore movement algorithms.
Work towards your alpha-code hand-in