[MUD-Dev] The effects of object oriented servers on the itemdatabase

[brianleeprice at hotmail.com]

--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2001Q2/msg00684.php

On Wed,  9 May 2001 01:49:50 -0700 (PDT)
Bryce Harrington <bryce at neptune.net> wrote:
 
> On Tue, 8 May 2001, Chambers wrote:
 
>> How would you implement a database for the object hierarchy?  Since
>> each derived object would have different properties, you would need
>> very large databases, right?  Does anyone have any tricks or
>> articles about this? Maybe even an example?

> There are particular databases that are object oriented and useful
> for such things.
 
> However, that is most likely the wrong answer.
 
> As has been mentioned on this list and elsewhere, inheritance
> hierarchies are not really the ideal solution for representing game
> objects in computer RPG's.  There's probably a zillion different
> solutions out there (i.e., research is good!)  But one approach
> would be to create a single simple "Entity" type, which contains a
> list of Parameters that describe it and a list of Actions it can
> perform, and then handle the different natures of each object
> programatically.  This is essentially the approach taken by
> WorldForge (add in containerism, dynamically loadable modules to add
> new actions, algorithmic grouping, and some other goodies.)

Before I get into disagreeing about ideals, :) let me flesh out the
generic "Entity" approach a bit.  Basically using this approach, only
the most common, basic, information is part of the Entity class.  One
example would be location. Everything else about an Entity is encoded
as one or more properties in a property collection(s).  For example:
property name "Name" - ascii name of Entity; property name "Strength"
- numeric strength value for the Entity.

Property lists map well to relational databases, especially in their
simple forms, for example:

  [Entity Table] 
  <Field EntityID>, <Field X>, <Field Y>, <Field Z>, <etc>;

  [Numeric Property Table]
  <Field EntityID>, <Field PropertyName>, <Field NumericValue>;

  [String Property Table]
  <Field EntityID>, <Field PropertyName>, <Field StringValue>;

In the example above, each property type has its own table and is
indexed both by the property name and by the EntityID for the Entity
it is associated with.  The generic approach can also be extended by
using properties which have more than one field or even ones that have
no fields.

IMO, the relative merits of the generic approach vs inheritance are:

  + Easier to design/implement           - Can become hard to maintain
  + Easier to map to a rdb               - Slower access to data
  + Easier to extend dynamically         - Less efficient memory use

An alternative model that I favor combines both inheritance and
generic approaches.  This model is described, in brief, below:

A shallow, single inheritance, tree of basic game objects.  In my
current model I use less than a dozen classes to represent the dynamic
state of all game objects.  Each game object has an associated (many
to one) prototype object. The prototype objects represent the static
state of game objects and is represented using a deep, multiple
inheritance, tree of many classes.

Using this model, a basic game object; whether sword, anvil, or
saddle; is represented by an instance of the generic game object class
SimpleGameObject but with it's prototype set to a shared instance of
the appropriate specialized game object class.

In cases where a game object is modified further from its prototype
than its particular generic game object class can represent, the
prototype object is cloned and the clone is suitably motified.

What makes this model work in practice is the use of SEOs (Sticky
Effect Objects).  SEOs are similar to the properties used by the
generic Entity approach but are only used to represent either
temporary changes to static prototype data or changes which cannot be
expressed by either a prototype clone object or the dynamic game
object data.  An example of the latter use of SEOs would be an
inscription on a sword.  (Note: SEO's can also have methods and can
respond to events.)

An 'Entity' in this model is represented by a genericized dynamic
state object, a (possibly cloned) prototype object with static state
information, and zero or more SEOs to represent dynamic or static
state information which cannot be expressed by the appropriate generic
object class nor an associated prototype clone.

Most methods are invoked upon an object thru its associated prototype,
this allows for each 'Entity' to mimic a traditional object at runtime
with only a single additional dereference (in most cases) yet maintain
an efficient memory footprint and an extensible/maintainable
representation.

In comparison to the more generic Entity/Property representation; this
Entity/Prototype/Property representation has IMO the following merits:

  + More efficient memory footprint      - More Difficult to map to RDB
  + Faster performance in most cases     - Harder to design/implement
  + Easier to maintain/extend

If you're determined to use an RDBMS, do yourself a big favor and use
the Entity/Property approach.  However, if you're interested in using
an OODB/persistent object store backend, the EPP approach is a viable
alternative.

Brian Price
-=have compiler, will travel=-

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev