[ViewVC] Annotation of: cvs/deliantra/server/TODO

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.  Some of the things are put here just so my mailbox
doesn't overflow.

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

If a shop is placed in a random map (special map), the objects below the
shop wall stick around - normally not much a problem, unless it is placed
in a glory hole (treasure level), in which case coins are now beneath the wall.

Slaying is sloppy in that it uses strstr.  This, an item that has 'slaying
giant' (like holyword of mostrai) will kill ants.  strstr matching was most
likely added to support comma seperated slaying lists (slaying demon,undead).
However, the code should really insist on exact matching, and if necessary
break apart the comma seperated list.  Probably best to make something like a
'does_slay()' function which can be used all over the place (consistent
behaviour is a good thing).  If performance for this becomes an issue, making
a slaying a set of pointers could be done (char **slaying), and it gets filled
in at load time, and at save time, gets filled in the opposite direction.
However, from a simple basis, a check in does_slay() can be done to see if
slaying does contain a comma, and if not, just do simple strcmp, and only if
it does does extra work need to be done. MSW 2003-03-28


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

- Change code so that if a player kills another player, he gets no
  exp.  Perhaps also log number of times a player has killed another player
  so problematic player killers can be more easily tracked.  This should
  be pretty simple, but is mostly here because I want to re-write the
  kill_player for the new skill code, and that should clean things up
  up a bit to make this code easier to put in.

- Allow possibility of one players magic not harming another player (should
  probably be a flag/settings value) - given that most spells are large
  area of effect spells, this may make cooperative adventuring easier.
  However, this could be a little odd - if my friend it immune to my fireball,
  shouldn't I be immune to my fireball also?  But if that is allowed, you 
  now have the case people could cast fireballs on themselves and hit a 
  whole bunch of surrounding monsters.  Perhaps allow this no damage 
  attribute based on different spells, eg, it could be argued that for bolt
  spells you'd aim it so that it doesn't hit your friend, but that same
  claim can't be made for fireballs.  Or maybe add something like the 
  ability of spells to not take effect to some range, eg, 'cast lightning
  bolt range 6' or the like, in which case it goes 6 spaces before the
  lightning actually starts.

- Refine blocking of spaces - instead of 'blocks all or nothing', ability
  to block walking but not flying, block swimming (for future expansion
  of oceans).  Also, add different LOS blocking for differing conditions -
  if flying, jungles shouldn't block line of sight, but they still should
  if your walking.  Also, add seperate blocking (pass) for monsters and
  players, eg, block_monster and block_player.  What should probably be done
  is make this a bitmask or the like with multiple possiblities.  If the
  object doesn't have another bitmask set, object can't pass through.  For
  compatiblity reasons, no_pass should set all the new no_pass_.. bits.
  Note that these bits should also be extended for movement of more than
  just the player, eg, spells, diseases, etc.  Thus, you could have something
  like a 'no spell propogation' space - players could still cast spells on
  themselves, but range spells don't go anywhare.

- Ability for stores to set different prices for goods (eg, remote store
  charges more for the services it provides).

- dm command 'Follow' which lets him see what a player is doing, where he
  is going, etc.

- Further control on what players can do on maps/spaces.  For example,
  prohibit players from shouting, attacking others, issuing tell,
  etc.

- Change inscription - instead of looking at range field of the player,
  have the spell to be inscribed part of the inscription command, eg
  'inscribe scroll of identify'.

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

- Add armor quality, with armor being damaged as it is used.  Add repair
  shops to go with this.  Uncertain if people really like this idea or not
  Further notes from mailing list: 
  Item has current quality rating -  different items have different max
  ratings - magic would increase its rating.  ITem operates normally
  when it has 50%+ of its quality.  At less than 50%, item loses
  functionality in a limited fashion (eg, multiply quality percentage
  by two to determine effective abilities in terms of percentage.)
  Item max qualities should be in the same range for most all items, so
  that powerful items given to low level characters get dinged up just
  as fast as their normal items.
  Diminished effects would be handled in fix player.
  Cost to repair based on how damage item is (100 = half cost,
  0 = full cost).  Items can be repaired on pro-rated basis.  Repair
  anvils would need to get added.
  Items are damaged based on how much damage player takes - more
  damaging attacks have higher chance to do item damage.  Amount of
  damage done to items might depend somewhat on damage done to player.
  Acid attacks would be changed to use this same code - they just
  always damage items at a much higher rate.  Different ideas is that
  chance of item damage is fixed, but amount done is based on damage
  sustained.  Other idea is that chance of damage is based on
  real damage (percent, square root, other adjustments, perhaps
  ignoring low values), but damage is somewhat constant.
  Should probably be tunables in settings to determine amount of damage
  done to item, and how often item is damaged.

