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

requirements need to be dcoumented: json-sykc, safe:hole, gperf, glib

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