wiki:PlanningWiki/ObjectGeneration

Object Generation

Restructure

  • object structs (object_type, object_kind, egos and artifacts) (Nick)
    • pvals are an obsolete hack, and should be replaced with actual values
    • it would be nice to see tvals and svals go away too, but I'm not as clear how to do that
    • ID (within this struct) is also pretty much a hack, and needs to be thought through; I have some ideas, but they're not radical enough yet
    • see Brands & Slays for how to handle these -- takkaria)
    • bitflag flags[OF_SIZE] is fairly clear, but maybe should have negatives/curses pulled out
    • there should be some fields for ID, and maybe pseudo-ID

  • if you wanted to remove tvals and svals you could consider something like bool wearable[EQ_MAX]. Although, in the end, it's probably worth it to be able to separate axes, from polearms, from maces, so you're not gaining much. At the very least, we should be thinking about how to accommodate classes that dual wield weapons.
  • For dual-wielding, you could add a flag on weapons/shields that permit offhand usage and move to weapon+offhand slots; this gives you the opportunity to restrict dual-wielding and shield usage independently.
  • Latest consensus seems to be tval->type, sval->subtype (but retained) (Nick)
  • Also, probably one type per slot, then crown/helm and sword/hafted/polearm can be handled by flags (Nick)
  • resist[GF_MAX], modifers[OBJ_MOD_MAX] (for stats, speed, stealth &c), brands and slays (both these two (entity, multiplier) linked lists) have now been added to all the object structs (Nick)
  • Some big ideas for eliminating tvals/svals (molybdenum):
    • Assign each object a unique four-char code (unsigned 32-bit number). I have this done already.
    • Each object_kind can have a parent object_kind, from which it inherits values and flags. The child overlays its values on top of the parent's; some additional logic needs to be added to differentiate between null values and actual zero values.
    • Intermediate nodes could be handled two ways:
      • Maintain intermediate nodes (which cannot be generated) in the object kind list so that the hierarchy can be queried in the game: "does this object have the armor node as its ancestor?"; or
      • Create appropriate flags for certain intermediate nodes which are inherited by descendants, allowing for the intermediate nodes to be flattened out.
      • There would probably need to be a meta-flag to indicate an abstract/intermediate node.
    • A lot of this can be done at initialization, so changes to the rest of the game are minimal. Changes can be made incrementally, such as making checks where we currently use tvals/svals.
    • object_base will go away.
    • Artifacts are added to the hierarchy as well. They just become a very specialized child of a more common node.
      • Because they also have a unique code, keeping track of generated artifacts is a much easier lookup than the current scheme.
      • struct artifact will be folded up into object_kind.
      • There would probably need to be a meta-flag to indicate artifact-ness.
    • Conceptually, egos are just subsets of particular evals. Instead of defining each relationship explicitly, egos are defined as a set of attributes that can be applied to the descendants of a given node.
      • Artifacts would need to be excluded, so egos would also need to check the artifact meta-flag.
      • struct ego_item might be able to be consolidated into object_kind as well, depending on how clever the rest of the implementation is. It'd also need a meta-flag.
  • molybdenum, I'm not sure what this gains us. One advantage of the current system is that it is fairly clear and intuitive, whereas I'm having trouble understanding this one. Can you explain its advantages? (Nick)
    • A concise answer: to allow object types to be created and modified more easily by just editing object.txt. As an example, someone wants to add new class of body armor to the game (say, orc armor, which has varieties like dragon armor). Currently, they'd have to add a new TV_ constant and then find everywhere that similar TV_ constants are used (in this case, adding TV_ORC_ARMOR to places where TV_DRAG_ARMOR shows up). The tval_ functions I added were a partial way of simplifying the TV_ mess, as well as to see what kind of places the TV_s were actually used. In the ideal implementation of my system, someone would only need to add entries for orc armor and set appropriate flags and such. Admittedly, I do need to flesh out details more; I just wanted to get the foregoing notes up so gaps in my thinking could be exposed.
    • That sounds like a good aim. I'll look forward to seeing code :) (Nick)

Post-restructure

Possibly Related Tickets

Last modified 4 years ago Last modified on 02/08/14 19:22:00