- 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?)
- Add adjustments to objects that adjusts chance of skill success.
  Eg, objects the player use may adjust the characters effective level in
  using a skill.  Likewise, objects/monsters could have resistances to
  certain skills (eg, skill_resist values).

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

- Change identification handling.  Possible idea is to have different levels
  of identification, with low level only showing basic information, and high
  level showing full detail.  Skill identification should basically use this,
  with the skill level determining actual level.  Depending on level of
  identification, different information may be revealed (value, face, 
  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.
- 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.
- If 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).
- Figurine (when a figurine pet dies, it becomes a figurine, and can be reused)

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

- Better sound support - instead of having hardcoded events for sounds (eg,
  button push, door open, etc), sounds should be tied to objects, with some
  number of sound events (eg, object active, object destroyed, object moved,
  objected attacked, repeat forever, random, etc).  Information about how far
  they can be heard (in spaces) should also be contained.  When a sound is
  played, then do a simple check to see nearby players, and if one is within
  potential range, then check for intervening objects (walls).  Walls would
  have some dampening effect, counting for more spaces (something behind a
  wall may sound 5 spaces further away.)
  Exactly how to store the sound information would need to be investigated -
  the cheapest in terms of memory would be something like how animations are
  done - have a global array of the sound information.  However, sound
  information would be tied pretty closely to object types (eg, if the sound
  info said its used for both apply and destroy, then if some other object
  used that same info, it'd also get that apply and destroy behaviour).  This
  is probably good enough - one could make individual sound information
  sequences for the individual parts if those were needed.

- Make the elevation of terrain adjust line of sight.  If on the tallest
  mountain, you would be able to see over neighboring mountains and not 
  get your view blocked.

- Change attacktype handling.  Currently, attacktypes are just bitmasks,
  so if a weapon does 'dam 30' it does 30 dam for all attacktypes it has
  set.
  The idea is to make an array of dam values for the attacktype, so
  you could have a weapon like 'phys 12, fire 6'.  This then gets adjusted by 
  appropriate resistances the creature has.
  For attacktypes that are effects (slow, paralyze, etc) dam should be the
  potency of the effect (number of ticks player is effected).
  If an item has multiple dam values set, then it would do damage from all
  the attacktypes (eg, a phys 10 fire 3 is something like a flameblade
  which does mostly physical and a little fire).

- Improve material code:
  1) Make material file more readable.  Mostly, make it one entry per
     line (no comma seperated lists), with values 0 by default, so only
     values that are different need to be entered.  Maybe make materials
     archtypes, and then use treasurelist type setup below?
  2) Remove random material selection from the material file and put it
     elsewhere - basically, more fined grained material control (silver daggers,
     but not silver axes for example).  Perhaps the idea of material
     type treasurelists?
  3) Remove material bitmask.  Instead, have a pointer to the actual materialtype
     struct, and determine basis on that (eg, this could burn up, etc).  If
     necessary, add some appropiates field to the material struct that
     denote those abilities.
  4) Suffix to be used for alternative image names and animation sequence
     for objects (eg, dagger.111.gold for example)
  5) Some way to denote that even though 'materialname' is set, that the loader
     should still do appropriate adjustements for the material.  Thus, if a
     person sets the material in the editor, the server will adjust the values
     appropriately.
  6) Allow for multiple materials in same object.  Trickier to do this.
  7) More hints for materials.  Eg, is it a notable material that should be
     included in the object name, or mundane?  Likewise, is it a type of material 
     that can be reconstituted (metals) or not (wood, stone, etc)

Improve exit/teleporter code.  With tiled maps, it is now desirable to move
   monsters between those maps, so exits should be able to move monsters.  Add
   bitmask/flag to exit to denote what it moves - players, monsters, or
   objects.

