The first week of GSoC was a smooth one, with just making some dependency[1] changes for the MasterOfOreon module and getting the Oreons to spawn correctly in the world.

Retiring the Miniion module

Currently the Miniion module is composed of a lot of deprecated code and recent changes to the engine have rendered it to an unusable state. MasterOfOreon has(rather had) a dependency on the Miniion module for its Task Management System and assigning AI behaviors to the minions spawned in the world. Removing Miniion dependency was a straight-forward task which just involved deleting out the Miniion related code and adding some comments for later refferal. The Task Management system will implemented from scratch as a part of my project and as far the AI assignment to creatures is concerned it is to be done using the the shiny new Behavior Trees[2].

Spawning the Oreons

The feature to spawn creatures into a world was previously implemented in the Spawning module, as evident from the fact that it is a fairly old module and it only supports spawning one type of creatures the Oreons buggy behavior from it was expected. But it was cool to watch the Oreons come alive for the first time.

spawning
Buggy Oreon spawn from Portals

The idea behind the Spawning module was to create a way to spawn a plethora of creatures into the world hence the multiple Oreons and since they the Oreons do not have any behaviors attached they just remain static at the location of spawn. This is where my work began. I started by adding the Portal block to the module and then attaching an interaction screen with it, which can be triggered using the e key when the Portal is in your crosshairs. The interaction screen displays the options for various Oreons available and their item requirements for spawn. An initial implementation involved the use of Dirt and Sand blocks, but these would be replaced in the future with more “oreon-centric” items.

interactionscreen
Screen for selecting the Oreon to spawn

So, using the minimalistic screen above a player can now spawn three types of Oreons given that they have the required items in their inventory. The items required by the Oreon for spawning are defined in their prefabs[3] as below:

"OreonSpawn" : {
         "itemsToConsume" : {
             "BlockFamily[core:Dirt]" : [1],
             "BlockFamily[core:Sand]" : [2]
         }
 }

The OreonSpawn component would be attached to every spawned Oreon entity and consist of some basic information about the Oreon like its owner that are required by the Central Holding to keep track of happenings in the village, but I am getting ahead of myself. More on this later!

oreons spawned
All hail the Oreons!

List of issues and PRs

Additional Info

+ What is a module dependency?
Module dependencies are similar to dependencies for java libraries. If module 'A' has a dependency on module `B` then all the features implemented in module B and all its methods can be used in `A` thus avoiding repetition of code and redundancy. When module A is activated while creating a new game `B` will be activated automatically.
For details like how to declare a dependency and how they are resolved see this Module Dependencies wiki.
+ What are Behavior Trees?
A behavior tree is a collection of various nodes. These behavior nodes consist of logic related to the behavior of the entity the tree is attached to. A node is executed based on the result obtained from its parent node, which can be `RUNNING`, `SUCCESS` or `FAILURE`. This tree is executed with every game update tick until a node returns `RUNNING`. See this forum post by the curator of BTs and this wiki link for details about various core behavior nodes that have already been implemented.
behaviortree
A basic Behavior Tree
+ What is a prefab?
A prefab is a JSON file which describes an entity, all the components attached to it and the values of different fields in those components. Wiki link

.