The Component System

Many Loci in the FaerieMUD world are really compositions of other smaller Areas or Items. A forest (an Area), for example, has many trees (among other Organisms), each of which has a trunk, roots, and limbs. Each limb has leaves and perhaps fruit; the leaves have stems; the fruit has flesh, stem, and seeds, etc. To model each seed of each fruit of each tree of each forest would, as one can imagine, consume vast quantities of memory, and be mostly useless, as only perhaps one in a million will ever be interacted with directly. Eliminating them entirely, however, eliminates all kinds of useful and interesting game play that can be built around them. A herbalist's skill would be mostly useless if one could only interact with whole forests, and would be substantially less interesting even at the whole-tree level.

Components are an attempt to eliminate this conflict.

The tentative plan is to make Loci capable of existance in two modes: as a normal unique instance, or as a prototype. Prototypical Loci are flyweight instances of a Locus subclass which can serve as the integral contents of a higher-order object. An Locus's Prototype is the Platonic ideal of that object's class: a perfect unmodified instance. If the world interacts with this unmodified instance and causes it to be changed in some way, the Prototype is cloned in place (as are all of its Prototypical parent/container objects), and then forever1 becomes a unique object, capable of containing its own changed state.

I'm endeavoring to have some real code on disk in the next week or so that implements this, so I've been doing some research into other component-based or at least data-driven object systems. A list of links that have influenced my thinking are below, listed as I find them:

Two excellent articles on GameArchitect.net

A Data-Driven Game Object System

Problems and Solutions

If you don't have an instance for each sub-component, how do you know how many leaves can be picked from a tree?(Posed by Silverlock)
Answer: The containing object will know how many there should be, and will lazy-load instances as appropriate. This needs to happen anyway for descriptions. For instance, the species object for the Sycamore tree knows that one of the size from which leaves are being picked has between 8,000 and 10,000 leaves in its pristine form, so when some actor causes the leaves to need to be counted (examination at a very fine level of detail, picking some, etc.), the tree object decides that it has 9,000. If 6 are picked, it instantiates 6 unique objects and then stores the fact that it now has 8,994 leaves of 9,000. This storage only happens when something happens which distinguishes the tree from all its neighbors.

Footnotes

  1. Or at least until it's destroyed, transformed, or optimized away.

— GedTheGreysHain - 19 Jun 2003
— GedTheGreysHain - 30 Sep 2003