[DGD]Re:Rooms with views

[balduin at uni-paderborn.de]

Serhat Sakarya wrote
> On Wed, 3 Nov 1999, Neil McBride wrote:
> > John West McKenna wrote:
> 
> [snip]
> 
> > To achieve this would take some sort journaling system to record where a
> > character has been, and what they saw there.  Then some sort of method
> > to cross-reference these journal entries with what they see when
> > something new appears so the description can then be based on the
> > characters prior experiences.
> 
> Hhm.. to which extent could this be accomplished with 'toggles'? I could
> imagine some (run-length encoded?) compressed bitstream or whatever to
> accomplish this.
> 
> I guess the majority of things you need to keep track of only require 1
> bit. Exceptions can be handled individually (with "properties" or
> whatever).

Well I doubt that one bit will be sufficient in most of these cases, even
in the snipped examples are at least two, wich won't be covered with this.

Beeing familiar with a place proposes something like a commoness you 
visit a place, thats hardly covered with one bit. The last time you 
visited a place isn't either. As well as the tallest building you
ever visited is an object reference or a measurement, but not a bit.

The biggest problem I see with such an implementation is not the technological
challange. It's realively easy to provide mechanisms to store every bit
of information about what a player visited. You could even store different
types of Information like flags (yes/no), times(e.g. last visit), 
measurements(e.g. sizes of bulding, mountain etc.), commoness(how often does
he visit the town, harbour, orc camp...) list to be continued.

The biggest problem I see with such an implementation ist that you need
to keep track of all these "facts" known about a player when creating the
description. Either the description generator or the object to be described
needs knowledge about the classes of "facts" known to the system. E.g. to
achieve the "tallest building" effect, all buildings (or rooms with buildings
in the desc) need to "know" they are a building and their size. The description
generator could then generate the desc and update the "facts" database in the
player. This implies at latest at the time you write a specific object you
need to know about all "facts" an object has to ever respond to.

This makes the problem a social one. At least if more than one developer
work on your game you will soon experience a bloat of such facts unless
you are very restrictive when introducing new "facts". This problem is
unaffected from the way you store the information needed. It occurs always
as well when storing it per player in the objects, per "fact" in the player
or in a journal or database in the filesystem. Compression doesn't matter
either for this problem. I'd even strongly object against it unless you have
a cery fast CPU but very limited memory. But it might save diskspace if you
have a huge player base entering only rarely the game. Btw. the bad thing
about the bloat mentioned above is not the memory you need to store the 
information. Memory - RAM as well as a hard-disk is pretty cheap. The bad thing
about it are the inconsistencies you will get if somebody writes the new worlds
biggest cathedral but forgets to state that this is a building. Even worse
he might consider it worthy to introduce a new "measurement" cathedral without
telling anyone about it.

Anybody suggestions how to cope with this problem ?

Ludger Merkens
(balduin at uni-paderborn.de)
(grumbel at xyllomer)

List config page:  http://list.imaginary.com/mailman/listinfo/dgd