                             ENVIRONMENT
                         DRAFT AS OF 12/21/99
            Team members: Cosmo, Fakir, Illarion, Scathe, Wocket

I. Overview
   The primary goal of this team is to expand and improve the environment
of Nirvana while preserving the atmosphere and uniqueness of the MUD. A
secondary goal is to make the code more efficient, flexible, and modularized
to account for future changes and expansions. To accomplish these goals, the
team has broken down the overall environment into three major tasks: 1. rework
the basic room code, 2. rewrite room descriptions as needed to produce a more
rich atmosphere, starting with the main village, and 3. refresh the current
quest system.  The tasks will be performed in order and each task shall build
on the progress made with the previous task. A detailed proposal of the work
to be done in each task is outlined below.

II. Rooms
Given:
   Current room code doesnt have the flexibility to allow wizes to add
different standard sets of environment types, such as 'outside', 'inside',
'hot', 'dry', etc. A set of standards should be developed and incorporated
into a listing of possible area types. Maybe even a room daemon module
could be built into the base lib that would automatically set certain
environment parameters into operation (such as lighting, temp, geometries,
etc). We should also consider a description search system for wiz usage or
at least a room type search base.

Proposed changes:
   The basic room.c code will be rewritten and modularized. The minimum room
code will have settings for long, short, and environment variables. These
items will be setable as they are currently done in the monster.c code (e.g.,
set_short("blah")). The environment variable - set_env() - will be based on a
set of standard values (e.g., plain, marsh, cave, city, indoor, forest,
mountains, water, desert, space, etc). This exact set of standard values is
still debatable, but will have configuration control once finalized. The room
code will also allow for other free-text variables such as smell, listen, and
search capabilities. Consideration will also be given to allowing for dynamic
long() descriptions based on the room condition.
   In addition to the basic room, other modules will be written for added
enhancements. These will include, but are not limited to: descriptive items
with multiple ids, player tracking code, doors, windows, and traps. Some of
these may be pre-defined based on the room environment. The player tracking
code will allow for determination of what direction a player enters and exits
the room. The door module will be based on the current /obj/door.c code, but
upgraded to include options for picking locks and bashing doors, as well as
integration with the room.c code.
   We will also create a light (and possibly weather/climate) daemon that will
call all rooms every so often and set the light based on the environment
setting. Preferred method of handling the light issue is to have the daemon
track all rooms and automatically set the light, as opposed to having
individual rooms call a daemon to check the time. We are proposing to use
a -2 to +2 scale for light, corresponding to dark, dim, normal light,
bright, and blinding.
   Since the light daemon will contain an array or mapping of all current
rooms, this could also be used to implement some sort of description search
system or room type search base.
   Another proposed change to room.c would be to implement standard values
to the property variable that currently exists. Standard values will be
established for setting PK, Spar, Teleport, Magic, etc. From this, other
objects can perform boolean queries to determine the environment of a room,
e.g. query_property("NT").
   Another item to consider for the room code is implementing ranged combat
(i.e., using arrows, bombs, guns, etc to allow for fighting from an adjacent
or nearby room). Any implementation of this would have to be in coordination
with the player/monster interaction team.

III. Descriptions
Given:
   Descriptions are what the players see and interact with. If the language
written is in high old english then the readers themselves will begin to use
the same language set. What needs to happen here is that areas and items must
hold true to good descriptions and consistancy of language. The only push I
can give here is that this hold true and that all areas and items (including
the main village area) not consistant must be improved upon or removed.

Proposed changes:
   Once the room code is rewritten and tested, rooms will have to be modified
to adhere to the new standards. Active wizards will be responsible for
updating their own code. This team will concentrate on updating the main
village area and then other areas that are no longer administered by active
wizards. Areas which are completely out of date and no longer used may be
considered for removal altogether. Some of this work may be done concurrently
with the revisions to the room code.
   Additionaly, a handbook will be written to provide guidelines on things
such as how to use the new room code, how descriptions should be written,
level of detail to provide in item descriptions, what standard values are to
be used, etc. The goal of the handbook will be to provide wizards some
metrics and guidance on how to construct proper environments, while not
stifling their freedom of creativity.

IV. Quests
Given:
   Current quests need to be filtered thru and upgraded once again. We should
standardize the code base of quest objects so that checking for certain quest
object ids would be easier. Quests should also be expanded to have more of a
type basis, so instead of just mental/physical ratings there would be others.
We should also reconsider how quests can be made more randomized/ complex as
well as consider if questing is the way that wizes are to be made.... 

Proposed changes:
   A final effort of this team will be refreshing the current quest system.
This work will involve updating quests to conform with the new room code,
as well as examining the quest system in general to improve upon the current
method of operation.

