Changes between Version 12 and Version 13 of PlanningWiki/ObjectGeneration


Ignore:
Timestamp:
02/02/14 00:23:18 (6 years ago)
Author:
molybdenum
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PlanningWiki/ObjectGeneration

    v12 v13  
    1919    * 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) 
    2020 
     21 * Some big ideas for eliminating tvals/svals (molybdenum): 
     22    * Assign each object a unique four-char code (unsigned 32-bit number). I have this done already. 
     23    * 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. 
     24    * Intermediate nodes could be handled two ways: 
     25       * 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 
     26       * Create appropriate flags for certain intermediate nodes which are inherited by descendants, allowing for the intermediate nodes to be flattened out. 
     27       * There would probably need to be a meta-flag to indicate an abstract/intermediate node. 
     28    * 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. 
     29    * `object_base` will go away. 
     30    * Artifacts are added to the hierarchy as well. They just become a very specialized child of a more common node. 
     31       * Because they also have a unique code, keeping track of generated artifacts is a much easier lookup than the current scheme. 
     32       * `struct artifact` will be folded up into `object_kind`. 
     33       * There would probably need to be a meta-flag to indicate artifact-ness. 
     34    * 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. 
     35       * Artifacts would need to be excluded, so egos would also need to check the artifact meta-flag. 
     36       * `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. 
    2137 
    2238=== Post-restructure ===