Add exp rewarder type object.  It's basic properties:
    1) amount of exp to reward the player (stats.exp)
    2) Skill to award the exp to (skill field)
    3) Flag to denote we should teach the player this skill if they don't
        have it (can_use_skill flag?)  In this way, rewarders could grant
        skills to the player.
    4) Different ways to be activated (walk on/fly on, as well as it being
        activated from something that 'pushes' it (aka, magic mouth, button,
        etc)).  In the case of another object activating it, the player
        would still need to be on the space the object is on.
    5) Use the 'slaying' field to denote that if the player has a force in
        his inventory by the same name, he doesn't get the reward, and if
        they don't have such a force, we add one to the player (so you can't
        get the same reward repeatedly).  Use something like 'value' or
        other field to denote how many ticks the force lasts for.  If value
        is zero, then force never expires
    6) Use nrof to denote how many times the reward works.  Eg, if nrof
        is 1, then once a player uses it, no one else can get that reward
        until the map resets.

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.

Revision:	1.1.1.1 (vendor branch)
Committed:	Fri Feb 3 07:11:14 2006 UTC (18 years, 3 months ago) by root
Branch:	UPSTREAM
CVS Tags:	LAST_C_VERSION, UPSTREAM_2006_03_15, UPSTREAM_2006_02_22, UPSTREAM_2006_02_03, difficulty_fix_merge_060810_2300
Branch point for:	difficulty_fix
Changes since 1.1:	+0 -0 lines
Log Message:	initial import
#	User	Rev	Content
1	root	1.1	Various bits, in no particular order. This is far from a complete list -
2			however it keeps growing as various problems are discovered that
3			don't have an easy fix. Some of the things are put here just so my mailbox
4			doesn't overflow.
5
6			------------------------------------------------------------------------------
7			Known Bugs:
8
9			These are things which don't work as expected, but are difficult enough to
10			fix that they get put here:
11
12			Make lighting not go through walls. Maybe move it to the 'set_wall'
13			function - hard to do so that it is still somewhat efficient yet the same
14			light source does not illuminate the same space multiple times.
15
16			If a shop is placed in a random map (special map), the objects below the
17			shop wall stick around - normally not much a problem, unless it is placed
18			in a glory hole (treasure level), in which case coins are now beneath the wall.
19
20			Slaying is sloppy in that it uses strstr. This, an item that has 'slaying
21			giant' (like holyword of mostrai) will kill ants. strstr matching was most
22			likely added to support comma seperated slaying lists (slaying demon,undead).
23			However, the code should really insist on exact matching, and if necessary
24			break apart the comma seperated list. Probably best to make something like a
25			'does_slay()' function which can be used all over the place (consistent
26			behaviour is a good thing). If performance for this becomes an issue, making
27			a slaying a set of pointers could be done (char **slaying), and it gets filled
28			in at load time, and at save time, gets filled in the opposite direction.
29			However, from a simple basis, a check in does_slay() can be done to see if
30			slaying does contain a comma, and if not, just do simple strcmp, and only if
31			it does does extra work need to be done. MSW 2003-03-28
32
33
34			------------------------------------------------------------------------------
35			Future feature requests
36
37			- Change code so that if a player kills another player, he gets no
38			exp. Perhaps also log number of times a player has killed another player
39			so problematic player killers can be more easily tracked. This should
40			be pretty simple, but is mostly here because I want to re-write the
41			kill_player for the new skill code, and that should clean things up
42			up a bit to make this code easier to put in.
43
44			- Allow possibility of one players magic not harming another player (should
45			probably be a flag/settings value) - given that most spells are large
46			area of effect spells, this may make cooperative adventuring easier.
47			However, this could be a little odd - if my friend it immune to my fireball,
48			shouldn't I be immune to my fireball also? But if that is allowed, you
49			now have the case people could cast fireballs on themselves and hit a
50			whole bunch of surrounding monsters. Perhaps allow this no damage
51			attribute based on different spells, eg, it could be argued that for bolt
52			spells you'd aim it so that it doesn't hit your friend, but that same
53			claim can't be made for fireballs. Or maybe add something like the
54			ability of spells to not take effect to some range, eg, 'cast lightning
55			bolt range 6' or the like, in which case it goes 6 spaces before the
56			lightning actually starts.
57
58			- Refine blocking of spaces - instead of 'blocks all or nothing', ability
59			to block walking but not flying, block swimming (for future expansion
60			of oceans). Also, add different LOS blocking for differing conditions -
61			if flying, jungles shouldn't block line of sight, but they still should
62			if your walking. Also, add seperate blocking (pass) for monsters and
63			players, eg, block_monster and block_player. What should probably be done
64			is make this a bitmask or the like with multiple possiblities. If the
65			object doesn't have another bitmask set, object can't pass through. For
66			compatiblity reasons, no_pass should set all the new no_pass_.. bits.
67			Note that these bits should also be extended for movement of more than
68			just the player, eg, spells, diseases, etc. Thus, you could have something
69			like a 'no spell propogation' space - players could still cast spells on
70			themselves, but range spells don't go anywhare.
71
72			- Ability for stores to set different prices for goods (eg, remote store
73			charges more for the services it provides).
74
75			- dm command 'Follow' which lets him see what a player is doing, where he
76			is going, etc.
77
78			- Further control on what players can do on maps/spaces. For example,
79			prohibit players from shouting, attacking others, issuing tell,
80			etc.
81
82			- Change inscription - instead of looking at range field of the player,
83			have the spell to be inscribed part of the inscription command, eg
84			'inscribe scroll of identify'.
85
86			- If player tries to login with same name/password as a character currently
87			active, drop the old connection and associate the player with the new
88			connection. Useful if connection is dropped but server hasn't detected
89			it yet.
90
91			- Generalize the code better - split between 'rules' and 'engine'. The engine
92			would be the aspect of loading/saving objects, dealing with maps, and
93			basic object support (exits, levers, etc - things useful for any working
94			system). The 'rules' would be the more general genre of the game -
95			a science fiction game would have a different set of rules than the
96			fantasy game. And even the same genre may have a different ruleset
97			(ie, adding new skills). This is sort of like the current server/common
98			split, but goes a bit more than that - the engine would be able to compile
99			into an executable with the addition of some basic stub functions,
100			but playing as such would really just amount to a ghost moving accross
101			a world which time is pretty much stopped (as monsters would be in the
102			rules side, and not engine).
103			- Changing the stat generation system - instead of roll based, give some
104			number of points. This makes it easier for players to choose what they
105			want to play - otherwise, I think some clients will be written that will
106			do this for the players in any case.
107			- Change draw_info so that server tells client what type of message it is
108			instead of the color. Client can then decide what color to draw it
109			or other special handling.
110			- Change code so that objects 'spill over' to other spaces if too many
111			get piled in one space.
112			- More/better maps. Add more quest maps or maps to take advantage of
113			newer features (ie, church maps for each god, maps for alchemy quests
114			or with rare ingredients, etc)
115			- Add some identifier for unique objects so that if the player that has
116			a unique objects quits the game, the object goes back into circulation.
117			- Add flag to make price of objects not affected by charisma or other
118			abilities. This should act like gems do right now (pay 1.03, receive
119			0.97). In this way, gems don't have to be hardcoded, and other items
120			could be similarly set. Nuggets should be added to this list - its possible
121			to make small amounts of money alchemy silver and then selling the nuggets.
122			- Add/change door handling - make them more real life - they stick around,
123			can be opened, closed, different keys for different doors, etc. This
124			sort of mimics the gate behaviour, except keys may need to open them, etc.
125
126			- Add armor quality, with armor being damaged as it is used. Add repair
127			shops to go with this. Uncertain if people really like this idea or not
128			Further notes from mailing list:
129			Item has current quality rating - different items have different max
130			ratings - magic would increase its rating. ITem operates normally
131			when it has 50%+ of its quality. At less than 50%, item loses
132			functionality in a limited fashion (eg, multiply quality percentage
133			by two to determine effective abilities in terms of percentage.)
134			Item max qualities should be in the same range for most all items, so
135			that powerful items given to low level characters get dinged up just
136			as fast as their normal items.
137			Diminished effects would be handled in fix player.
138			Cost to repair based on how damage item is (100 = half cost,
139			0 = full cost). Items can be repaired on pro-rated basis. Repair
140			anvils would need to get added.
141			Items are damaged based on how much damage player takes - more
142			damaging attacks have higher chance to do item damage. Amount of
143			damage done to items might depend somewhat on damage done to player.
144			Acid attacks would be changed to use this same code - they just
145			always damage items at a much higher rate. Different ideas is that
146			chance of item damage is fixed, but amount done is based on damage
147			sustained. Other idea is that chance of damage is based on
148			real damage (percent, square root, other adjustments, perhaps
149			ignoring low values), but damage is somewhat constant.
150			Should probably be tunables in settings to determine amount of damage
151			done to item, and how often item is damaged.
152
153			- Change players draining exp from others. Currently, there are problems
154			in that it not adjusted based on levels, so there are various abuses
155			draining from low level characters. Also, generally it is not possibled
156			to drain exp from monsters. Possible ideas:
157			- Change draining from other players to be a ratio of levels (ie, a level
158			10 character draining from level 5 only gets half the exp.
159			- Ability to drain exp from monsters (might make drain weapons more
160			useful). Maybe have monster lose some portion of the exp he would
161			award when drained, and try to adjust level/other stats downward as
162			it looses exp?
163			- Fix map loading/saving so it can do it over several ticks for smoother
164			performance (maybe thread it?)
165			- Add adjustments to objects that adjusts chance of skill success.
166			Eg, objects the player use may adjust the characters effective level in
167			using a skill. Likewise, objects/monsters could have resistances to
168			certain skills (eg, skill_resist values).
169
170			- Delete oldest swapped map in case the TMPDIR disk fills up while
171			swapping out a map. To do this, detection of error on save would need
172			to be done (presently, the fputs are done without return value checks.)
173
174			- Seperate weapon speed and real speed for players - one is used for attacking
175			only, and the other for movement only. Right now, a characters real speed
176			could become the weapon speed when they attack something.
177			Make speed more variable for some actions (limit how much can be picked up
178			at once, certain skills should take longer than others.)
179			- Make monster pick up more intelligent - only pick up items if they may be of
180			some use (perhaps base this on int - stupid monsters might pick up everything)
181			- Add different dragon scales, in which different types of armor could be made
182			from.
183			- Add random terrain type square. Idea being you might make something a
184			random tree, and when the map is loaded, it chooses a tree random. This
185			would allow some variation in maps each time with possibly keeping the bulk
186			of it the same (Depending how extensively the random trees are used.
187			- Allow transportation objects (ie, horses, carts, dragon, griffins, boats,
188			etc.) Flying objects should probably ignore line of sight for most
189			objects (you are above the forest or mountains, but then fog should still
190			affect things). To do this, a terrain type value probably needs to be added,
191			and this acts a bitmask. Thus, transports compare bitmasks to see if
192			travel through that is allowed.
193
194			- Change identification handling. Possible idea is to have different levels
195			of identification, with low level only showing basic information, and high
196			level showing full detail. Skill identification should basically use this,
197			with the skill level determining actual level. Depending on level of
198			identification, different information may be revealed (value, face,
199			name, etc).
200			- Allow monsters to be randomly generated on a map without generators (ie,
201			orcs show up in forests or whatever.) Uses this as an option to use instead
202			of the existing random encounter code.
203			- Have monsters potentially attack others if they are damaged by a friend.
204			It looks like the code should already allow this, but I think the problem is
205			that monster reevaluate their objectives too often, and which time they
206			switch back to attacking the player.
207			- Allow treasure lists to be specified as part of the objects message
208			- Perhaps print out a message shortly before a spell effect is about to end.
209			- Rewrite all variables, using own typedefs of type:
210			[us]int8, [us]int16, [us]int32 : Variables that should be at least that
211			size (is there actually anything that needs to be precisely some size?)
212			These typedefs can be set depending on system type.
213			- If communication remains the same (keyword matches),
214			highlite the keywords or in some way make them more noticable so players
215			can know to use them. This is no worse than many commercial games which
216			give you just a few choices to choose from to continue a conversation.
217			- Statues turning into golems when activated (like doors).
218			- Figurine (when a figurine pet dies, it becomes a figurine, and can be reused)
219
220			- Ability to aim at targets not in the front row. This should apply for
221			most range attacks (thus, in a group of orcs, the ones not immediately
222			around the player could still use missile weapons.)
223
224			- Better sound support - instead of having hardcoded events for sounds (eg,
225			button push, door open, etc), sounds should be tied to objects, with some
226			number of sound events (eg, object active, object destroyed, object moved,
227			objected attacked, repeat forever, random, etc). Information about how far
228			they can be heard (in spaces) should also be contained. When a sound is
229			played, then do a simple check to see nearby players, and if one is within
230			potential range, then check for intervening objects (walls). Walls would
231			have some dampening effect, counting for more spaces (something behind a
232			wall may sound 5 spaces further away.)
233			Exactly how to store the sound information would need to be investigated -
234			the cheapest in terms of memory would be something like how animations are
235			done - have a global array of the sound information. However, sound
236			information would be tied pretty closely to object types (eg, if the sound
237			info said its used for both apply and destroy, then if some other object
238			used that same info, it'd also get that apply and destroy behaviour). This
239			is probably good enough - one could make individual sound information
240			sequences for the individual parts if those were needed.
241
242			- Make the elevation of terrain adjust line of sight. If on the tallest
243			mountain, you would be able to see over neighboring mountains and not
244			get your view blocked.
245
246			- Change attacktype handling. Currently, attacktypes are just bitmasks,
247			so if a weapon does 'dam 30' it does 30 dam for all attacktypes it has
248			set.
249			The idea is to make an array of dam values for the attacktype, so
250			you could have a weapon like 'phys 12, fire 6'. This then gets adjusted by
251			appropriate resistances the creature has.
252			For attacktypes that are effects (slow, paralyze, etc) dam should be the
253			potency of the effect (number of ticks player is effected).
254			If an item has multiple dam values set, then it would do damage from all
255			the attacktypes (eg, a phys 10 fire 3 is something like a flameblade
256			which does mostly physical and a little fire).
257
258			- Improve material code:
259			1) Make material file more readable. Mostly, make it one entry per
260			line (no comma seperated lists), with values 0 by default, so only
261			values that are different need to be entered. Maybe make materials
262			archtypes, and then use treasurelist type setup below?
263			2) Remove random material selection from the material file and put it
264			elsewhere - basically, more fined grained material control (silver daggers,
265			but not silver axes for example). Perhaps the idea of material
266			type treasurelists?
267			3) Remove material bitmask. Instead, have a pointer to the actual materialtype
268			struct, and determine basis on that (eg, this could burn up, etc). If
269			necessary, add some appropiates field to the material struct that
270			denote those abilities.
271			4) Suffix to be used for alternative image names and animation sequence
272			for objects (eg, dagger.111.gold for example)
273			5) Some way to denote that even though 'materialname' is set, that the loader
274			should still do appropriate adjustements for the material. Thus, if a
275			person sets the material in the editor, the server will adjust the values
276			appropriately.
277			6) Allow for multiple materials in same object. Trickier to do this.
278			7) More hints for materials. Eg, is it a notable material that should be
279			included in the object name, or mundane? Likewise, is it a type of material
280			that can be reconstituted (metals) or not (wood, stone, etc)
281
282			Improve exit/teleporter code. With tiled maps, it is now desirable to move
283			monsters between those maps, so exits should be able to move monsters. Add
284			bitmask/flag to exit to denote what it moves - players, monsters, or
285			objects.
286
287			Add exp rewarder type object. It's basic properties:
288			1) amount of exp to reward the player (stats.exp)
289			2) Skill to award the exp to (skill field)
290			3) Flag to denote we should teach the player this skill if they don't
291			have it (can_use_skill flag?) In this way, rewarders could grant
292			skills to the player.
293			4) Different ways to be activated (walk on/fly on, as well as it being
294			activated from something that 'pushes' it (aka, magic mouth, button,
295			etc)). In the case of another object activating it, the player
296			would still need to be on the space the object is on.
297			5) Use the 'slaying' field to denote that if the player has a force in
298			his inventory by the same name, he doesn't get the reward, and if
299			they don't have such a force, we add one to the player (so you can't
300			get the same reward repeatedly). Use something like 'value' or
301			other field to denote how many ticks the force lasts for. If value
302			is zero, then force never expires
303			6) Use nrof to denote how many times the reward works. Eg, if nrof
304			is 1, then once a player uses it, no one else can get that reward
305			until the map resets.
306
307			Secondary features:
308
309			These are more features (low priority at that) to be added. Some of these
310			may be related to items above, or they may be things that just would not
311			add a lot to the game (IMO).
312
313			- Flag so that there is a random chance that an object will or will not appear
314			on a map (this is perhaps better handled by treasurelists. Unfortunately,
315			treasurelists can not be set in the maps).
316			- Ability to have pixmaps set in maps or otherwise be able to load images
317			without having to rebuild the default images.
318