Resource modules

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
Now that things are coming together on github, should we start providing models sets as pure resources without any extra information about how they will be used? Then provide additional modules to specify usage, along the lines of what LightAndShadow/Resources appears to be doing?

For example, the Oreons module prefabs contain references to spawners, minions, and character attributes. I would suggest that the OreonResources module only contain "persisted", "skeletalmesh", and "Animation". Maybe also Character/Location/CharacterMovement/CharacterSound as these are engine components. Then the user of this module would add in things like Minion, SimpleMinionAI, Inventory, AccessInventoryAction, and Spawnable in a prefab that inherits from Oreons:OreoBuilder.

Code:
{
    "persisted" : true,
    "location" : {},
    "skeletalmesh" : {
        "mesh" : "Oreons:OreoBuilder",
        "material" : "Oreons:OreonSkin",
        "animation" : "Oreons:BuilderIdle",
        "loop" : true
    },
     "Minion" : {
         "icon" = "minionskull",
         "Healthtotal" = 300,
         "Hungertotal" = 100,
         "Staminatotal" = 100
   },
    "CharacterMovement" : {
        "faceMovementDirection" : true
   },
    "Character" : {
  },
  "Animation" : {
        "walkAnim" = "Oreons:BuilderWalk",
        "idleAnim" = "Oreons:BuilderIdle",
        "attackAnim" = "Oreons:BuilderThor",
        "dieAnim" = "Oreons:BuilderDead",
        "fadeInAnim" = "Oreons:BuilderIdle",
        "fadeOutAnim" = "Oreons:BuilderIdle",
        "workAnim" = "Oreons:BuilderBuild",
        "terraformAnim" = "Oreons:BuilderShow",
        "randomAnim" : ["Oreons:BuilderWave", "Oreons:BuilderShow"]
    },
  "SimpleMinionAI" : {},
  "CharacterSound" : {
        "footstepSounds" : ["Slime1", "Slime2", "Slime3", "Slime4", "Slime5"],
        "footstepVolume" : 0.7
  },
  "Inventory": {
      "itemSlots": [
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0
      ]
    },
    "AccessInventoryAction": {},
    "Spawnable" : {
      "type" : "oreon"
    }
}
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Sounds pretty much like what we intended modules to be - building blocks more than traditional full "mods" :)

There's still some open questions on exactly how to deal with optional module stuff - like having Spawning available in general so you could throw in definitions for that in a model module without having to update the central spawning module. That's why I've sometimes left spawnable stuff outside if its own module, yet without any sort of module dependency. I don't really know if that's good or bad but it doesn't break anything. Maybe it makes sense for some of the very basic stuff.
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
I think it would be better to define these with inheritance. Right now, there seem to be widely different game types being proposed, and putting game logic on the base model will make it harder, or at least more confusing since you have to worry about conflicting components, to share these models between game types. The downside is that you will have to manage more modules as each game type will have its own model customizations -- but really, this is what you'd want to have happen anyway.

For example:
Code:
{
 "parent": "OreonsResource:OreoBuilder",
 "name" : "OreonMinions:OreoBuilder",
     "Minion" : {
         "icon" = "minionskull",
         "Healthtotal" = 300,
         "Hungertotal" = 100,
         "Staminatotal" = 100
   },
  "SimpleMinionAI" : {},
  "Inventory": {
      "itemSlots": [
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0
      ]
    },
    "AccessInventoryAction": {},
    "Spawnable" : {
      "type" : "oreon"
    }

}
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
In fact, if we are marking these kinds of entities as "Character" (and since it's an engine/Core component, we could do that in the Resources module), then I'm pretty sure that we could automatically assign additional component types, for example, Spawnable, to all components of type Character that do not already have them defined by intercepting the on creation/load/activation event (whichever one it is) for the minion.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
True that - I want to try out the player-centered spawning again soon and know there's an event to catch to attach it. Could be better to do something similar.
 

Mike Kienenberger

Active Member
Contributor
Architecture
GUI
I have went ahead and moved non-engine-specific attributes out of Oreons/assets/prefabs:Oreon*.prefab and into Minions/assets/prefabs:OreonMinions*.prefab. Separating the two works as expected.
 
Top