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

?