Project M.AI.S.Multi-threaded AI system
Per Erskjänsgame engineer
Project goals
• A system that scales to the number of available cores.
• AI implemented with a data oriented behavior tree.
• Work with a data oriented mindset.• Flocking behavior with simple graphical
representation.• AI behavior not the main focus.
Project reasons
• Get experience working with a multi-threaded environment.
• Get experience working with a behavior tree.• Train my self in data oriented design.
Result
• 50 – 85 % framerate gain with 2 threads.
• Not tested on quadcore computer.
• Gain depends on computational cost.
• Only one class with heritage.
Result
• A data oriented behavior tree.
• A component based entity system.
• There are many oppertunities for optimization, was not a focus.
System design
Scheduler
Graphics system
Movement system
AI system
Sensory system
FrameworkMain loop
update
update
update
update
changes
changes
Distribute changes
System design
• One change que per thread, using thread local storage.
• Each system have ownership over 0 – many attributes. Only one owner per attribute.
• Max number of entites are preallocated into system specific arrays at application start.
System design
• Serial or parallel system update depending on entity numbers.
• In parallel update the update loop is split in to tasks.
• Intel Threading Building Blocks, used for task managment.
Behavior tree design
The implementation is a data oriented solution without heritage,virtual functions and recursion.
The whole tree is laid out in a flat array in a depth first order.
Behavior tree designAll nodes share the same data structure;
struct BehaviorTreeNode{
node_types::Enum node_type;union{
u32 end; BehaviorFunction execute;
};};
After the creation of a tree (or loaded it from disk) the array is runthrough a initiation function to set the correct function pointers.
Behavior tree design
• Each AI entity is represented as a BehaviorTreeInterpreter object, containing a blackboard (keeps the entity knowledge) and a pointer to the appropriate behavior tree.
• On each frame an interpreter function loops through the behavior tree.
Behavior tree design
• The parent nodes are pushed or poped to/from a stack and used to decide how to handle a return state from a behavior function.
Problems
• Not to many problems but some things that took more time than needed to solve.
• Some really stupid misstakes like a (–) instead of a (+) in some calculations.
• Some strange bugs with SFML.
Conclusion
• Did learn much, both small and big things.• Learned most from research, not
implementation.
• Didn’t get as deep knowledge of task managment as planed. Mainly because of TBB.
• Unit testing could have helped.
Questions
?