This document discusses various approaches to game AI, including intelligent agents, neural networks, finite state machines, decision trees, behavior trees, and the goal-oriented action planning technique. For each approach, it provides pros and cons as well as examples. The techniques range from simple reflex agents to more complex learning agents. The document advocates considering the specific needs of a game before choosing an AI technique and provides guidance on when different approaches may be suitable.

1. Approaches to game AI
Ivan Dolgushin
Game developer at Appturn

2. Artificial Intelligence
Artificial intelligence (AI) is
the intelligence exhibited
by machines or software.

3. Intelligent Agent
• simple reflex agents
• model-based reflex agents
• goal-based agents
• utility-based agents
• learning agents

4. Why should we bother?
• philosophy: understanding the
nature of thought and the nature
of intelligence and building
software to model how thinking
might work;
• psychology: understanding the
mechanics of the human brain
and mental processes;
• engineering: building algorithms
to perform human-like tasks;

5. Duck-testing game AI
If it looks like a duck,
swims like a duck,
and quacks like a duck,
then it probably is a duck.

6. Simple vs Complex
• Simple things can look good.
• Complex things can look bad.

7. Not Too Hard, Not Too Easy

8. Not Too Hard, Not Too Soft

9. What do we need it for?
• Steering
• Pathfinding
• Decision making
• Learning
• Predicting actions
• Group AI and
coordinated actions
• Sensory input

10. Cowboy Style

11. Neural Networks

12. NN: Summary
Pros:
• mass parallelism;
• distributed representation of
information and computation;
• ability to learn and generalize;
• adaptability;
• process information in the
context;
• tolerant to errors.
Cons:
• hard to teach;
• hard to test;
• hard to interpret data.
Summary: think twice before adopting in your project

13. Finite State Machines

14. FSM: State Polling vs Event

15. FSM: State Polling vs Event

16. FSM: To Stack Or Not To Stack

17. FSM: Example
Stack-less event-based FSM example:
<stateMachine>
<states>
<state class="move" id="moveAfterStampede" animation="move" speed="1.6" walkTime="2.33"/>
<state class="dead" id="dead"/>
<state class="getout" id="getout" initial="initial" animation="getout"/>
...
<state class="wait" id="rot" animation="rot" delay="3"/>
<state class="wait" id="disappear" animation="disappear"/>
</states>
<events>
<state id="disappear">
<event name="animationEnd"><state id="dead"/></event>
</state>
<state id="rot">
<event name="waitEnd"><state id="disappear"/></event>
<event name="wait"><state id="waitForRevive"/></event>
</state>
<state id="die">
<event name="animationEnd"><state id="rot"/></event>
</state>
<state id="getout">
<event name="animationEnd"><state id="stampede"/></event>
<event name="hit"><state id="stampedeHit"/></event>
</state>
...
</events>
</stateMachine>

18. FSM: Summary
Pros:
• easy to understand;
• flexibly parameterized;
• allow wide variety of
abstraction levels;
• easy to interpret;
• easy to test;
• has a lot of well described
modifications.
Cons:
• large FSM can be hard to
comprehend;
• hard to maintain large FSMs;
• don’t learn;
• has no memory;
• trivial state switching triggers
logic;
• may force some redundancy.
Summary: nice universal option for most small-to-mid
projects. Good starting point if you have few well defined
behaviors.

19. Growing Trees

20. Decision Trees

21. DT: Linearization

22. DT: Linearization
If no HP left
Then monster is dead
Else If player is in melee radius and monster can use a ‘Hammer’ skill
Then monster uses ‘Hammer’
Else If player is close
Then monster flees (move) from a player
Else If player is in aggro-radius and monster can use a ‘Summon’ skill
Then monster uses ‘Summon’
Else If player is in shooting radius
Then monster shoots
Else If player is in aggro-radius
Then monster chases them (move)
Else Monster wanders (move) around the room

23. DT: Summary
Pros:
• easy to understand;
• easy to interpret, especially
in linearized form;
• easy to reuse subtrees;
• easy to add learning
• easy to understand learnt
knowledge.
Cons:
• don’t learn;
• has no memory;
• depends on world state, not
on events in the world;
• may force some
redundancy.
Summary: good for turn-based games and other games
with atomic (instant) actions and a lot of factors with the
few significant values each.

24. Behaviour Trees

25. BT: Flow Control
Selector (any) Sequence (all)
Result:
• Success
• Failure
• Running

26. BT: If-Else
Result:
• Success
• Failure
• Running

27. BT: Example

28. BT: Example
<all> <!-- Attacking block -->
<isPlayerInRoom/>
<isPlayerInAggroRadius/>
<callForBackup/>
<any> <!-- Using skills block -->
<any>
<all> <select target="Player"/> <use skill="Advanced"/> </all>
<all> <select target="Player"/> <use skill="Basic"/> </all>
</any>
<go to="Player"/>
</any>
</all>

29. BT: Summary
Pros
• very flexible and extensible;
• easy to interpret after some
practice;
• extends strengths of DTs with
some FSM features;
• allows to work on different
abstraction/detail levels;
• high modularity;
• easy to reuse subtrees.
Cons
• require certain mindset to
comprehend;
• explicit flow control
configuration may sometimes
look redundant;
• don’t learn;
• has no memory;
• depends on world state, not on
events in the world;
Summary: great technique for all variety of project sizes
and complexities, if you are willing to learn thinking in BT-
way.

30. Cause vs Goal

31. GOAP

32. GOAP

33. GOAP: Example

34. GOAP: Example
1. GetAxe<2>  ChopLog<4>  MakeCampfire<1> = 7
2. CollectBranches<8>  MakeCampfire<1> = 9
3. GetAxe<2>  CollectBranches<8>  MakeCampfire<1> = 11

35. Thank you!
Questions?
Ivan Dolgushin
ivand@appturn.com