Goals:
- Explain how to design AI Behaviour
- Explain how to design AI decisions, and how to leverage systems, how to handle priority/dependencies
- Explain how to design Actions. Explain *briefly* how decisions handle switching.
In the Designing AI and Creating AI pages, you'll be shown how to create a Woodcutter AI with a variety of features.
Designing AI with VisAI is simple. There are 3 steps. Creating the Behaviour of your AI, creating the Decisions for your AI, and creating the Actions for your AI.
The AI will get a tool when needed, chop down the nearest tree, and deposit it into the nearest stockpile with inventory availability. If storages are full, they will stop all together.
We'll begin by designing the Behaviour for our AI.
VisAI provides you with a set of AI systems designed to give you powerful features that are performant and easy to use. You can use these systems while creating decisions, actions, and more.
You will find most AI systems in the AI Controller, located within their own graph. However, some are located in the Character as Actor Components. To learn about extending or modifying an AI system, check out the Modifying the Framework page.
You can learn more about each system individually by visiting the links below:
Designing behaviour is designing what your AI is, how it functions, what it's capabilities are. Behaviour defines your AI as a whole.
The Behaviour Structure in VisAI is based around Behaviours, Goals, and Plans.
Behaviours are what the AI is, or does. It allows you to switch between behaviours easily when using advanced AI such as RTS citizens, which have many capabilities.
Goals are what the AI wants. What would an AI in your game want? Our woodcutter wants to gather wood, and do nothing when it's done!
Plans are how the AI could get what it wants. What does your goal require? Our gather wood goal requires a tool, and chopping down trees.
The structure ends up looking something like this:
Designing Decisions is easy. You'll create considerations for each "B/G/P" you have, which then assign a score to the decision based on it's findings. Scores are arbitrary and define the priority of decisions.
Conditions and Scoring
Decisions work a little differently than other AI
Example 1
A decision could check static values such as "Do I have a key in my inventory?" to check if an AI can unlock a door;
Example 2
As a wider consideration, your AI could check "Do any enemies have low health?" to see if there are any enemies with low health that they could target and take out quickly.
You'll design the conditions for each decision, then apply a score based on the decisions findings.
Example 1
Do I have the key in my inventory? Yes, give a score of 1.
Example 2
Of all the enemies I see, do any of them have health below 30%? Yes, Target them first.
Decision Inferring
Because of the way that the behaviour system splits the decisions, we can use the structure to infer information, thus reducing overall cost.
As an example:
A goal such as Kill Enemy would do a simple check, "Any enemies in sight?"
If so, we would consider the plans for the goal.
Now, when designing the plans for Kill Enemy, we can *infer* that any time these plans are considered, there is an enemy in sight.
Structure and Performance
Because of the way the B/G/P structure splits decision making, you're only considering the decisions that make sense to consider.
As an example:
The FPS AI have 3 goals. Kill Enemy, Stay Alive, and Look for Enemies. While the AI is looking for enemies, it's not considering how it needs to kill an enemy, or how it needs to stay alive. It only considers whether or not they *should* be doing it. So, the Decision System ends up only checking if there are any enemies to kill, or if the AI's health is low, rather than considering everything at once.
Now that our Decision System is feeding information into the Behaviour System, all that's left to do is create Actions.
With the Decision and Behaviour Systems handling structure and decisions, Actions are free to do their work.
Actions are simple tasks within the behaviour tree, but with the kick of not having to worry about starting or stopping them. Because of the Behaviour enumerators in the Behaviour Tree, when a new decision is made, the tree automatically switches to the correct action.
If you have logic such as a move to task, which may need to be canceled, you can use the "Event End Execute" event to stop any logic necessary.