Building

Muck Book: Basic Syntax and Terminology

The frame below is a direct link into the book available in the game. Note that the chapter letters are clickable and will take you to the respective chapters.

Muck Book: Building 101

The frame below is a direct link into the book available in the game. Note that the chapter letters are clickable and will take you to the respective chapters.

Muck Book: Building 102

The frame below is a direct link into the book available in the game. Note that the chapter letters are clickable and will take you to the respective chapters.

Muck Book: Building 103

The frame below is a direct link into the book available in the game. Note that the chapter letters are clickable and will take you to the respective chapters.

Muck Book: Building 104

The frame below is a direct link into the book available in the game. Note that the chapter letters are clickable and will take you to the respective chapters.

Finding Database Items (@find and friends)

After building your one thousand room Palace, complete with servants, fountains, and the occasional stray chicken; you would probably be having problems keeping track of all the dbrefs, exits, rooms, and things. Fortunately, there are a group of commands designed specifically to help you find database items. All of these commands have similar options which will be explained in more detail after explaining what the "default" behavior of the commands.

@find [options]
The first of these commands is @find. If you are a non-wizard, @find lists all the database items that you own. If you are a wizard, @find lists EVERY LAST database item on the muck, including database items that are "garbage" (recycled). If you are a wizard--be careful! Typing @find by itself may take a long time--during which your connection to the muck is completely tied up with @find's output.

B. @owned [options]
For mortals, there is no difference between @owned and @find, both list every item you own. For wizards, it is a safer alternative to @find, since it either only lists items you own and can be used to list items that another player owns.

C. @contents [options]
@contents lists the database items that you control that are contained by the database item specified (or the current room if none is specified). You have to own/control the item to list its contents. Note that actions/exits are listed as contents of a database item if the item is their source. Also, using @contents on a parent will include the child rooms of the parent in the output.

D. @entrances [options]
This command lists the 'entrances' to the specified database item, or the current room if none is specified. The command is handy to see what exits are linked TO the specified item.

Options:
@find will take an optional parameter that filters the list to the items matching it:

'@find food' will list all the database items with 'food' in their name, regardless of type.

'@find apples' will list all the database items with 'apples' in their name, regardless of type.

You can also refine the search by using ? to match any single character:

@find f??d will list items with an f followed by any two characters followed by a d. Food, faad, feed, faed, would all be listed.

Or use a * to match any number of characters:

@find f*d will match 'fed' 'feed' 'food' 'foeruqoruweurworuwd' :)

Refining the search further:
Adding a = sign and a flag to any of these commands will filter the list by the flag. For example:

@owned =E will list all the items you own that are exits/actions.
@find apples=R will list all of your rooms with 'apples' in their name.
@owned =C will list all of your items that are CHOWN_OK

Additionally, you can use the flag % to find items that are 'unlinked', for example:

@owned =E% will list all exits you own that are not linked.

You can also use an @ sign to list items that haven't been used for more than
90 days:

@owned =R@ would list all rooms that haven't been used for 90 days.

Changing the Output Style:
Normally these commands only list the name of the item and its dbref#. You can refine the output by adding a 2nd equals sign and specify the style. The possible styles are: owners, links, and location. For example, if you wanted to list all your database items, and what they're linked to:

@owned ==links

Or perhaps more usefully, all of your exits and what they're linked to:

@owned =E=links.

Another possibility would be to use the 'location' output to see where your items are, the source of an exit, or what the parent of all your rooms are:

@owned =T=location (All things owned by you, displaying their location)
@owned =R=location (All rooms owned by you, displaying their 'location' which is their parent)
@owned =E=location (All exits owned by you, displaying their source)

Again, you can use these with @entrances or @contents as well:

