The main goal when implementing hierarchical behaviors for an AI engine is to allow them to be as modular as possible, while still allow them to interact with other behaviors. You have two ways of doing this: a centralized approach, or a decentralized one. The AI logic in both cases can end up the same, but the implementation is very different.
In this case, each behavior is responsible for the memory management and updating of any other behavior it depends on.
- There’s nothing imposed on the programmer/scripter who wants to create a new behavior in the hierarchy. The child behaviors are run by their parents, so both are always running in parallel.
- Managing many behaviors quickly becomes very tedious, even with good helper functions/classes. It can be less efficient, and it’s much harder to disconnect child behaviors who need to run longer than their parent.
Here, common facilities are used to manage the execution and the data for each behavior. So when dependencies in the hierarchy are necessary, any behavior can just request another to be allocated and run.
- Simpler to work with for programmers, and has many optimization benefits. Behaviors have the option of running in parallel with their children if necessary.
- If you get the central part wrong in any way, it can really burn you!
Nothing is stopping you from providing an optional set of services to manage the computation and memory, but making them optional for the behaviors. In practice, this turns out to be a healthy compromise, but there are many important decisions to make, and many ways to get it wrong.
The next articles will look at how to implement this, and good practices to help content creation go smoothly.