The second week of GSoC involved getting the behavior trees integrated with the Oreons, and thus the ability to run different animation loops based on the scenario in the game.

Deltas for Oreons

The basic prefab of an Oreon creature is defined in the Oreons modules. This prefab declares the ‘bare bones’ features of an Oreon like its skeletal mesh, its animation loops for standing, walking etc. In order to add components to this prefab a delta[1] was added to MOO which declares the behavior tree to be used.

Finding a task

The core behavior of an Oreon in MOO is its task acquistion. The Oreon while roaming leisurly in the village constantly looks for tasks to do. The behavior tree of an Oreon consists of guard node which checks the value of the assignedTaskType field in the TaskComponent attached to the Oreon, as long as this value is none the Oreon follows the critter behavior tree. When an Oreon finds a task it walks to the concerned area and performs the task. This involved implementing two new Oreon specific behavior nodes the look_for_task and perform_task, the former requests the task management system for a task which in turn checks the Holding and modifies the Task Component attached to the Oreon according to the new task assigned, the latter node is where the magic happens, the task is performed and concerned blocks are placed in the world.
Currently the perform_task node is just a placeholder and just logs a message (intended for debugging).

Oreon Behavior Tree

Adding tasks to be done

In order to test the above BT I implemented the basic outline of the Task Management System, the Holding System and the task creation UI.

Task Creation

Many different approaches for the flow of the task creation logic were discussed including use of a menu for task selection and using different tools for specifying different tasks available in the village. Finally, it was decided the most ‘player-friendly’ version (considering the GSoC time constraint) would be the one below, select an area which would trigger the task selection screen then select a task for the area. The Cancel Selection button can be used to abandon the current selected area if the player changes their mind about the selection made.

Task Selection Screen

Holding System

The Holding System is the one place to store information about the happenings in the village. All the tasks created, all areas which are marked with a task are stored here and would act as a base for the overview system in the future. The Holding Component is attached to the player entity owning the village, this component currently has two fields a availableTasks queue and a list of all the areas that have marked for a particular task. Whenever a new task is created it is added to the end of the queue thus maintaining the order of execution same as the order in which these tasks are created.

Task Management System

The Task Management System consists of all the task related logic for MOO. An Oreon looking for a task, requests this system. The Task Management System then checks the Holding attached to the player for available tasks, if found it modifies the task component attached to the Oreon and removes this task from the availableTasks list. Addition of new tasks to the holding is also handled by this system, after the player selects an area and a task for this area is selected from the pop-up screen.

Task Creation Flow

Link to forum post for this week’s update.

Additional Info

+ What are Deltas and Overrides?
A module can use prefabs defined in another module, but if modification to these prefabs are required to make them work with the new module, it is accomplished by using Deltas and Overrides. The basic difference between the two is : Deltas - modify a single value or sets of value in a existing prefab. Overrides - modify the entire prefab. For details related to the usage of deltas and overrides refer this Wiki