Combining behaviors using a steering pipeline

This is a different approach to creating and blending behaviors that is based on goals. It tries to be a middle-ground between movement-blending and planning, without the implementation costs of the latter.

Getting ready

Using a steering pipeline slightly changes the train of thought used so far. We need to think in terms of goals, and constraints. That said, the heavy lifting rests on the base classes and the derived classes that will define the behaviors; we need to start by implementing them.

The following code is for the Targeter class. It can be seen as a goal-driven behavior:

using UnityEngine;
using System.Collections;

public class Targeter : MonoBehaviour
{
    public virtual Goal GetGoal()
    {
        return new Goal();
    }
}

Now, we create the Decomposer class:

using UnityEngine;
using System.Collections;

public class Decomposer : MonoBehaviour
{
    public virtual Goal Decompose (Goal goal)
    {
        return goal;
    }
}

We also need a Constraint class:

using UnityEngine;
using System.Collections;

public class Constraint : MonoBehaviour
{
    public virtual bool WillViolate (Path path)
    {
        return true;
    }

    public virtual Goal Suggest (Path path) {
        return new Goal();
    }
}

And finally, an Actuator class:

using UnityEngine;
using System.Collections;

public class Actuator : MonoBehaviour
{
    public virtual Path GetPath (Goal goal)
    {
        return new Path();
    }

    public virtual Steering GetOutput (Path path, Goal goal)
    {
        return new Steering();
    }
}

How to do it...

The SteeringPipeline class makes use of the previously implemented classes in order to work, maintaining the component-driven pipeline but with a different approach, as mentioned earlier:

1. Create the SteeringPipeline class deriving from the Wander behavior, including the array of components that it handles:

   using UnityEngine;
   using System.Collections;
   using System.Collections.Generic;
   
   public class SteeringPipeline : Wander
   {
       public int constraintSteps = 3;
       Targeter[] targeters;
       Decomposer[] decomposers;
       Constraint[] constraints;
       Actuator actuator;
   }

2. Define the Start function to set the references to the attached components in the game object:

   void Start ()
   {
       targeters = GetComponents<Targeter>();
       decomposers = GetComponents<Decomposer>();
       constraints = GetComponents<Constraint>();
       actuator = GetComponent<Actuator>();
   }

3. Define the GetSteering function to work out the goal and the steering value to reach it:

   public override Steering GetSteering()
   {
       Goal goal = new Goal();
       foreach (Targeter targeter in targeters)
           goal.UpdateChannels(targeter.GetGoal());
       foreach (Decomposer decomposer in decomposers)
           goal = decomposer.Decompose(goal);
       for (int i = 0; i < constraintSteps; i++)
       {
           Path path = actuator.GetPath(goal);
           foreach (Constraint constraint in constraints)
           {
               if (constraint.WillViolate(path))
               {
                   goal = constraint.Suggest(path);
                   break;
               }
               return actuator.GetOutput(path, goal);
           }
       }
       return base.GetSteering();
   }

How it works...

This code takes a composite goal generated by targeters, creates sub-goals using decomposers, and evaluates them to comply with defined constraints before "blending" them into a final goal in order to produce a steering result. If everything fails (the constraints are not satisfied), it uses the default Wander behavior.

There's more...

You should try to implement some of the behavior recipes in terms of targeters, decomposers, constraints, and an actuator. Take into account that there's room for one actuator only, and it's the one responsible for making the final decision. A good example is as follows:

• Targeters: seeking, arriving, facing, and matching velocity
• Decomposers: path-finding algorithms
• Constraints: avoiding walls/agents

See also

For more theoretical insights, refer to Ian Millington's book, Artificial Intelligence for Games.