
General outline of future versions:

1.0: First true public release - fully stable, and very well balanced.
Post 1.0 outline, with the goal for a 2.0 release:
1.1 -> 1.5: Make the big changes that will result in the biggest bunch
    of new bugs.  Things I think about are map tiling, increased
    viewable playing area, and object cleanup.  Small changes can also
    go in these releases, but the idea is get the big stuff in early
    so there is more time to find the bugs and get it working
    (some will also require new clients or support within the client)
1.6 -> 1.8: See what is still on the TODO list and other ideas, and decide
    if they should get in by 2.0 or wait for 3.0
1.9 -> 2.0: Releases for balancing and finding bugs - no new features,
    and bug fixes should be well thought out.

Various bits, in no particular order.  This is far from a complete list -
however it keeps growing as various problems are discovered that
don't have an easy fix.

------------------------------------------------------------------------------
Known Bugs:

These are things which don't work as expected, but are difficult enough to
fix that they get put here:

Make lighting not go through walls.  Maybe move it to the 'set_wall'
function - hard to do so that it is still somewhat efficient yet the same
light source does not illuminate the same space multiple times.

------------------------------------------------------------------------------
Future feature requests

- Make random treasure chests lockable, such that you need a special key
  to open them.
- If player tries to login with same name/password as a character currently
  active, drop the old connection and associate the player with the new 
  connection.  Useful if connection is dropped but server hasn't detected
  it yet.
- Generalize the code better - split between 'rules' and 'engine'.  The engine
  would be the aspect of loading/saving objects, dealing with maps, and
  basic object support (exits, levers, etc - things useful for any working
  system). The 'rules' would be the more general genre of the game -
  a science fiction game would have a different set of rules than the
  fantasy game.  And even the same genre may have a different ruleset
  (ie, adding new skills).  This is sort of like the current server/common
  split, but goes a bit more than that - the engine would be able to compile
  into an executable with the addition of some basic stub functions,
  but playing as such would really just amount to a ghost moving accross
  a world which time is pretty much stopped (as monsters would be in the
  rules side, and not engine).
- Changing the stat generation system - instead of roll based, give some
  number of points.  This makes it easier for players to choose what they
  want to play - otherwise, I think some clients will be written that will
  do this for the players in any case.
- Change draw_info so that server tells client what type of message it is
  instead of the color.  Client can then decide what color to draw it
  or other special handling.
- Better handling of saved characters on potentially better maps.  The save
  can either have been caused via disconnection or autosave.
- Change code so that objects 'spill over' to other spaces if too many
  get piled in one space.
- More/better maps.  Add more quest maps or maps to take advantage of
  newer features (ie, church maps for each god, maps for alchemy quests
  or with rare ingredients, etc)
- Add some identifier for unique objects so that if the player that has
  a unique objects quits the game, the object goes back into circulation.
- Add flag to make price of objects not affected by charisma or other
  abilities.  This should act like gems do right now (pay 1.03, receive
  0.97).  In this way, gems don't have to be hardcoded, and other items
  could be similarly set.  Nuggets should be added to this list - its possible
  to make small amounts of money alchemy silver and then selling the nuggets.
- Add/change door handling - make them more real life - they stick around,
  can be opened, closed, different keys for different doors, etc.  This
  sort of mimics the gate behaviour, except keys may need to open them, etc.
- Added armor quality, with armor being damaged as it is used.  Add repair
  shops to go with this.
