RULES
-----

There are only a few simple rules you _must_ keep in mind when you want to open
an area.

1) 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).

2) The area shouldn't contain any illegal objects. All objects not following
   the rules must be approved by admin and be written into your permissions
   file.

3) 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.

4) 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.

5) Use properties wherever applicable, including terrain properties.
   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.

A sixth 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. However, some
tips will be presented under guidelines, below.




GUIDELINES
----------

_Things_that_make_the_admin_happy_

1) When you get an idea for a wonderful new area of 250+ rooms, discuss it with
   an admin before you set about coding it all. Often it is better to open an
   area step by step rather than everything at once - especially since you'll
   learn a lot about LPC while coding it.

2) Start coding the inner parts of the area, and leave the 'edges' of it until
   last. This way, it'll be more flexible and much easier to find a suitable
   place for it in the game.

3) Balance the area. Don't create hordes of alignment -1000 level 1 monsters
   running around everywhere. Don't only make level 19-20 monsters. 

4) 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 ~leowon/weapons/ than if you have
   four different directories of weapons depending on where in your area they
   can be found. This is absolutely nothing necessary, it's just convenient for
   the admin. If you have a very large about of files, it might also be idea
   to divide them among several dirs... But generally, it isn't.

5) 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.


_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).

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'.

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.

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, it's 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/.


_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 file. 

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.

Help topics available:

README	area.r	armour.r	behave.r	clubs.r
container.r	debug.r	general.r	guilds.r	heal.r
monster.r	paragon.r	pub.r	puzzles.r	quests.r
room.r	shop.r	spells.r	testplaying.r	weapon.r
word_list