[MUD-Dev] Re: MUD Design doc (long)

[Nathan F Yospe]

On Fri, 18 Dec 1998, Mik Clarke wrote:

:Caliban Tiresias Darklock wrote:
:> From: Mik Clarke <mikclrk at ibm.net>
:> >      if (!object->can_you_be(CMD_SNIFFED))
:> >        send_to_char "It smells of nothing in particular."

:> The usual smartass message I've seen is:

:>   > smell foo
:>   Smells like foo.

:> While this is cute the first few times you see it, especially when it
:> recognises the command and not the objects in the room ("smell teen spirit",
:> huhuhuhu that was cool), it gets boring rapidly. Same thing with default
:> messages in general.

:Well, fundamentally it's an error message: 'The target object does not
:support the verb "smell".'  That really mucks the SoD up though, so it
:gets replaced with an ingame message (sometimes of a margianlly humerous
:nature).

Which rarely helps the illusion. The flaw, IMO, lies in the treatment of
verbs. If a verb exists, it should exist universally, if you intend some
form of global consistancy to be an objective. Returned messages must be
generated by the verb, as above, but they should also be sensitive to an
environmental failure...

> smell foo
Foo?

>smell foo
You can't pick out any scent particular to the foo, but the lilacs quite
overwhelm you.

>smell foo
You inhale the aroma of slightly charred campground roast.

:> Senses present the most challenging array of problems; whenever I want to
:> smell something, I should be able to even if the game doesn't know what to
:> do about it. I can smell a door if I really want to, even if "open" and
:> "close" are all the door itself understands. If I am in a room with a
:> description that includes flowers, and I try to smell them, it is important
:> to my suspension of disbelief (SoD) that I be able to do so. If there is no
:> flower object, I should still get a response back like "You smell the
:> flowers." or something. If there is nothing there that matches, however, I
:> should (from a SoD perspective) get a "Smell what?" message or the like.
:> This is not really feasible; "The room is filled with flowers of every
:> conceivable type" should theoretically allow me to smell "flower",
:> "flowers", "tulip", "rose", "daisy" -- but obviously only the first two are
:> even remotely achievable, and that at some performance expense.

:This can be done by adding 'smellable' objects to rooms in the same
:fashion as 'examinable' objects are added. Diku/ROM uses extra
:descriptions - with a little rewiring the same mechanism can also do
:smell, listen, touch and taste (although the effects for touch and taste
:might be a bit more complicated).

This *should* be done by making the root object explicitely "scentless",
and deriving doors and such from them, and by actually having props when
you have descriptions. (Of course, I'm biased, as props are all that can
be done under my own design.) If you can smell it, you should be able to
pluck it, burn it, trample it, and fertilize it.

:> Instead of asking "how do we do X", it's productive in most cases to ask why
:> X is important in the first place. What does X give you? Why is it
:> important? If your rationale is "I have a flower and the player should be
:> able to smell it", you probably want to rethink whether this is important to
:> the game. It is certainly intuitive to think you can "smell" a flower, so it
:> might be a good idea to handle for the flower... but in the world as a
:> whole? Do we legitimately need a "smell" handler for all objects?

:I'm working on an investagative RPG mob - sort of like Scooby Doo - a
:lot of work to find the monsters and then run away.  Commands like smell
:and listen can add a lot more options for area builders to disguise
:clues and build atmosphere.

I don't think that's a problem with an OO object heirarchy. Just use the
default/null value for the base object, and reference parents on objects
dynamically, so the children needn't carry the baggage. Smell will go to
the child class, query its scent attribute, and that will cascade to the
highest level with a defined scent attribute...
 
:> Intuitive action is not always correct. It may also be intuitive, if the
:> flower is in a room with a bonfire, to throw the flower into the bonfire.
:> Does it need a "burn" handler? A "throw" handler? What if the flower is not
:> in a room with a bonfire, but can conceivably be put into one? Should the
:> "burn" handler be on the flower, or the bonfire? Is it a good idea to use
:> inheritance for this, and give the generic MUDObject type all these
:> handlers? Wouldn't you get stupid things like trees and doors with "throw"
:> handlers? Who the hell throws a tree? (Caber throwing notwithstanding.)

Just a note: My ogre was very upset at your implication that he wouldn't
want to throw trees and doors...

:Well, that's why you need a good object hierarchy at the base. 
:Consider:

:  Static Object
:    +--- Door
:    +--- Sign
:    +--- Plant
:    +--- Moving Object
:           +--- Weapon
:           +--- Armour
:           +--- Bottle
:           +--- Pouch
:                  +--- Money bag
:                  +--- Container
:                         +--- Bag
:                         |     +--- Chest
:                         +--- Room
:                         +--- Mob
:                                +-- Player

Well... seems acceptable, I suppose, except for the pouch/container bit.
that was backwards. Another note: I have no "static" objects... that can
really make a difference for SoD when it comes to serious damage... When
a big mech grabs a door and rips it off the hinges, it becomes quite the
mobile plank.

:In such a hierarchy you would have different throw methods on Static
:Object (a don't be silly message), Moving Object (it gets thrown),
:Pouch (thrown and spills some contents), Container (maybe comes open and
:loses it's contents).

Interesting. Throw simply initiates a vector for me, unless there's some
problem with seperation. Honey and octopi don't throw well... Containers
will always check their contents for seperation when rattled around. The
base object considers itself a container. (Localities, if you're looking
in the archives.) This leads to a far more dynamic world, but some major
dificulties in narrative assembly.
--

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
University of Hawaii at Manoa, Dept of Physics, second year senior (joy)
(On Call) Associate Algorithm Developer, Textron Systems Corp, Maui Ops.
yospe#hawaii.edu http://www2.hawaii.edu/~yospe Non commercial email only