>look Richelieu This note contains some quick guidelines I've drawn up to help people create a more coherent and interesting virtual environment for themselves. Most of these are not hard rules, but should be followed anyway. The exceptions to this are primarily under the Topography section and point 4 of the Instructions and Help Texts section, which you may be called upon to comply with by the wizards. >read Richelieu Note that in this and other documents, spivak pronouns are often used. Spivak is a fairly easy and well-developed system of non-gender-specific pronouns that is often used in MOO related communication and is the recommended form for such references. For more information, type 'help spivak'. Instructions and Help Texts =========================== Help and instructional text is one of the most important aspects of the MOO, particularly for new people, and it is important that it be done correctly. There are several guidelines which will help to ensure that information is readable and understandable by the MOO populace at large: 1. Document EVERYTHING. 2. See rule 1 (this cannot be emphasized too much). 3. When at all possible, provide cross-references at the bottom of your informational text to related information, particularly related topics in the MOO's help system. 4. When explaining a command syntax, or instructing a user to do a particular thing, the following conventions should be used: a) Commands or text which a user is intended to type should be enclosed in single-quotes (apostrophes). This is not only a character which is almost never present in MOO command strings, but is one that users are already familiar with as denoting a quoted passage. The back-apostrophe (`) should not be used in this context, as it can lead to confusion and often looks strange on people's screens. The quotes at both the beginning and end of the command should be normal apostrophes ('). b) Portions of the command/input which a user is intended to replace with their own choice of text should be represented by a representative label, enclosed in angle-brackets (<>). Any such labels should be explained in the help text immediately after the quoted command string, even if they seem to be obvious. c) Portions of the command/input which are optional should be enclosed in square brackets ([]). Exactly what each optional portion does, and why it is optional should be explained following the quoted text, as well. Example: If the following text were found in a help or information passage: ... type 'honk at [and [alternately]]', where is the name of the object you want to honk, is who you want to honk it at, and could be someone else you want to honk it at. If "alternately" is specified, it indicates to honk it at each of the people in turn, instead of trying to honk it at both of them at once. it would indicate that the user was intended to type the word "honk", followed by the name of an object to honk, followed by the word "at", and the name of a person to honk it at. It also indicates that they can follow it with the word "and" and the name of another person, and that if they choose to do this, they can also optionally end it with the word "alternately". Note that all portions of the command are fully explained in the text that follows it. 5. When explaining a command to a user, whether interactively or in a help text, always explain the full form of the command first, and make sure all information is fully covered (and if being done interactively with the user, make sure they understand how and are able to use it) before introducing any shortcuts or abbreviations for the command or the process being explained. Failure to observe this simple rule has resulted in more confusion than I like to think about on the part of new users learning how to do things. 6. Try to refrain from using the term "player" to refer to users of the system. While this term is built into many of the aspects of the MOO, and MOOcode in general, due to the origins of this medium as a game-space, Diversity University is not simply a game, and its inhabitants are not really players anymore. The terms "user" and "person" are generally good substitutes. Building and Topography ======================= While the insides of buildings at Diversity University are fairly flexible, there are several guidelines that should be followed whenever building new areas: 1. Give exits compass directions (north, west, southeast, up, etc.) whenever possible. It is generally much easier to navigate and to remember how to get back somewhere when the directions a user moves are in a specified, orientable direction. There are generally very few situations where one has a valid excuse for not specifying the direction an exit is in. Be sure to include the abbreviation for the direction (n, w, se, u, etc.) as an alias for the exit. Giving exits aliases related to where they lead is also fine, so long as their primary name is the spelled-out compass direction. 2. The argument that there are too many exits off of a particular room to give each of them a realistic compass direction is no excuse for not following rule 1. If this is actually true, then there are too many exits from that room period. Divide it up into several smaller areas, each with a few of the exits. This is both more realistic (and thus, again, easier to navigate), and easier for a user to deal with in general. 3. All exits should have an exit in the reverse direction, unless there is a plainly obvious reason why the user cannot go back that way (for example, e just jumped out a 2nd story window). If you go north to get into a room, you should be able to go south to get back. This is common sense, and provides a necessary coherency to the MOO. 4. For every room in the MOO, there should be one (and only one) exit with an alias of "out", leading towards the outdoors, or, if outdoors, towards the student union. It should be possible for a user, wherever they may be, to get to the Student Union by simply typing 'out' enough times (some existing exits/rooms around the MOO still do not comply with this. If you find one, please use the @bug command to notify the owner of the room). 5. If you need more quota to comply with any of these, ask. Any of these is a sufficient reason for a quota increase, with almost no questions asked. Descriptions and Messages ========================= Most of these points apply to room descriptions more than other descriptions, but they should be kept in mind when describing anything. Descriptions are the very core of the reality of the MOOscape, and a badly described MOO is quite simply not as enjoyable a space to be in. 1. Make sure people know what they need to know. This is especially important when dealing with All-In-One rooms, which have details and seats. Have you explained that there's a sittable chair in the room? Have you mentioned the details that are available for people to look at more closely? 2. Avoid long room descriptions. While this is often not easy to do, particularly when trying to comply with all the other guidelines mentioned here, the fact remains that one must balance the quality of the description with the quantity. It is a well demonstrated fact that the longer a room's description is, the less likely people are to read it at all, and the best description in the world is worthless if nobody reads it. 3. Don't tell people the obvious, and try not to generalize. Think carefully about what you've already said implicitly. If they're on a street, don't tell them that there are sidewalks and a yellow line down the middle. Don't tell them that there are a bunch of houses there, either. Instead, pick out one or two houses, and describe some interesting or unusual details about them. 4. Don't spell out everything. Leave a little room for imagination and personal impressions. Be careful not to force your feelings on people. Don't explain what it's like to be there, just describe it. The feelings will follow from a proper description in their own way, and be much more real for the individual. Be wary of phrases such as "you feel" or "you expect". 5. Use adjectives. Don't just tell them there's a carpet. Tell them there's a gaudy, yellow and pink carpet. Throw in a couple of similes and metaphors (but only a couple) to add depth to the description. 6. Try to include as many of the five senses as possible. It isn't only what one sees that makes a place what it is. Talk about what they hear, what it smells like. Is there a breeze? You get the idea. 7. Avoid cliches. This is, admittedly, one of the hardest of these rules to follow, as it's not always apparent that what you're doing is, in fact, cliched. This is one of the reasons why it is important to follow rule 8. 8. When you're done, get one or two other people who don't know anything about your place/object to take a look at it, see if they can figure out how everything works and what they can do by just looking at the descriptions. Ask them how they feel about it. Does it seem real? Is it interesting to them? 9. Use details. If your room description is too long, consider whether you can move some of it into some room details (if you don't know what a room detail is, ask someone. they can be very useful). If your room description isn't too long, look around and see if there's anything that stands out that you might want to make a detail for. 10. Note that people can look at exits, just like other objects, and the default description is quite boring. This is also an easy way to spruce up an area and make it more interesting. 11. Check the settable messages on objects you create. use '@messages ' to list the available messages and type '@ is ""' to customize it. Custom messages make the MOO much more interesting to explore and play with.