A brief explanation of each area header follows.
This area header is the beginning of the file, telling the mud what the file is, how to reference it, how to display it in certain commands, and so on. Without this the area file will not load into the mud.
<help>This section allows a builder to give an explanation of the area either to the playing public, to the immortals or to both. Lots of information can be given here, including what certain powerful items do, explanations of mobs, and even histories of some areas.
#MOBILESMobiles are the things with whom the players interact. They talk, sell, cast spells, give out objects and quests, fight, and so on, acting much like players but with limited, if any, intelligence. This section details who they are, what powers they have, and how well they interact with the players and the world.
#OBJECTSObjects are the things with which the players interact. They can be picked up, eaten, used as weapons, worn, drunk from, and so on. They are what tend to make players more powerful than skills and spells alone. A builder uses this area header to develop objects.
#ROOMSRooms are where the players interact. Mobiles, objects, and players all occupy rooms, which can have an affect on the overall interaction of all three parties, healing, damaging, blinding, tripping, even trapping the unwary. This portion of the area file describes the rooms and all their nuances.
#RESETSMobiles and objects do not appear out of nowhere. For them to exist in the virtual world of the mud they need to be reset. The #RESETS area header does just this, loading objects, equipping mobiles, closing doors, and so forth.
#POPULATEAn alternative to #RESETS, this area header allows for random placement of mobiles and objects in an area. Resets still can be used, and must be used for doors and random rooms, but if a builder does not want certain mobiles to always appear in the same places at each reset, this section will do the job.
#ENCOUNTERSEncounters give more flexibility to builders in creating mobs, objects, and programs when a player enters a room. They allow for randomness and infrequent, sometimes unexpected, occurances. If, for example, a builder wanted to design a rare mobile that sometimes carries (but most times not) a unique object, encounters will help greatly in this.
#ENCOUNTERTABLESEncounter tables are the implementations of populations and encounters. An entry in either #POPULATE or #ENCOUNTERS always will refer to an encounter table, whether in the area file or in another area file. Yes, using populations, encounters, and encounter tables allows a builder to access mobiles, objects, and programs from other area files.
#SHOPSTo allow certain mobiles to buy and sell objects, the mobile needs to know what to sell, what to buy (if it buys anything), when to open its shop, and how much markup it charges. The builder makes those decisions in this area header.
#SPECIALSA few mobiles are a cut above the rest, having breath attacks or spells to cast. This section allows for such power among mobiles.
#MOBPROGSMobprogs are the programs that give life to the mobiles of the mud's virtual world. They can give a mobile the abilities of basic decision-making, quest giving, player bias, mob calling, and much more. Many atmospheric programs are small mobprogs hidden away from view, and even objects can get in on the act.
#SCRIPTSScripts are an extension of mobprogs, allowing for ritualistic behaviors and elaborate schemes.