[DGD]Re:Rooms with views

[Jason Cone]

----- Original Message -----
From: <balduin at uni-paderborn.de>
To: <dgd at list.imaginary.com>
Sent: Wednesday, November 03, 1999 4:45 AM
Subject: Re: [DGD]Re:Rooms with views


> 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).
>
> [Snipped single-bit, compression, and "commonness" problems]

I would have to agree here.  Rarely, if ever, can a single bit be used for
describing anything but a logical condition (on/off, yes/no, true/false, etc.).
This could work in the above situation were you solely interested in whether or
not the player has visited a given "room" or not.  Even there, you run into
problems.  Specifically, you would need some sort of generic map mechanism to
associated a given bit with a specific "room."  If a mapping were employed to do
this, you would be required to use a data type (for the value) that would exceed
a single bit anyway.  Not that this is bad, but if disk space is that much of an
issue...

I would also advise against use any sort of compression on real-time data.  The
introduced overhead may be acceptable for a handfull of players, but once you
reach a sizeable concurrent userbase, performance problems would probably start
to rear their ugly little heads.

As Ludger pointed out, most things are representable relative to the "viewer" so
long as strict rules are in place for describing objects and the universal pool
of material characteristics.  The most significant problem that arises, as he so
clearly pointed out, is the instance where a builder creates a building of
monolithic proportions and forgets to programmatically describe it as such so
that the system can represent it appropriately to the "viewer."

I've done proof-of-concept implementations of "rooms" that are completely
coordinate-based (even takes line-of-sight into account), ones that are based on
the tried and true autonomous "room" object, and ones that borrow concepts from
both genres.  The common denominator in each of those implementations is that,
in order to achieve any sort of ground-breaking dynamic functionality, you
_must_ require that the "builder" be mindful of the programmatic details of the
underlying system and have an incredible attention to detail.  While not a huge
requirement, it's hard to find in most potential "builders". :)  Some sort of
OLC mechanism could alleviate some of the stickier details, but the "builder"
needs to know what they're doing and what they're building in the grand scheme
of things.

I've struggled a bit with this as it really does alienate a large segment of the
"let-me-be-a-wizard" community.  The conclusion that I've come to, though, is
that 1) while I'm not a believer in the concept of macro-evolution, I do believe
that general advancement requires that some people be left behind and 2) a small
development team results in a cleaner and much more coherent implementation,
faster development times, and the ability to introduce advanced and complex
functionality without grinding development to a halt.

That said, the fact that an implementation may require someone to spend 10 times
the amount of time to get an area working to specification than they're used to
is not a bad thing so long as they 1) fundamentally _want_ to do what they're
doing and 2) are able to see unprecedented results as a result of the time
they've spent on it.  What this discussion has been centered around is largely
non-existent in most production-quality MUDs and would add a great deal of
enjoyment for the players if implemented correctly.  But, as my co-admin so
astutely pointed out, if the players don't want what you create, then you've
wasted your time.  Specifically, if it introduces a degree of complexity into
game-play that the players are not willing to adapt to, your work benefits no
one.  As someone who likes to push the proverbial envelope, this is a painful
lesson to learn sometimes. ;)

This leads me to my next topic -- mudlibs under development.  In the
not-so-recent past, I was advertising the "soon-in-coming" release of my mudlib
for DGD (Cornerstone).  After having to deal with the realities of life and the
not-so-flexible time restrictions of a single day, I realized that I was doing
nothing but advertising vapor-ware. :)  It's still under development and has,
within the last 4 months, undergone a major paradigm shift to more closely match
the goals of Dworkin's kernel library than that of a game-specific library.
Without making any promises, I hope to have that out and available for general
use by the end of the year.  It should be done well before that, but I would
actually like to use it in a practical environment to ensure what's been done is
what's needed.  I'll probably post a more specific description of what's being
created in the near future so as to obtain general feedback on the implemented
feature set.  If you find that you're bored and have nothing to do with your
free-time, I would love to bring on one or two more core programmers. :)  Yeah,
I know, it's a shameless plug, but the paragraph seemed incomplete without it.
;)

I've rambled enough for now.

Jason

--
  Jason Cone
  Senior Software Developer
  Usability Sciences Corporation
  jcone at usabilitysciences.com



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