Oreon’s leisurely tasks

In the previous week BTs were attached to the Oreons which enabled them to look for various tasks added by the player like build, guard, plant etc. walk to the added location and “perform”(just a log message for now) these tasks. But if a player has added no such tasks or all these tasks are completed by our hard working Oreons, they would be idle. This is the time the Oreon chooses to work on itself i.e. satisfy their hunger, sleep if it is night time or training to improve its attributes. Two out of these three tasks were on my agenda this week.

Eating

An Oreon while working on any task works up an appetite, +30 to its hunger attribute everytime it finishes a task. As soon as the hunger value grows beyond 50 it starts looking for Diners in the village, if found walks to it completes a eating task thus reducing its hunger value to zero. The Diner currently is just an area that the player previously marked for a diner building task. As an enhancement to the gameplay this would be later replaced with a fancy building for the Oreon to walk into. If the Oreon, however cannot find a diner, the player is notified about its hunger with a request to build one.

Sleeping

An idling Oreon constantly checks if it is currently night in the village and sneaks in some sleepy time into its busy schedule. The Oreon would heal after completing each sleeping task.

Both of these advanced tasks are added into the advancedTaskAcquiring behavior for the Oreons which uses a selector node(wiki here). This node runs until one of the child returns SUCCESS. Therefore, this can be used to emulate priority based task selection, the task nodes higher up in the BT will be checked for their conditions first and if met the further tasks would not be performed.

{
   "selector" : [
        "needs_food",
        "needs_sleep",
        "...",
        "..."
    ]
}

Consider the current BT shown above, the eating task is given a higher priority than sleeping, so a hungry Oreon would(rather should not :) ) not go to sleep.

The battle with multiplayer

I spent a major a part of this week debugging the multiplayer gameplay of MOO. A major problem that I faced was with the block selection for assigning tasks. Trying to get the block selection to render correctly in multiplayer is what I am stuggling with right now. The current implementation of the BlockSelectionSystem does not work correctly in multiplayer, I tweaked it a bit by adding replicate annotations where required and adding NetworkComponent to all necessary entities. But, so far the area only renders in the client for a while and then vanishes Also, the CameraTargetChangedEvent is sent by a localPlayer after the selection process has begun but still this is attached to the host client’s held item, so if a connected client tries to start a selection, the area of the selection can be changed by the host client by moving their camera.​ The changes I made to the block selection logic can be checked here on my fork of the Terasology repository in conjuction with the latest branch of MasterOfOreon.

Up next week

Training the Oreons to enhance their attributes(strength, intelligence) will be implemented next week. So an idling Oreon will improve its attributes and become a better worker in the village.