| version 1.23 | | version 1.24 |
|---|
| | |
| Various bits, in no particular order. This is far from a complete list - | | This file is now obsolete. |
| 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. | | |
| | | |
| ------------------------------------------------------------------------------ | | Bugs and minor feature requests can be found on the sourceforge tracker: |
| Known Bugs: | | http://sourceforge.net/tracker/?group_id=13833 |
| | | |
| 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. | | |
| | | |
| | | More major features can be found the metalforge WIKI: |
| | | http://wiki.metalforge.net/doku.php/dev_todo_new |