requirements need to be dcoumented: json-sykc, safe:hole, gperf, glib, std::tr1 (::unoredred_map) 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.