ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/deliantra/server/TODO
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

File Contents

# User Rev Content
1 root 1.3 requirements need to be dcoumented: json-sykc, safe:hole, gperf, glib
2 root 1.2
3 root 1.1 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