Color Guide:
Red indicates a command (or commands) you enter into the MUCK.
Navy indicates text returned by the MUCK, usually a result of a command you typed.


Building Rooms
Interested in creating MUCK rooms? This tutorial describes how to do just that. This tutorial doesn't assume that you know much about MUCKs, but it will be helpful if you understand the basics of MUCK objects. You should know that objects such as rooms have numbers called 'dbrefs' assigned to them, and these are the true 'names' of the objects used by the MUCK server. You should also know that objects have many properties used to describe the object's appearance and functions, and most of these properties can be changed by the owner of the object.

To add your own rooms to the MUCK, all you need is a Builder flag set on your character (sometimes called the Builder Bit), and a little bit of effort and creativity. Most MUCKs give you a Builder Bit when you make a character. Note that a 'room' may represent an open field or a lake, but they are still called rooms for purposes of MUCK building.

Once you've made a new room, it is always accessible by you. If you want to make it accessible to others on the MUCK, you will want to ask an administrator to review your work and link it somewhere to the rest of the MUCK. Good room building requires you to be reasonable as well as creative. If you want your rooms added to the public portion of the MUCK, your rooms should fit the theme of the MUCK, and provide an element that isn't already present.

Some players build rooms for a particular story, use them once, and remove them after the adventure is completed. Other players build private rooms never seen by most players in the MUCK. Then there are loonies like me who build them just to experiment with room-building and descriptions. In any case, read on to learn how to become a MUCK Engineer.

Contents
Creating the Room

Making a new room is easy. All you need is 10 monetary units (grains in A Bug's MUCK), and the @dig command. For example, say you wanted to create a place called 'Winding Path'. You'd type the following into the MUCK.
The MUCK will respond with something like:
The number is the room's dbref. The number you get will vary, but the idea is the same. You'll need this number later, so record it with a '#' in front of it and keep it handy. For example, you might want to go to your new room right after creating it. You don't have a normal way in yet, but you can use the jump command and the room's dbref to get there:

Renaming a Room

If you change your mind about the name of the room, you can always rename it with the @name command:
This works for the names of exits (see below) as well, and you can include the exit's aliases in the new name.


Recycling a Room

If you want to delete a room, you can use the @recycle command. You must 1) be in the room and 2) specify 'here' as the name of the room.
For some reason, you can't even use the room's dbref to specify it for disposal; you must say 'here'.


Setting the Description

Now that you have a room, the first thing you'll probably want to do is describe it. Few things are less interesting than an undescribed room. The following two methods can be used to set a room's primary description.
When using these, be sure you replace 'my_room' with your room's name or its dbref. Let's set a description for the Winding Path:
When you look at the room, you'll see something like this:
This description would do, but it would do even better with a little paragraph formatting. Indents and paragraph breaks can do a lot for the readability of your descriptions. Try this:
Note that {nl} is a little MPI function that forces a line break. A look at the room now displays:

Exits

Rooms aren't very useful unless you have a way to get in and a way to get out. This is done by creating special MUCK objects called exits, attaching them to your room, and linking them to other rooms. There are two ways to do this. The first method uses the @open command. Let's say we want to add a way east from the Winding Path to another room called Near the Brook with the dbref #2545. First, make sure you are in the Winding Path room, then enter:
The MUCK will respond with something like:
This did several things. It created an exit object called (E)astern Path and attached it to the Winding Path room. It gave the exit several alias, 'east' and 'e', so that players can use the exit by typing either (e)astern path, or east, or just e. Lastly, it created a link from the Winding Path to the Near the Little Brook room. The link means that if you use the exit, it will drop you into the Near the Little Brook room.

IMPORTANT: A link is really a one-way teleporter. You can use this exit to get from the Winding Path to Near the Little Brook, but if you go to Near the Little Brook, you won't see a way back to the Winding Path. You must make a sister exit in the Near the Little Brook room to link back to the Winding Path. In most cases you'll want to do this, but there are situations where you might not. For example, an exit might represent a cliff where a player could tumble down into a field below, but might not be able to climb back up.

Look at the room now.
Notice the new exit. Remember to give your exits meaningful names as well as short-hand aliases. Try to name your exits so that only a single letter is necessary to use it. This is easier and reduces potential confusion. An exit called (E)astern (P)ath with the alias ep may be meaningful, but the alias requires entering two characters, and may not be obvious to newer players who try to type e to take the path.

I mentioned there were two ways to make an exit. Here's the other:
Notice the dbrefs. @action creates the exit along with its aliases and associates it with the Winding Path room. @link points the exit to the Near the Little Brook room. These two commands together do the same thing as the @open command. So why do it this way? Because this method allows you to add exits to a room you aren't currently sitting in. If you use this method, be very sure to immediately link the room to the target room. Leaving an exit unlinked is a bad idea because anybody can come along and link it to where they like, among other nasty possibilities. If you want to leave an exit unlinked for now, do this:
This assigns the link to a little program that does nothing but counts as a valid link. Make sure you change 'my_exit' to the name or dbref of your exit. Later you can do @unlink my_exit and then use @link to redirect it to wherever you like. This is handy for building reference exits that will link to rooms which haven't been created yet.

