[crossfire] Changes to swamp behaviour
Hello. I implemented the feature request #1539125 by Andreas Kirschbaum. Swamps will now be fatal even to players having the woodsman skill. This skill will only means you'll survive on the swamp longer :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Rebalancing, difficulty curve -- simple ideas
Raphaël Quinet wrote: The current exp_table (with its flaws) was obviously designed for the combat skills and for the total experience. But it does not work as well for the mental/craft skills. Awarding more exp points for using these skills successfully would not be a good solution because these should not contribute as much to the total exp. But on the other hand, it would be nice if it was possible to reach level 100+ in literacy or other skills. I think there is more an issue of just monsters - for the combat skills, you can basically find tougher and tougher monsters, that give lots more exp. For most of the mental skills, the complication of things gets cut off. Readables above level 10 are pretty darn rare. I'm not sure about find/detect traps, and the item identification skills are another issue all together. I don't think multiple exp tables is really the way to go. Why? Because I think you may really need 6-7 tables for things to be fair for all the skills. And given that the exp table is currently a config file that can be customized, having lots of tables one has to adjust would seem to be really complicated for servers. I do think the correct approach is this: 1) re-adjust exp rewards for non combat skills so that level can go up in a reasonable fashion. For readables, it could mean that 10 readables at your current skill level amounts to a level for example, for lockpick, 30 doors, etc. 2) Adjust the non combat skills so they contribute less exp to the total - that can be done right now - make it 20% or something. However, this second point can be an issue - lots of people say that it should be reasonable to play non combat characters. Overall level doesn't mean a whole bunch - it is just hp. A level 100 character with no combat skills will still fair poorly in battles ` ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Rebalancing, difficulty curve -- simple ideas
Wim Villerius wrote: The main problem i've observed when playing was that once you can kill a certain mob, you can continue killing it until you 'die' out of boredom. That means: hit - say - lvl 40 and start killing demon lords until you're lvl 110. A method that works perfectly. (and in case you get bored on demons, go dragons or angels, they work more or less the same) My suggestion is to adjust the amount of exp gained by killing a certain mob by at least hte following factors: 1) the number of that mob you have already killed 2) mob lvl / player lvl in that skill One problem here is that at higher levels specifically, the number of reasonable monsters go down. How many monsters are there really for characters at level 50+ to fight? If there are not a lot, you're effectively limiting exp gain because there is nothing left to kill. I'm not sure if that is a really good approach. There used to be code that would adjust exp based on creature level and player level. But that had several problems and was removed - notably it becomes really difficult to try to find correct exp values when you have many variables (exp table increases at some rate, amount you get for killing it at a different rate, etc). And then you start getting abuses, like I'll weaken it with my highest level skill, then kill it with a lower level skill to get more exp, etc. IMO, there are basically 2 ways to do this: 1) Make the exp table harder at higher levels - in this way, at level 60, you need to kill more of the creatures than at level 40 to gain a level. We don't need to further adjust that by level comparison - the exp table itself should be adjusted. 2) Make the exp table linear, make most monsters the same exp, but adjust reward based on level difference. The problem is that if a character, especially at lower levels, is able to kill a higher level creature, they get lots more exp (15/10 = 1.5 reward, where as 70/60 = 1.17 reward). With certain items/spells that are really effective against certain creatures, this means fast exp gain. It seems like the goal here is to make it so you have to kill more monsters at higher level. That is currently the case with the exp table, but it sounds like the exp table needs to be re-adjusted. This 1) stops players reaching demigod status fast - it will take them long, and a lot of different mobs as well. No more efficient TC-training 2) doesn't necessarily recuire a new exp curve 3) most important: makes sense. killing ants at lvl 110 should not give exp. that's rediculous :) Point #3 isn't much a point. Sure, the player gets some exp when killing an ant, but at level 100, probably needs to kill a million ants to gain a level - if he wants to do so, fine. I think one of the general problems is things like the training center and random dungeons (and even non random dungeons) where monsters are just stacked high. The fact players can basically find monsters to fight as fast as they can reasonable fight them is a bit of an issue. In the vast majority of games, that really isn't the case - there is some amount of exploring to do, etc. Even in nethack, which hack and slash, most rooms only had a single monster and only half a dozen rooms per level - you probably are spending as much time moving room to room as you are fighting. Recording number of kills of each monster the player does is interesting, if nothing else than for record keeping purposes. I think it was ularn which would provide stats of what you kill, as well as more info about the monster itself the more times you kill it. But as said, I'm not sure that adjusting exp is really the way to go. And the problem with all formulas is finding the right one. The current exp tables were not designed to be bad tables - the best table at the time was done. The same is true with formulas - while putting them out here sounds good, it may be after months of testing, we find the formula in fact isn't good (too easy/too hard). I'm most inclined to do exp table adjustments, because that is the easiest thing to adjust. If during play testing you find 'I got to level 28 way too easily - it should take 3 times longer', it is pretty clear that the exp table gets adjusted upwards accordingly by a factor of 3. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels
Note: this mail is a bit long. If you want just the summary, jump down to the Proposed solution below and read the last paragraphs. If you do not understand or if you disagree with this proposal, then maybe you should read the whole text. I would like to remove the option death_penalty_levels, which limits the number of levels that can be lost when a player dies. After analyzing the reason why this option was added, I am now convinced that it is the wrong fix for just one symptom of a deeper problem: the interaction between the exp_table and the death_penalty_percentage. Using this option hides a part of the real problem without fixing it. I would like to remove this option so that we can find a solution to the real problem. First, a bit of history: several years ago, crossfire had only about 20 levels (and no skills, but this does not matter much). The formula for the experience loss on death was added and the default percentage was set to 20% (this is now configurable: death_penalty_percentage). The experience table was revised a couple of times, with some attempts that were a bit more linear while others were more exponential. After a while, this table evolved to something similar to the first levels of table A: basically, reaching the second level required 1000 experience points and then each level required twice as many points as the previous one: a 100% increase per level. Due to the limited number of levels available in the game, gaining a level was a big thing that required several hours. On the other hand, losing 20% of that experience did not always imply losing a level because the relative increase between levels was about 100%. Later, the number of levels was greatly increased and eventually reached the 115 levels that we have today. Skills were also added in the meantime. After a few revisions, the experience table A was introduced: the lower levels require a 100% increase in exp points between levels, then the relative difference between levels gets smaller and smaller: above level 90, increasing the exp points by only 1% is sufficent to reach the next level. This flattening of the curve was introduced because near the higher levels, even a small relative increase of 1% represents a large amount of experience points. The consensus was that it was difficult to gain so much exp easily so it was better to use a curve that becomes almost linear near the high levels (except for levels above 110, for which a larger gap was introduced). But this created two problems: 1) Contrary to what was expected, it is not very difficult to gain a lot of exp near the high levels. Due to the availability of high level monsters and deep dungeons with a lot of monsters, the player can still collect points almost exponentially while the exp curve becomes almost linear. As a result, it takes less time to go from level 50 to level 100 than it takes to go from level 1 to level 15. 2) The death penalty was still 20% of the exp points (plus a stat loss). Because the ratio between levels was increasing only by about 1% near the high levels, losing 20% of the points meant losing a lot of levels: a level 100 player could drop down to level 85 by just dying once. A solution was found for the second problem: introduce a limit to the number of levels that can be lost at once. The default value of death_penalty_levels ensures that a dead player will not lose more than 3 levels. Although this seemed to be a good solution at that time, I am now convinced that it did more harm than good. This did not solve the first problem; on the contrary, it even made it worse. The option death_penalty_levels increased the gap between the high level players who would never lose more than 3 or 4% of their experience points while the low level players would still lose the full 20%. The real problem comes from the exp_table: the players can collect exp points almost exponentially even at relatively high levels. If this had been known when the curve was designed, it would have been better to keep the same ratio between successive levels instead of decreasing this ratio near the high levels. Then it would not have been necessary to introduce death_penalty_levels. For example, if the ratio between successive levels would be 10% (for low, medium and high levels), then a penalty of 20% would always represent about two levels. With a ratio of 30%, the penalty of 20% could never cause the loss of more than one level. This does not work with the current system, which uses a ratio of 100% for the lowest levels and 1% for the highest ones. Proposed solution: - Get rid of death_penalty_levels. This option hides the real problem instead of solving it. - Switch to a new experience table that uses a constant ratio between levels for most of the table. Yesterday, I mentioned that designing an experience table before having reliable measurements aobut how much time is really spent for levelling up
Re: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels
Raphaël Quinet wrote: snip But this created two problems: 1) Contrary to what was expected, it is not very difficult to gain a lot of exp near the high levels. Due to the availability of high level monsters and deep dungeons with a lot of monsters, the player can still collect points almost exponentially while the exp curve becomes almost linear. As a result, it takes less time to go from level 50 to level 100 than it takes to go from level 1 to level 15. One little note on this, I would say the levels 95-100 are fairly tricky actually (of course not as much as 100-115 of course), and that your statement might be a more accurate with level 50 to level 95, but yes, despite the nitpicks I agree with your point, I might even say level 40-95 might more accurate for the range that is too quick to gain levels in. 2) The death penalty was still 20% of the exp points (plus a stat loss). Because the ratio between levels was increasing only by about 1% near the high levels, losing 20% of the points meant losing a lot of levels: a level 100 player could drop down to level 85 by just dying once. Well, with both default and metalforge exp tables, the situation with that improves after level ~107, however yes, with the exception of that minor nitpick I would agree with assessment of the problem. snip Proposed solution: - Get rid of death_penalty_levels. This option hides the real problem instead of solving it. I'm personally more inclined to leave the death_penalty_levels option, but set it's default to unlimited, so server admins could do things such as make their server do something like a 1 level per death max if they wanted to. - Switch to a new experience table that uses a constant ratio between levels for most of the table. Yesterday, I mentioned that designing an experience table before having reliable measurements aobut how much time is really spent for levelling up was like putting the cart before the horses. But I have changed my mind since then. I am now convinced that instead of trying design the perfect experience table and adjust the curve according to how experience is gained in real games, it would be better to start by selecting a new curve that is based on a constant ratio for most of the table and then adjust the parameters of the game (exp given by some monsters) to this curve. This makes sense to me. We still need to measure how experience is gained. But this data will be used to increase or decrease the sources of exp points in the game in order to ensure that a reasonable amount of playing time is necessary for each level according to the new exp_table. Doing the opposite (trying to adjust the exp_table according to how exp is gained) will never solve the problems associated with player deaths and the differences between high- and low-level characters. Measuring exp gain gives me an interesting idea. It might be interesting to devise an algorithm to have the game adjust the exp given by monsters according to how easily players kill them, perhaps analyze how much different traits affect the exp, and automatically change how much exp such monsters would give. Perhaps too much effort/trouble than it's worth, but it's an interesting idea anyways, making the game self-balancing (within limits). Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Reminder: Vote: Crossfire source code control system.
Reminder that there is less than a week of voting left. For every vote I receive, I reply confirming I received the vote - if you've voted but not received a confirmation, send mail again, and if still don't get a confirmation, try to find my on irc. As any readers of the mailing list know, there has been much discussion on what source code control system should be used for crossfire (stick with CVS, or switch to something else, and if we do switch, what to switch to). This is your chance to vote. Ballot is below. Send these back to me ([EMAIL PROTECTED]) to reduce traffic on the mailing list. Voting ends ~September 8. I don't know precisely what time I will tabulate the ballots, and I'll include any I receive up to the the time I start tabulating. If you want to make sure your vote is in, send it before then. I'll then send out results, including what everyone voted for. Please use the ballot below and keep to that form, so it will be easier to process the data with scripts. One ballot per person. The exact method of tallying is yet to be decided - most precisely potential different weight based on peoples current usage. Hopefully, no matter what method is used, the votes will be sufficiently clear cut that there will not be any issues, but I can perhaps forsee some discussion after all the votes are in and tallied. To make things easier, please only include the ballot portion in the e-mail. Ballot Starts Here - Crossfire user names (irc, sourceforge accounts, other names you be be known as): Please check what best describes your use of the current source code control system (current system being the CVS repository): _ Frequent (average more than once a week) committer _ Infrequent committer (at least once a year, but less than 4/month) _ Read only access (keep server/client up to date, etc) _ Do not currently use CVS access Please rank in order of preference which system should be used, with 1 being the system you would most like to use, 5 being least desirable. If you select the other line, then rank 6 choices): _ BZR _ CVS _ Darcs _ Mercurial _ SVN _ Other (specify: ) - Ballot Ends Here - Sample ballot example (before anyone reads anything too much into the list of preferences below, I randomly generated those): Sample Ballot Starts Here Crossfire user names (irc, sourceforge accounts, other names you be be known as): Joe User, juser, bigjoe Please check what best describes your use of the current source code control system (current system being the CVS repository): _ Frequent (average more than once a week) committer X Infrequent committer (at least once a year, but less than 4/month) _ Read only access (keep server/client up to date, etc) _ Do not currently use CVS access Please rank in order of preference which system should be used, with 1 being the system you would most like to use, 5 being least desirable): 3 BZR 2 CVS 4 Darcs 5 Mercurial 1 SVN _ Other (specify: ) - Sample Ballot Ends Here - ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
