This is a very first draft to help with the current work on enabling Eulora's GUI client to make use of new information as it becomes available from the server rather than expecting everything to be fully known upfront (as it currently does, laugh you not!).

Eulora's data is one big hierarchy with 3 main types of information: structure, description, representation.

• 1. Structure (i.e. what entities are inside what other entities)
  Structure is always a tree of entities where each entity is given through ID (unsigned 32 bits) + Position (x,y,z,rx,ry,rz):

  The Root of the world will ALWAYS contain:

  • an *abstract object* with meta-info:
    • ID of "self" (SelfID)
    • ID of current location (aka "sector" or room or world or whatever else it is) (LocID)
    • List of Skills: list of (skillID, skillName, skillCategory, skillRank, skillXP, skillKnowledge) (?)
    • Game Date and Time (?) --- is this a meta-matter or is it a location-property?
  • the *top-most ID* (aka topmost entity); NB: this is not always the same as LocID since character may move into a location inside another location, presumably.
  • from top-most ID down, EACH node will have zero or more contained entities (hence, child nodes given through their unique ID and concrete position within their parent).

  NB: each node can also have in addition to its structure-children (hence entities), any relevant number of description-children (see 2 below) or representation-children (see 3 below).

  • 2. Description of what entities themselves "are" through their relevant properties

    ANY structure-node may further have, alongside its children, one or several of the following properties (given as a tuple property,value):

    • name
    • description (??)
    • (- equipment slots (list of (slotID, entityID) ?) -- are those any different from "contained"? I can't see a truly significant difference.)
    • stack count
    • quality
    • HP (hitpoints)
    • BP (bloodpoints)
    • SP (stamina points)
    • MP (mana points)
    • SpP (spirit points)
    • MSP (mana spirit points)
    • weight
    • bulk
    • weight limit (max weight)
    • bulk limit (max bulk)
  • 3. Available representation of entities (graphics, sounds, effects, maps etc)

    NB: in principle there can easily be a structure + properties split at this level too since a graphical representation may have its own structure (e.g. map defined as a hierarchy of contained terrain + geometry meshes that have in turn different submeshes with corresponding textures/materials). This seems rather unseemly though and it's unclear if there really is a need for a hierarchy of graphical detail that is anything OTHER than hierarchy of world entities to start with. So perhaps this can be flattened so that representation of entities means just that: a list of relevant graphical characteristics of ONE entity.

    ANY structure node may further have, alongside its entity-children and its properties, one or several of the following representations:

    • Mod2D (aka 2D model; at its most basic, the filename of icon to show for this; tbd)
    • Mod3D (aka 3D model; at its most basic, spec for mesh including material/texture and sockets if any; tbd) ; NB: sockets allow graphical representation of contained (specifically "equipped" or "component") entities and therefore they should probably be identified by "position" so that the entity "child" on that position will then give the actual representation shown to the user (?).
    • ModAnimations tbd
    • ModMap (aka map for this entity; at its most basic heightmap + size (or is this fixed?); possibly also a list of materials to use + corresponding density)
    • ModWeather (unclear yet if this is any different from sounds+effects really)
    • ModSounds tbd
    • ModEffects tbd (unclear yet if this is substantially different from animations+sounds)
    • ModSkin tbd (stuff like window borders and button colours)

    ANYWAY: GUI may request whatever it wants from local cache, regardless of cache's own internal representation (just as cache may store data in any form, regardless of smg's own description of hierarchy).

  TO DO: flesh out in more detail each possible representation, for GUI to ask & work with + get it to actually work outside of/inside the intricate mess of ps paws, widgets, managers and whatnots maggots.

  Category: Eulora

  Comments feed: RSS 2.0