Here's a simple model for Game AI that I've come to use. I would appreciate hearing your thoughts on it, positive or negative.

I like that it scales nicely between different types of projects. It also abstracts the idea of the AI problem being solved from the specific technique used to solve it.

How does this map to the way you approach AI in your projects? Thank you for any input.

It's very common to use layers of multiple AI algorithms or tools to control characters. In particular, the idea of using utility values to choose high-level activities and then a state-machine like system (e.g hierarchical finite state machine, or behaviour trees) to execute them is a common and reasonable approach. If you need a planner in between (e.g. HTNs, GOAP) for your problems then that is fine too, although often not necessary as planning can often be done implicitly via the utility functions or embedded within the task execution itself.

What I haven't seen before is the idea that these algorithms exist in some sort of cycle; it's not clear to me how that would work in practice.

This is just a normal AI state machine, you show here. It isn't what people call high-level, but I bet high-level AI do have a lot of state machines; so maybe the first steps to a high-level AI.

There is no real criticism to provide year because this is a good idea. State machines are the back bone of many components in game engines. They make a lot of sense when you look at them and is very flexible.

The most common problem with any system like this is dependency, a bug in the code effects the whole system instead of just a part of it. So you need some way to see what is happening where to debug the code. Making debugging slow.

Some people solve this with a visualizer that allows you to see how properties change over time and how they effect other code.

**Gamedev didn't tell me someone responded, a bug or part of the new system?**

52 minutes ago, Scouting Ninja said:

This is just a normal AI state machine, you show here. It isn't what people call high-level, but I bet high-level AI do have a lot of state machines; so maybe the first steps to a high-level AI.

Hey Ninja. My apologies for making a misleading diagram. It doesn't depict a state machine. The arrows don't represent an agent transitioning between states.

Kylotan has it right- this shows a contextual model of how ai problems are divided into different domains, and how those different domains relate to each other to govern different parts of an agent's Ai.

Let me see if I can do a better job here. As an example, let's say you have an NPC agent:

1. All of the agent's behaviors are carried out by a 'Task Execution' system.
2. Maybe that agent is executing a behavior which listens for an event ("Enemy within range", let's say), then decides on a response.
3. In order to respond, it pings a separate 'Goal Forming' system to choose a new goal for the agent, based on the current game state. This goal is then returned to the behavior. This goal is actually a target game state, which the agent would like to achieve- For example: one in which the enemy's Health == 0.
4. The behavior then needs a sequence of behaviors which will actually form the response. It passes the goal game state to a Planner system, which looks through a wide space of available behaviors, and returns a sequence of them which can transform the current game state into the target (goal) state. Example: ["Run to Enemy", "Kill Enemy"]
5. The behavior then hands this plan of behaviors back to the Execution system, which sets about performing those behaviors.

The last point is that these Systems (Execution, Goal Forming, Task Planning) are abstracted from the specific ai techniques used to accomplish them. In the diagram, A Utility AI is being mapped to the Goal Forming domain. But in another project, a different technique might be used to choose goals. In that case, the AI technique may have changed, but the 'Goal Forming' purpose of the domain would not.

Any better?

5 hours ago, Henrik Luus said:

It doesn't depict a state machine.

This description is better. However that only makes me think that debugging will be even more difficult.

5 hours ago, Henrik Luus said:

The behavior then needs a sequence of behaviors which will actually form the response. It passes the goal game state to a Planner system, which looks through a wide space of available behaviors

So the same as forming a sentence. Just like there are Subjects, Verbs and Nouns you use similar categories to form a "idea" for your AI?

Quote

So the same as forming a sentence. Just like there are Subjects, Verbs and Nouns you use similar categories to form a "idea" for your AI?

Kind of! What I was describing there is just the function of a planner AI- to build a sequence of tasks which can accomplish some goal.

Thanks, @IADaveMark. 

• In my implementation, each behavior queue has its own blackboard structure, which its active behavior can use to store some state data. The agent itself also has a blackboard, which multiple behaviors can use to communicate with each other.
• In my code, each behavior queue can have a set of tags. This makes it simple to do thing like “pause all behavior queues dealing with movement”, for example.
• beyond clearing a behavior queue, a new behavior can be inserted at any index in a queue. So for example, an agent with a plan to interact with ‘thing A’, and then ‘thing B’ could have new behaviors inserted in the middle of the queue to give it a third stop along the way.

Do you have any thoughts on this pattern? How does this compare to what's already out there for handling task execution work?

Regardless, thank you for reading such a long post.

(Apologies for the image spam below. I don't know how to make these appear smaller. ?)