Object Design in Epigon

Physical Objects’ structures are about 80% designed!

While that’s the exciting news, first some information about the data classes themselves.

The base idea for the data classes in Epigon is Inheritance and Interface. Like an object oriented language, all data elements subclass another data element. This includes Physical Objects, Biomes, Terrain, AI Strategies, etc. While this adds complexity to the data structures themselves, it allows for some nice effects.

Some examples of the power of subclassing data:

  • Sword of Orc Slaying can be tagged to do bonus damage against the Physical Object “Orc” and without having to specify anything further, it will get that same bonus against everything that subclasses Orc, such as Orc Shamans, Pink Orcs, and Giant Orcs.
  • Resistance to the Element “Fire” will include resistance to the element “Magma”

This kind of carry forward of effects works on the declared class and anything that subclasses it, but not on the ancestors of the declared class.

The biggest downside to this kind of subclassing is that it promotes an overly large hierarchy in which many elements exist simply to be umbrella classes, such as “Animal” or “Tree” without any specific instance of that class wanting to be created. I think this comes down to a choice on the data designer’s part about how generic they want things to be. A basic set of umbrella classes is not a bad thing, and they can be tagged so that they don’t have instances of them actually created.

There is no multiple inheritance allowed in the data sets. This keeps things more organized, but it does make some things a bit more interesting. If you wanted to create a half-dragon half-orc creature, the “Half Dragon Half Orc” creature, and dragon and orc were not in a direct line, you would make a decision as to which one it directly inherited from and then tag it as “also counts as” the other. This way the designer has the flexibility to have things count as multiple things, but since it can only directly inherit from on parent, a tree is maintained rather than a complex connected graph.

So there’s some of the highlights of the data structures in general :D

The current news is that the Physical Object class definition is complete enough to start working with in a programmatic sense. That means combat, recipe, and object creation testing!

Next up: planning out the starting data classes that will provide good examples for others who may wish to modify what goes into the world of Epigon!

Leave a Reply

Your email address will not be published. Required fields are marked *