[MUD-Dev] Re: Room descriptions

[Adam Wiggins]

On Mon, 28 Sep 1998, Koster, Raph wrote:
> > From: Adam Wiggins [mailto:adam at angel.com]
> > On Mon, 28 Sep 1998, Koster, Raph wrote:
> > > I would
> > > not call the goal of having a fully interactive environment even
> > > necessarily contradictory to what I am discussing. You can 
> > > have a fully
> > > interactive environment that still imposes a perspective or 
> > > a worldview
> > > on the player, I would think. 
> > 
> > On this particular point I don't think I can agree.  In the end, if
> > someone detonates a nuclear bomb inside your candy store it's 
> > still going to have the same roomdesc.  I don't think this sort of 
> > constructed world
> > will ever be interactive in the way that I'm thinking; it will always
> > be a sophisticated Zork spinoff, which is to say you only have the
> > interactions which are coded by whoever created the area.
> 
> Yes, well, this is the case for all the interactive world interactions
> you might have, too.

I don't agree, precisely, and I'm surprised you would say this, considering
your work on Ultima Online.

If I write a very specific area, typical of most muds, where there are
highly specialized room descriptions and most of the interactions are
coded to be specific to that area, any functionality you don't cover
will not work in your area.  If we build the candy store via typical
methods - writing room descs, adding extra descs, adding little spec
procs to handle different things the player might do - it can't deal
with something not coded, including extreme effects like the atom
bomb, but also effects like someone rearranging the furniture, or
killing the candy store owner and taking his clothes and masquerading
as him, or painting all the walls black and installing a movie projector
and turning it into a movie hall, or even something simple like dropping
a rotting carcass into the center of the floor (which would certainly
draw attention away from all the normal decorations).

If, however, the candy store is built the way Orion suggests - by actually
creating each piece of furniture, all the candy stocks, the guy behind the
counter, a full uniform for him, big window panes, and a shiny tile floor,
all the interactions the game supports are automatically enabled for that
room.  You can now drop an atom bomb in it, or kick over the tables, or
track mud all over the floor, or turn the room into an animal shelter, and
the room description will never not make sense.

One way you get the ultimate in flexiblity and freedom to create a specific
feeling and environment, at the expense of difficult to add or change
interactivity.  In the other case you loose the builder flexbility and
probably a lot of mood, but you get the ultimate in dyanmicly built worlds,
which can truly be torn down to nothing and then built up again if there
are players willing to do it.  I'm not suggesting that one is better,
just attempting to point out the differences...

> If you leave out atom bombs from your code, after
> all, there's no way one is going to be detonated in the candy store. :)

Sure, this is the old "Doc, it hurts when I do this"/"Well don't do that!"
fixit.  It certainly is a handy excuse, but it hardly represents good design,
and in the end will lead to a very inflexible and proprietary functionality.
This may or may not be a Bad Thing.

> Similarly, if you don't have "burned" long descs for all the various
> objects in your database, then once the fire is over, you may not have
> achieved the effect you want. We're always stuck with "only the
> interactions which are coded" after all...

Yes - but assuming that you build the room out of standard components
(wooden furniture, latex paint, plaster walls, glass windows) then this
should already exist.

Again, it's just a question of whether you want to spend a lot of time
building/coding many interactive, reusable pieces and then building a world
out of those, or whether you want to spend your time making hand-crafted
areas and objects which are highly proprietary.

Adam W.