The Mechanics of Building

Herne the Hunter
(A short essay on my methods of building.)

Contents

If You Build It…
Builders and Building
Getting Started
Building Logistics
Layout and Planning
Linear vs. Nonlinear Layout of Areas
Writing the Area
Things to Avoid
Things to Include
Conclusions

If You Build It…

Area creation is arguably the most difficult part in the process of building your MUD. The game, the MUD itself, is built on the areas it contains and those areas will separate what is considered a "good" MUD to everything else. Players and code base, while important to the "feel" of the MUD aren't very useful without a "world" to play in, therefore MUDs must strive to make better places to explore.

Many people will describe themselves as "Builders," however that title applies to very few people. Anyone can slap together a text file and call it an area, but only those who take the time to provide a "descriptive realism" to flesh out an area can truly call themselves as a (capital—B) "Builder." If you're one of those people who sees a room description as unimportant or something to ignore, but will spend countless hours perfecting the perfect mob program or create objects with massive hit point gains and damage modifiers, then perhaps you are not a Builder. This does not mean what you do is not important to the MUD you work for, everything someone does to further the MUD environment is important; from building, to coding, to playing.

Builders and Building

It is easy to describe a bad builder. A bad builder will create an area on the fly from a block of vnumbers, using two or three sentence room descriptions at best. Room exits will be made randomly depending on what that builder had on his or her mind at the time. Flags will be minimal unless they have something specific to do with the mob, or this is a special room that they require for a specific mob. Exit descriptions will be nonexistent, as will extra room descriptions (or "eds"). Mobiles in these types of areas tend to be huge by most MUD standards, with massive hit points, many attacks, and large damage, or they may be classed as "leveling mobs" with mediocre HPs and damage. Mob descriptions, if any, will be short one-line affairs. Objects in these sorts of areas tend to lean towards large weapons or heavy armour.

Generally, the reason most people are considered "bad builders" is because they often come at area building from the wrong direction. When creating an area, your foremost thoughts should not be on the size of the Mobs, nor should they be on the strength or power of the objects you create, they should be about theme, the atmosphere you're creating and congruence with the rest of the MUD. Many people also use the opportunity of building to "get back" at all those nasty equipment-laden Avatars who really need to get a good beating, or to try to fill a weapon or equipment niche that they feel needs to be filled, often unbalancing the game with overpowered items. Nobody wants a player-mangling, DT-strewn, killing field of an area, nor does anyone want a gawd-slaying sword with a +37 DR and 600 HPs attached to it. Players might think they do, but things would get extremely boring very quickly if this were the norm.

Getting Started

A good builder's best tool is their brain. Before starting an area, be sure that your brain is present and fully engaged. The next thing you'll want to do is turn off your computer — A good area is not created by sitting around in OLC-mode whacking at keys until something comes to you, a good area is planned from the beginning.

The first thing you'll want to do is decide what your area is going to be about — Are you making the castle fortress of the Hill Giant named Fred, or Dread Pirate Jim's island hideaway, or perhaps a Dwarven city buried deep inside a boxwood hedge. Your area needs an overshadowing theme. Everything about your area should be based upon this theme, from mobs to rooms to objects; everything should reflect the theme. If you're in a giant's fortress, everything will probably be huge, and if you're in a boxwood hedge then there will probably be all sorts of objects made of wood or something organic.

To use an analogy; if your area was a tree, your area's theme would be the trunk, and everything else would hang off of it — rooms would be branches, mobs and objects would be twigs, programs and descriptions would be the leaves that "fleshed" your area out.

Once you have your theme decided upon, you'll want to think of the purpose of the area, in other words, why do players want to explore this area? Theme and purpose often work hand in hand, however they don't necessarily need to. For most areas, the purpose is to accomplish a main goal; defeat the Giant, capture the Pirate, or steal the Dwarven king's golden beard comb. Often, areas are built merely for the joy of exploration and their only goal is to give the players the experience they need to make the next level, or perhaps an area is made to link one large area to another. These are all quite valid and necessary purposes for an area.

Now that you have a theme and purpose in mind your next step in the process would be the planning. Planning what?