Exits cost 2 monetary units. The @open command will charge you two units, and the @act and @link commands will charge you one each. A typical room with three exits will cost you 16 monetary units.


Making a Room "Jump-OK"

If you want to allow other players to be able to use the jump command to directly enter the room without using the normal exits, set the J flag with the following command:
To turn off Jump-OK, do this:
Using Property Lists and MPI for Advanced Descriptions

If your room description consists of only two or three short paragraphs, use the standard _/de: property for the description as usual. The _/de: property has limitations on the length of the description itself, just over a thousand characters on A Bug's Muck; some MUCKs may have smaller limits.) While turning your room description into a novel isn't going to make you a popular room builder, a thousands characters is only about three average paragraphs. You can get around the length limitation by adding a property list to your room, either by hand with a series of @set commands (if you know what you're doing with property lists) or by using lsedit.

To use lsedit to create your room description, fire up lsedit with something like this:
'desc' will be the name of the property list lsedit will create and add to the Winding Path room. When you're done editing your description, you have to tell the MUCK to use the desc property for the description rather than _/de. Simply change the standard description like this:
This tells the MUCK to redirect the source of the description to the desc property. I use the MPI {lexec} function to do this, although there are more efficient alternatives. {lexec} has the advantage of forcing the execution of any MPI in your description. If you don't do this and you use {nl} functions in your desc property descriptions, the new line functions will be literally printed, rather than generate new lines.


Exit Elaborations

You can look at an exit just like any other object. This can be useful when you don't want your primary room description cluttered up with detailed remarks about the exit. To add a description to an exit, set the _/de property:
Note that some players won't think to look at an exit for more information, so consider using exit descriptions only as elaborations, and keep important exit information in the primary description. Also, try to be consistent with your rooms. If you describe exits, describe all exits so that players are encouraged to look at them, rather than be discouraged after seeing one to many "you see nothing special" responses.

You may also want to describe what a player sees when the exit is used by setting the success property:
To describe what other players in the room see when somebody uses the exit, set the osuccess property:
The next one can be a bit confusing. It describes what other people see when the exiting player arrives at the exit's linked target destination.
The exit is literally dropping you into its target (linked) room. So if you had a room called Winding Path with an exit called East which linked to a room called Near the Little Brook and the East exit was set up like this:
then using the East exit in the Winding Path room will dump you into the Near the Little Brook room, at which time others in the Near the Little Brook room see a message like "Terry walks out of the west along the Winding Path."

The above properties can add more dynamic character to your areas. For example, you can describe what a player sees while traveling to the next destination. There are other properties that may be useful to set for exits, but these are the basics. Note that properties like odr and osc always prefix the using player's name to the message. There is nothing you can do to change that behavior.


Look-Traps

A look-trap is a property tacked on to a room object which can be used to describe additional things in the room. It is similar to creating an object and adding a description to the object without actually creating the object. To make an fake object this way, use the @set command on the room to add a new property:
In the following example, we add two look-traps to the Winding Path room:
When someone types 'look mosses' or 'look ferns' they see the related description.

Look-traps are parsed for MPI, so you can include MPI functions in your descriptions.

The advantage of look-traps is that they take up very little system resources compared to actual objects, and they don't cost you 10 monetary units to make them. The disadvantage of look-traps is significant: they don't show up in the room's object list. Because of this, you must make it clear that additional descriptions are available by looking at stuff mentioned in the room's description. Some builders do this by quoting the word that is a look-trap in the room's primary description like 'tree', but inexperienced players may try simply typing 'tree' instead of the necessary 'l tree' or 'look tree', and they'll get a confusing "I don't see that here." response. You might try writing 'look tree', or adding a list of lookable objects in the description's closing paragraph. Whatever you do, be consistent.

Look-traps are a subset of a larger group of properties called sense-traps. Here is the complete list of sense-trap properties and how you can set them:
A player can see these descriptions by using the various sensory commands: look, lookat, look at, listen, listen to, listento, feel, smell, touch, and taste. Again, many players won't know about these functions, so you might need to hint at them in your primary room description.


Editroom

Editroom (also known as Room Hammer) is a menu-driven set of programs available on many MUCKs (including A Bug's Muck) for automating many of the steps involved in setting up a room. Editroom allows you to set most of a room's descriptions without knowing much about MUCK commands or room and exit properties. I talk about Editroom last, because I believe builders should know the basic workings behind making rooms. Editroom also generates a lot of text on your screen, and for many simple jobs it is overkill.

To use Editroom, make sure you are in the room you want to work with, and type 'editroom'. Note that you can't use Editroom on rooms you don't own. The following is an example of the opening Editroom menu. What you see will be a bit different.


That's all there is to my Building Rooms tutorial, but that's not all there is to room building. Once you're comfortable with the basics of building and describing rooms, I encourage you to learn about environment rooms, locks, and MPI functions that can enhance your room designs. Also, I've mentioned only the mechanics of room building; learning how to write good room descriptions is another topic, best left to someone who can write better than I can. In any case, I hope you got something out of this tutorial. Cheers and happy room building!