AI (FSM, Behavior Tree, GOAP,

Utility AI)

AI​
Nez includes several different options for setting up AI ranging from a super simple
transitionless finite state machine (FSM) to extendable behavior trees to ultra-flexible
Utility Based AI. You can mix and match them as you see fit.

Simple State Machine​

The fastest and easiest way to get AI up and running. Simple State Machine is a
Component subclass that lets you set an enum as its generic constraint and it will use
that enum to control the state machine. The enum values each map to a state and
can have optional enter/tick/exit methods. The naming conventions for these methods
are best shown with an example:

enum SomeEnum
{
Walking,
Idle
}

public class YourClass : SimpleStateMachine<SomeEnum>()

{
void OnAddedToEntity()
{
initialState = SomeEnum.Idle;
}

void Walking_Enter() {}
void Walking_Tick() {}
void Walking_Exit() {}

void Idle_Enter() {}
void Idle_Tick() {}
void Idle_Exit() {}
}

State Machine​
The next step up is State Machine which implements the "states as objects" pattern.
State Machine uses separate classes for each state so it is a better choice for more
complex systems.

We start to get into the concept of a context with State Machine. In coding, the context
is just the class used to satisfy a generic constraint. in a List<string> the string
would be the context class, the class that the list operates on. With all of the rest of the
AI solutions you get to specify the context class. It could be your Enemy class,
Player class or a helper object that contains any information relevant to your AI
(such as the Player , a list of Enemies, navigation information, etc).

Here is a simple example showing the usage (with the State subclasses omitted for
brevity):
 // create a state machine that will work with an object of type SomeClas
var machine = new SKStateMachine<SomeClass>( someClass, new PatrollingSt

// we can now add any additional states

machine.AddState( new AttackState() );
machine.AddState( new ChaseState() );
Behavior Trees​
// this method would typically be called in an update of an object
machine.Update(
The de facto standardTime.deltaTime
for composing AI);for the last decade. Behavior trees are
composed of a tree of nodes. Nodes can make decisions and perform actions based
on//thechange
state ofstates. the
the world. state
Nez machine
includes will automatically
a BehaviorTreeBuilder create
class that and cache
provides a
machine.ChangeState<ChasingState>();
fluent API for setting up a behavior tree. The BehaviorTreeBuilder is a great way to
reduce the barrier of entry to using behavior trees and get up and running quickly.

Composites​
Composites are parent nodes in a behavior tree. They house 1 or more children and
execute them in different ways.

Sequence: returns failure as soon as one of its children returns failure. If a child
returns success it will sequentially run the next child in the next tick of the tree.
Selector: returns success as soon as one of its child tasks return success. If a child
task returns failure then it will sequentially run the next child in the next tick.

Parallel: runs each child until a child returns failure. It differs from Sequence only
in that it runs all children every tick

ParallelSelector: like a Selector except it will run all children every tick
RandomSequence: a Sequence that shuffles its children before executing
RandomSelector: a Selector that shuffles its children before executing

Conditionals​
Conditionals are binary success/failure nodes. They are identified by the IConditional
interface. They check some condition of your game world and either return success or
failure. These are inherently game specific so Nez only provides a single generic
Conditional out of the box and a helper Conditional that wraps an Action so you can
avoid having to make a separate class for each Conditional.

RandomProbability: return success when the random probability is above the

specified success probability
ExecuteActionConditional: wraps a Func and executes it as the Conditional. Useful
for prototyping and to avoid creating separate classes for simple Conditionals.

Decorators​
Decorators are wrapper tasks that have a single child. They can modify the behavior of
the child task in various ways such as inverting the result, running it until failure, etc.

AlwaysFail: always returns failure regardless of the child result

AlwaysSucceed: always returns success regardless of the child result

ConditionalDecorator: wraps a Conditional and will only run its child if a condition is
met
Inverter: inverts the result of its child

Repeater: repeats its child task a specified number of times

UntilFail: keeps executing its child task until it returns failure

UntilSuccess: keeps executing its child task until it returns success

Actions​
Actions are the leaf nodes of the behavior tree. This is where stuff happens such as
Nez framework playing an animation, triggering an event, etc. Search ⌃ K
documentation
ExecuteAction: wraps a Func and executes it as its action. Useful for prototyping
Nez Setup and to avoid creating separate classes for simple Action s.

Nez Core
WaitAction: waits a specified amount of time

LogAction: logs a string to the console. Useful for debugging.

Scene-Entity-Component
Rendering BehaviorTreeReference: runs another BehaviorTree

Content management
Goal Oriented Action Planning (GOAP)​
Dear IMGUI
GOAP differs quite a bit from the other AI solutions. With GOAP, you provide the planner
Physics
with a list of the actions that the AI can perform, the current world state and the desired
Farseer physics world state (goal state). GOAP will then attempt to find a series of actions that will get
the AI to the goal state.
Verlet physics

Entity Processing Systems

GOAP was made popular by the old FPS F.E.A.R. The AI in F.E.A.R. consisted of a GOAP
and a state machine with just 3 states: GoTo, Animate, UseSmartObject. Jeff Orkin's
Deferred lighting web page is a treasure trove of great information.
Nez UI

Pathfinding
ActionPlanner​

Runtime Inspector
The brains of the operation. You give the ActionPlanner all of your Actions, the current
world state and your goal state and it will give you back the best possible plan to
Svg Support achieve the goal state.
AI (FSM, Behavior Tree, GOAP, Utility
AI) Action/ActionT​
Links
Actions define a list of pre conditions that they require and a list of post conditions that
will occur when the Action is performed. ActionT is just a subclass of Action with a
handy context object of type T.

Agent​
Agent is a helper class that encapsulates an AI agent. It keeps a list of available
Actions and a reference to the ActionPlanner. Agent is abstract and requires you to
define the GetWorldState and GetGoalState methods. With those in place
getting a plan is as simple as calling agent.Plan() .

Utility Based AI​

Utility Theory for games. The most complex of the AI solutions. Best used in very
dynamic environments where its scoring system works best. Utility based AI are more
appropriate in situations where there are a large number of potentially competing
actions the AI can take such as in a RTS. A great overview of utility AI is available here.

Reasoner​
Selects the best Consideration from a list of Considerations attached to the Reasoner.
The root of a utility AI.

Consideration​
Houses a list of Appraisals and an Action. Calculates a score that represents
numerically the utility of its Action.

Appraisal​
One or more Appraisals can be added to a Consideration. They calculate and return a
score which is used by the Consideration.

Action​
The action that the AI executes when a specific Consideration is selected.

Previous Next
Svg Support Links
Powered By GitBook

Last modified 4yr ago WAS T H I S PAGE HEL PFUL?