Building
This guide is designed to provide information for novices to begin building on MUSH style servers, including TinyMUSH, TinyMUX, and PennMUSH. Command syntax should work on any of the above servers. To learn how to build, it is highly recommended you find a game with open building. Social games often provide areas for players to build and create objects. Consult your favorite MUSH list to locate an open-building game. For illustration, commands that are used on the game will be illustrated in italic type.
A First Room
To create a room on a MUSH, the @dig command is used. @dig provides multiple forms.
The simplest form of the command is:
Syntax: @dig <name>
Example: @dig Mark's Office
where <name> is the name of the room you would like to create. This command merely creates a room on the game but does not open an exit to travel into or out of the room.
Thus, to access the room, you would need to use @teleport to get into it. Fortunately, a more complex version of the command is available to aid the builder in creating exits as the room is created.
The most useful form is:
Syntax: @dig <Room Name>=<inbound exit name list>,<out bound exit name list>
Example: @dig Mark's Office=Mark's Office;mo;office,Out;o
This example creates a room with the name "Mark's Office". It then opens an exit from your current location into the new room with the name again as "Mark's Office". The second portion of the first list is "mo". That is an alias for the list. The next section, after the comma, opens an exit from the new room back to your current location. It would have a visible name of "Out" with an additional alias of "o". As with most things on a MUSH,the names are not case sensitive so "O" would work just like "o".
Before moving on, let's examine exit lists a bit further. Exit names are unlike any other style of object names on a MUSH. Exits can have numerous aliases as specified by a list separated by semi-colons. The standard form is: <visible name>;<alias1>;<alias2>;...;<aliasN>
Each name can be used to move through the exit but only the first name is typically visible. It is common to set at least one alias on an exit that is made up of the capital letters used within the visible name of the exit. For example, an exit used to enter the Red Rabbit Tavern might have an exit name like Red Rabbit Tavern;rrt;red rabbit;tavern;rabbit. In outdoor settings, exits often have directional aliases to indicate the direction of travel. These directions can also be utilized by softcoded commands such as +compass to provide a directional map of exits leading from the room.
As with any object, if you happen to mis-spell a word or otherwise need to correct the name, you can utilize the @name command to change the name. For a room you are currently in and control, you can type:
Syntax: @name here=<new name>
Example: @name here=Plush Corporate Office
For exits, you can specify the exit by its visible name or an alias:
Syntax: @name <thing>=<exit list>
Example: @name Out=Hallway;h;out;o
As with any object, you can also specify the <thing> by its DBREF. A DBREF is the database reference number associated with that object. An object controlled by a player can be seen by that player when viewed via look or examine.
Exit Creation Without @dig
While you can create exits into and out of a room with the @dig command. It is often necessary to add additional exits between existing rooms or to move an exit from one room to another.
To accomplish these tasks, the @open command will be examined.
Let's first focus on the @open command. @open is used to create a new exit in your current location by default. You must own the room or have permission to add an exit to the room. Much like the @dig command, it has a variety of forms. The simplest form is:
@open <exit list>
For example: @open Narrow Trail;nt;northwest;nw;trail
This example, much like the simple format of @dig has a major problem. The exit is created but it has no destination. Trying to move through the exit will not move the player anywhere. This fault makes it less than useful. Luckily, a more complex version of @open allows you to specify where the exit leads. Let's assume I am opening the exit from my current location to a room that describes the trail in the woods. That room, for illustration purposes is named 'Narrow Trail' and has a DBREF of #1333. My current location is 'Large Clearing' and has the DBREF #1393.
To open an exit from my location in the clearing to the trail room, I have to know the DBREF of that room. As noted, it is #1333 for this example. So I make use of a more powerful form of @open.
Syntax: @open <exit list>=<destination>
Example: @open Narrow Trail;nt;northwest;nw;trail=#1333
This is much more useful as I can now type 'narrow trail' to move northwest onto the trail. However, even after I move northwest onto the trail, I discover I now have to repeat the process to open an exit back to the southeast from the trail to the clearing. After all, if I can travel one direction, it makes sense to be able to move the opposite direction.
Again, @open provides a mechanism to allow this through a more complex syntax. Let's assume I am still in the clearing and want to open both the exit leading onto the trail and one leading back from the trail to the current room.
Syntax: @open <exit list>=<destination>,<return exit list>
Example: @open Narrow Trail;nt;northwest;nw;trail=#1333,Large Clearing;lc;southeast;se;clearing
Breaking this down, the first portion of the command opens the exit like the example above to the Narrow Trail room. It also opens an exit name 'Large Clearing;lc;southeast;se;clearing' from the Narrow Trail room back to my current location, which is the Large Clearing.
Modifying Exits
It is sometimes necessary to change where an exit leads or to set its destination if it was overlooked during the open process. Rather than having to destroy the exit and create it again, the @link and @unlink commands can be utilized to manipulate the exit's destination.
Let's use the Narrow Trail example from above once again with some additional details. Assume I created the trail with three individual rooms with exits leading to and from those rooms. After finishing the initial creation, I decide that three rooms is overkill for such a trail and want to reduce it by removing the room in the middle. For illustration purposes only, let's assume the trail looks as follows with room names and associated DBREFs listed below:
Clearing #1393 -- Narrow Trail #1333 -- Overgrown Trail #1343 -- Crossroads #1345
As mentioned, I want to eliminate the Overgrown trail room but I don't want to create new exits. I first move to the Narrow Trail room. I can modify the name of the exit from this location to the overgrown trail segment to match moving onto the crossroads by using @name. I then need to switch the destination from #1343 to #1345. To do this, I turn to the @unlink and @link commands.
First, let's remove the current destination from the exit.
Syntax: @unlink <thing>
This removes the destination from the exit. If you examine the exit after the unlink command, you will see its destination is *UNLINKED* meaning it leads nowhere. However, since the destination is known, the exit can be linked to its new destination using the @link command.
Syntax: @link <thing>=<destination>
Example: @link Crossroads=#1345
This would reset the link of the exit named Crossroads to lead to room #1345, which as noted above, is the Crossroads room.
Descriptive Building
Until now, the rooms created have been featureless beyond the name set during the @dig process. A room with just a name is not very useful. Room information can be set with two different commands, @describe and @success. These commands are commonly abbreviated @desc and @succ.
@describe is probably a familiar command you used during character generation on one or more games and reset to change your character's appearance. It is used as follows:
Syntax: @describe <object>=<description>
Example:
@desc here=In the frontyard, a grassy area, surrounded by a tattered hedge, and a huge hybiscus bush, half shaded by a scrawny but picturesque tree. The fence keeps dogs and guests in, and neighbors out, low and crisscross hurricane fencing you can see through and lean on, with care. The gate squeeks, and there is a window you can peek through, into the kitchen, and another, larger one, that peeks into the livingroom.
The example describes a front yard room as set when within that room. You could specify the <object> by DBREF as well if describing the room remotely.
The second command, @success, can be used to add a second attribute that is displayed to a person successfully viewing a room. Since it is highly uncommon for someone to be forbidden from viewing a room, this is a convenient method for adding another block of description to the room. The @success is often used for information detailing the exits leading from the room but can be utilized in other manners. Here's yet another example:
Syntax: @success <object>=<message>
Example:
@success here=There's a circle beaten in the grass, from people sitting and tramping and falling down. Games have been played here. A white gate leads out onto the sidewalk and mahogany door provides entry into the house.
This example adds some information following the description. So if one were to enter the room or to look while in the location, the following would be displayed:
Front Yard
In the frontyard, a grassy area, surrounded by a tattered hedge, and a huge hybiscus bush, half shaded by a scrawny but picturesque tree. The fence keeps dogs and guests in, and neighbors out, low and crisscross hurricane fencing you can see through and lean on, with care. The gate squeeks, and there is a window you can peek through, into the kitchen, and another, larger one, that peeks into the livingroom.
There's a circle beaten in the grass, from people sitting and tramping and falling down. Games have been played here. A white gate leads out onto the sidewalk and mahogany door provides entry into the house.
Informative Exits
Exits, much like rooms, do not provide much information when they are first built. If someone moves through an unadorned exit in the room you are in to another room, you will see only '<name> has left.' Likewise, if they arrive through a similarly blank exit, you would see '<name> has arrived.' where <name> is the moving object's name.
At a minimum, exits should provide messages that are seen by the moving object, others in the room being left, and objects in the room that is being entered. This can be accomplished, respectively, by the @success, @osuccess, and @odrop messages. The first two are often abbreviated as @succ and @osucc.
The general form for these commands is @<command> <object>=<message> where <object> is the object being set, e.g. the exit name, and <message> is the message to be shown. <command is one of the above commands.
@success sets the message shown to the object moving from the current location to the new location. @osucceItalic textss sets the message displayed to the occupants of the room being left. @odrop sets the message shown to the occupants of the room being entered. Both @osuccess and @odrop prepend the moving object's name to the message prior to it being displayed.
For illustration, let's assume we are in the Front Yard as described above and want to set messages on the White Gate exit that leads out of the yard onto the street. A sample set of messages might be as follows.
@success gate=You open the squeaky gate and step out onto the sidewalk.
@osucess gate=opens the squeaky gate and steps out onto the sidewalk.
@odrop gate=steps onto the street through the white gate.
For demonstration, I'll assume that Sandy and I (Mark) are in the front yard. Bob is out on the street in the destination room. I then move through the white gate.
Mark would see:
You open the squeaky gate and step out onto the sidewalk.
Sandy would see:
Mark opens the squeaky gate and steps out onto the sidewalk.
Bob would see:
Mark steps onto the street through the white gate.
Exits are also commonly adorned with descriptions. These are set like any other @desc on an object (@desc <object>=<description>). Exit descriptions can add additional details to an area. Descriptions are not absolutely necessary but are often used to enhance the quality of an area.
Advanced Building
All building on a MUX or MUSH is done with these commands. In addition, a skilled builder will be able to use zones and locks to his advantage, and will collaborate with the game's coder to use softcoded tools like places, views, ambience and parent rooms.
Remember the purpose of your MUX or MUSH. If it's RP, remember that your purpose is to foster RP. Choose which rooms you construct based on how well they will foster RP.
In a private home, think about which rooms you expect to have people gather in. There is no purpose in building a closet or cupboard, unless it's significant (like the Wardrobe to Narnia or the cupboard under the stairs that's Harry's room in the Potterverse). Similarly, bathrooms are often unused spaces in a Generic Modern game, though they're communal gathering places in a Romanesque one.
If you're making a larger space, try to keep 'hallway' or 'roadway' rooms to a minimum. Try to make even your halls and roads do double duty - use plazas or open-plan living areas where it's reasonable, or use places code to add 'rest stops' and parks to a room that represents a long road.
In designing a grid, resist the temptation to represent everything. Think about which settings you need to foster RP (or for whatever purpose your MUX has), and ensure you have at least one region (ie: road, suburb, city, planet, island) of each type of setting, represented by at least one @dug room.
Within each region, decide which buildings in that region you must represent, and how many you expect the players to want to build. I find that 10 or 12 exits off a room is a reasonable maximum - your opinion may vary from mine. Create enough 'roadway' (or plaza, hallway, pier or whatever) rooms to house those buildings, and design the region to be flexible enough for later expansion.
Lay the regions out on paper before you @dig anything. I like to use a tool that's actually a flowcharting program, that lets me make named bubbles and connect them with links, then drag the bubbles around until I'm happy. If you're representing a real-world place or a place that's established in canon, your layout options will be limited by what your players expect. Otherwise, you can experiment with juxtapositions (put your snobs right next to the slums and see what happens!)
Summary
Using the commands listed above, a novice builder should now be able to create rooms with the @dig command to build an area. Further use of the @open, @unlink, and @link command will allow the addition and manipulation of exit destinations. Finally, using @describe, @success, @osuccess, and @odrop the area can be fleshed out with information room descriptions and messages provided when objects move through the exits. Additional options may be available for these commands on the game you are using. See 'help <command>' for additional options.