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

[Mik Clarke]

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).
 
> 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).
 
> 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.
 
> 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.)

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

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).

Mik
--
http://www.geocities.com/SoHo/Cafe/2260