action Thumbnail

action

  • noun The specification of how to interpret a command in MUDDL. MUDDL actions are the equivalent of MUDDLE functions, save that all actions are directly usable by players whereas functions are executed indirectly through vocabulary ties. The only actions that can't be used directly are demon actions, which are meant to be time-delays but are often chained to the end of actions so a command can do more. MUDDL's action definitions are impressively hairy, consisting of a number of templates which commands are matched against in turn until one catches. The basic template format is:

    	<vb> <sp>? <obj> <ins> <fn> <par> <success> <fail> <global>? <demon>?
    

    <vb> is the verb, optionally followed by the name of a special function <sp> which is to be handled first when a template matches a command. Anything complex has to be coded as a <sp>, eg. '.get', '.drop', '.quit'. Following on is an object <obj> (or 'null' if the <vb> is intransitive) then another object <ins> (or 'null'). Next is a normal function <fn>, which does more simple things than <sp> and can be used to change the way objects look or appear. Such functions act either on <par> or on <obj> and/or <ins>; some <fn>s are doubled up for extra functionality, so whereas 'inc null' means 'increment the property of the <obj>', 'destroyinc second' means 'destroy the <obj> and increment the property of the <ins>'. <fn>s return either success or failure, and the text bearing the appropriate number is printed. If <global> is present, that text is sent to all players. If <demon> is present, that demon is invoked.

    The above is just the standard model of an action - some templates have eg. null <obj> but named <ins>, or room names as <success>, or numeric parameters to <fn> as <success> and the real value of <success> in <fail>! Whether an object or class name is used is also meaningful in strange ways. The best way to figure out how to add a new command is to look up the MUDDL for something similar and use an adaptation of that. The binder is implemented as a part of the command lookup process, so there is flexibility in what can be bound to what, but the nature of the binding is restricted to certain stylised forms (objects that are here, objects that are carried, objects that are either; global searches for objects are handled in the code of the <sp>s). Some <fn>s can affect binding, and even determine the matching of templates against commands.

    For comparison with MUDDLE, here are the relatively straightforward definitions of the actions that implement the 'fix brand in sundial' command:

    	fix torch time ifprop sundial 0 386
    	fix torch time ifprop null 0 387
    	fix torch time destroydec sundial 388 0
    

    The first of these lines says that if the sundial is in state 0 (it starts in state 1, by the way) then print message 386 ("It's already got a brand in it, birdbrain."). The second line says that if the brand is in state 0 (its 'aflame' property), print message 387 ("You can't put a lit brand in there or you'll burn your hand!"). If the third line is reached, it means neither of the two previous lines applied, so the brand should immediately be destroyed, and the state of the sundial should be decremented (which will move it from 1 to 0, ie. the first line would catch it next time). Message 388 is then printed ("The brand fixes solidly into the sundial, in fact so solidly that you won't be able to take it out. It looks like the sundial will work now."), and the action is complete. Note that in MUDDL, 'fix' is a different command to 'drop', whereas MUDDLE has the oomph to combine them. See function.


Copyright © Multi-User Entertainment Ltd. (muse@mud.co.uk)
23rd September 1999: action.htm