MOO programming workshop

Compiled by Ken Eustace, May 2000-2004 using major works by Pavel Curtis, Jan Holmevik and Cynthia Haynes

Introduction

It all began with AusieMOO in September 1994, with the ISPG at Charles Sturt University hosting Australia's first educational and social MOO. Today AussieMOO has been set free and is operating at http://www.aussiemoo.org/ by a team of talented programmers and Web developers. You can download a copy of the Dank Fairy's The Ultimate AussieMOO Manual which is described as the definitive guide to AussieMOO, but also covers a great deal of MOO learning in general as well as a host of information specific to AussieMOO. Ten years later the ISPG provides two main MOO services:

K9MOO for training and development of programmers, fun "learn-by-doing projects" and a space for MOO research.
LC_MOO A facility for professional groups, educators and students for workgroup practice.

The MOO programming workshop can take place at either MOO and may be applied for use at other MOOs.

According to Pavel Curtis in his MOO programming manual, one-line commands are parsed and interpreted by the MOO. Such commands may cause changes in the virtual reality, such as the location of a character, or may simply report on the current state of that reality, such as the appearance of some object. The job of interpreting those commands is shared between the two major components in the MOO system: the server and the database. Either way, this workshop will change your thinking as a programmer as you program your own self as an avatar object in an object-oriented virtaul world.

Some time ago I drew a diagram to explain how the architecture of the MOO may be of interest to client/server application developers as it shows horizontal scalabity by use of different clients and protocols - telnet and HTTP. The enCore Xpress system devised over several years by Jan Holmevik and Cynthia Haynes, uses Java applets to build a GUI interface and to extend the database core, as shown in figure 1. Multimedia users connect via HTTP while text-only users may use a telnet client. Many exist for customised telnet access, but I use Pueblo/UE. You can download the latest version from http://pueblo.sourceforge.net/pueblo/index.php. I use HTTP with MOO classes and workshops and programming, while I also use Pueblo for patching upgrades and system tests. You can program the MOO with either client, but the enCore program editot is useful. The command are given in this workshop so you can program through either client type.

Figure 1. The client/server architecture of the enCore Xpress MOO system.

The MOO server is a program, written in a standard programming language, that manages the network connections, maintains queues of commands and other tasks to be executed, controls all access to the database, and executes other programs written in the MOO programming language.

The database contains representations of all the objects in the virtual reality, including the MOO programs, that the server executes to give those objects their specific behaviors. Almost every command is parsed by the server into a call on a MOO procedure, or verb, that actually does the work. Thus, programming in the MOO language is a central part of making non-trivial extensions to the database and thus, the virtual reality.

Objects in the MOO

The object with number `#494' in LC_MOO does not exist just because you write down its number, but it is a good idea that you write down object numbers on creation.. An explicit operation, the `create()' function described later, is required to bring an object into existence. Symmetrically, once created, objects continue to exist until they are explicitly destroyed by the `recycle()' function.

The identifying number associated with an object is unique to that object. It was assigned when the object was created and will never be reused, even if the object is destroyed. Thus, if we create an object and it is assigned the number `#1076', the next object to be created will be assigned `#1077', even if `#1076' is destroyed in the meantime. Every object is made up of three kinds of pieces that together define its behavior: attributes, properties, and verbs. Verbs are to MOO like methods toJava.

K9MOO uses a canine metaphor

Canine metaphor and themes are used as an “alternative world” to a university. With its learn-by-doing apporach, K9 has a simple topology for builders:

• KennelWorld – build your "kennel" as your personal space
• CanineCampus – lectures, workshops and team meetings as a group space
• DogWorld – building and designing cyber worlds as your Project space

Creating your online persona

Stop and close you eyes. Imagine a scripting language sitting on top of a network interface. The server provides a basic framework, but all the real behaviors are programmed in the scripting language and part of the "database".
A MOO database is a collection of MOO objects, with inheritance, properties, and program code. It's not a relational database. In a MOO, an object in the game world sense is the same as an object in the programming sense.
http://games.slashdot.org/games/03/05/07/017234.shtml?tid=127&tid=186, so harness your imagination and hang on to your seat!

