Building 105 -- Using @find and Quality Building
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Type 'read book5=contents' to see what it's about.
You turn to the contents page and read:
Title Chapter
---------------------------------------------------------
Using 'find' and its friends..............A (5 pages)
Quality Building..........................B (6 pages)
To read a chapter, type read book5=A1
Which displays chapter A, page 1.
I. Finding Database Items
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 items. All of these commands have similar options which will be explained
in more detail after explaining what the "default" behavior of the commands are
A. @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).
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 only
lists items they 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 in the database
To read the next page, simply type 'next'.
item specified (or the current room if none is specified). You have to
own/control the item to list its contents.
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 the words 'food' 'feed' 'faad' in their
name.
To read the next page, simply type 'next'.
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.
To read the next page, simply type 'next'.
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, or perhaps what the parent of all your rooms are:
@owned =T=location (All things, display their location)
@owned =R=location (All rooms, display their 'location' which is their
parent)
Again, you can use these with @entrances or @contents as well:
To read the next page, simply type 'next'.
@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)
This is the last page of this chapter.
Chapter B: 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
To read the next page, simply type 'next'.
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.
Section 1. 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
To read the next page, simply type 'next'.
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.
Section 2. 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
To read the next page, simply type 'next'.
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
To read the next page, simply type 'next'.
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
To read the next page, simply type 'next'.
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.
This is the last page of this chapter.