Watts (chipotle) wrote,

Stupid MUCK tricks

So one of the things that I’ve always disliked about TinyMUCK-based systems is the parser. Even Scott Adams’ adventure games, written for TRS-80s with 16K of RAM in 1978, had a (marginally) better grasp of action and direct object. In TinyMUCK, if you wanted to implement just a small set of commands that weren’t built-ins, like (say) “eat,” “sit,” and “listen,” it’d be a fair amount of work: make a listen @action with the appropriate lock and messages in a high-level environment room as a default, then have separate @actions everywhere that needed to be overridden. And suppose you have a room with background music playing, and you’re carrying an MP3 player: make sure your actions are all named right, because native actions don’t actually have objects from the parser’s standpoint.

What I’ve done is create two MPI macros, {genaction} and {ogenaction}, which are meant to be put in the @succ and @osucc messages of an action at the top environment room. What’s the action named? Every command that you want it to respond to.

See, what you can do then is create properties in the _action and _oaction propdirs named after commands, like “eat” and “listen,” which do what they say. Defaults are put in the same high-level environment room.

@set $env/null=_action/eat:{if:{istype:{&arg},player},Cannibalism is frowned upon in polite society.,That doesn't look edible.}

Then, to make an object respond specifically:

@set apple=_action/eat:The apple is delicious.

But, of course, it’d be nice if you could make object “classes,” wouldn’t it? The apple should belong to a “food” class. Well, we can fake that!

@set apple=_type:food
@set $env/null=_action/eat/food:The {name:{&arg}} is delicious.

There are _actnoarg and _oactnoarg properties used for commands that are given with no arguments. (So you can have a default just for “listen” and a default for “listen apple” if you want.) If you don’t have the “noarg” variants, it’s assumed commands require arguments, and the parser will complain appropriately.

Also, since some commands are synonyms, you can set those up as aliases. If your action contains both “eat” and “munch” verbs, put the code/messages on “eat” and:

@set $env/null=_alias/munch:eat

Last but not least, this also works on the _details directory for fake objects. If you’ve made a description for the walls:

@set here=_details/wall;walls;floor:Mere details.

You can set an action detail command for it:

@set here=_actdet/eat/wall:Are you nuts?
@set here=_oactdet/eat/wall:inexplicably tries to consume the

The property is named after the first name in the _details directory (i.e., “wall,” not “walls” or “floor”). If action detail commands aren’t set, then any attempt to invoke a {genaction}’ed command on a detail will produce the default message for that action (i.e., _action/eat).

There’s some work left to do: while it respects @locks on objects, it should allow individual locks on actions (i.e., ”_action/eat/lock”); it should also allow aliases on objects. Both of those will require a bit more work. (It just occurred to me it’d be nice if it could allow the concept of objects that are subclasses, i.e., an object is of type “clothes” and subtype “hat,” but I’m not sure I want to open that can of worms.)

One might ask: okay, what are you actually going to do with this? The answer is: I have no idea yet. Jaffa’s MPI collection does have a {moveto} command in it, which is probably the most important “missing” MPI function for adventure-game-like responses. I doubt I’m going to be writing any adventures using these—but I’d like to have a good range of tools for making environments more interactive, pulling together things like this, more use of the _details directory, using some of the rarely-used things built into the server like containers, and so on.

Tags: mucks, programming
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded