AREAS(Inherittance)
| CoffeeMUD |
|---|
| Administrator Builder Player |
| =CoffeeMUD Builder Information= | |||
|---|---|---|---|
| Basics | Praetor Player Support Commands Zapper Masks | Advanced | Races Classes Abilities Socials Scripting |
| Building | Behaviors Properties Areas Rooms Exits Items Mobs | Systems | Achievements Crafting Help Info Ships Planes of Existence Quests Triumphs |
Areas can be organized in a tree-like structure for inheriting properties. There are many desirable reasons to structure areas in this fashion within CoffeeMUD, and some peculiarities to consider when assigning inheritance.
Contents
Root Area
When building your mud, a DEFAULTPARENTAREA may be assigned within your coffeemud.ini file. Any area without a StdTimeZone or StdPlanet parent will automatically be assigned this area as its parent. This area should be selected based on the scale of your MUD and where players will predominantly be adventuring.
Advantages of Parent Areas
Parent Areas allow any child area (and grand child, great grand child, etc) to default to certain settings of the parent. TimeZone, Currency, Weather, Atmosphere, Tech Level, Blurbs, Behaviors and Properties of the parent area are all passed down to the child. This makes setting regions with different weather patterns, or different economies easy to maintain, since you only need to edit the parent area instead of each child. TimeZone, Currency, Weather, Atmosphere and Tech Level can be overridden by a child's setting. Behaviors and Properties can only be partially overridden by the child areas (the behavior/property must exist on the child, but the parameters may be different). Blurbs are universally passed down to the child, even if they have the same flag.
- It is particularly convenient to have a parent area when you wish to have an event that earns extra experience through the Prop_ModExperience for that grouping of rooms (or all rooms on the MUD), since you just need to apply that property to one location.
Disadvantages of Parent Areas
Since parent areas pass their Blurbs, Behaviors and Properties to all children, builders need to be particularly aware of how these will affect each child area.
- Blurbs that are applicable to the entire region would be appropriate, but blurbs that reference JUST the parent area are not, since child areas would also receive that blurb.
- Behaviors and properites may be useful on a parent, and may be partially overridden by a child area. For example, WeatherAffects of a parent area may specify certain parameters, and a child area could also have a WeatherAffects behavior specifying a different parameter. In this case, the WeatherAffects of the child will take precedence, and the parent's WeatherAffects would not apply. However, another child could not negate the WeatherAffects behavior entirely...it would always have a WeatherAffects with either the parent's definition or the child's definition. This makes some behaviors, like CONQUEST or Prop_ReqNoMOB unweildy to use on a parent area.
Best Practices for Parent Areas
Areas that are Regional in nature, such as political entities, are best handled as a parent area with a single restricted-access room which players are not intended to ever interact with.
