With the current skill system, players often have to do a lot of micro-management with skills. It was already the case in the old system. A skill at 80% progression to next level was a prime candidate for victory dancing, because all the XP invested in it won't do any good until it actually levels up. The new system has exacerbated the problem by giving more control. I think there's about 3 ways to play the game:

• Casual. Play in auto mode and only visit the skill screen for strategic adjustments. The result is that you constantly have a lot of idle XP lingering between skill levels and not actually doing anything.
• Optimal. Train skills one at a time. On each level up, you check your stats and/or spell success. If the desired effect is obtained, go to the skill screen and train another skill.
• In between. Either in auto mode, or manual mode with 2 or 3 skills. Might want to check from time to time if one skill is getting closer to levelling up in which case others are deactivated to make it level up faster.

The new training system was just implemented in trunk, and hasn't even had the kinks worked out yet. It seems rather early to say that there's definitely a problem at all. At the moment auto mode is less useful than micromanagement, but it's still on its very first publicly visible design iteration so we can reasonably expect it to get substantially better after there's been more time for testing, brainstorming, and updating.
The proposed change is furthermore an enormous project that will affect almost every part of the game. Is it really wise to start planning a core re-write based on experience of a change only a few days old in trunk? — KoboldLord 2011-07-23 06:36

Let's fuzz out the artificial step which is skill level. Make skill progress continuous. The XP invested is immediately useful. You go to the skill screen only to make strategic adjustment, not to babysit your skills and skill levels. The casual way of playing is no longer suboptimal. Optimal play is less tedious as you can train 2 or 3 skills at the same time without losing anything.

Training 2 or 3 skills at once is usually preferable to training all of them at least in part because there are many situations where a small, targeted increase in a particular skill has wildly disproportionate effect compared to all available alternatives. Take charms skill for example. Gaining a couple levels of charms to make Swiftness usable is vastly more useful than gaining the same couple levels of dodging for a single point of EV, for instance. Charms then has a large dead zone where it gives nearly no rewards at all, and then you start approaching Haste and charms is suddenly more valuable than everything else combined again. Spending as little time in this dead zone as possible is always going to be desirable, regardless of whether you get benefits continuously along the curve or at discrete levels. — KoboldLord 2011-07-23 06:58

If I'm not mistaken, the point of this is not to make it undesirable to train only a few skills at a time; it's to reduce instances of the following phenomenon: I have 10 Axes skill and 10 Spellcasting skill. I want both of these, so I'll turn off one until the other gets to 11, because having one skill at 11 and the other at 10 is always better than having two skills at 10.5, when the increase won't have an effect until the next whole number. — Danei 2011-10-02 15:30

I think with this system we can just remove the skill progress. You don't need to know if you're at 7.3 or 7.8, this is irrelevant detail. We just make it a continuous scale with a discrete display like everything else in the game.
However, showing a decimal has the advantage of immediately conveying to the player that partial skill levels have an effect. So if more precision than a skill level is needed we can add a single decimal, but I don't think it will be necessary.

A single decimal will pressure players to train one skill at a time even more than the current system does: it will be the only way you can keep track of where your skills actually are. In your proposal, you can't see at a glance whether a skill is 7.3 or 7.8. The result is that you should train one skill at a time, and turn it off as soon as it hits a 7.0, because the only way you can tell it's at 7.0 is to disable it as soon as it hits 7. — minmay 2011-07-23 03:22

And why do you need to know at which point you are between 7 and 8? If you have the information, how do you use it? Can name a single tactical or strategical decision that would be influenced by having that level of precision? If not, then it is irrelevant detail. — galehar 2011-07-23 09:26

And why would a new player know that it's an irrelevant detail? — minmay 2011-08-21 20:31

Seems a bit weird that a skill which is at 7.9 would display as 7. There's not much of a difference between 7.9 and 8.0 if I'm understanding your proposal correctly. An observant player (at least when it comes to some skills) would be able to tell the skill is closer to 8 than 7, simply from how it behaves. I should also add that it will still be important to raise certain skills to certain levels, as before… particularly with weapon skills and reaching minimum delay (you have proposed changing how weapon delay works as well, but which would be changed first?) — evilmike 2011-07-23 06:18

