HardLife - Unified Object Structure v1.0 (for engine v0.27+) (Patreon)

I've finally settled on a unified object structure for all things in the game. Now I can begin integrating it into the game and CMS as linked features are implemented.

Of particular note are the object-type specific nodes, which ALL objects will possess regardless of their CURRENT type (yes, that's right, we're including support for object-type transformations... exploring characters as places, having NPCs become/behave-as vehicles, having items come to life, etc.)

_ basic object properties, applies to all objects, generic of any type

B STRUCTURE-TYPE properties (body, building, etc.)

C CONTAINER-TYPE properties

I ITEM-TYPE properties

L LOCATION-TYPE properties

N NETWORK-TYPE properties (connections, relationships, etc.)

R RESOURCE-TYPE properties

V VEHICLE-TYPE properties

Z MAP-TYPE properties

Notice CHAR-TYPE isn't listed... that's because ALL OTHER BRANCHES ARE RESERVED FOR CHARACTER DATA.

Below is the FULL DATA STRUCTURE for ALL OBJECTS, which has been OPTIMIZED for CHARACTER-TYPE DATA:

OBJECT.{

_ OBJECT-LEVEL PROPERTIES (qty, mass, durability, expiration, volume, density, conductivity, temperature, color, etc.)

A ACTIONS

B BODY/STRUCTURE

C CHAMBERS/CONTAINMENT

D NEEDS/MOODLETS

E METABOLISM/[BIO-]MECHANICAL ENERGY-SYSTEM (multi-socketable)

F FACTIONS

G GEAR/WEARABLES (EQUIPMENT/CLOTHING/MODULES/READY-WEAPONS/WORN-GADGETS/etc)

H HISTORY (significant events)

I ITEM PROPERTIES

J JOURNAL (objectives, notes, bestiary, bio/intro, replaces PASSAGES node)

K SKILLS/KNOWLEDGE

L LOCATION PROPERTIES

M METRICS

N NETWORK/RELATIONSHIPS

O RECORDS/ATHLETICS/ABILITIES

P PERSONA/BIASES (likes, dislikes, quirks, etc.)

Q QI (and the 15, stat-based, Qi Energies)

R RESOURCES (Property/Finances, Volume-based or Non-tangible Supplies; possibly Fuel- though that will likely be done through containment/chambers instead)

S STATS

T TRAITS (including FEATURES and NAMES)

U REPUTATION

V VEHICLE PROPERTIES

W POWERS (chosen for the Greek-letter Omega)

X RESERVED FOR EXPERIMENTAL FEATURES

Y ACHIEVEMENTS/STATISTICS

Z MAP PROPERTIES

$ RESERVED, BUT CURRENTLY UNUSED

}

All Nodes allow an underscore property to serve as a data-cache, all other properties/keys must be unique identifiers and begin with a letter.

Example from ACTIONS

OBJECT.A._ AVAILABLE ACTIONS CACHE (possibly)

OBJECT.A.{} ACTIONS QUEUE

CHAR.N._.S.{} SLAVES CACHE (stored for convenience, but refreshed when relationships change)

CHAR.N['npc name'].{} RELATIONSHIP properties for that NPC

Object-level properties can also be overridden by functions, and are automatically done for some object types (eg CHARACTERS have a more complex durability value based on their current stat and energy levels, and any wounds)

Some of the interesting/peculiar ramifications of the unified system include being able to apply item-use properties to characters, presumably triggering if you consumed said character. Not that there are any plans for such, I'm merely remarking it is *possible* under the unified structure.

On that same note, an object in the room can store a history/record of events that transpired there, should someone have the ability to psychically read objects.

Rooms can be Networked together for navigation as well.

Vehicles, Characters, Rooms, Furniture, Clothing, Equipment, etc. can also act as a Container and thus hold other objects (based on their storage/chamber capacity and the object's volume).

Now, is it genius or insanity...? I'll leave that for history to decide.**
(** a remark typically made by insane dictators right before instituting their evil plan for global domination, but whatever, ;p)

To address the question of why we are moving to single-letter property nodes, no it isn't for obfuscation, it serves 2 vital purposes. It neatly avoids collisions with previous data structures, both lexically and abstractly, and it is much shorter/easier to type and keep straight while coding. It also forces me to look very closely at what kind of information I want to store, and how to keep it logically organized for future expansions.

To use Income as an example, we now store that as CHAR .R .P .IS ._ .I ._ for the cached total income, and CHAR .R .P .IS .{} for the individual income and expense entries for that character's income-statement. CHAR .R .P .BS .{} will store their balance-sheet with all their assets, liabilities, and neutral-value securities, in case you were curious.

("CHARACTER .RESOURCES .PROPERTY .INCOME_STATEMENT ._CACHE .INCOME ._CACHE" is a pain to type, prone to typos, and adds a lot of bloat to the code, vs "CHAR .R .P .IS ._ .I ._")

Now, if you're wondering why there are 2 cache levels there, the first is the cache of all Income-Type entries, but as they have separate intervals, they cannot be combined at the first level. So at that level is the list of all income entries, but if we take the _cache entry at that level, then we get a single cached annual income value/projection.

But, we needn't worry about that for now, the financial system won't be added until around engine v0.29, right before we add jobs. That was just an elaborate example of the information we can now support.

Once the characters/etc. are fully converted over to the new format, we shouldn't encounter any more compatibility issues with with gamesave structures.