• What sorts of "rooms" will be in your area and an estimate of their numbers. Will you have a village? Will this village have single rooms for each building, or multiple rooms? Will there be an Inn? How large will it be? Try to estimate how many rooms or vnums you'll need to complete your area, if in doubt, think big. As a rough guide; A small leveling area for low-level players or a "transition area" (an area intended to link other major areas and give the feeling of space) will have about 50 rooms, a mid-level area will have about 100 rooms on average, and a large area intended for mid to high-level players will have 150-200+ rooms. Keep in mind that this is a very rough guide.

• What kinds of "mobiles" or people will be in your area. Based on your themes and goal(s), you will probably have one of more "boss" mobs, Fred the Giant, for example as well as several support mobs (Fred's henchmen, guards) and "atmosphere" mobs (Fred's maid or cook). You may have several levels of support or boss mobs scattered about the area leading up to a central figure, or you may have no central figure at all. Atmosphere mobs can be added on the fly as you require them and often provide amusement while playing a large part in the general feel of the area.

• What mixture of objects players will be likely to find in your area. Be sure to keep your objects within the theme of your area — if your area is a farm, you're likely to find pitchforks and rakes rather than swords and trebuchets, etc. Generally, the number of objects you can have in your area will be limited by the number of rooms that you have as most MUDs will assign vnums for rooms, objects and mobs in the same block amounts. Don't be afraid to dress up some of your mobs in clothing, or flesh out some of the rooms with items of interest or value if you have extra object numbers.

Building Logistics

So let's say we're building a Pirate Island, what do we need next? Well, foremost you'll want to familiarize yourself on the subject of pirates; what they do, what sorts of clothing or equipment they'd tend to have, they're mannerisms, their codes of conduct, etc. Then, assuming you're working in a medieval or pre-gunpowder type setting, you'll probably want to pick up some reference-type books. Read up on sailing vessels and learn about what sorts of ships pirates would use and why. Learn the lingo. Build yourself a glossary of words associated with privateers or pirates, their ships, their weapons, their clothing and other equipment so you're able to describe what players are seeing and equip your mobs as accurately as you can. Don't be afraid to write things down, make notes, or keep a small journal (either electronically or on paper) of things you find.

Most players will not sit and read every room description, some will. Write for those people who are willing to read. When you're talking about a specific item, say a lamp, describe it accurately — A ship's lamp would probably be made of something that wouldn't oxidize in the salt air and be mounted in a gimbals so that it moves with the rolling of the ship. An accurate description helps to bring your "world" alive in the minds of the players. Think of each room description as part of a story. Each room you write is a chapter in that story, each room furthers the plot, and every room builds on the "whole" of the area. Every room, mobile, or object should reflect your theme and continue the framework of your area.

Imagine you're describing the room or place you're sitting in right now to someone who is blind, or someone who is from another culture. Perhaps this person has never seen a light switch, a wristwatch or a table lamp, and has no clue as to their function. This person is likely to want to give these items a more detailed examination, and this is where you would want to focus your room's eds or extra descriptions. These eds are the perfect place to give the more curious players insightful information about the area, or clues to the room's secrets (hidden doors, objects, etc). If your room describes a peculiar style of writing desk, then be sure to add an extra description for that desk — Perhaps through searching for more information about that desk, players might gain insight on how to defeat the "boss mob" for your area. Particularly special items may warrant the use of a room object (an object that sits in the room), something that stays in that room and draws attention to itself by being obvious. (A large mahogany desk dominates the center of the room.)

Reward those players who are willing to stop and read through your descriptions and make inferences. Someone may even learn something new (maybe even you).

Layout and Planning

So now you have your theme, and you've familiarized yourself with the specifics of your theme. What next?

Now you'll want to start laying out or mapping your area. Most Builders will have a specific goal in mind when they create an area — Find the green key, open the blue door, kill the big mob and you gain the big weapon.

Mapping is a key step in the building process, and while your base map can be added to or altered as the area progresses, it should remain a primary step in building your area. A map will provide you with a visual representation of what you have in mind, with directional references to other areas or other parts of your area. It also provides important information as to the number of rooms you will require to start constructing your area and how many rooms you have left to work with as you progress through your building process. You may even want to sketch out feature items (Examples; a sunken ship, a castle, a fallen tree) of your area on the map so that you remember to provide visual clues in the room descriptions. (IE: Does that fallen tree pass through 2 rooms or 3? Does it block progress in a specific direction? Can players climb over it?)

Maps can be as simple or as detailed as you wish to make them — you might use squares or circles to represent each room vnum with arrows representing exits, or you might decide to use a program like Excel to keep track of each room and its exits. However you decide to map your map, it should be clear, legible and able to provide you with an instant reference to the layout of your area.