You could say the same of a spell at 94% success and one at 95% success. There's not much difference, yet one is at great, the other at excellent. That's what happen when you apply a discrete display on a continuous scale and it doesn't create any problem I'm aware of. And yes, you still have to train skills up to a certain level and the point where weapon reaches minimum delay doesn't change, it just gets there more smoothly. You still manage your skills, you just don't micro-manage skill levels. — galehar 2011-07-23 09:26

Seeing skill progress is hardly an irrelevant detail. Many skill increases don't have any immediately obvious effects, so that percentage ticking upwards is literally the only feedback a casual player gets until they actually level up the skill that shows that they are still making progress. Essentially, it's a progress bar. Watching the numbers tick up allows the player to intuit the connection between their actions and their progress. Without this feedback, there is less sense of progress. Killing monsters without feeling a satisfactory sense of progress is 'grinding'. — KoboldLord 2011-07-23 06:49

I believe it's better to give this sense of progress by putting the percentage of progress to next XL right on the main screen. I actually did that already, but it's only in trunk, not in 0.9 beta (will fix it). — galehar 2011-07-23 09:26

you.skill takes a scale argument (default 1). If you're at L7 with 89% progression to L8, you.skill(sk) returns 7 (as now), you.skill(sk, 10) returns 78 and you.skill(sk, 100) returns 789. We can use higher precision if needed, but 100 is probably enough for most cases. Many formulas will have to be scaled to accommodate the new precision. When it's not possible, randomization is used. For example, if your armour skill gives you an AC of 5.67, you roll random2(567) and div_rand_round the result by 100 to get the damage reduction.
Most skill effects can be easily scaled like that, a few ones are more tricky.

