CONCEPT
  Domains

LAST UPDATE
  Mateese, 04-November-1994

DESCRIPTION
  Old 2.4.5 LPMud consisted of a central area, managed by the game
  archwizards and administrators, and several separate wizard areas. The link
  between these areas were implemented by the wizards 'castle's - objects
  which were preloaded at game startup and which scattered 'link' objects
  into the rooms where two areas should be connected.
  Though this method provided an important part to the LPMud flair, it
  had several disadvantages: the overall landscape quickly grew inconsistent
  (not necessarily a disadvantage in magic settings), quite a number of
  objects were loaded without being used, and most important: only the
  creating wizard and a few game honchos could fix bugs in such areas.

  Domains were invented to give a group of wizards the opportunity to create
  more or less themed areas in cooperation. Within one domain, all members
  have access to all files, thus improving the creational and debugging
  opportunities. The system implemented in microMud appoints a few selected
  wizards to 'domain lords' with slightly superior permissions, in order to
  keep the development goals in focus.

  A common misunderstanding is to interpret domains as landscapes only.
  Though themed landscapes were the first applications of domains, they
  are in fact 'projects' (Mateese kept the tag 'domains' for historical
  reasons). It would be perfectly ok for a domain to do nothing but
  providing all other domains with ingenious red herrings.
  Even landscape domains need not be separate neighboured ares: a 'flathead'
  domain could build an underground area which has connections to rooms in
  all other domains.

  microMud features one 'mandatory' domain, called 'micro' (defined in
  /i/sys/config.h), holding the central areal. It is a good idea to keep
  micro the social center to support player interaction and socialization.


  The domain directories are all collected in the directory /d/.
  Each domain <name> gets an own directory /d/<name>. Each domain may
  decide upon their own directory structure, e.g. a regionalized domain
  may have an own subdirectory for each region, and additional ones
  for quests... you get the idea.
  All domain directories are readable for everyone.

  /d/<name>
    Parent directory for domain <name>.
    Writeable by the Lord, objects get Lord permission.

  /d/<name>/.err
    Logfile for errors happening in objects from this domain.

  /d/<name>/<dirname>/...
    Directories holding the objects and files of the domain.
    Writeable by any member, objects get Lord permission.

