Iím still trying to get the hang of the LambdaMoo programming language. I thought Iíd share some of what Iíve figured out, for both people who can program and for those who canít (yet).
This page isnít by any means complete. For that, see the documents on Shawnís page: the LambdaCore User's Manual, the LambdaMOO Programmer's Manual, and the LambdaCore Database Programing Manual.
[ Page o' SpinnStuff ]
Most of you have figured out how to make objects; in case you havenít, the basic command looks like this:
@create $thing named Maxwellís Silver Hammer,hammer
The new item will have a full name of Maxwellís Silver Hammer, but can be referred to as hammer for short. An item can have multiple aliases, separated by commas; you can also add aliases later with the @addalias command.
If you want a container instead, say $container instead of $thing.
You probably want to add a description that the user will see if she uses the look command:
@describe hammer as "Itís silver, and small, and really really dangerous."
Now, you want it to do something! How?
@verb rabbit:nudge this none none
That tells the moo to create a new verb nudge for the rabbit, and that the usage will be nudge rabbit. (Moo stupidly doesnít understand articles, thoí I suppose you could define an alias the rabbit for your rabbit.) If youíre an accurate typist, you can go on to program the verb like this:
player:tell( "You nudge the rabbit. It squeaks in dismay." );
player.location:announce( player.name, " nudges the rabbit. It squeaks in dismay." );
So, I edit my verbs with the editor, which you enter like this:
This will take you into a vintage-1970s line editor. You can type the program in the same way, but preceding each line with a quote mark, and omitting the final period:
"player:tell( "You nudge the rabbit. It squeaks in dismay." );
"player.location:announce( player.name, " nudges the rabbit. It squeaks in dismay." );
Type list to list the program so far. Type list 3 to list just line 3; del 3 to delete it; s/fred/joe/3 to replace fred with joe on line 3. For more commands, see the Programming Manual.
You type save to attempt to compile it. The moo may well bleat again; but the big advantage of @edit over @program is that you donít have to retype your program (an amusement which quickly gets old), just correct it.
As in the example, you often want these two messages to differ. The message to others should include the playerís name, not Ďyouí; you get at it with player.name.
What is printed appears in parentheses. You can print several things at once, including numbers, text, variables, and more exotic things. You just include them all in the parentheses, separated by commas.
Text appears in quotes: "This object rocks." If youíre not a programmer, itís very easy to leave out the quotes, or just one of them. Donít do that; the moo will complain.
Like most statements, the command ends in a semicolon.
@property dildo:on 1
@property radio:lastuser #233
@property topiary:form "a giant fish"
Unlike Ďrealí programming languages, moo doesnít require variables to be typed or declared; it just figures out what they are from what you put in them: in the example, respectively, a number, an object (object references are always preceded by # in moo), and a string (thatís programmerese for Ďtextí).
Now, within a verbís code, you refer to the objectís properties with this: e.g.
this.on = 1;
this.lastuser = player;
this.form = iobjstr;
From this you can figure out that player.name is a propertyóall players have a nameóand player.location is another property, one that points to the room that currently contains the player. The Database Manual gives a full listing of all the properties that various canned objects (like players, rooms, containers, and exits) have.
@verb glass:description this none this
Now you edit the :description verb. An example might be a radio:description verb:
basic = pass(@args);
if (this.on == 1)
basic = basic + " The radio is on." ;
basic = basic + " The radio is off." ;
We are overriding the default action of the description command, normally done by the parent object (the generic thing, generic container, or whatever). The first line executes the default routineópass passes the parameters of our call to the parentóin this case returning the default description to us, the one we set using @describe.
Now we add to this description. The + operator of course adds two strings together into a longer string. Note that weíre testing our property, this.on. Donít forget the semicolons.
Finally, we return the completed string, basic, because description expects a string value to be returned (passed back for printing).
Note that description doesnít use player:tell; this will be done for us somewhere else.
If youíre used to programming, moo verbs are frustratingly limited in parameter handling. (Actually the limitation is on the parser rather than the verbs themselves.) Basically you can only write verbs on the following models:
Turn radio on
Give hernia to zompist
Poke k-man with sharp stick
In effect all verbs have three parameters (called direct object, preposition, and indirect object). One of the objects must refer to the object, and the preposition is limited to a short list of predefined words.
When you define a verb, you do it backwards. Youíre going to say "eat pill", but you define it as "pill:eat".
When you create the verb, you always have to specify all three parameters. An unused parameter is none; one that refers to the object itself is this; one that refers to something else is any. The above verbs would be defined this way:
@verb pill:eat this none none
@verb radio:turn this on none
@verb hernia:give this to any
@verb stick:poke any with this
@verb pill:eat this none none
Each definition has one this parameter. You may be tempted to leave it out (@verb pill:eat none none none), but then the parser will never be able to call your verb! Think about the commands again, e.g. Eat pill. If itís a command for the pill object, the word pill has to occur somewhere in the command-- otherwise, the parser simply does not have any reason to pass the command to the pill at all.
For the simplest commands, then, the parameter list should read this none none.
What if I defined it wrong? You can use @rmverb. I tend to forget the parameters at first, then have to user @rmverb to get rid of the uncallable verb, as in this session:
@verb pill:eat this none none
Some verbs, like turn on or act up, sound better with an objectless preposition. (Linguistically itís a particle, but moo calls it a preposition, so there.) You want to say Turn radio on, not Turn radio. You do this with the this (preposition) none parameter list. Note that the parser is not smart enough to let you say Turn on radio.
Often you want two objectsónormally because you want your object to act on some other object. In this case you must define a preposition in between (from the list in the Programming Manual). You canít have a command that reads Give zompist money; it has to be Give money to zompist. Thatís why I had to define odd syntax like Play piano with "Greensleeves" or Drive bus to east.
In this case you can either specify the exact preposition in the verb (this on any), or allow any preposition (this any any).
You can put the other object (the any parameter) either as direct or indirect object. Itís just a matter of what command sounds better. Compare the following verbs for the Sharp Stick:
@verb stick:poke any with this -> "Poke zompist with stick."
@verb stick:poke this at any -> "Poke stick at zompist."
When you edit a verb, you donít have to repeat the parameters, which is a blessing. You can @define a verb as shed:get any off this (quick quiz! What command will you use with that?), but to edit the code all you need to say is @edit shed:get.
Can I have multiple variations of a verb? Sureójust in case you really really want to be able to say both "poke zompist with stick" and "poke stick at zompist". Just @define each variation, with its own parameter list. Now youíll have to specify the parameter list when you edit. A warning, though: I donít think itís worth it. Itís no use trying to pretend to the user that sheís typing ordinary English; and youíre just likely to confuse or frustrate yourself with the extra parameters and verb versions.
Can I have more parameters? Sort of. What you do is parse the third argument (the indirect object, available inside the program as the string iobjstr) yourself. For instance, maybe you want to say listplayers game from 1 to 10. You have to define this as @verb game:listplayers this from any. Youíll get "1 to 10" as the iobjstr, which you can then parse yourself. There are functions to help you do this. Itís a bit of a hassle, though, and your life will be easier if you define separate verbs or something.
I want a string as the third parameter. No problem; the parser takes care of this for you. The piano uses this: I defined Ďplayí as @verb piano this with any. If the player types Play piano with the music of Burt Bacharach, the parser takes the entire rest of the sentence, "the music of Burt Bacharach", as the indirect object, and places it in iobjstr. Since I simply want to treat it as a string, I donít need to do anything special.
The parser will handle some errors for you: misspelling required words (such as the names of your objects or verbs), leaving parameters out; referring to objects that arenít there.
Some error conditions to think about:
In general these conditions are handled by if statements. For instance, a radio:on verb might look like this:
if (this.on == 1)
player:tell( "The radio is already on!" );
player:tell( "You turn on the radio." );
this.on = 1;
As usual, you canít deviate from the exact syntax the moo wants. The condition has to be in parentheses; thereís no semicolon after the if, else, or endif; the endif must exist, even for a one-line statement.
Very confusing if youíre not a C/C++ programmer: testing a value requires a double equals sign (this.on == 1); setting one requires a single equals (this.on = 1). You can look at a misbehaving verb for minutes on end without noticing an error like this. (Not-equals is !=, by the way.)
The else part is optional. You can also have any number of elseif (another condition) blocks before the else.
The language is object-oriented, with inheritance. Note that the @create command specifies the base class of the newly created object. Verbs correspond to methods (but you use object:method, not object::method), and properties to data members (using the same . as in C/C++).
Can you define a verb thatís not called by a player, but only by other verbs? Sure. It uses a special parameter list: this none this, which the player cannot enter (if thereís no preposition the parser just quits). The dartboardís hit command works like this. Itís defined by @verb dartboard:hit this none this and called by the dart:toss routine with the line
#278 is the object number of the dartboard (object numbers are a special data type; think of them as pointers to objects). You can use this anywhere, to make sure the moo understands you whether or not the dartboard is around. Itís better programming practice, of course, to avoid using the same number all overóit means you couldnít use the object in another moo, for instance. If we needed to refer to it often, itíd be better to put the dartboard number in a property of the darts, for instance.
Thereís fairly nice list (array) support, and lists can include any other type, including other lists, as members.
One little gotcha: the C construction cond ? texpr : fexpr morphs in moo into cond ? texpr | fexpr.
Most things the player can do on the command line can also be done by the programmer within a verb-- sometimes with a slightly different verb or syntax. For a full exploration of this, see the Database Manual.
Don't worry about prettyprinting your program. Moo stores it in an interpreted form, and supplies its own indents and spacing when you next edit it.
Dildo. The dildo remembers its state in an on property. It also remembers the last user; I defined a lastuser property pointing to an object, and set it to player when appropriate. The delayed action is accomplished using a fork command; see the Programming Manual.
Piano. The piano isnít really a container; it just remembers who is hiding under it (using a hider property). The description is modified to make this seem more real. Note the error handling in the hide command: there can only be one hider at a time, so the previous hider (if itís not the player!) must be ejected. We cannot prevent the hider from leaving the room, so the description and other commands must check to see that the hider is really still there. We do this by checking if hider.location == this.location-- if the hider is in the same room as the piano. The play command uses random to determine the playerís style and the onlookersí reaction.
Slow glass. This is mostly implemented in a huge description command. There are three properties that increment (at different speeds, so they donít overlap) on each call: location, weather, and time of day. Thereís also a direction, 1 or Ė1, which determines whether location is incremented or decremented.
Readme. The readme object simply contains couple of list properties, items and signed. The first contains the items added to the bulletin board; the second contains the playersí names.
Dartboard. This was the most complicated programming task. The dartboard remembers the current scores (as pair of lists, the players and their scores) and contains verbs to reset the scores, set the target, print out the scores, or retrieve the darts, which may have wandered to another room. There is also a hidden verb, hit, which is called by the darts when you toss them. This verb makes heavy use of the random function to vary the results. It throws three darts, totals them up, adjusts the scores, determines winners, and on the second and higher rounds passes the darts to the next player.
VW Microbus. This required wizard status to fully implement; but the actual coding is straightforward. The bus is actually a separate room which stays in one place; the "bus" object you can pick up and carry around (and which moves around the moo as the bus is driven) is not even a container, and its enter verb just teleports the player to the separate room. The room has a single exit, whose destination point is reset as the player drives. The bus room itself is, of course, not inside another room at all; we just remember where it is as a property. The ways() function tells us what exits a room has; the Database Manual can be ransacked for tidbits like this. The difficulty here was not so much writing the code, as in being careful about what needed to be done. For instance, as the bus moves, the bus object not only has to be moved, but messages have to be printed in the previous and new locations so users see the bus coming through.
[ Page o' SpinnStuff ]