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