@entrances ==location (list all entrances to the current room, and their 'location' (where they come from).

For mortals, the 'owners' option is largely unuseful. Since the only items these commands list are the ones a mortal owns, 'owners' would simply display your name and dbref over and over. For wizards, it can be more useful:

@find food=R=owners (find all rooms with 'food' in the name, and display their owners)

The Role of Writing In Building

The preceding books and sections have focused on the technical skills required for building. Technical skills are not the only skills needed for high quality building. Just as important is attention to aesthetic details and good writing skills. Every thing, zombie, puppet, player, room, and action/exit are composed of numerous pieces of text. These pieces of text can be as small as a success message or as large and complex as an intricately detailed description of a player.

Using misspelled words and poorly thought out grammar is the most damaging thing you can do to your descriptive text or messages. Misspellings and bad grammar will prevent the reader from understanding what your text is supposed to say. Many readers will stop bothering to read the descriptions or messages if there are too many grammatical errors or misspellings. The mistakes lead the reader to believe that the writer doesn't deem the text important...and if the text isn't important to you, why should it be important to them?

The text is very important. This is a text based game, after all. So when you're planning your project, whether its a beautiful outdoor garden, a house you live in, consider the scope of your project. Don't plan a huge design that involves so many rooms that you can't provide decently detailed descriptions to each room. It is easy to spin out a one-hundred room mansion, a vast collection of 'things' with very basic descriptions, and none of the other supporting text messages. However, high-quality building includes detailed descriptions and messages that together create an illusion for the reader of actually being there.

Required Properties

There are several properties and messages that often need to be set on a given database item. Here is a list of database items and the the properties that are 'must haves' for that database item. Every database item should have a description. Even MUF programs should have a description...usually the description explains what the program does.

Rooms: Rooms don't have as many different messages needed but often involve several exits/actions which do. Primarily, the room should have a well thought out description, with possibly additional details added through use of @object or @detail. Some mucks will need you to set a success message to setup the 'obvious exits' program for that mud. A typical example would be: @succ here=@$obvexits. University doesn't require this because the obvious exits program is 'built in'.

Exits: Exits required several messages. They require a fairly simple description which usually gives some indication of where the exit leads. They should have at a minimum an success message, an osuccess message. If the exit is going to be locked (even part of the time) it will need fail and ofail messages set. It is usuallly appropiate to also set drop and odrop messages on an exit to parallel the success/osuccess messages.

Things: Things also required a fair number of messages. They often need fairly detailed descriptions, sometimes just as detailed as a player or a room. If they can be picked up they need success and osuccess messages. If they can be picked up, they can be dropped and will correspondingly require drop and odrop messages to be set. If they can't be picked up even some of the time they will need to have fail and ofail messages.

Descriptions

Rooms with descriptions such as 'The graveyard. Its spooky here' or things described 'A book about magic' aren't what we want in high quality building. We want rooms that have full descriptions, involving all the senses that make sense.

Do not forget that our senses can perceive a wide variety of information. The database item you are describing can have unusual textures 'the wood feels rough and easily splintered' or colors, the very air the reader is 'breathing' could taste, smell, or even feel a certain way. Cool breezes, foul odors, sweet smell of flowers, a bitter taste in the air, etc.

Text that tells the reader what his player should be thinking doesn't work either. For example, if a character description had: "And when you look into his terrible eyes, you tremble in fear". That makes the assumption that the onlooker is someone who is intimidated by the character...which won't always be the case. The character's description should describe what is seen and nothing else. Don't make assumptions about the capabilities of the 'looker', other than they have eyes and can see the character.

Another common mistake is to include material in a description that isn't description, but is instead an activity. The description that I used for years was in violation of this principle. The last sentence read '...and he turns to you and says, "Greetings". A nice friendly description, and completely, totally wrong. The character is apparently saying 'greetings' EVERY time someone looks at him. That doesn't really make sense. If I said "Greetings" everytime our eyes connected, you'd get tired of me pretty quickly. Again, a description should ONLY describe and nothing else.

It is even easier to make similar mistakes with room descriptions, where the dividing line is more vague. A typical error is to put things or creatures in the description that can be carried off or walk off on its own. Which if it isn't there, then the description will be wrong. Probably the relevant question is: Is this something that can ever leave (in game only...there are certainly things we put into the description that we count on players not carrying off)?

If yes, it should probably be made into a "thing" with appropiate messages. If no, then you can get away with putting in the description. Don't forget to use @object or @detail, if you want to have extra bit of description that won't fit into the main description.

Try to avoid the use of second person in descriptions, especially for room descriptions. It feels so easily right at first, but after traversing the 35th room that begins with "You see..." it becomes pretty old. It is acceptable to use "You see" for things the player has to 'look at' (people, things, directions, etc.). I find it works especially well for exit descriptions, since the implication is that the player is looking off in that direction, so 'You see...' makes sense there. It is something of a writing- challenge at first, but I find reworking a room description to avoid 2nd person produces a stronger, more powerful description in most cases.

The description should simply be what a player would see. It should be as detailed as possible, although I recommend keeping your description no more than 15-20 lines. Descriptions with page after page of description are not necessary, and typically annoy the reader. If necessary, one can add more detail on most worlds using a variety of techniques, which typically involve the reader issuing additional commands for the items or details they're curious about.

Utilize the format function to format your text to an 80-column format. You won't be able to count on the player's terminal, telnet, or mud client being capable of wrapping lines. You can safely count on their terminal being a minimum of 80 columns wide and at least 24 rows tall so those are good boundaries to work with. I recommend wrapping and limiting the text to just shy of those limits. I find that 78 works as nice horizontal limit (.format 1 10=78) and the entirely of a description, including borders, and the "name line" (Feaelin(#4PBJW), for instance) should definitely be under twenty lines--if not shorter.