The MP formula can use the scaled value of spellcasting and XL (same with fighting and HP by the way). So your MP and HP will gradually increase one point at a time while your skills and XL progress. For spell slots we can use:
(you.xl(100) + 2 * you.skill(SK_SPELLCASTING, 100)) / 100
You gain the slots one at a time and you've got a new message to warn you when you gain one if it's relevant (have spellcasting, not a Be, can learn a spell you couldn't before).

With a reduction of 1 every 2 levels (5 for UC), this is the worst offender of the new system. But this can be addressed. We need to increase BASELINE_DELAY from 10 to 100 to do so. It might seem extreme, but it's possible and has additional benefits. And obviously, changes to the time system are needed if we want to make the more precise attack delay relevant.

I think the time system also has steps too big. Currently, we randomize monster speed, by randomly giving +1, and players end up pillar dancing hobgoblins. For player movement speed it's even worse since we only use half the scale for some reason. Increasing BASELINE_DELAY opens many doors, and I'm not going to explore them all since this page is about skills. So what are the most obvious change to make if we have a more precise time system?

This isn't actually necessary. We can implement skill fuzzing by just using div_rand_round to calculate weapon delay. — galehar 2011-09-18 18:18

Each turn, monsters have their speed change by random_range(-10, 10, 2), with a cap at -15 and +15 relative to their base speed. It's unpredictable and has some inertia.

I hope this doesn't mean bringing back the ability for normal speed monsters to get “double attacks”. This was the case in version 0.6 or around there, and it wasn't fun at all. It was dumb when you'd be fighting an ogre and it would suddenly get two attacks due to the speed randomization. At early points in the game, it would often mean being killed from full HP, almost as if the monster got a “critical hit”. Luckily, this “feature” only lasted one version, owing to its unpopularity.

Making monster speeds more random would also make the combat feel a bit too random, and less tactical. One of the good things about crawl is that it encourages tactical play, and one of the ways it does this is by letting you make a good assessment of the enemies you are fighting, and plan accordingly. Monster speed is one thing you cannot tell at a glance, though. Even when you're fighting them, it's hard to tell exactly how fast they're moving. Randomizing this would make it even harder. The problem here isn't so much that it's hard to adapt to fast monsters, but that it's hard to tell monsters are fast.

Instead of this, why not give mosnters the ability to move faster, in a way that is immediately visible to the player? I think a good example of this currently is alligators. They “put on a burst of speed” (cast swiftness) to charge at you. As far as I know, they're the only monster that does this, though.

I'm not proposing just giving swiftness to every monster. But I think it's a good example of how to deal with monster speeds. — evilmike 2011-07-23 06:03

This formula is just an example, it's possible that it brings more problem than it fixes. And yes, no double attacks from speed randomization, so maybe this doesn't even help with the added precision to attack delay. For that, maybe applying a random -5/+5 variation would be enough.
For movement speed randomization, I'd just like a less predictable system, and I believe the added precision can help with that. Also, bonus point if low power swiftness doesn't guarantee escaping normal speed monsters. — galehar 2011-07-23 09:26

The added precision allows use to scale swiftness with power. Speed bonus can range from 5 to 20 with a power cap at 80. With flight, the speed bonus can reach 40 with 160 spell power. if you also increase the level of the spells and/or reduce the duration, maybe we can balance them this way. It's worth a try.

There are a lot of things that are difficult to scale finely enough to avoid skill micromanagement. Some are relatively simple to change; for example, minimum attack delay can be changed to only be attainable with 27 skill, and Str/Dex on ranged weapons can decrease the minimum. Shield penalties can be changed to only go away completely at 27 skill. The skill requirements of Annihilations/Grand Grimoire/Necronomicon can be removed altogether. But some are seriously problematic: for example, people might train Conjurations/Fire just enough to get Flame Tongue to range 3, then turn them off, because the additional range is a very large benefit. Training Spellcasting for another spell level is a particularly big example. Here's a list off the top of my head:

• Spell ranges
• Spell slots
• Spell power caps
• Receiving a Sif Muna gift

Please don't respond with “these are too small to matter.” If that's the case, then the benefit of training skills one level at a time is also too small to matter, making fuzzing unnecessary altogether. — minmay 2011-08-21 20:31

Suggestion to outright state level fuzzing will be used in calculations; you infer it in the Spellcasting section. — XuaXua 2011-07-23 03:03

The change has been in trunk for a bit, and I can confidently say that it has made the situation worse. It is just as important as ever to train skills to specific levels, but now you can't see how close they are to those levels, and so you need to watch them very carefully to make sure you don't accidentally put extra experience into them. Maybe it would work if minimum delay, spell ranges, needing to train a skill to level 1 before interacting with it, etc. were removed. — minmay 2011-09-20 16:47

First, this isn't finished, we've just started testing it and we'll polish it. Now, what does minimum delay has to do with it? You'll still reach it on a skill level up, so it's completely off-topic. And so is unknown skill system (which might be changed, but off-topic anyway). Regarding spell range, what's the problem? You want to stop training immediately after reaching a certain range? I don't think it's worth shouting messages at the player each time a spell range change. You have a suggestion to make?

Minimum delay and variable spell ranges are examples of how you still want to train one skill at a time to a specific level, something this system was supposedly intended to eliminate - and it hasn't. Barring removing control of skill training entirely, the only way to get people to stop doing this is to remove the incentive for it. This would mean no attack delay reduction every two levels of weapon skill (otherwise you end up only training weapon skill for 2 levels of it at a time), no minimum delay before reaching level 27 (otherwise you turn off a weapon skill as soon as it reaches minimum delay). — minmay 2011-09-21 16:55

Why would you restrict yourself to training the skill 2 levels at a time? With the new system, if you gain 0.5 skill, your delay is lowered by 0.25. The floor for delay is still in, but it doesn't make an abrupt cliff. — KiloByte 2011-09-21 17:13

Oh, I didn't know attack delay reduction had been changed. So that's one thing taken care of, then. I listed some other examples above here. (Also, the system has now been changed to show decimal skill levels, so it's no longer worse than the old situation.) — minmay 2011-09-21 17:50

The main goal isn't to eliminate training some skills to a specific level. This would be nice, but this isn't addressed by this change at all. The goal is to remove the optimal strategy of training one skill at a time which was needed to avoid having wasted XP when several skills are between levels. Again, this is about removing skill micro-management (intra-level), not general skill management.

The examples I gave are specifically about intra-level micromanagement, such as training Spellcasting half a level at a time (since you get one spell level for each half). – minmay 2011-09-22 18:33