[MUD-Dev] Object-Oriented Databases

[John A. Bertoglio]

From: "Adam" <adam at grexengine.com>
> John A. Bertoglio wrote:

>> The discussion on databases prompted me to delurk for a moment.

>> The problem is what kind of database? RDBMS are extremely fast
>> when

>> Over the last few years I have made my living doing consulting
>> and development for a database system that would (except for its
>> cost) be perfect for multi-player games. The product is a called
>> Cache' from InterSystems.

>> The key to these products are the way they store data. Instead of
>> using rows and columns, data is stored in multi-dimensional
>> arrays. It is a very odd product in many ways. If anyone cares, I
>> could expound on how Cache' works but perhaps that would be best
>> off list.

> I'd be really interested in hearing more about this, on or off
> list.  I've done some experimentation about 12-18 months ago with
> techniques that sound superficially similar: I had source code to
> some very old CRPGs, which used an object-hierarchy made entirely
> of multi-dimensional int (or even char) arrays. I was looing at
> the pros/cons of using such approaches in a heavily distributed
> environment - where many method-calls require a complete
> object-serialize/de-serialize, and memory requirements tend to
> spiral out of control.

There is an alternative that allows the use of these arrays. It is
all dependent on how you structure them for access. For example: A
chair can be used as a weapon. In a strict object environment, you
could have an furniture object that inherits from a generic item
object (object object?).  To allow it to be used as a weapon, you
would also have to inherit from a weapons class (assuming your
enviroment allows multiple interitance). If the chair can degrade
from use (non-weapon), you might need to inherit from a status
object. If the chair adds to one's prestige, you need to add
properties and methods from the prestige object and so on. If you
use item archetypes, you need another layer of objects.

This is very nasty if all you want to know is there is a chair in
the room.

My method is to use a pseudo-object model. The item array has
various levels of properties that represent objects. While these are
not true objects, all standard modeling techniques work just
fine. Here is a simplified example:

    ObjectID=1
    
    Item(1,ARCHETYPE)="33"
    
    Item(1,GENERAL)=""
    Item(1,GENERAL,MASS)="33.2"    // kg
    Item(1,GENERAL,HEIGHT)="1.1"   //meter
    Item(1,GENERAL,WIDTH)=".6"   //meter
    Item(1,GENERAL,DEPTH)=".5"   //meter
    Item(1,GENERAL,...etc)="..."           // and so on
    
If the item is a weapon, you don't need a flag, just add the properties
    
    Item(1,WEAPON)="YES"   //
    Item(1,WEAPON,BLUNT)=""   //
    Item(1,WEAPON,BLUNT,DAMAGE,)="YES"   //
    Item(1,WEAPON,BLUNT,DAMAGE,BASE)="2d3"   //
    Item(1,WEAPON,BLUNT,DAMAGE,MODS)="YES"   //
    Item(1,WEAPON,BLUNT,DAMAGE,MODS,NONWEAPON)="YES"   //
    Item(1,WEAPON,BLUNT,DAMAGE,MODS,NONWEAPON,VALUE)=".65" // %
        // reduction due to poor suitablity as weapon. Blunt weapons do
        // damage based on mass times longest dimention

    Item(1,WEAPON,CONSEQUENCES)="YES"   //
    Item(1,WEAPON,CONSEQUENCES,STAT,AGILITY)="YES"   //

    Item(1,WEAPON,CONSEQUENCES,STAT,AGILITY,VALUE)="-.50" // % lose
        // 50% of agility stat while wielding.
    
and so on. If the chair is not a weapon, none of the nodes above are
in the item record.

If the player says WIELD CHAIR (use it as a weapon) the system looks
into the db to see if Item(1,WEAPON) has a value. If it does, it
allows the player to wield the weapon, the code checks for the
existance of a CONSEQUENCES node and applies the proper
consequences. If there is none, the code moves on.

The same thing is goes for FURNITURE nodes (comfort, capacity, role,
etc).  Note that BLUNT could be seen as a subclass of WEAPON. In all
cases, you can have a an item ARCHETYPE (#33, in this case) that the
system can check if a value is not overridden in the "instance" of
ARCHETYPE 33 (the base object) in the data store. For a generic
chair, only the first node is required (along with information about
where it is in the world and any wear, etc.)  will be found. This
has the advantage of saving a huge amount of disk and memory storage
especially if you enter a banquet hall with 100 chairs. Make for a
heck of a bar fight but normally all that data would be a waste to
load. The ARCHETYPE might have the weapon node set to NO as a
default. But since it has all the base data for a weapon, all the
designer needs to do to "weaponize" a chair is reset the node to
YES.

In the actual code, we use numeric subscripts because they are
smaller, faster and allow the use of bitmapped indexes which are
VERY fast.

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