Infinity LPMud: Area-Making Guide
The following is available on Infinity in the Tome of Wizardhood under the tome areas. We highly suggest that all Wizards read this before creating an area.
Suggestions for making a solid area
The purpose of an area shouldn't be to slam down some ideas in code as fast as possible, only submitting it so you can say you've coded something on the mud. The areas on muds are usually considered to be important parts of the game. Players have to kill in these areas on the way to being a wizard, so every wizbound player will see them. Because of this, it's imperative that wizards set forth a good example. This is often why the arches will take their time to approve areas, and will seem to be extremely strict with their standards.
Written by: Mutara, Huan, and TanziWhen we were players, we weren't too impressed with lazy areas. By a "lazy" area, we mean an area that someone didn't put much effort into. Symptoms of this would be misspelled words, whole chunks of text missing because no one bothered to proofread the text, things that couldn't be examined, etc. What separated the good quests from the bad was being able to examine things. Trying obvious actions and seeing some sort of response for them. Seeing a monster interact with the players on a basic level. Perhaps even multiple ways of solving a quest, if you've placed a quest in the area.
In light of the fact that many muds often don't have much in the way of documentation for writing clean areas, we thought we'd take a stab at it. The following guidelines are what the archwizard staff on Infinity look for when we check out an area. If you're writing your area, you may wish to check this list out, and see if you follow all of these.
Once you can look at your area, look through these guidelines, and say you've taken care of all of these, the area should be much tighter and more complete. You can propagate the chain further by showing your own sponsorees these guidelines, teaching them how to make a cleaner area, as well.
- Make sure everything is spelled right, and ensure that the grammar is correct. This counts for the long() and short() of objects, what you see when you examine things in a room, and so forth. Some of you may not be able to spell, but I'm sure all of you can read. Look it up in the on-line Webster or ispell if you have the features, or look in a dictionary. Alternatively, you can always ask someone on the game how to spell something. There are dozens of people who can spell well, and who are always glad to help.
Likewise, check your grammar. Most of us who have learned English as our first language should know better, and have no excuse. For wizards who have learned English as a second language, we'll be happy to try to help you with difficult-to-spell words, as well as the subtle nuances of English grammar. Some of us are by no means experts, but we can look things up, which is often more than some people will try.
- For every noun in the long_desc of a room, have an item. If we see "You are standing in a large field. There is a large broken wagon here.", we'd like to be able to examine "wagon" and "field". We'd also like to be able to examine "broken wagon", "large wagon", "large broken wagon", and "large field". Most /room/room.c's make doing this extremely easy. Check the local documentation to see how. Don't be bashful with this, either. Item as much as you can, including nouns with their adjectives.
- Make sure your long_desc's will work for a variety of situations. Unless you're sure the player will only enter from a certain direction, don't use something like "As you travel north, the air gets cooler..." If the player is heading south, it looks pretty foolish.
Something else to do, is to make sure you don't reference any objects or monsters in the long_desc that might disappear. Seeing "There is a large orc here." after you've drawn and quartered the poor beast looks....strange.
- Don't be obvious with hints. Too often, we see text like, "There is a stream here. Perhaps you can 'wade stream'." Not only is that giving them hints, but it looks bad, and you can bet the arches will ask you to change it. The point of the area isn't to give the commands to them on a silver platter. Let them figure it out. However, don't make the syntax so difficult that they need to be a walking dictionary to figure it out. Try to find a good balance.
- Give your objects many aliases. If you have an object called "a brilliant blue sword", give it aliases like "sword", "blue sword", "brilliant blue sword", and "brilliant sword". This makes it easier for players to distinguish between different objects in the shop. Likewise, do the same with your monsters, naming a large ugly troll "troll", "ugly troll", and "large ugly troll". Players will often refer to a monster by the simplest name possible. It's important to provide as diversity as possible in this regard. It also makes for a cleaner-running game overall. In addition, you can also set a unique alias for your objects and monsters, like "yourname_priest". This allows you to reference them easily when compared to other similar objects.
- Use senses other than sight. Are you in a room that smells bad? Can you hear something in the distance? Look into "listen" and "smell" abilities, as well as your average "look at" or "examine" abilities. Use them.
- Allow for some obvious actions. If you have a tree in a room, for example, let the players try to climb it. Some /room/room.c's will have an actions array that lets you do this simply. If not, go through the extra work of setting up a few add_action()'s. We're not suggesting that you need to make each room into a quest in and of itself, but on the other hand, seeing a message like: "You cannot find any low branches." is preferable to "What?". When we snoop players in our own areas, we see what actions they try. After they leave, we take the time to add in the actions with some sort of reply. That's what 'snoop' is for, and it adds to the overall quality of the area.
- Be consistent with actions. While it's a great idea to stick in a large number of actions, keep in mind that you also don't want to broadcast that a certain tree is special, for example. If that one tree is the only tree that gives a result for "climb tree", that's a pretty big giveaway. Make other trees respond to actions, and keep important objects from sticking out like a sore thumb.
- Make sure your rooms are lit correctly. If you just stick in a short_desc, long_desc, few items, and a destination or two, you won't have any light. The default is a dark room. To give your room the standard brightness, use set_light(1); Also, don't overdo darkness. Setting a dark room to set_light(0) (or not even setting the light in the first place) is enough.
- Set up the parameters of the room before you clone objects into it. This is the most prevalent mistake we see. What usually happens is that wizards clone a monster into the room first, and then try to set up the parameters of the room. If the monster bugs, the code that sets up the room is never executed. This isn't good, especially when you consider that you might easily end up with a room that has no short_desc, no long_desc, and worse, no exits. A player shouldn't be trapped in your area due to your mistakes. Set up the room first, and then move in the monster or items.
As added incentive for setting up the parameters of a room first, keep in mind that if you move a monster into the room first, and then define the room around it, the monster will not be able to use the exits, and will be trapped. That's not good coding, if you have wandering monsters.
- Not all monsters and objects need their own file. In fact, most of them don't. Unless your monster has been written to do something special when fighting, you don't need to give it it's own file; you can clone the monster into the room directly, and configure it with call_other()'s. This also works for objects. You end up saving a tremendous amount of memory, which is always a good thing.
- Make sure you don't clone multiple copies of a monster into a room. Often, while testing an area, we will reset a room manually, and the room code will clone a monster into the room without even checking to see if one already exists. After 5 or 6 resets, you can have a pretty crowded room. To make sure you did this correctly, you can try to reset the room yourself. Calling reset(1) in the room will duplicate what occurs when the game resets your room. Make sure you do this only in your own area; you don't want to screw up another wizard's area by accident.
- Check the sex of your monsters. We'd guess that 60% of the time, you'll call your good soldier Bob, give him armour, refer to him as "He", use "his", and other masculine-oriented words, and then forget to set_male() in him. This is pretty inconsistent, and looks bad. Catch it before some annoying player does.
While on the same subject, let's remember a bit of political correctness. Let's not assume that the player is male, female, heterosexual, or homosexual. Just assume the player is a player, and don't tell him/her/it that "you find the lady attractive", or "you find the man attractive." Offending fewer people makes for a smoother-running mud. Also, don't use "him" and "her" in standard monster.c chats, since these message are set at the monster creation time. The player encountering the monster at a later date could be of any gender.
- Make sure the names of your monsters are banished. To do this, go to the Adventurers' Guild, and type "banish monstername". The name may already be banished, which is a good sign (players won't be able to use that name to login). If it instead says, "That name is already used.", you're in trouble. A player is currently using that name; rename the monster. We make sure that only either player OR monster can have a name, so that if we destruct the monster by using it's name, we don't accidentally destruct a player on the game by the same name (It's happened many a time).
If another wizard has already banished the name, it's not a problem. If you think this is too much of a hassle, banish only the most important and unique names. For example, if a quest in your area is to "Help Mondius break free of the Chains of Circe"...banish "mondius" and "circe".
- Use transfer() correctly to move objects to a player. We've seen a lot of wizards use a move_object() to move an object with weight to a player. This messes up how much they can carry, and will just cause bugs to occur at a later date. Stop this at the source by using transfer() correctly. (transfer() updates weight properly).
You need not use transfer() for moving players though, or moving objects to rooms. move_object() or move_player() would be more appropriate, since you wouldn't need to worry about weight concerns in those cases.
- Don't destruct worn or wielded objects on a player. While it's a nice idea to have a bolt of lightning shatter a worn shield, it can be a bit dangerous. If you destruct a weapon or armour that was worn, the player will end up still having the wc/ac, even though the item is gone. To counter this, be sure to make the player "drop" the item somehow. Contact an arch if you want to know the best way to do this.
- Before you put an object or a monster into a room, figure out why it's there in the first place. While having a level 19 storm giant-dragon-zombie-lich-blob from the nether regions of the abyss may fit in perfectly with your area, it might be a bit out of place to have it be in the first room of your castle. Recall that your castle will be an addition to the rest of the mud, and make the area fit in well with the game.
- Think twice about how much gold and equipment you give out. Giving out too much cash and equipment will just make the mud too easy. If that happens, the archwizards will probably start pointing out things you can reduce. Save them the trouble by realizing that unless a monster has a very good reason to have a lot of money and equipment, you shouldn't give it to the monster in the first place.
- Forget treasure troves. If every wizard had one, there would be far too much money in the game. Take the initiative, and give the players something else to earn. Perhaps you can hand out some experience points, or stick their name on a scroll. Anything, instead of introducing more free cash into the game.
- Forget mazes. There's no skill in going through a maze. It takes up a lot of space, annoys players, and we certainly don't want to waste our time getting lost in your area. Try to write a real challenge, instead of something we can hack a robot to do for us.
- Don't make your rooms look all the same. While it may seem efficient and less time-consuming to code one room, and make many copies of it, it looks terrible. If you're too bothered to write a new description for each room, don't bother writing an area. It takes no skill to get lost in an area like that. Or to create an area like that, for that matter.
- Make sure player exit messages don't look strange. A wise person once said that the ideal castle will blend into the mud so well that you won't quite know where the original mud code ends, and where the area begins. Once you've mastered that, it seems like a foolish idea to make the exit look strange, like "Mutara leaves castle.". What kind of exit is that? Why not something like "Mutara looks around warily, and walks into the castle."?
Likewise, use your move_player() calls carefully. Instead of using the function to show: "Mutara leaves hedge.", you can usually use some creative coding to write: "Mutara parts the hedge and steps into it." You'd be surprised how much cleaner your area will look.
- Indent your code. Some people don't bother to do this, and it's not easy for us to figure out what you were trying to do if you left-justify all of your code. If you don't indent your code, start now before you get stuck with a bad habit. We can give you examples to follow, if you want to learn some methods of indenting.
- Remember that players like to see "complete" areas. We realize that wizards often like to open their area before it's totally "complete". Perhaps you have one more wing of your area to finish, but you really don't want to wait. This isn't a problem, as long as you don't actively point out that the area is incomplete. Having a sign that proclaims, "THIS PART OF THE CASTLE ISN'T FINISHED YET." isn't very good. Instead, you could cleanly seal off the exit that leads to the unfinished part of the area.
- Test your own code before submitting the area. We don't have the time to be everyone's personal debuggers, and nothing gets us more annoyed than trying to leave in a direction and seeing: "Failed to load file." If you can't take the time to check your own area to make sure everything works, we don't see why the archwizards need to take the time to look at it.
- Have another wizard go through it. If given the choice between having an archwizard point out incorrect parts of your area, or having another wizard do it, most people choose the wizard. Your peers are just as good at spot checking. They can't approve areas, and we'll still go through them, but it would certainly help us if they caught the major errors for you. Keep in mind that players cannot do this for you; that's interfering with the game, and is forbidden on certain muds.
PLAYERS || WIZARDS || ADMINISTRATION || FAQ || GUILDS || LORE || HOME