
General outline of future versions:

0.94.0: complete client/server implementation (done)
0.94.x: Various refinements/fixes for the cs stuff above.
0.95.0: Remove all X11 dependant code - only client/server play supported
	at that time.

0.99.0: Start refining crossfire to be stable and balanced for 1.0 release.
	This means the only changes here would likely to be bufixes, and not
	new features.
1.0: First true public release - fully stable, and very well balanced.

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.

- 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.
- 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?)
- When you try to load a map that you already have loaded, have crossedit
  raise the window of the original map.
- 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.)
- Have map tiling handled automatically by the code - this should make
  map designing easier and some spells work better.  Ideas for doing
  this:  Keep present map system pretty much the same.  Add some extensions
  so crossfire knows what directions, if any, there are other maps to
  be tiled in.  Replace functions like out_of_map, get_map_ob,
  insert_ob_in_map, et. al. to by multimap aware.  For example, if map
  coordinates of -2 -2 are given to out_of_map, it would check to see
  if due to tiling there is a map there.  If so, it claims it isn't out of
  the map.  Likewise, if insert_map_in_ob gets such coordinates, it 
  inserts the object in that map (and updates the op->map appropriately.)
  In some sense, the map becomes a hidden object.  In this scenario,
  if get_map_object or insert_ob_in_map gives coordinates outside the
  map, it would then load the map.  A member of last tick this map
  was referanced probably needs to be added (a player could be moving
  parallell to and edge, but we wouldnt' want that other map swapped out.)
  Advantage of this map idea is that for most all objects, this tiling
  should be invisbile to most objects - those spells, monsters, etc
  would freely move accross this tiling.
  Possible problems:  How to deal with multi space objects (both in
  terms of movement and actual placement).  I think movement might be
  OK (I am not sure there is any requirement that all of a monsters has
  to be on the same map).  However, for multi space objects (towns,
  forts, etc) placing them accross maps becomes more difficult because
  you need to be able to save a map with that setup.  A possible solution would
  be to break apart non living objects that span maps.  For monsters, it may
  be possible to just save this head (however, this will not work if the
  monster has treasure in other bodyparts.)
  
- 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.
- Look at getting better tools to split & merge the images.
- 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.
- Increase the outdoor scale, so travelling from one town to another is
  actually a real adventure.
- 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
- Set up config file that is read when the program is run that control
	many of the options presently in config.h - for ones that make
	sense (inventory icon, perhaps full ring descriptions), even let
	them be things players can set. (even let TMPDIR be set in the file)
- 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.
- Expand the features of parse_message():
  Support for state-variables in messages.
  Support for services (ie, receive item, give different item, or advice)
  Allow for automated movement (ie, guards could do patrols, etc).  Both
  relative direction and absolute coordinates should be supported.
- 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)
- maybe even make a simple interpreting programming language to be used by
  the objects. [object ob;ob=environment();set_speed(ob,3);sleep(30);
  set_speed(ob,default_speed(ob));destruct(this_object());]
  (sleep(30) is the easy part: speed_left=-1,speed=1/30.0)
- 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).

- Redo immunity/protection/vulnerable code to have varying levels (maybe
  -127 to 127).  Have an index table for each value to determine how much
  damage you would take.  Multiple protection spells increase the index
  value, and thus increase protection.  Very high protection level (100+)
  may equate to an immunity.  In order to prevent getting immunities from
  casting a lot of lower level spells, limit protection to something like 99
  unless the protection being added is above that (thus, 5 +20 protectin get
  you to 99, but 1 100 gets you 100.)  To do this would likely mean all the
  archetypes need to be set up (although immunity could be 100 protection for
  that attacktype, protection is 20 or something.)  Also, instead of listing
  protection numbers on items, a verbose listing is probably better (0-10
  might be minimal protection, 11-20 low protection, 31-40 good protection,
  etc.)

- 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.)

- Look into updating the map look at the end of each time.  Presently, when
  ever an object is inserted, it recalculates what the maps looks like on
  a particular space as well as properties.  However, for things like buttons,
  this function may be called several times (as well as if a bunch of objects
  is being inserted.)  Better method would be to add some flag stating if a
  space needs to be updated (ie, is stale), and if so, update it.  In fact,
  a lot of updates would not need to be done until it is needed (ie, who cares
  if a space out of the players view is out of date?)

- 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.

- Add a line or two in the window which will show some statuses of
  immunities, confusion, depletion, and other things which might be obvious
  to the character but are not conveniently displayed for the player.

- Handle multi space objects more efficiently in saved files.  The current
  problem is since multi space objects are saved last in the map, they can
  'bury' objects below them (ie, drop a sword on a shop, and when the map
  resets, the sword will now be below the shop.)  Best method might be
  to only save a monsters head when the map is saved (head contains all
  the needed information), and the rest of the monster can be inferred when
  loading the map.  For buildings, we probably jsut need to break apart the
  building into individual segments - main gain of it being 1 object is
  that updates to it affect all pieces.

- Allow more items to be merged (rings mostly).  This involves code
  changes (need to split the object), archetype changes (nrof=1),
  and potentially map changes.

- Ability to transfer a singular item directly from a container to the
  floor (definately a client issue)

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.

------------------------------------------------------------------------------
 Things that are client issues, or ones that will no longer apply if X11 code
is removed from the server:

- Use X-resources more extensively (colors, etc)
- Ability to save keybindings/preferances across characters (either done with
	X defaults or via client.  Note - client already lets you do this)
- When two players using pixmaps enters the game at the same time, the
  first player will be freezed while the pixmaps are loaded for the second.
  The other players won't notice anything though, so don't know if this is
  worth fixing.  (Shouldn't be noticable without debug option - this will not
  be an issue with the client)
- make a client/server system (tcp/ip) - work has been started, still some
	stuff that needs to be done.
- made pickup command more intelligent - you should be able to use
     words or more generic terms for things you want to pickup up.
- better inventory handling - ability to hide items from normal inventory view,
  or perhaps allow some user defined settings for showing inventory (maybe
  via keywords.)

 Things that should perhaps be removed - my comments are included.

- make (more) DOCS! (or even keep the present docs up to date) - I think the
  docs are reasonably good now - at least from a player perspective.  For
  map designers and progammers, things should be cleaned up some.
- A flag so that when an object burns it becomes other_arch (random chance?)
  (is there really much use for this)?
- Add a ring of warning/ spell of warning, which compares your level
  with the level of the most high-level monster on the current map. (is this
  really an accurate test?)
- Some of the older bullet walls don't work, but new ones are OK.  Need to
  find a map that has the old ones to track this down. (This may have
  been fixed on 0.93.1 with the object spellcasting fix)
- Clean up object structure, so dead objects (walls, floors, etc) don't use
  as much space (with the amount of memory in systems now days, I wonder how
  important this is - even if we do manage to reduce space usage to about
  half it is, that only amounts to a savings of about 1.5 megs if there are
  10,000 objects in use.)