Workshop 1: Designing your part of the canine world

In workshop 1 we must stop and design our character or avatar using text and images and by setting properties using the OPTIONS button on the menu applet .

1. Use a checklist as a design tool for a scalable, portable design. This is done by making 3 plans: Thematic,Technical and Community plans. At least have a thematic plan before you start to program.
Thematic plan – think of your part of the world as a theme park that must have:

• Purpose
• Attractions
• Themes and activities
• Multiple avatars support

Technical Plan
Which technologies, protocols, interfaces?

Community Plan

• Promotion
• Archiving history and culture
• Customised features

Here is my basic design for my avatar at LC_MOO, where my MOO wizard character is Hopper (#247):

Table 1. Hopper's details

And at K9MOO my Wizard character is GrisWald (#2):

Table 2. GrisWald's details.

2. Fill yours in now...

Table 3. Your draft details.

3. Design the avatar as part of design. Add more properties to your character via Options button. Learn by doing. Make a change and see what happens. Use the URL for each multimedia content and icon. I suggest you make a folder in your ZOPE folder or any Web server where you can store documents and store encore MOO images, sounds etc for you MOO programming exercises:

Figure 2. Player object properties to edit..

Creating rooms, spaces or even a kennel!

Here are 3 ways to create a room by entering commands (Courier New font) directly into the telnet window. You may need a Wizard character to help allow rooms to be connected in certain areas. You can use MOO Mail (or e-mail) to post such a message to a Wizard character. To find out you object inventory and the object numbers of each of your objects, simple type @audit me in the telnet screen entry window.

If you have to make a change to an object's name, type @rename me to jane will change your name to Jane.

Room WITHOUT entrances and exits: @dig mykennel
Room WITH entrances and exits: @dig in|out to mykennel
Add entrance and exit to current room without them already, to the attic: @dig up|down to attic

The room names are interachangeable with room numbers, so instead of using "attic" which has a room number of #1313, we can use the object number: @dig up|down to #1313

Decorating your room or kennel

Stop and design what objects you will need.

You will need to add a bowl to your kennel for the next exercise. Try these commands, substituting "mybowl" for the name of the object.

@create $container called mybowl

Enter drop mybowl and hit the "Look" button or just type "look" into the telnet window to see it is in the room. When you create each object, it belongs to you. To leave it visible in a room, you must use the drop command.
look mybowl to see its description.
open mybowl to see inside it as a $container class object
take mybowl will let you pick it up again.
@recycle mybowl will remove or destroy the mybowl

Now edit its properties using the button to change properties:

Figure 3. The Object editor.

Exercise: Give a dog a bone

Here is a chance to revise your plans. Use the thematic, technical and community plan you are to add a bone to your mybowl object of class $container. Griswald has a bowl called GrisBowl with object number #1508 and parent generic container (#8) made with that command entered into the MOOTcan telnet applet window. Some have added some imagination to include objects inside their kennels such as a box of chocolates, a rug with a fleas verb and in one case the kennel is an Italian restaurant!

Workshop 2: Programming and building your canine world

You are now on your own. All dogs are now off the chain and free to roam and explore. Use the hypertext links below and put what you learn into action, through your thematic plan development which began in workshop 1.

This will allow you to learn-by-doing in your own time and each week for the duration of the workshop series, we will meet to discuss our progress, share our joys and frustrations as well as enjoy learning what each has done. Use the MOO-workshop sub-forum to "show and tell". Good luck.

2 Object-oriented design in the MOO
    2.1 A simple object modeling design technique

3 Object-oriented programming in the MOO – Is it hard?

4 Programming in the MOO
    4.1 Becoming a MOO Programmer: the First Steps
    4.2 Time for a drink break
    4.3 Creating you generic object
    4.4 Defining verbs and arguments
    4.5 Defining Properties
    4.6 Permissions on an object, verb or property
    4.7 Expressions, Statements and Operators
    4.8 Selection Statements
       4.8.1 If structure
       4.8.2 If..then..else structure
       4.8.3 If..esleif..else..endif structure or case..if
    4.9 Iterative statements
       4.9.1 For statement
       4.9.2 While statement
    4.10 Passing messages to player objects
    4.11 Operators
    4.12 Editing objects, properties and verbs
    4.13 Examining MOO code
       4.13.1 MOO coding example 1: @list object:verb
       4.13.2 MOO coding example 2: What’s on TV?
       4.13.3 EnCore Xpress verb editor
    4.14 Verb structure
    4.15 Quick verb programming example
    4.16 Fixing bugs
    4.17 Sharing your Generic Objects
    4.18 Checklist for MOO programmers

References

1 How to program in an Object-oriented World

If you are new to the ideas expressed in object-oriented design and programming in software engineering (or don’t much care), then beware of information technology specialists who suggest that this is a new paradigm. Firstly it has always been an object-oriented world, secondly Grace Hopper was doing object-oriented programming just after World War 2, only we didn’t call it that then. This led to the suggestion that in IT we don’t really do anything new, we just rename some old stuff. Renaming objects is a common feature in object-oriented programming and you can do it in a MOO.

So what does this paradigm suggest?

The object-oriented way of doing things makes the following points:

• Processes (methods and verbs), data (properties and values) flow into an object model (this is called encapsulation) where objects are modeled as independent entities that can be re-used.
• The conversion from the design model to an implementation is easier and therefore cost-effective.
• Database record structures and multimedia information are also supported.

2 Object-oriented design in the MOO

First we have some terms and concepts to collect and digest.

An OBJECT is usually an abstraction of a real-world entity. Everything is an object in a MOO. Players, Rooms, Containers, Notes, WhiteBoards, Editors etc. Each object has an OBJECT NUMBER in the MOO database e.g. Crayfish Bay is object number #267 at LC_MOO. The object number can be substituted for the object name at any time.

A CLASS is a collection of objects having common features. A good example is the set of player classes of wizard (administrator), programmer, builder, player and guest. Use @classes to see the public classes available for use. The player classes represent a skill-based hierarchy that is flattening out as you can then change yourself by getting your own MOO player object by @requesting (type help @request) thus upgrading your parent class from guest to player and so on. For higher levels such as programmer and wizard, these are awarded to experienced players on request to a layer of class wizard. (type '@wizards' for a list of on-line wizards).

MOO objects are grouped together into classes by a mechanism called Inheritance. Inheritance is a relationship between two classes of objects, such that one of them, the CHILD, inherits all of the relevant features of the other class called the PARENT. Each class produces a particular type of object. For example all player objects are descendants of some kind of $player class in a MOO. The $player class has sub-classes that reveal a MOO character hierarchy, from least to most power and influence. Guest, builder, programmer and wizard are typical parts of the hierarchy of access levels and privileges. Once you get a MOO character yourself, use the @parents me command to list all classes of your player object back to the root class. Here is my list of classes for my character GrisWald(#2), at K9MOO:

GrisWald(#2) generic wizard(#57) generic programmer(#58) generic builder(#4) Frand's player class(#90) Generic Mail Receiving Player(#40) generic player(#6) enCore Web Object(#126) enCore Web Class(#138) Root Class(#1)

Each object inherits "layers of characteristics" form its parent classes (super classes). The object has a new layer added for its own characteristics. This is illustrated by the construction of classes through inheritance in Figure 7.2 on p100 of Holmevik and Haynes.

2.1 A simple object modeling design technique

Sample tasks are taken from a MOO object modeling table to help show development of your ideas, using very simple object modeling techniques. Here is a simple way to model your objects. Use the level 1 and 3 tables for designing any object in a MOO.

Level1 – User and system tasks table

Table 4. Simple OO use case.

Make a list of things done by the user and the system.

Level2 – Abstraction

The next step is called finding the level of abstraction, where MOO objects build on each other to form classes from the most general and abstract – root class, to the more refined and concrete – what could be more concrete than a bottle of soda! So by the end of this step, you should have a good idea about which list classes to use or make for your design, but it may be much shorter than the list revealed by the @parents <object> command in the MOO.

Level3 – Object description table

Use the level3 table below to detail your design with the example used in object-oriented design.

Table 5. Object description table.

NOTE: as a rule, you should only place your verbs and properties on generic objects like #208, which should NOT be used to interact with – instead create a subclass to use as a test object, as shown by #209.

3 Object-oriented programming in the MOO – Is it hard?

MOO programming is easy once you get started with a few good resources, take your time and learn a few simple concepts about Object-oriented (OO) programming – a lot easier than learning Java and more fun. People are objects. Your understanding of OO concepts will be enhanced at using a MOO as you behave as an object in an OO world, something that MOO programming has over learning Java, Smalltalk and C++. Walker (1999) has the resources you need to get started – the LambdaMOO programmers manual (Curtis, 1997)-use this as a reference, and Yib’s Pet Rock: a programming primer for beginners (use this as a tutorial). Other resources also exist on the Web.

The MOO database core starts off with basic object types – classes called GENERIC OBJECTS or GENERICS. Generic objects are intended for use as the parents of new objects. As you create new objects, the class is defined. Typical generic objects are $thing, $player, $room, $note and $container. The $root_class is the ROOT CLASS where all objects begin. If I wanted to create a computer object in the current room using the $note class:

    @create $note named "computer"

If I wanted to create a computer SUBCLASS, the command is:

    @create "computer" named "macintosh"
    @create "computer" named "compaq"

So it is easy to create objects and to make that object can either be an instance of a generic object or a subclass of a generic object, as was the case for "computer" as a sub-class of the generic object called $note . The next step is to attach special methods to an object in order to make an object do something. These methods are called VERBS and this is a second level of the MOO programming process. Most of the tutorials will take you through three main steps:

1 make sure that your character is a programmer or wizard sub class
2 create or find the object(s) in the database.
3 create, program and/or edit the verb(s) and properties for that object.

4 Programming in the MOO

Holmevik and Haynes (2000) provide an excellent step-by-step introduction to the way the MOO makes programming "fun and easy" in Chapter 7. MOO is also a good preparation for learning object-oriented design and programming techniques that are used in C++ and Java. In my own opinion, MOO, Visual BASIC and Python are better for beginners then either C++ or Java. If new programmers still find programming "fun and easy" then let them loose with C++, Java or maybe even jPython (See http://www.jpython.org)

• Read page 97-98

Let me digress and talk about the Java programming language, in order to make a brief point. When teaching Java, I always tell my students to know the language. Start by dissecting its parts and putting them back together. So off they go to study the class hierarchy in the various Java packages before tackling the work at http://java.sun.com/docs/books/tutorial/java/

The java.net package of classes for Java 1.2 is shown below:

java.net Class Hierarchy

class java.lang.Object
class java.net.Authenticator
class java.lang.ClassLoader
class java.security.SecureClassLoader
class java.net.URLClassLoader
class java.net.ContentHandler
class java.net.DatagramPacket
class java.net.DatagramSocket
class java.net.MulticastSocket
class java.net.DatagramSocketImpl (implements java.net.SocketOptions)
class java.net.InetAddress (implements java.io.Serializable)
class java.net.PasswordAuthentication
class java.security.Permission (implements java.security.Guard, java.io.Serializable)
class java.security.BasicPermission (implements java.io.Serializable)
class java.net.NetPermission
class java.net.SocketPermission (implements java.io.Serializable)
class java.net.ServerSocket
class java.net.Socket
class java.net.SocketImpl (implements java.net.SocketOptions)
class java.lang.Throwable (implements java.io.Serializable)
class java.lang.Exception
class java.io.IOException
class java.net.MalformedURLException
class java.net.ProtocolException
class java.net.SocketException
class java.net.BindException
class java.net.ConnectException
class java.net.NoRouteToHostException
class java.net.UnknownHostException
class java.net.UnknownServiceException
class java.net.URL (implements java.io.Serializable)
class java.net.URLConnection
class java.net.HttpURLConnection
class java.net.JarURLConnection
class java.net.URLDecoder
class java.net.URLEncoder
class java.net.URLStreamHandler

Interface Hierarchy

interface java.net.ContentHandlerFactory
interface java.net.FileNameMap
interface java.net.SocketImplFactory
interface java.net.SocketOptions
interface java.net.URLStreamHandlerFactory

Find the class java.net.Socket in the above package, by following the links at the same Web site. If you look for the class method to use to find out which port a MOO server is running you may want to use the method below, from the class java.net.Socket

getLocalPort()

This method when installed, returns an integer value for the local port to which this socket is bound.

Is a Java method the same as a MOO verb?

• Compare what was just said about the Java class hierarchy for just one package of Java classes to the simpler MOO class hierarchy. MOO verbs and properties are much easier to handle.

After that heavy piece of thinking about comparing class hierarchies, your thirst to learn MOO programming continues after a drink.

• Design and create the bottle of soda (OK you can make it champagne, but you had better have a reason to celebrate, I recommend a cheap bottle of soda for beginners J ).

The construction of classes by inheritance and the anatomy of the MOO object depict verbs as the object processes and properties as the stored data about the object. Starting with a subclass of $thing:

@create $thing named Generic Drink, drink
@describe soda as "You see a bottle of soda."

The new test object named soda is now a subclass drink and will inherit the verbs and properties used to define GenericDrink.

The next step in the design process uses pseudocode to describe any verb. The design suggests that the Generic Drink object (super class or parent of the soda object) requires a verb called Drink and a review of the design adds a property called taste.

4.4 Defining verbs and arguments

Verbs are like commands and are formed in two steps:

1. Define the verb on an object
2. Program the verb.

1. on which object it is defined – this is called the direct object.
2. whether a preposition is allowed
3. whether an indirect object is allowed, in the command syntax.

@verb object:verb direct_object preposition indirect_object

Note how the verb argument variables operate. You can now define the verb drink and its arguments on to the Generic Drink object:

@verb "Generic Drink":drink this none none
Verb added (0).

and now you may even have time to teach yourself how to throw a snowball at someone whicl drinking a bottle of soda J

4.5 Defining Properties

The drink verb also needs to define the message property. The five MOO data types that properties and other variables can hold.
 

Data type	Example
Object number	#64
Integer	42
Floating point (decimal)	4.2
String	"The time has come, the walrus said"
List (an array that can contain all the data types above)	{"The","cat","sat","on","the","mat"}

Table 6. MOO data types to consider..

The command to create properties on an object has the general format that uses a period to separate object names and property names.

@property object.property_name data_type init value

So if the Generic Drink object is to store text messages about how the drink tastes – like in a property, then the data_type string is used. See the example in table 7.3. Now to add the property:

@property "Generic Drink".taste ""
Property added with value "".

Why an empty string or null of "" for the taste property? Each type of drink, either soda or champagne will have its own taste message, when new test objects form Generic Drink are created. The table below summarises what has been done to this stage.

That now defines the verb on an object, but step 2 of programming the verb is still to do. This will require a closer look at the "building blocks" of the MOO language and its expressions, statements and operators.

4.6 Permissions on an object, verb or property

If you are familiar with UNIX, you may already know abouit read, write and execute permission on a file or directory. In a MOO we are concerned about similar permissions on an object. Here are some useful notes on permissions from http://tecfa.unige.ch/moo/book2/node120.html

Acknowledgement: This text is a formatted version of a message posted to *programmers on (now defunct) WorldMOO on Sat Mar 4 07:50:23 1995 PST by Defender (#160)

1. Every object, verb, and property has an owner.
2. Verbs are executed with a 'set of permissions', or a flag indicating which player owns the task. Any verb you write will normally run with your permissions, which means it can affect things you own. Wizards can use a built-in function called set_task_perms(), documented, to change the permissions of a particular verb's execution. This doesn't change the verb ownership, nor does it change permissions for other verbs. Normally you don't need to worry about that.
3. A verb with the permissions of the owner of something, or a wizard's permissions, can affect that something (read its value or write to it). For instance, you can create verbs and properties on objects you own, because the creative verbs run with your permissions.
4. Everything (objects, verbs, and properties) have a set of possible 'permission bits', which control access to them. Two of these potential bits are always R and W (for Readable and Writable). For verbs whose permissions aren't the owner and aren't wizardly, these flags are important.
5. If the R bit for something is set, any set of permissions can read it. For example, if a verb you write has its R bit set, anybody can read the verb code. If it is not set, the object/verb/property is said to be "E_PERM'ed", referring to the error code E_PERM (Permission Denied), which will be returned upon attempts to read the value. Unless you are deliberately needing to hide some information, it is good practice to make things readable by setting the R bit.
6. If the W bit for something is set, any set of permissions can write to it. For example, if you have a property whose W bit is set, anybody can set the property value to anything they want, or remove it altogether. The W bit is almost never set, and should NOT be set for verbs in particular.
7. What reading and writing mean depends on what you are dealing with.

Table 8. verb permission to consider.

4.7 Expressions, Statements and Operators

At the simplest levels, MOO code can exist as expressions and statements separated by semi-colons. Using your pseudocode design, the body of code in a verb program is a combination of expressions, statements and operators. While expressions generate values and statements provide structure to verbs, operators are used to manipulate both expressions and statements.

While the expression 2 + 2 = 4 generates the value 4, a variable can be used as a temporary place to store values as shown by the expressions using the assign (=) and addition (+) operators:

Number1 = 2;
Number2 = 2;
Answer = Number1 + Number2;

When learning a new programming language like Java or Python, students often misunderstand the significance of local and global variables. While properties can be accessed form any verb, variables like Number1 are always local to the verb, are temporary and disappear when the verb stops running. Meanwhile properties are permanent and keep their assigned value until it is changed or removed. Hence we can define local and global variable as:

Local variables – variables used inside verb programs
Global variables – properties defined on objects e.g. taste
The programmers manual has listed the reserved variables used in the MOO system.

Now on to examine the selection and iterative control structures that form the basis of algorithm design of MOO verbs.

4.8 Selection Statements

It’s a matter of choice… using a logical test condition in order to make a decision.

4.8.1 If structure

if..endif

The basic If-statement selects an action based upon the result of a certain condition being TRUE.

if (it is raining)
   Stay home
   Read a book
endif

4.8.2 If..then..else structure

if..else..endif

This variation of the If-statement is structured so that the action based upon the result of the test condition is TRUE, has an alternative or else action to be carried out if the result of the test condition is FALSE. Note the use of the reserved word else for this type of binary selection mechanism.

if (it is raining)
   Stay home
   Read a book
else
   Go for a long bike ride
endif

4.8.3 If..esleif..else..endif structure or case..if

What happens when you go to a restaurant?

Well for a start, you usually get busy talking and forget to order. Then you are faced with make a quick decision from the multiple of choices on the menu. Will you have an entree as well as main course and dessert? If so, which entrée and which main course? Ok leave the decision about dessert until later. Here we have the case..if structure in action, where there are a multiple number of option to select.

if I am hungry
   go to restaurant
elseif thirsty
   go to coffee shop
else
   stay home and repair bike
endif

Note the level of indentation (using 3 spaces) and how each if structure must have its own endif statement. In some programming languages the esleif is seen as an abbreviated elif statement.

4.9 Iterative statements

Iteration is a process to perform an expression or statement for a set number of times. So the program enters and leaves a loop, but since iteration is a fancier term than looping, that is why it is used J

"Let me re-iterate"

Since to iterate is to repeat an action, then to re-iterate is almost a tautology or a recursive action… let’s not go any further with that discussion.
The two iterative statements are the for…endfor and the while…endwhile structures.

4.9.1 For statement

This is used when you want to run in a loop until a certain condition is met. This is a test condition where the iterative process happens until the exit condition is met.

for (first to last student in class)
   Give them a homework exercise
endfor

for (10 downto 0)
   Print each number
endfor

Like if-statements, the for..endfor and while..endwhile loops must always be closed off with an endfor and endwhile construct, respectively.

4.9.2 While statement

The while..endwhile statement is an iterative statement with a pre-test condition. This means that unless the condition is met at the start of the loop, then the process never enters the loop in the first place. Thus we do not know in advance, how many times the process loops through the set of expressions and statements

while (the book is interesting)
   keep reading
endwhile

4.10 Passing messages to player objects

In MOO, we don’t just use the print or some variant of an output statement to the user’s screen, we pass messages to each other. The two main ways of doing this are to send a message to all players in the same location or to tell it privately to a player.

What do the following statements imply? Who gets each message?
Do you remember the significance of the colon : and the period . in the MOO object syntax for verbs and properties?

player.location:announce_all(player.name, " has been cursed .");
player:tell("The curse is upon you now.");

4.11 Operators

The operators used in a MOO - Arithmetic, Value comparison and Boolean operators provide the programmer with the logic to manipulate the various expressions, statements and variables used earlier in this topic.

• Try to design and add a drink verb to the soda object.

Just as the @set command is used to assign values to properties by the following syntax:

@set object.property to value

the EnCore Xpress buttons called Objects (Create and Edit object), Edit (Properties) and Program (for editing verbs), are an . Note the use of the @display command for listing verbs and properties on objects.

• Draw up a table to describe the action of the following command list:

4.13.1 MOO coding example 1: @list object:verb

Sign is a verb attached to the Generic Room object #3, on LC_MOO and K9MOO. Here is what it looks like:

@list #3:sign

#3:sign any any any

1: lines = player:linesplit(argstr, 75 - length(player.name + " holds up a SIGN: | " + " )"));
2: length = 0;
3: for line in (lines)
4:    length = max(length, length(line));
5: endfor
6: space = $string_utils:space(length(player.name) + 15);
7: bound = $string_utils:space(length + 2, "_");
8: player.location:announce_all(space, " ", bound);
9: player.location:announce_all(space, " |", $string_utils:space(length), " |");
10: for line in (lines)
11:    player.location:announce_all(player.name, " holds up a SIGN: | ", $string_utils:center(line, length), " |");
12: endfor
13: player.location:announce_all(space, " |", bound, "|");

4.13.2 MOO coding example 2: What’s on TV?

Like most programming environments, the MOO code has to be compiled into an internal form and this is done for you by the @program command. If I use the Generic TV object #104 and use the command @examine #104, a list of the following verbs appears:

@examine #104
Generic TV (#104) is owned by Secretariat (#2).

Aliases: Generic TV and gentv

Congratulations on your new TV! Type 'schedule <tvname>' to see the tapes available for viewing. You can also hook a VCR up to your new tv and view cdr/format tapes. Enjoy!

Key: (None.)
Obvious Verbs:
Turnon play init_for_core
Turnoff pause
Tune res*ume
look_self autopause
sch*edule dumptape

4.13.3 EnCore Xpress verb editor

4.14 Verb structure

Each of the verbs in the list have the following attributes:

Verb Name:
Verb Owner: Boxer (#2)
Permissions: rxd
Read
Execute
Debug
Arguments: this any none
Direct Object
Preposition
Indirect Object

If I want to look at the 14 lines of entered MOO code inside the verb sch*edule, I use the @list <object>:<verb> command and study the syntax of the for and if structures:

@list #104:sch

#104:sch*edule this none none

1: player.location:announce_all(player.name, " consults the tv schedule. .");
2: player:tell("The following tapes in the tape Library can be viewed at ANY time. Just tune your tv to channel 11, turn it on, and 'play <selection #> on tv'.");
3: player:tell(" ");
4: n = 1;
5: for tape in (this.library.tapes)
6:    if (length(tape.labl) > 30)
7:       lab = tape.labl[1..30];
8:    else
9:       lab = tape.labl;
10:   endif
11:   su = $string_utils;
12:   player:tell(su:left(n, 5), su:left(lab, 31), su:left(tape.owner.name, 15));
13:   n = n + 1;
14: endfor

4.15 Quick verb programming example

This is the shortest number of steps in adding one line of MOO code to a verb called start which is to be attached to a new object that I create called car:

@create $thing named car
@verb car:start this none none rxd
@program car:start

player:tell("You start the car. Nothing happens.");.

Note the arguments and permission included in the @verb statement. To fix a verb or edit it, you can use @program car:start again by typing in ALL the code again, as this command includes the compile step or use the verb editor @edit car:start.

NOTE: once you use @verb to create the verb, you can only use @program or @edit.

If you want to remove the verb from the object use @rmverb car:start and if you want to go further then, use @recycle car to remove the car object. That may be a good idea if the car won’t start J

Still confused? Then maybe you need more time working with Chapter 7 of the textbook do some programming in the MOO.

4.16 Fixing bugs

The MOO code is checked for errors at two stages: when the verb is compiled and during runtime, where the trace back call points to the verb and line where the bug occurs. Study the code if an error occurs and fix it!

4.17 Sharing your Generic Objects

A lot of MOO’s have a place or repository where programmers drop off generic objects for others to use. In some other languages, this may be called a class library. Since all the objects you create are part of your inventory, you will need to make your generic objects fertile so that they can have subclasses created – i.e. for others to share your code. Make sure that your code is free of bugs and then use the chmod command used in UNIX to change the access privilege and make your generic object fertile.

@chmod "Generic Drink" +f
 

4.18 Checklist for MOO programmers

1. Build yourself a room to attach to your kennel in KennelWorld at K9MOO.
2. Design and attach the following room to your ‘kennel’:

An attic with a door, a window (with view), a mirror, a poster, a map of the world and a mahogany dresser.

3. Do any of the objects in your room interact with each other?
4. How would you change the décor? It is your attic! Find out who else has built an attic and compare design ideas.

References:

Curtis, P. (1997). LambdaMOO Programmer's Manual For LambdaMOO Version 1.8.0p6 March 1997. [Online] Available at ftp://ftp.lambda.moo.mud.org/pub/MOO/

Holmevik, J. R. and Haynes, C. (1999). EnCore open source MOO project. [Online]. Available at http://lingua.utdallas.edu/encore/

Raza, H. (2000). Design and management plan for K2MOO. Master’s project [Online] Available at http://www.csu.edu.au/research/ispg/razak2.html

Schneider, D. K., Godard, R, et al (1997). The evolving TecfaMOO Book- Part II: Technical Manual. [Online] Available at http://tecfa.unige.ch/moo/book2/tm2.html

Sørensen, S. (1999). MOOtcan files. [Online]. Available at http://cmc.uib.no/~sindre/mootcan/

Yib (#58337 at LambdaMOO). (1999). Yib's Pet Rock: A Programming Primer for Beginners. [Online]. Available at http://cmc.uib.no/moo/yib/

Walker, D.W., Collings, P. and Richards-Smith, A. (1998). Synchronous IT Support for Group Work. [Online]. Available at http://simnotes.canberra.edu.au/synch.nsf/

Walker, J. (1999). MOO programming resources. Cyber Culture Media Center. [Online]. Available at http://cmc.uib.no/moo/