Here is an example of a simple map that clearly shows the major features of the landscape — A pathway, a creek, a fallen tree, and a large hill. Once you've decided on the basic "look" of the landscape, you can go back and overlay the map with your room vnumbers. For this example, I've used little boxes to represent each "room" or "view" that I want to translate into a vnum. Each box need not be the same size (although they are in the example), the size of each room is relative to the description that you're making — You may wish to use one vnum to represent 4 miles of road, or one vnum to represent a room in a house. The "scale" of the vnumber usually depends on your intent or the content you're describing.

From this example we can be quite certain that room 1003 has the trunk of a fallen tree passing through it, and the direction in which the trunk is laying is readily interpreted. Room 1009 is on a hillside, and we can easily read how steep the climb might be for those passing through the room. As well, we can see that Room 1008 is in the middle of a creek and players may or may not need some means of travelling through water to enter this room.

This second example shows the deck of a small ship. This map clearly helps you locate the positions of masts and hatches visually and spatially within the body of the ship. If you imagine that this is the main deck, the deck below being slightly smaller (perhaps containing fewer vnums), while the deck above, where the wheel would be is probably very small (maybe only 2 or 3 vnums) and only covers a small portion the stern, etc.

Maps help take the guesswork out of writing your descriptions — Where does that tree go? How much area does it cover? Well, if I look at the map, I know that tree is angled off to the northeast, and I can easily include that in my description without a lot of guesswork. Also, should another room fall adjacent to room 1003. I can very easily see where my fallen tree is in reference to this new room and include the necessary references in the description of the new room. You don't have to go crazy with details, just include your major landforms (hills, rivers, roads, etc), and perhaps any major non-movable items that impact on this landform (giant rocks, shacks, fallen trees, etc) and you'll be on the right track.

Linear Vs. Nonlinear Layout of Areas

Due to the nature of MUDs, areas tend to be linear in nature (travel is from A to B to C), but they don't need to be. In fact, a superior Builder will design areas that can be approached from several directions, and mesh into similar areas or transitions zones with ease. Nonlinear areas tend to be more interesting and can provide much entertainment without getting oneself too deeply into trouble. Such areas can provide several lesser "boss mobs" in place of the usual "ultimate goal" mob, or allow players to work a progression of more difficult mobs until they are ready to attempt a very large mob.

Here are some graphical representations of linear and nonlinear area layouts.

Figure A: This describes the vast majority of areas found in most MUDs today — Players enter the area at one and only one point of the area and progress along assigned pathways through the various challenges from A through C along one and only one pathway. One cannot travel from A to C without first passing through B, and neither can one return from C to A without passing back through B.

Figure B: This is a slightly more advanced version of Figure A — Players can enter the area from several locations, however they all enter into the same "dungeon level" or "task level" ("A" representing the first task to be accomplished in this example). Players are then given numerous choices in order to progress upward into more difficult levels of the area until they eventually reach the final task at C. In this example, players are only allowed to move about by specific "avenues of movement" and are not allowed the freedom of movement to pass from lesser tasks to harder tasks — they must follow specific paths set for them.

Figure C: This is a more fluid version of Figure B — Players can enter the area from almost anywhere in the surrounding areas and progress upward into more difficult tasks through just about any pathway they can find until they reach the final goal. In this example, players move up and down through different tasks without really knowing that they are entering easier or more difficult levels as they move. This method of linear planning tends to give a better "feeling" to an area — tasks aren't "chunked" into rigidly defined levels which provides a sense of free movement. This sort of area also allows for easier placement within the MUD "world" as it doesn't require an specific direction for a main entrance.

Figure D: This figure represents a basic nonlinear area — Players can enter the area from any one of the predefined entrances and progress through each task as they wish. Each task is chunked out or compartmentalized so that each could be considered an encounter unto itself which means that players don't need to accomplish task "A" before they move on to task "B" as they would in a linear-style area. Once players have figured out the shortest route to the "boss mob," they are free to go there directly without having to pass from A to B to C, and so on.

Figure E: This layout represents a sort of miniature MUD world map — one large level "A" contains several smaller levels or tasks within it which encourages players to explore and seek out the more hidden or perhaps more difficult "encounters." Players are able to enter the area from any path provided from adjacent areas and find themselves in the all-encompassing level "A", or they could find themselves in a smaller encounter area which hangs just outside the main area, (using "B" in this example) which would eventually lead them deeper into the main area.