- Change players draining exp from others.  Currently, there are problems
  in that it not adjusted based on levels, so there are various abuses
  draining from low level characters.  Also, generally it is not possibled
  to drain exp from monsters.  Possible ideas:
  - Change draining from other players to be a ratio of levels (ie, a level
    10 character draining from level 5 only gets half the exp.
  - Ability to drain exp from monsters (might make drain weapons more
    useful).  Maybe have monster lose some portion of the exp he would
    award when drained, and try to adjust level/other stats downward as
    it looses exp?
- Fix map loading/saving so it can do it over several ticks for smoother
  performance (maybe thread it?)
- Clean up skills table so that the basic skill information is dynamically
  generated when the program runs, and not compiled in values.
- Clean up party code with respect to experience/skills.  Currently,
  other party members can get exp in whatever they want and let another
  party member do the killing.

- With above, a general cleanup of skill experience for the player needs to
  be redone - there are too many ways where players can shuffle exp into
  the skill they want.  The problem is really the spells since the player
  can change exp category after the spell has been cast.  But I could also
  see problems with pet monsters and the like.  Probably some extra
  field for spell effects which mark which spell category they are from
  needs to be added.

- Add method so characters that get transported into the middle of oceans
  can get back to the city with sysadmin intervention.  It would be pretty
  easy to check and make sure the player is surrounded by ocean - not sure
  if this might be used to cheat somehow (dimension door to the ocean,
  then use the command instead of word of recall?) 
  I believe this problem is now fixed - MSW 2001/07/07

- Delete oldest swapped map in case the TMPDIR disk fills up while
  swapping out a map.  To do this, detection of error on save would need
  to be done (presently, the fputs are done without return value checks.)
  
- Seperate weapon speed and real speed for players - one is used for attacking
  only, and the other for movement only.  Right now, a characters real speed
  could become the weapon speed when they attack something.
  Make speed more variable for some actions (limit how much can be picked up
  at once, certain skills should take longer than others.)
- Make monster pick up more intelligent - only pick up items if they may be of
  some use (perhaps base this on int - stupid monsters might pick up everything)
- Add different dragon scales, in which different types of armor could be made
  from.
- Add random terrain type square.  Idea being you might make something a 
  random tree, and when the map is loaded, it chooses a tree random.  This
  would allow some variation in maps each time with possibly keeping the bulk
  of it the same (Depending how extensively the random trees are used.
- Allow transportation objects (ie, horses, carts, dragon, griffins, boats,
  etc.)  Flying objects should probably ignore line of sight for most
  objects (you are above the forest or mountains, but then fog should still
  affect things).  To do this, a terrain type value probably needs to be added,
  and this acts a bitmask.  Thus, transports compare bitmasks to see if
  travel through that is allowed.
- Make an object type/subtype setup.  Thus, the object type might be a
  monsters, with a subtype as grimreaper.  Or type equipment, with subtypes
  of armor, weapon, boots, etc. This probably would clean up things a bit,
  and make more logical sense.  However, this is a major change and would
  require a bit of work.
  Related to this:  Make access of object attributes through macros/inline
  functions instead of direct referance.  In this way, the code can actually
  request things by what they are used for (ie, instead of requesting hp and
  sp in maps for destinatins, you would request dest_x and dest_y, and the
  the macros would know those are actually sp & hp).  This also makes it 
  easy to change overloading of some values to actually use differente elements
  or add new elements to the structure.
  Secondly related:  Make better handling for identified & non identified
  item properties (ie, face, value, name, etc)
- Allow monsters to be randomly generated on a map without generators (ie,
  orcs show up in forests or whatever.)  Uses this as an option to use instead
  of the existing random encounter code.
- Have monsters potentially attack others if they are damaged by a friend.
  It looks like the code should already allow this, but I think the problem is
  that monster reevaluate their objectives too often, and which time they
  switch back to attacking the player.
- Add a confirmation setting for the dm command so that the password doesn't
  appear as plaintext.
- Allow treasure lists to be specified as part of the objects message
- Perhaps print out a message shortly before a spell effect is about to end.
- Rewrite all variables, using own typedefs of type:
  [us]int8, [us]int16, [us]int32    : Variables that should be at least that
	size (is there actually anything that needs to be precisely some size?)
	These typedefs can be set depending on system type.
- Related to above:  In communication remains the same (keyword matches),
  highlite the keywords or in some way make them more noticable so players
  can know to use them.  This is no worse than many commercial games which
  give you just a few choices to choose from to continue a conversation.
- Statues turning into golems when activated (like doors).
- IDEA: Make spells be objects.  One object for each spell you know.  Same
  system for the monsters.  For now let the objects be invisible.
  Then later create a spellbook into which the spells can be "put".
  Thus knowing a spell consists of having the spell-object in some
  spellbook.  With this, more properties of the spell (level, cost, etc)
  from the current array to the spell object.  Alternatively, spellbooks
  have the spell objects that are then put in the players inventory when
  the spell is learnt.  scrolls, wands, potions would just be objects with
  some spell object as an inventory.
  As a further extension, make general spell casting code, which can look
  at the spell object and come up with effects.  For example, right now
  the cones could be pretty generalized - all that is really different
  is the attack form (could be determined by attack type), area of effect
  (some other value in the object), damage, spell cast, level, etc.  In
  other words, the spell objects could pretty much provide all the information
  needed for some of the more general functions (cast cone, fire_bolt, etc.)
- Figurine (when a figurine pet dies, it becomes a figurine, and can be reused)
- Make some general variable structures, try to get rid of the current
  mess where some variables are used for other things than they
  were meant to (union won't do either).

- Ability to aim at targets not in the front row.  This should apply for
  most range attacks (thus, in a group of orcs, the ones not immediately
  around the player could still use missile weapons.)

- Ability to rename objects in your inventory.  Best way would probably be
  to just add another pointer to the object that points to the desired name.
  That name is only used when in the inventory, other name is still used
  for other purposes.  When object is dropped, remove that name tag.  This
  could be a client issue, but something more would need to be added to 
  preserve the names accross runs.

Secondary features:

These are more features (low priority at that) to be added.  Some of these
may be related to items above, or they may be things that just would not
add a lot to the game (IMO).

- Flag so that there is a random chance that an object will or will not appear
  on a map (this is perhaps better handled by treasurelists.  Unfortunately,
  treasurelists can not be set in the maps).
- Ability to have pixmaps set in maps or otherwise be able to load images
  without having to rebuild the default images.

