1. Project M.AI.S. Multi-threaded AI system Per Erskjäns game engineer

2. 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.

3. Project reasons Get experience working with a multi-threaded environment. Get experience working with a behavior tree. Train my self in data oriented design.

4. Result 50 – 85 % framerate gain with 2 threads. Not tested on quadcore computer. Gain depends on computational cost. Only one class with heritage.

5. Result A data oriented behavior tree. A component based entity system. There are many oppertunities for optimization, was not a focus.

6. System design Scheduler Graphics system Movement system AI system Sensory system Framework Main loop update changes Distribute changes

7. 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.

8. 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.

9. 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.

10. Behavior tree design All 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 run through a initiation function to set the correct function pointers.

11. 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.

12. 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.

13. 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.

14. Conclusion Did learn much, both small and big things. Learned most from research, not implementation. Didnt get as deep knowledge of task managment as planed. Mainly because of TBB. Unit testing could have helped.

15. Questions ?