Re: Where did all the ...

From: Lemming <thiswillbounce@bumblbee.demon.co.uk>

Date: Sat, 03 Jul 2004 14:06:31 +0000

On Sat, 03 Jul 2004 04:04:03 GMT, lindahl@pbm.com (Greg Lindahl)
wrote:

>In article <rb39e0d9d8ge28j4cenabcer3t7n5ppfnv@4ax.com>,
>Lemming  <thiswillbounce@bumblbee.demon.co.uk> wrote:
>
>>More specifically, the problem I'm wrestling with (and I'm losing
>>miserably) is how to model locations, actors and containers in a
>>generic way using a relational database.
>
>This is a standard PBM programming problem. If a relational database
>is the answer (usually people decide the answer in advance, so I won't
>try to sway you on that one ;-), then "a generic way" isn't very
>doable.

Well, there's nothing fixed about using a RDBMS, just that I'm most
familiar that model and also have software available.  I could just as
easily, at this stage, implement the game with a heirarchical database
(I'm fairly sure that the data model will be for the most part
heirarchical anyway).  But I'm also open to suggestions ... if there
is a better model for handling this stuff, I'd love to hear about it.

>What you end up doing is having a table LOCATIONS with 1 row
>per location, and then a LOCATION_CONTENTS table with N rows per
>location, containing the contents of all the locations. What, you have
>several types of things that can be in a location? Well, the schema
>for LOCATION_CONTENTS can either be really general, or it can mostly
>point at other things, i.e. if there are 3 types of things that can be
>inside a location, the schema can contain 3 different types of IDs per
>row, only 1 of which will be non-NULL.

Yes, that model has it's attractions (the main one being simplicity)
and it's close to the one I am considering at the moment, but I feel
it has some problems too.

As an illustration of some of the problems I'm thinking about,
consider the question "what is a container"?

Obviously, a location is a container.  A suitcase is a container.
Slightly less obviously, an actor might be a container.  I say "might
be" because I could equally well have an "inventory" type object which
is associated with an actor, and it is the "inventory" which is the
container.  This might well simplify matters from a data modelling
point of view.

So, we may have three types of "thing" which contain other things.
The things that can be contained have to be sensible (at least in
*some* game worlds they do) e.g. you can't squeeze a quart into a pint
pot; you can't put a football into a matchbox, etc.  This can be done
to a sufficient level with "capacity" and "volume/size" attributes, so
that's not too serious a problem.

However, when I started thinking about other types of objects, I began
to realise that there are other types of "container".

Vehicles are fairly obvious, and have problems of their own, as they
have a passenger capacity, a luggage/cargo capacity, and although they
are different, each can borrow from the other - e.g. I can put an
extra suitcase on the back seat; A passenger can ride quite safely on
the back of a pickup truck, but would suffocate in the boot of a car.

Then I started thinking about weapons, and particularly weapons which
use ammunition.  A gun is loaded with bullets, does that make a gun a
container?  But it can't contain anything *but* bullets, so it's not
really - is it?  How do I constrain it to only hold bullets?

I know the simplest way to handle guns and bullets (and indeed any
weapon which is loaded with a number of "shots") is to handle the
ammunition like a "charge" for the weapon.  I'm reluctant to do it
this way though as I don't want to lose the fact that the bullets are
in fact things in their own right.

Thinking more about ammunition: Certain types of weapon are loaded
with a magazine, and it is the magazine which contains the ammo, not
the weapon itself.  An implementation which loaded guns with bullets
and handled the bullets like "charges" would not handle this
relationship satisfactorily.  Also, how can you remove a single
"charge" from a weapon and give it to someone else?  You can do that
with a bullet; you can't do it with a "charge".

Still on weapons: A bow is a weapon which is loaded with an arrow.
It's only loaded one at a time, so we might ignore the fact that it is
a "container" and just instead rely on the quiver to supply arrows to
the bow each time it is used.  This, however, has a knock on effect on
the type of actions which are possible, and the ending states of
failed actions.  For example, that the action of firing an arrow is
"shoot arrow" rather than "load bow with arrow, draw string back,
release arrow".  Why does this matter?  Well, if the action is
interrupted in some way, then in the first implementation the ending
state is "arrow not fired", whereas in the second imnplementation you
might end up with the bow in the loaded state and the string drawn
back ready to be released.

Containers, or the property of being a container, seems to me to be
not at all trivial;  Is a book a container?  Not on the face of it.
but then: what happens if you want to tear some pages out of it?  How
many pages does it contain (i.e. how many can be torn out)?  If a page
is torn out, can it be put back in?  Probably not: so this is a
special kind of container that can only have things removed from it -
and very particular things, at that.

Is a computer a container?  No?  Where do you insert the floppy disk
or CD/DVD then?  Can we consider loading a program onto the computer's
hard drive a type of "containment"?  The program has a size, measured
in bytes; the coputer's hard drive has a finite capacity.  Once you
get too many programs and data on there you can't fit any more in.  It
seems like it fulfils a lot of the properties of a container to me.

Before getting into all this, I started with a fairly simple:

location -------< item
        |
         -----------< actor

but an item might be a container, so how do you put an item inside
another item?  An actor must also be capable of carrying an item.
Then went to:

Still not good.  Next:

Maybe getting closer, but what if a location can be contained inside
another location?  Or even inside an item?  Silly idea?  What about a
"floating city", e.g. a giant ship which sails the oceans?  Each
location on the city is "contained by" the city, and the city is
"contained by" the sea location in which it currently finds itself.
Or what about a matrix-style game world, where weird things can happen
(e.g. a location is inside another location which is inside the first
location).  Or something like "Men In Black" where a whole galaxy is
contained within a pendant.  I don't necessarily want to write either
of these games, but the data model shouldn't make it impossible to do
so.

