From the NannyMUD documentation
2005-02-02
NAME
area - rules on areas.DESCRIPTION
These are the rules you _must_ keep in mind when you want to open an area. 1) It is strongly recommended that you open an area of no more than 10 locations. 15 is possible but discouraged, and 20 is an upper limit. 2) You shall find a reasonable location where to open your area. Just outside the logon points isn't reasonable. 3) You shall have a plan over the area. This could very well be a simple sketch. 4) The new area shall not contain anything that needs approval. 5) The area shouldn't bug (Naturally it's almost impossible to make sure the area is completely bug-free, but you should have tested it before you allow it to open. Don't use mortals to test it, since it's illegal to move mortals into unopened areas. Do it yourself and/or with a testchar). 6) The area shouldn't contain any illegal objects. Refer to the rules for weapons, armours, and monsters specifically. An extremely useful tool for checking monsters is /std/tools/monster_check.c. Clone it, examine it, follow the instructions. 7) If you use items from other areas, you have to check first if that area is open. Use the area daemon (area_d) for this purpose. See the documentation on area_d for how to do it. 8) Use the newest lib files whenever possible. At the last update of this file, this means using files from the /std/ dir. Documentation on these files can be found under the topic 'std'. However, you should NOT use files from /std/rfc, since these files are not yet tested thoroughly and might be removed or changed without prior notice. Or at least, if you do use things from /std/rfc, don't open that part of the area until the files you use are moved to /std. An area that uses obsolete lib files when newer ones are available will not be allowed to open. 9) Use properties wherever applicable, including terrain properties and colour. If properties are a mystery to you, there is a lot of help on it (try the topic 'properties'), or ask your sponsor/your friendly neighbourhood admin. The topics 'terrain' and 'damage_types' might be of interest as well. This is also a good place to mention setting types on all weapons, and race and gender (where appropriate) on all monsters, which is required. If your monsters have special attacks, you must set a type on the damage inflicted. See the documentation for simple_monster. Note that all objects that have a main colour needs to have the colour property set to that colour! If in doubt what to set, ask your sponsor or an admin. 10) Before presenting the area to your sponsor for a check, you should have done your utmost to weed out typos and bad language. If the language of the area is too bad, the sponsor might simply refuse to check the area until it has been improved. 11) If the area is to reside upon the new continent of Antharis, there are some other things you will need to consider. Apart from all the things said in this file, also make sure to read the rules about Antharis. GENERAL HINT Another thing that is not a rule per se, but more something to keep in mind, is that the better area you make, the better locations it will be allowed - and what constitutes a 'good' area is, finally, up to the admin. One thing to keep in mind, here: If your area needs more work to become 'good', the admin might elect to place it on the Isle of Lost Empires, an island where topography is not an issue, where it will remain until deemed good enough to be placed elsewhere. Some tips will be presented under guidelines, below. If you follow them also, chances are much greater than you will get the location you want. This file is rather long, but take the time to read through it all. It will pay off. Big time. THINGS THAT MAKE THE ADMIN HAPPY 1) When you get an idea for a wonderful new area of 250+ rooms, start with 10 locations. Open that, and then open things step by step. This is better than trying everything at once - especially since you'll learn a lot about LPC while coding it. 2) Balance the area. Don't create hordes of extremely alignmed monsters running around everywhere. Don't only make level 19-20 monsters. Don't take these tips literally: 20 level 20 monsters and 1 level 1 monster is not balanced. Use common sense. Make monsters friends who should be, logically, like guards or priests of the same order. Use the /std/tools/monster_check tool to make sure your monsters are legal. Don't code monsters with level > 20. Don't code the area to be 'useful' for specific guilds. Try to include a little something for all kinds of players. 3) This is just a thing that makes it easier for admins, again - if your area has several parts, don't have one separate dir of monsters, armour, weapons etc for each area part. It's much easier to keep track of your items if all your weapons reside in a directory like ~name/weapons/ than if you have four different directories of weapons depending on where in your area they can be found. This is nothing necessary, it's just _very_ convenient for the admin. If you have a very large amount of files, it might also be a good idea to divide them among several dirs... But generally, it isn't. Most of all, keep your directory structure shallow, ie, don't have paths like ~name/area/rooms/forest/glade/glade1.c, where ~name/rooms/glade/glade1.c would suffice just fine. 4) If your area connects to another wizard's area as opposed to the /room area, you must use the area_d (area daemon) to make sure that area is open, before letting players enter it. For more info on how to do this, see the help on area_d. 5) It's very common to want to log things happening in the area, to see what's going on, for balance purposes, etc. DO NOTE USE write_file() FOR THIS!!! If you are going to log things, use caching. There are standard loggers provided in the lib. 'man logger' and/or 'man simple_logger' for more information, including why it's so important to use a logger. THINGS THAT MAKE YOUR AREA APPRECIATED BY EVERYONE 1) Use add_item(), so players can examine things in the rooms (note that in the /std lib, you can also use add_item() in non-room objects, which is a very nice feature allowing much more interesting items). A good rule of thumb is to make it possible to examine all significant nouns in the long description of a room or an item. 2) Try to make the area interesting. Don't code endless expanses of rooms without monsters or items in them. Don't code 40 exactly lookalike monsters with only some value differing them from each other (unless you're coding an army of course :). Detail is always interesting. Note that interesting is NOT the same thing as 'lots of easy xp/money/eq to find here'. Give monsters some add_attacks() (man simple_monster). Use random() a lot to make the area less predictable (note, however, that while having a non-predictable area is a good thing, having an illogically random area is generally a bad thing, unless you have some specific purpose in mind). Having a theme is good, and helps creating atmosphere. Make sure the area makes sense according to the theme, or just plain common sense if you don't have a specific theme. Unless there is a good reason for it, such as a maze, a long road, a deep forest or whatever, don't have the area consist of bunches of rooms that are identical but for the exits. Cut and paste is nice, but it can be over-used too. 3) Try not to make too many typos. This is naturally varying from person to person, but the less there are, the more players can concentrate on what your descriptions say, instead of their grammar. If your English isn't spotless, ask for help! Failing all else, the topography admin might know someone willing to check your area. Also, there is a club named the "Typo squad", whose members are willing to help with weeding out typos. Remember not to let any mortals into an unopened area, though. Talk to the wizardly members of the squad. 4) Puzzles are fun, and if you don't feel up to coding a whole quest, puzzles are a good way to make people snoop around in your area and explore it thoroughly. 5) If you do have grand treasures in the area, don't let them just lie around for the players to find. Make them work for it! Many players appreciate 'questing for gold and xp', as Mats once put it. Protect them with guardians and ingenious traps. 6) Don't make instakilling traps/monsters. If you have a truly lethal feature in your area, make sure players get ample warning before running into it. 7) If a room or an item description hints that it would be possible to do an unusual command in the room (but you haven't intended the command to be possible), like moving a boulder, swimming in a lake, climbing a cliff, etc, it looks nice if you allow some other message than 'What?' when a player attempts it. In /std, this is easy to do with add_command() or add_item_cmd(). See help on 'std' for more information on this. Also see the rooms in /examples/. COMMON PITFALLS TO AVOID 1) If your monsters wield weapons, they will automatically get the higher weapon class of the weapon and their natural base wc. You do NOT have to set it, using set_wc() after wielding weapons. When monsters wear armours, the class given by the armour will be added to the base ac value. 2) If you have many monsters in the area, you really should consider not giving them all the lowest values allowable in ac, wc and hp. This naturally depends on what category of players you are catering for, but the power of today's parties have reduced monsters with default values to little more than walking xp supplies. This applies mostly to monsters with level 15+. On the other hand, there is little point in making insta-killing monsters either, unless you give out plenty of warning hints. If you feel unsure about what might be reasonable figures, ask your sponsor or an admin. 3) If you use add_object (a very useful tool), make sure you understand how it works. Specifically, do _not_ call it every reset. See the documentation for /std/room for more details. 4) Don't capitalise the first letter in set_short() unless it is really a name or some other kind of unique identifier. Examples: set_short("Glamdring, the sword of Gandalf"); and set_short("a fine longsword"); are both correct. set_short("A knife"); is wrong. 5) In /std objects, linebreaking is done automatically in the functions set_long() and add_item(). This means, you don't need to linebreak them yourself. Ie, set_long("This is a long description that is longer than just one "+ "line, but we don't need to add any newlines to it anyway "+ "since the /std lib is so nice and user-friendly."); will work just fine. The advantage of not doing linebreaks manually is that you'll get the same general width of all descs in your area, which is nicer for people who visit it. Of course, if you _do_ want to do your own linebreaking, by all means go ahead. This is just a tip to save you the bother, if you don't need some special formatting of text. 6) If you find yourself repeating the same code in room after room, you should consider if it could be better solved using inheritance. If you are unsure how this works, talk to your sponsor or an admin. 7) If you somewhere in the area use add_money() to take money from players, for example when they throw money into a wishing well or the like, make sure they can't throw in a negative amount of money and actually gain from it. WHAT TO DO WHEN YOU WANT TO OPEN THE AREA 1) Have a friend wizard or testchar go through it looking for bugs and typos. DO NOT let a real player into the area before it is opened. 2) Make sure that nothing in the area that needs approval. Check the rules, armour, weapon, monster, etc, for guidelines on what's allowed and what isn't. 'man RULES' to see what rule files there are. 3) Find 2-3 places where you would like to open it. Make sure it fits in with the surrounding areas, terrain, etc. If you have a coast, don't put it in the middle of a plain. If you have a desert, don't put it next to a jungle, etc. Note that these places might be disallowed by topography admin. But you should have them, nevertheless. 4) Talk to the topography admin, have him/her or someone he/she designs look through the area. This area check should not be a typo hunt; the bulk of the typos you should have weeded out before coming this far. To see which admin is in care of topography, do 'help wizinfo/admin'. 5) Once the admin and you agree on where to put the area, the following steps are needed: a) If the area is not on an island, set up your castle.c file. Otherwise, set up a harbour room so that one can call a ferry from there. Sometimes adding a few 'starting' rooms to make the area fit in nicely with the surroundings might be required. If you don't know how to set up your castle.c file, ask your sponsor or another wizard of level 25++. b) Make a dir with your name in /open/info/ and place one or more files there describing you, your area, or whatever else you deem appropriate (for example, /open/info/leowon/area). This is for the tourist office. c) Make sure the admin notes in your permissions file that the area is now open. Also make sure the admin makes your castle.c load at reboot. d) If you want to put up a note on the adv guild board that the area is now open, do so. If you want a note on the announce board as well, ask the admin overseeing the area opening to put one there for you. e) Welcome to your new level! AFTER THE AREA HAS OPENED 1) Make a habit of checking your .rep file regularly. Players appreciate it when their reports are fixed quickly. 2) When an area bugs somehow, you can find the errors in the /runtime.log or the /lpmud.log files. 3) Don't leave odd ends like, 'This part of the area is not ready yet, but will soon be expanded upon' visible to players, if you don't realize the plans for a long time. Better to just remove any hints to upcoming additions to the area. 4) If you later expand the area, you don't need formal approval on the new parts. It is assumed it will be at least as good as the part that was approved originally. However, all objects that don't conform to the rules still need approval as usual. And one important point to keep in mind: When the area opened, it was fit into the surrounding lands as much as possible. Don't break this coherence in topography with later additions. For example, if your original area was a hot desert, don't build a coast where icebergs float around just adjacent to it. Nor add major topographical features like large mountain ranges, large rivers, new coastlines, etc, without consulting the topography admin first. 5) If the area should prove to give out way too much xp/money/eq compared to existing ones, be prepared to lower it (as in decreasing money given out, lowering monster levels, reducing number of monsters, reducing eq carried by monsters, etc) drastically. In extreme cases, admin might even lower the area and notify you via mudmail. Do yourself a favour and save the admin this extra work: If your area has a very high give-away on the wizlist soon (as in a few months) after opening, lower it yourself. Chances are your own measures taken won't be as severe as if an admin goes over the area. 6) Do not code the area for your own seconds. As a warning example, picture a thing like adding an exit nigh-impossible to find without knowing in advance it is there, leading to an area full of easy kills with loads of money, known only to the creator's seconds and close friends. Such cases usually end up with the creator being demoted. Don't succumb to the temptation to use your area as a way to speed up advancement for your seconds. You may succeed for a while, but chances are eventually admin will discover it, and you may lose both your wizard and your second chars. Also note that the admin's interpretation of what goes and what doesn't may differ from your own. Also see 'general' for rules concerning second characters.