PirateMUD and CSL

Niklas Elmqvist croziys at algonet.se
Mon Aug 4 13:24:50 CEST 1997


Greetings everyone,

Seeing that this is my first *real* post to the MUD-Dev list, allow me to
say this: it is more than a little daunting to post things to this list (at
least the first time) when observing the highly technical and interesting
traffic going on. So please bear with me should my findings seem obvious or
even silly to you. :)

Well, as I mentioned in my little introductory bio a few days ago, I am
currently part of a two-man development team working on a from-scratch MUD
which we tentatively have called PirateMUD (granted, development is a little
slow right now). Armed with fresh inspiration from DUMII and having seen the
varying degrees of flexibility of different MUDs (meaning the possibility to
change the game without considerable redesign of the actual MUD code), we
went out to create a sort of script language for our MUD. The objective was
not to be able to use this language to change the actual MUD engine (which
arguably is possible for driver/mudlib architectures such as LPMud), but to
be able to create intricate puzzles and quests for the game. In honor of a
long tradition of three-word acronyms, we called the language CSL (for Catch
Script Language, or maybe Compiled Script Language). 

If there is interest, I could elaborate a little on the actual
implementation of the language, but below I choose to discuss just the
design issues.

Since CSL is aimed towards quest creation, every CSL function is linked to
an actual game event. Each game object (room/item/mobile) can have CSL
functions assigned to their event catches. When a specific event happened to
the game object, the mud engine checked for catch functions and executed
them. Often, the success of the event hinged on the return code from the CSL
function. For example, let's say that you need a pair of fraznium gloves in
order to pass through a specific door (yes, borrowed from UW2). The CSL code
of the room in which the door was in (let's say to the north) would look
like this:

        <room>
        .. (room data)
        <csl>
        <leave>
        if (is_env("north")) then {
                if (has_item("fraznium gloves") {
                        tell_room("The portal glows as @the(i) enter at ve(i).")
                        okay()
                }
                else {
                        tell_room("The portal prevents @the(i) from entering.")
                        fail()
                }
        }
        </leave>
        </csl>
        </room>

This worked tremendously well, and has allowed us to write some very nice
puzzles and quests. However, there is one little problem with this approach:
Since the MUD engine gets confirmation of an event from the CSL function,
things may happen in the wrong order. 

Example: A player tries to open a chest. The corresponding CSL function is
consulted, and all the checks turn out good -- the player is allowed to open
the chest. As a final measure before returing okay() (like above), the CSL
function tells the room about the rumbling voices and the fireworks erupting
everywhere. Now, when the MUD engine relinquishes control, it will write out
the standard success message. The output would be like this:

        -open chest
        As you open the chest, deep voices rumble from the underworld,
        and huge geisers of lava erupt everywhere.
        You open the chest.

As you can see, things happen in the wrong order, and even worse examples of
this phenomenon can be found (such as mobiles responding *before* you ask
them a question). One solution for this would be to have the MUD engine keep
quiet about its standard messages if there *is* CSL code attached or a
specific flag set. The problem with this is that it requires the zone writer
to write all the confirmation messages himself so that they appear in the
correct order (such as "You open the chest.") Sometimes (as in the above
example), this might actually be good (providing for more of a fantasy-book
read), but in other cases (during conversations, for example), this might
become very tedious.

Hmm, this amounted to a longer posting than I intended. I'd be happy to
answer any questions or receive any suggestions about CSL and the CSL
problem (there are more problems, I only can't seem to remember right now :) .
-------------------------------+-------------------------------------------
Niklas Elmqvist (Crozius)      | - I find the best approach is to take life
-------------------------------+ as it comes, [Death said.]
http://www.algonet.se/~croziys | - That seems very irresponsible...
e-mail: croziys at algonet.se     | - It's always worked for me.
			       |	(Feet of Clay, Terry Pratchett)




More information about the mud-dev-archive mailing list