TMC: Stylistics ( part 2 )

Stylistics ( part 2 )
by Ephera May 2, 2006

Disclaimer: The opinions herein belong solely to Ephera. Some games look for different things when building, but overall any zone made by these rules should be good for most muds. A lot of the building philosophy within is somewhat personal and in some cases very picky. Not everyone will agree with all points, but if one follows the rules laid out here, they will make an excellent zone, albeit of a particular style.

The Polish (I.E. Picky Stuff)

  1. Do not use the word ‘is’ in descriptions. It’s generally accepted by the literary community that the active voice is more powerful and eloquent. Dodging the use of this word enriches descriptions in another way as well as forcing you to use the active voice. It’s easy to describe something as it is red, it is big, it is heavy… and the word ‘is’ becomes repetitive.

  2. Do not to use the word ‘you’ in descriptions. It creates almost 90% of direction bias and movement method errors, as well as the classic “telling the player how to think or feel”. In any case, the small percent of innocent uses of the word ‘you’ are easily written with other terms, and getting used to writing descs without it means you don’t have to constantly be on guard for these three blunders.

  3. Never tell a player how they feel. If you want a sad description, don’t tell someone they’re sad, write the description to make them weep. The same goes for scary, happy, disgusted, etc. You name it, make them feel it. Do not simply say they are.

  4. Be extremely careful when building with color. Especially if you’re adding it to your room descriptions. Try not to use more than one, and usually you shouldn’t use them in the text at all, only in the room title. On objects and mobs this rule is more relaxed, but if it’s part of what the player automatically sees when entering a room, it’s probably best that it not be too colorful and should only have 1 alternate color in it. Color is the hardest thing for many good builders to learn how to use properly. Don’t be disheartened or surprised if asked to change even a minor amount of color. If you use color, -always- terminate the color correctly according to your mud’s system.

  5. Never put a period at the end of a room title. Write all titles as you would the title of a book, capitalizing all words except for a, the, and the few excluded prepositions like ‘of’. Short descs on mobs and objects should always include the article or a measure word like ‘some’. Long descs must have the keyword of the object in it. In fact, it’s usually best to write the keywords -after- writing the short and long descs. A player should never have to guess what the keyword is to affect an item. If they can see it, they should be able to refer to it.

  6. Never describe a mob that’s loaded into a room in the room description, and if the mob’s sentient (like a humanoid or race), it simply must be a mob and cannot appear in the room description. An example such is butterflies circling a bush. That’s fine if the butterflies are not supposed to be sentient and are not loaded into the room. You should never describe drunks at a bar in the room description of the bar, instead put them there as mobs.

  7. Always write extra descriptions and ALWAYS add at least one extra desc to all objects including all of the general keywords so that the player can look at whatever they pick up. Always. If your game supports a certain type of description in addition to the typical ones, such as exit descriptions, use them consistently.

  8. Any noun in the room description that cannot be adequately described should either have an extra description in the room or outright exist as an object to represent it. This goes even if the idea of the object being of use is a mere smokescreen.

  9. When building streets or any other generic structure with a name, give it a meaningful or fanciful name. The Main Street is boring and overused in almost all cities. Each city on a mud should have streets with unique names. Same goes for the “Central Building” or ” West Wall”.

  10. If you describe an object, mob, or anything else in the room desc, do not add it to the room and vice versa. This means if I describe a table in the room desc, it should not be a visible object for the player to see in the room. The reason for this goes back to the idea that you should never ‘repeat yourself’.

  11. Try not to describe objects that a mob is wearing in their look desc, and never do it if you’re actually going to load the eq onto the mob. The player will see it twice when looking at the mob.

  12. Do not write about the considerations of a player or thought processes. Don’t ask questions in a room desc. Try to describe the looks of the mob you’re writing about in the look-desc. The trick of making a mob say something when looked at can be handled with scripts, and a player should be able to see what they look at as if they’re doing so in real life. Remember that your job with descriptions is to create an interactive environment that the player sees, hears, etc. This means that your number one goal is to be eloquently descriptive, but to do it in such a way as to simulate natural input as well as possible.

  13. Never just describe the important things in a room, always try to describe the room in its entirety, given the acceptable space. Do not focus only on the information a player needs to know. Things that are important, like that special hammer, or the doorway behind the painting should be found not because they are the only thing the player sees, but because of hints or thought based on everything they see. For example, if I walk into a room and see blank walls and a description that simply screams ‘This object is important, more important than anything else at all!’, people won’t think on what they’re seeing and will loose a great deal of the point of descriptions in the first place. In addition, do not do the opposite and make something else seem of importance that is not while trying to hide the true answer. Such misdirection will lead to player dissatisfaction… the thing that we are trying to avoid wherever reasonable.

  14. Room titles should be original in nature. This means for the most part, do not copy room titles. A person should be able to look, and by title alone, know exactly where they are. There are exceptions (like roads), but try not to make them to common, and you can break those room titles up with prepositions, etc, as well. Ex: Thistledon Road by a Willow

  15. Room titles should pick out the most important thing in the room or give the room a name to go by. For example, ‘By a Patch of Daisies’ if daisies are the most prominent thing or a name such as ‘The Green Room’. Try not to describe the title in the description of the room as the only item in the room. In some cases, if the room has a name, try not redescribe the title with the same words. For example, if the room title is ‘By a Patch of Daisies’ there really is little need to add the daisies to the room desc. It is acceptable to do so, but be descriptive in these instances instead of repetitive.

It’s important to be neat and orderly. Even if the players don’t know where things are, you should probably have a good system for finding them and know your zone inside and out. Some MUDs are very good about indexing through code, but not all of them. I highly suggest you come up with a good comment system and use it, and if you can get a programmer to support you in adding one – awesome (A lot of muds use @comment or something ed descs, but it’s best if a programmer makes those inaccessible to players). One way or another, there are some “trouble spots” people often find when building. I’ve included a tidbit I wrote for TBA and The Inquisition (my own mud) about keys here, because they’re a personal pet peeve. I’m sure every builder will find their own.

  1. If your mud has a commentary section for objects, always use it to describe the purpose of the key. Include the following:

    • The purpose of the key
    • Where the key can be found if it can be gained in a zone
    • What the key opens (use real words to describe this as well as vnums)
    • Pertinent vnums in relation to the key

    If your game does not have a commentary, it may be reasonable to use @imm or @comment and make a notation in a beginning room of your zone (usually where people put the zone overview) that this is the syntax you used.

  2. Always do a vnum obj key and use a unique name for the key. There is no reason to have 200 “simple iron key” objects laying around your mud. Most people who own keys know which key is which on sight.

  3. The key’s description should give a hint to the player about its use.

I know this was a long read – 5 pages in Word. but I hope you got something out of it that will improve your game. As with my things on TBA, feel free to use these documents where you see fit. Please, however, if you change them to suit your MUD, write your changes in and copy the original document somewhere that your imms can link to and note in brackets that there was a change to the original text. This will give me credit for my work and not put words into my mouth. Something like this will do:

This is the original text of the document. (Edit), Or, if in help files, this could be the original text with a reference. (See help ORIGINAL)

All grammar errors and so on are my own, and I’d love to hear feedback either here or at ephera@theinquisition.org – or you can visit us on The Inquisition MUD.

Ephera is the owner of The Inquisition, a Role-Play Enforced MUD. The articles submitted to MudConnector are available on her MUD forums at www.theinquisition.org/forums, but expanded for general MUD consumption.


Posted

in

by

Tags: