Difference between revisions of "Category:AREAS(BuilderInfo)"

AREAS are a collection of ROOMS, ITEMS, MOBS and SCRIPTS with a common theme in which to adventure in. AREAS can be as small as a single room, or a large as hundreds of rooms.

TYPES OF AREAS

MODIFYING AREAS

Areas have a variety of fields that can be defined at the area level. Not all areas will have all of the fields listed below.

• CLASS: This is the Area Type (from the list above). It can be changed only via the MUDGrinder, not via command line.
• NAME: This is the name of the area. It may include spaces and special characters.
• DISPLAY: This field is available for StdBoardableShip. <r>Not certain when it is used.</r>
• DESCRIPTION: This field provides the basic data for the HELP (AREANAME) parameter. It should be descriptive of the area in general, without giving away any secrets within the area. This field should be written from an RP-perspective: What characters would know of the area from rumors or history.
• AUTHOR: This is the name of the creator of the area. It is highly advised to keep this to a single name, so players can sort areas by author, if desired.
• THEME SETTING: This setting is often Inherited from a parent area. It defines what parameters work in the area (Fantasy, Sci-Fi, Powers, etc).
• CLIMATE: This field influences the weather patterns of the area, and may be inherited from the parent area.
• ATMOSPHERE: This field determines the area's primary breathing environment, and is often inherited from the parent area.
• CALENDAR: StdPlanets may set this field. Child areas inherit from the planet settings and cannot be changed.
• PLAYER LEVEL: This field determines how the area appears in the WHERE command, and should be the average player level recommended for the area. Setting this value to 0 will use the Median Mob's level instead.
• PARENT AREAS: Allows structural organization of areas. This area will inherit any value specified as INHERIT from the parent area, as well as any Behaviors and Effects, unless those behaviors/effects also show up in this area with different parameters.
  • If a parent area does not exist, this area will be blocked off from player access, as will any children/grandchildren of this area.
• CHILDREN AREAS: Any area defined as a child of this area will INHERIT all of the inherited fields, behaviors, and effects from this area.
• AREA STAFF NAMES: This is a list of SUBOPS or builders who have been granted area-based security settings who can perform those operations while within this area.
• AREA BLURB FLAGS: This list of definable flags and their definitions. The definition of the flag will appear at the bottom of the HELP (areaname) result. You may define any number of AREA BLURB FLAGS, and each area may use a different set of these flags. These flags are part of the wiki template output when using the LIST AREA WIKIHELP command.

  Examples 

  RECOMMENDED: This area is recommended for players level 10-16.

  LANGUAGES: Dwarven is spoken here.

  ECONOMY: This area uses gold coins.

• RADIUS: This is the size of the planet's radius. It is used in determining collisions with the planet (both controlled collisions such as landing, and uncontrolled, such as crashing, bombing, shooting).
• COORDS IN SPACE: This is the three-dimensional coordinates of the planet
• MOVING: This is a combination of the planet's speed and direction. Set to 0 for a static frame of reference.
• AUTOGEN XML FILE PATH:

  Examples 

  randareas/example.xml

• AUTOGEN VARIABLES: This field allows you to set variables defined in the XML in the format VAR=VAL.

  Examples 

  LEVEL_RANGE=1?30

  THEME=forest

• BEHAVIORS: This is a listing of behaviors and parameters that affect the area.
• EFFECTS: This is a listing of properties and parameters that affect the area.
• MXP IMAGE FILENAME:
• CURRENCY: This field allows you to specify or create a currency system for use in the area.
• PREJUDICE: This field allows an area to affect the price of items bought and/or sold by a mob meeting a zapper mask criteria.
• ITEM PRICING FACTORS: This field allows an area to affect the price of items that meat a specific zapper mask criteria.
• BUDGET: This field can be set to limit the available money every GenShopkeeper in the area has to purchase items (unless specified otherwise by the GenShopkeeper)
• DEVALUATION RATES: This setting determines the price of subsequent items purchased by the same shopkeeper, preventing a shop from overloading on a bunch of one item that a player has farmed up. This will cause players to have to find other buyers for their goods if they have a large stock of a particular item.
• INVENTORY RESET RATE: This field is the number of ticks that must pass for an unattended shopkeeper to reset their inventory back to the base inventory. This will clear out all purchases made by the shopkeeper, and restore the basic inventory.
• IGNORE MASK: This setting determines, via a zapper mask, what type of mobs a shopkeeper in the area will not interact with.

Guidelines for Areas

Listed below are general guidelines for creating areas. These are guidelines, only, not requirements. However, these guidelines were developed over many years of area design. They are specific to the CoffeeMUD engine, especially the Official CoffeeMUD server.

• Areas should have a common theme. The Author of an area is not a common theme (an area Author could write hundreds of areas, so there is no need for this field to be limiting the area).
• Areas should have a tight level range. The lower the level of the area, the tighter the range. For an area below level 20, consider a 5 level spread.
• Players hate non-Cartesian rooms because it makes hand-drawn maps difficult. However, there are times when it is useful to mess with non-Cartesian layouts. Cartesian layouts do display better in the MUDGrinder, though.

• Loki's CoffeeMUDification Project

Starting Zones

Special care should be applied to the areas where new players will begin. This area is your sales pitch for your MUD, so you want it to really shine, but not overwhelm. Starting areas should provide players with an opportunity to learn your MUD's features, but also enable veteran players to jump into the game. There are certain features that start areas should have to accommodate the variety of classes that CoffeeMUD has, as well as offset or introduce game features:

• Start areas should have a water source and food source so players wont die of starvation.
• Start areas should provide a variety of weapons so players can experiment with variants of their class instead of just the default weapon. This is especially important in the event that a player gets an allergy to whatever material the default class weapon is made out of.
• Start areas should introduce the combat system, including WIMPY and FLEE.
• If your MUD requires a specific type of room to logout from, be sure there is a room of that type in the start area.
• Your area should have a way for scholars to gain paper to write on.
• Your area should have resources for artisans to gather.
• Consider both indoor and outdoor rooms for your start area so that you can accommodate classes such as trapper, gaian and delver.
• Your mobs should either be all neutral, or have both good and evil mobs, so that classes with alignment restrictions can maintain their alignment.

City Features

Cities are defined as areas with a preponderance of city street and indoor room types, so this needs to be taken into consideration for building your city. Don't forget about area inheritance though, where one area may be the parent of one or more child areas.

• Cities should have laws.
• Starting cities (and any neutral cities) should not be Conquerable to avoid ruining gameplay by an overly powerful, beligerant clan.
• Consider using area inheritance to define housing areas and other related areas
  • For example: When I make a city, say PARIS, I will create a parent area (GREATER PARIS) with a single room, and the room (not the area) is protected from teleport, wish, and player entry (see. I place the city laws on GREATER PARIS, which all child areas then inherit. I also create a series of sibling areas, HOMES OF PARIS, CLAN HOMES OF PARIS, etc which are children of GREATER PARIS, and therefore subject to the same laws. It would, therefore, be possible to create OUTSKIRTS OF PARIS, which is a wilderness area (mostly woods and plains type rooms) which would still be subjected to the laws of GREATER PARIS. Also, sometimes you may wish to hyper focus on details on a specific building, like PARIS MUSEUM, which would be a child of PARIS (grandchild of GREATER PARIS). This would allow you to keep your PARIS city map viewable in the Grinder, while having a very large area that is effectively within the city limits of PARIS. I do NOT put CONQUERABLE behavior on parent areas, because child areas would automatically become controlled once the parent area is. So if you decided to make your city CONQUERABLE, and put it on PARIS, the homes, and outskirts areas would not be conquered automatically once PARIS was conquered, however, the PARIS MUSEUM would be!
• Special citizens:
  • Library (GenLibrarian)
  • Armor Mender
  • Armor Resizer
  • Armor Vendor (May have multiple for different armor types)
  • Weapon Vendor
  • Magic Shop
  • Potion Shop
  • Pet Shop
  • Pub (Food and Drinks)
  • Inn (Place to sleep, may serve food and drinks)
  • Class Guildmasters (Trainers)
    • If you create a restricted access to a class guildmaster, use the appropriate zappermask based on the guildmaster's MOBTeacher behavior. If you create a MOBTeacher that can train all mages, make sure your zappermasks to enter his building reflects all mages (-baseclass +mage). If you create a MOBTeacher that can ONLY teach alterers, the zapper mask should also reflect that (-class +alterer)
  • Resource Vendors (GenResources)

Overland Map Areas

The FibS world-model is a superior example of how to nest area parents to provide world organization and an overland map. In this model, you may build an area as your overland map, and use GenPortals to access specific adventuring areas, and normal directions to travel the overland map. Overland maps have the nomenclature of GREATER xxx, and are sibling areas to the adventuring areas that they have connecting portals. The sibling areas will need portals leading to the overland map, as well. Note: This structure also normalizes player homes and clan homes area nomenclature so that you can keep all sub-areas closely associated.

• WORLDNAME
  • Greater WORLDNAME (contains the overworld map rooms, has resourceoverride, regional awareness, etc.)
  • NATIONNAME
    • Greater NATIONNAME (if you can wander a specific nation outside of any city or particular dungeon, etc)
    • CITYNAME (has city laws placed on it)
      • CITYNAME Outskirts (the fields / forest / mountains outside town and their random spawns)
      • City of CITYNAME (has streets, buildings, and all "safe rooms" of city, place Conquest on if desired)
      • Possible extra areas for major landmarks of CITYNAME; place under CITYNAME instead of City of CITYNAME if you made the city Conquerable but don't want these areas to be
      • CITYNAME Player Homes
      • CITYNAME Clan Homes
    • CITYNAME
      • etc etc
  • NATIONNAME
    • • etc etc

Overland Map Area Properties and Behaviors

• Overland Map areas should not have the conquest behavior.
• You may add Prop_HereEnabler for the skill Regional Awareness to provide all players with added functionality while in the overland map, without giving away too much detail of your dungeons. Similarly, you could add Prop_HereAdjuster to increase their nature lore expertise, increasing the range of the overland map display in game.
• Overland Map areas may have Arrest behavior if you plan on having roaming patrols to enforce that.
• Consider making overland maps areas have a resource override to nullify gathering while in the area (or a restrict skill property) so that your gatherers must use other adventuring areas for resource harvesting.

Player Housing Areas

Player housing is a major draw to many MUDs. There are many ways to set up player housing, depending upon your design concepts. There are a few guidelines to managing this feature. See for more considerations.

• It is ideal to create one or more areas per region for your player housing. For example, a major city may have 4 or more sibling housing areas, so that you may manage these areas more readily.
• Each housing area should have one GenShopkeeper that sells the realestate.
• Do not mix clan realestate vendors with non-clan realestate vendors.
  • In general, clan property is much more usable by players than personal property. Therefore, Clan property should be 3-100 times more expensive. The CoffeeMUD uses a factor of 3 for clan property.
• In order to reduce player confusion, each housing area should use ONE type of realestate property (ie, Prop_LotForSale, Prop_RoomsForSale, etc), and any parameters of those properties should be the same (either all GRID rooms, or all "snowflakes") and similar limitations enforced with prop_reqcapacity.
  • Players are notoriously messy. You will want a prop_reqcapacity on your rooms, with an items= of 100-1000 items, depending upon your generosity (and this could be used to make certain property more valuable). Player areas with lots of rooms and lots of items take a VERY LONG time to load in the grinder, so managing your realestate is important to prevent noticeable lag during play.

Planar Areas

Areas that represent an extraplanar location (like Heaven or Limbo), can be made by:

• Make the area type a StdPlanet
  • Putting an extraplanar area on another planet will prevent players from teleporting to that region unless they are already on that plane.
• Adding a PlanarAbility
  • Modifying the area to have an affect of a planar ability (such as Spell_Planeshift) with the designated plane of existence as a parameter will give the following affects from the planesofexistence.txt file:
    • SPECFLAGS
    • BONUSDAMAGESTAT
    • RECOVERRATE
    • WEAPONMAXRANGE
    • REQWEAPONS
  • All of the other parameters (such as mob modifiers) will need to be added manually to your inhabitants.
  • Restrict planar travel abilities from working on a planar area with Prop_RestrictSpells or Prop_RestrictSkills with Spell_Planeshift, Chant_PlaneWalking, and Prayer_PlanarTravel to prevent people from going to different planes within your plane.
    • Prop_RestrictSpells - Spell_Planeshift;Chant_PlaneWalking;Prayer_PlanarTravel

Area Tools

How to update the Area HELP file

After modifying the area's mobs' levels, you may notice that your area help file still shows the previous range of MOBS. This is because that data is generated on the area load at startup. You can reset the help file with the following commands:

• Example 

  LIST RESOURCE STATS_(AREANAME) - Just to make sure you have the right file

  UNLOAD RESOURCE STATS_(AREANAME) - This will remove the help file entry...but fear not!

  HELP (AREANAME) - This will find that there is no help for that area, so it will generate a new help file for it (with the most current data).

Area Blurbs

Area blurbs are special flags set from editing the area. Each flag should have a unique name, which is not displayed, and a text field, which is displayed after the system area help file when players type HELP (area name). These special flags are used in generating area wikihelp, as well.

For the Official CoffeeMUD server, consider adding the following BLURBS to your areas where applicable:

• AQUATIC - start off the description with the color cyan (^c). Add this blurb for areas that require lots of swimming, boating or underwater action.
• ECONOMY - Add any sort of economic biases for the area (IE, Shopkeepers preferring to deal with elves). (NOTE: Currency will be listed within the help file for the area automatically).
• LANGUAGES - Add this flag for areas where conversation may be important (IE, cities that sell things, RP areas).
• RECOMMENDED - Add this flag to all finished areas. Provide a recommendation for what levels, player skill sets (IE, hack-n-slash, observant, powerful, questers, RPers), and types of characters may enjoy adventuring in this area.
• RENTAL - For property areas that rent out their property. This Blurb should describe the rental costs and process. See Apartments of New Thalos for an example of the RENTAL blurb.
• TRAVEL - For zones whose primary purpose is to connect to other zones, this blurb can be used to list the commonly known linkages to the area.
• UNDEAD - start off the description with the color blue (^b). Add a short statement of the known undead presence in the area (heavy, light, ghosts, etc). Do not add this blurb if there are no undead, or if the undead are not generally known to the rest of the area's inhabitants.
• URBAN - start off the description with the color dark yellow (^Y). Add this blurb if the area is primarily a city or a district within a city.
• WILDS - start off the description with the color green(^g). Add this blurb if the area is primarily feral, or uninhabited by intelligent creatures, and of outdoor or cave type rooms. Do not use WILDS for water areas.