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).
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.
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.
Link to forum post for this week’s update.
Additional Info
.