In Figure E, each encounter or "task" could in effect be made into it's own self-contained area (hence the reference to this being a MUD world in miniature), which would naturally lead the more advanced Builder toward the construction of mega-areas. "Mega-areas" being larger areas (say 500 rooms and up) comprising several smaller areas, all based on the same major theme or "background story," and inter-linked and dependent on one another to function properly. This idea also lends itself to having several Builders working on small projects towards the same larger goal area.

Writing the Area

You've researched, you've mapped, and you're reasonably sure how many vnumbers you want to use to make your area, so now you're ready to start building — What to do first?

First, turn off your computer and take up a pad and paper.

Yes, that's right, low-tech is the best way to start building a really good area. Get yourself some ruled paper, or a journal, and a pen and start scribbling. Journals or small ring-bound notebooks lend themselves to writing better than your basic three-hole punch paper as journals tend to travel better. Area building can happen just about anywhere where you can sit down and write, but first remind yourself that room descriptions are limited to 24 lines of 75 characters (approximately) each. This doesn't mean that you need to limit yourself to small, cramped paragraphs of text, it just means that if you wish to describe something, (say a painting on a wall) in detail, you will need to use eds or edits. Players who take the time to read your descriptions with care will come across these more interesting tidbits of information, perhaps to their benefit. Write whenever and wherever you can, and don't limit yourself to 1800 characters for each room, go nuts! You can make editorial changes later on.

When I started building, I used a small text-only editor set to wrap lines at 75 characters and made small text files for each room (1000.txt, 1001.txt, etc) from my handwritten notes. After a while, I was able to graduate up to a better text-editing program that included a spell checker and a thesaurus, and life became easier — A thesaurus can be your best friend. Then, once I had the bulk of the area done, I used my MUD client to send these text files to the MUD, one line at a time. (A program like ZMUD will do this, just make sure you have a hard return at the end of each 75-character line, and add a short delay between sending one line and the next — You should be able to set up these sorts of options in the ZMUD preferences. Otherwise, cut and paste works just as easily, but it takes a bit longer. Also, if you add "redit desc" as your first line, and "/s" as your last line, your text file can automatically open and close the editing buffer for you.)

The best way to begin writing is to have your map in front of you, and picture yourself in the "room" (vnum) that you're describing. Pretend you're standing in the centre of the room and describe what you see around you — imagine you're describing it to someone in a letter, or to someone who can't see where you are. Be as descriptive as you possibly can, and use your thesaurus!

Things to Avoid:

Some MUD Building Councils refuse to accept areas where the word "you" is used in the room descriptions, but I feel this is a bit of overkill myself. There are exceptions to this rule, however;

A room description should never say something like, "You feel scared." — This is one of the major blunders of building. What if the content of the room isn't scary to the player? What scares one player may not even phase another. Never tell a player how they are supposed to be feeling, use the room description to tell them what they're seeing, and let them draw their own conclusions as to how they should act or feel.

Don't give them any information about the room which isn't blatantly obvious. You may want to tell a player "You smell smoke." — This is generally acceptable as we assume that all players have a sense of smell. Likewise, you may use something like "You hear a bird singing," as we assume that most players will have a sense of hearing — This wouldn't be true for room that is flagged as "silent," however, so you'd need to be careful with that. If something isn't openly obvious, you may want to add some sort of hint to the room description to tempt players to examine the room more closely — the addition of descriptive eds help in this case.

Room descriptions should never mention the mobile in the room — "Geoff, the shopkeeper, polishes his wares…" Well what happens when Geoff is dead or not in the room? A Mobile's long description is what you see when you enter the room — let the mobile speak for itself. How do we know this is Geoff's store anyway? Is the room name "Geoff's Store"? If not, then we have no idea who this guy Geoff is, so let him speak for himself. Also remember to fill in Geoff's description so that when a player looks at the mob, they know what or who they're looking at. Room descriptions should only describe the room. Mob descriptions should only describe the mob. Object descriptions should only describe the object.

