The past two weeks were rather low on the “things accomplished” front as compared to the past ones mainly because I am a bit ahead considering timeline laid down in the proposal and also due to some health related bumps along the way.
Squashing bugs
I resolved two issues from the pool thus we are now up to 3 out of 6. Area selection texture are now rendered according to the Task after a Task has been assigned to the area. This would act as a visual clue for the player about what the area has been selected for. Although this was a pretty
straightforward task, just specifying the Texture in the BlockSelectionComponent before attaching it to the taskEntity, it motivated me to implement a new class Task which could have the various types of tasks as children. This object oriented approach would not only clean up
the task component but would also make it easier to add new types of task in the future.
This resolved the following
issue :
Another bug was related to the serialization of Queues, as there was no TypeHandler implemented for a Queue the field availableTasks in the Holding was not serialized thus leading to the loss of assigned tasks when loading a saved game. Implementing the required handler and
tweaks to the engine’s SerializationLibrary resolved the following :
A Task object
Impelementing a object oriented approach for the different task types would not only make the codebase more readable but also lead to a much easier way to add new types of tasks and implementing the related logic. This involved implementing a new Taskclass with fields specifiying
the task related information like its effect on various Oreon attributes, its area texture, buildng required if any etc. All the tasks now extend this base class and specify the required field value in their constructor and saving this object the TaskComponent. This rendered moot the various switch
statements all over the codebase which were used to have different effects for each task type.
Fence Construction
In order to improve the MOO experience further I implemented the fence construction logic for the selected areas. As soon as the player assigns a task to the selected area fence blocks are placed all around it. In the future these fences would be placed around the area differently for all the tasks,
for instance for Plant the area selected would be final whereas for the Build task this area would have to be calculated according to the building to be constructed, moreover no such fences would be required for Guard and other such tasks.
FlexibleMovement for the Oreons
After construction of a buidling and the fence block placement around it, this area would prove no less than a maze to the Oreon going to task areas in or out of the buildng.This is due to the current logic used for the Oreon path calculation, which moves the Oreon along a staright path towards the target blocks, though it jumps if a block “blocks” the way, this would not be of much help if it is stuck behind a wall of a building. In order to overcome this I tried to modify the FlexibleMovemnt implementation by kaen,.its implementaion has to be altered to work with the new Behaviors implementation. I got an initial version of this working by implementing the various behavior trees and related nodes from scratch but for some reason this is not able to fetch the required path from the Pathfinding system, which gets stuck in an infinte loop trying to provess the surrounding blocks. Due to this unexpected issue in a different module this is still a WIP and Oreons for now keep getting stuck trying to jump their way out of the situtation.
Up next week
Next week would involve some interesting implementations related to the village Research System. This would involve adding the Research Tasks to be performed by the Oreons resulting a block or a potion which can be used by the player for a better Oreon performance among other things. All related logic to be implemented i.e how would the Research be used by the player is still under discussion.