Perhaps:

>------- location >-----
	container >------- item >------   |
      |||     >------- actor >--   |  |
      |||                       |  |  |
      || ------------------------  |  |
      | ---------------------------   |
       -------------------------------

So evey thing -- be it an item, location, actor, or whatever -- has an
associated "container" entity, which indicates the item's location.
Each item which is itself a container is pointed to by another
container item, and so on.  Thus containment is handled externally to
the thing being contained.  This, I think, is fairly close to what you
described above.  It's certainly the most flexible, and allows for the
recursive nature of containment (the bullet in the pistol is in the
holdall being carried by the pilot in the jet fighter which is for the
moment on the deck of an aircraft carrier located at ...) but has the
disadvantage(?) that using this model it is possible for an item/actor
or location to be in more than one place at once.  This might be a
good thing, but it does mean there will need to be additional
integrity checks (over and above those provided for by foreign key
constraints) in place to ensure it doesn't happen where it shouldn't.
It also doesn't properly model all of the oddities - computer programs
and data, for example, aren't moved from the CD to the computer, they
are copied.  Pages to be torn from a book would be extremely clumsy to
model in this way, as would rifles/magazines/bullets.  Admittedly the
model only really seems to break down at these extreme edges, so maybe
it's not worth worrying about.  Conversely, maybe the whole thing is
overkill and a simple model would be better, even though it constrains
the things which can be done.

I know that all the examples I've described can be catered for with
specific coding, but I don't want to have to have different handlers
for all these cases -- and handlers for all the others I've thought
about and havent mentioned above -- and for all the cases I haven't
thought about yet.  Nor do I want the data model to unreasonably
constrain what can and can't be done in the game world.  I'm not
modelling for a specific world, I want to be able to model as many
different types of game world as possible, within the scope of
"Multi-player RPG".

Of course, the "special case" problem isn't just limited to
containment.  Other properties of objects give rise to special cases
too.

Tools, for example.  A hammer is fine for repairing a boat or a
sideboard, but useless for fixing your computer (other than for some
very specific definitions of "fixed").  How best to model suitability
of tools for their particular uses?  Oh, and lets not forget that a
hammer can be used as a weapon - and then can be either a melee or a
range weapon.

Weapons seem simple.  You use them to kill things.  The only obvious
slight complexity is the difference betwen range and melee weapons,
and point and area effect weapons.  However, you can also use certain
types of weapon for other things.  Blow a lock off a door with a
pistol; Knock down a gate with a rocket launcher;  Light a campfire
with a flamethrower; Send a message a distance by tying it to an
arrow.  And the effectiveness and range of a weapon may be
characteristics of the weapon, or of the user of the weapon.  For
example, the range of a rifle is the same for all users, but the range
of a bow and arrow will vary according to the strength and skill of
the user.

Locks and keys/picks are also a problem.  A key fits a specific lock,
fine.  But a lockpick fits certain *types* of lock.  A key will always
open the lock.  A lockpick may or may not work depending on the
quality of the pick and the skill of the user.  Lockpicks can be
improvised -- i.e. created out of other objects, such as a coat
hanger, etc.

So: the objective is to have the data model support all these special
cases, and not make it impossible to handle them.

>I'd advise looking at some code for existing games to see what you
>like.

Yes, a good idea.  Can anyone point me to links for pbm source code?

>Lots of games don't use relational databases; they use in-memory
>data structures instead.

Fine for small games, but I'm trying to design something which can
support a persistent game world consisting of anything from a handful
of players in a fairly small game world, up to thousands of players
with a game world running to millions of distinct locations, along
with the requisite numbers of NPCs, creatures, items, gods, religions,
political factions ... that's not going to fit in core all at once,
and has to be put out to disk at some point anyway.

>> A year or two
>> ago this was a very active group, and I wondered if all the discussion
>> had moved to a Yahoo group, a web forum, or "somewhere else".
>
>You're wearing rose-colored glasses! Ah, well, I won't harm your
>memories.

Ok, maybe a bit more than a year or two, at that: late nineties,
anyway.  It was around the time Bob McLain took over American
Flagship, and Nicky Palmer was elected MP for the first time, if that
puts it into a better context.

Lemming
--
Curiosity *may* have killed Schrodinger's cat.

References

Where did all the ...
Lemming <thiswillbounce@bumblbee.demon.co.uk>
Wed, 30 Jun 2004 22:26:01 +0000
Re: Where did all the ...
Hugh Bayer <hugh@bigspider.net>
Thu, 01 Jul 2004 05:29:14 +0000
Re: Where did all the ...
Lemming <thiswillbounce@bumblbee.demon.co.uk>
Thu, 01 Jul 2004 22:33:19 +0000
Re: Where did all the ...
lindahl@pbm.com (Greg Lindahl)
Sat, 03 Jul 2004 04:04:03 +0000

Referenced By

Where did all the ...
Lemming <thiswillbounce@bumblbee.demon.co.uk>
Wed, 30 Jun 2004 22:26:01 +0000
Re: Where did all the ...
Hugh Bayer <hugh@bigspider.net>
Thu, 01 Jul 2004 05:29:14 +0000
Re: Where did all the ...
Lemming <thiswillbounce@bumblbee.demon.co.uk>
Thu, 01 Jul 2004 22:33:19 +0000
Re: Where did all the ...
lindahl@pbm.com (Greg Lindahl)
Sat, 03 Jul 2004 04:04:03 +0000