"You are Falling!" — How do you know the player is falling? The player could be a pixie, or some other winged species that is constantly flying around, so they wouldn't be falling at all. If you wish to use a phrase like "You are falling!" first use a room program to check to see if your victim is flying or floating and then mpecho at the non-flying creature that they are falling. There are few exceptions to this rule however, such as when some sort of magical force prevents a creature from flying, or perhaps a strong wind keeps a flying creature grounded. These sorts of situations would need to be immediately presented to the player, presumably with a room program (anyone who scried into the room could read the description), as they enter the room. IE; "A strong wind whistles through the cave, shoving you into a deep hole! You are falling!." Etc.

"Over to the left you see…" — This is a common enough mistake for many builders, especially if you're making a linear area with one predefined path A to B to C (See Figure 1 above). Never assume that the player's left is west — a player may not be facing north when they enter the room, they could be going in any direction so don't build your descriptions to read in only one direction. If something is on the west wall, state that it is on the west wall and not "to the right". For simplicity sake, we assume that all players are born with a compass built into their heads and they are able to differentiate north from south. Also, try not to fall into the trap of describing every room like you're reading a shopping list of compass directions — "To the north you see… And to the west you see… And to the east you see…" These sorts of room descriptions can get pretty boring in the long run.

Things to Include:

Specific objects, such as large items of furniture or perhaps a sign post, that are mentioned in the room description may be better described if you make them into their own object. For example; let's say you're in the throne room of a large castle and you want to emphasize the fact that the throne is particularly ornate or maybe there is an important clue to the area associated with it — this would be a perfect opportunity to make yourself an object for the room. If a player has his display preferences set to "brief," then he will fail to notice anything specific mentioned in the room description (unless they type "look"), so if you want your throne to be noticed make it into an object and put the description(s) of the throne on that object. Then the player will be sure to notice it.

Atmosphere is everything. If your player is stepping from dry land into a creek, then you may want to add a room program that says something like "Splash! You're in the creek." But you need to be careful of a number of things if you do this; Primarily, is your victim flying? Also, try to avoid "spammy" room programs that fire off every time someone enters into the room — If you have 4 people travelling in a group, your program is going to fire 4 times, so make sure you're using "mpechoat" to send the message each player individually. Atmosphere also includes things like; The sorts of noises you might hear if you're walking through a forest, ie; croaking frogs, singing crickets, etc. If you're in a town, you might hear sounds of merchants yelling about their wares, the clinking of glassware as you wander by a pub, or the ring of a hammer and anvil near the blacksmith's shop. Atmosphere "sounds" can be accomplished by using various room programs with mpechoat, mpecho, and mpasound.

Descriptions for large areas of the same sorts of terrain, such as a forest or swamp, are often difficult and tedious. Avoid using the same description over and over for 20 rooms; instead try making one long description to describe the of the "forest" as a whole unit, this may give you 25 lines of text, and then use bits and pieces of this description in each room. Move the lines around a bit, add some new words here and there, make the whole thing more interesting to read — if you use one big description and then chop it up, it is easier than trying to write a new description for each room. The only exception to reusing descriptions would be in a maze, but even so, try to use a variety of descriptions throughout your maze, each based on the same "base" description.

Conclusions

The mechanics of building, in itself, isn't difficult once you learn the various commands you need to open and close the editing tools. The difficulties arise when someone with little or no imagination, who'd rather not spend a whole lot of effort, starts running off areas and calling himself a "builder." Anyone can "build," but then anyone can construct a house too — the differences show up in the quality of the workmanship. A Builder (capital-B) will research and plan what he is going to build, a builder will not. This doesn't mean that every area needs weeks and months of preparation and research, but you should at least know what you are talking about when you start using the lingo, and you should have some sort of broad plan (and a map) in mind when writing.

Good Builders will also innovate new ways to do things, either with words or mpprograms, or both. For example; Why does a shopkeeper always need to be standing in his shop? Does he have no life outside the shop? If the shop is closed, then there is no reason for the mob to be standing there, so why not add some clever programs in that allow the shopkeeper to lock up his shop and go home? What about guards — Are they always guarding the same spot for 24 hours? Why not switch the guards, change them around, or send some off duty and bring new guards out? Areas need to live and breath, they shouldn't remain a static thing. Move mobs around, close up shops, include mob social interaction within your areas. Make your area feel more alive!

Building doesn't need to be a difficult thing — Every area is a story, with each room you write telling a chapter of that story. A good Builder is a good story teller.

[  Rooms  ] [ Objects ] [ Mobs ] [ Resets ] [ Programs ] [ Resources ] [  FAQ  ]

The entire contents of this page is Copyright ©1997—2007 FoxDesigns