Improve Player Accuracy Calculations

[Floodkiller]

Currently, to calculate player accuracy for both 0.19 and 0.20:
Start with 15
Add floor(dexterity/2)
Add random2(fighting*100+100)/100
If in wisp, fungus, pig, or non-vampire bat form, add random2(XL*100+100)/100
If not in one of the above forms, add random2(weaponskill*100+100)/100 (unarmed is a weapon skill)
If unarmed and not in one of the above forms, add 2. Add an additional 2 if you also have claws.
Add the weapon's enchantment.
Add the weapon's base accuracy.
Add all slaying.
Subtract 3 if starving, bloodless, or fainting. Yes, even as a ghoul.
Subtract armour to-hit penalty and shield to-hit penalty. I will trust you to figure these out yourselves as they are pretty simple.
Subtract 5 if under vertigo.
If you have the eyeballs mutation, add 2*[eyeballs level]+1.
Now set the result to random2(result).
Now subtract 5 if wearing inaccuracy.
Subtract 5 if missing an eye.
Subtract 5 if confused.
Subtract 6 if you cannot see the target.
Add 2+random2(8) (or 1+1d8) if you can see the target and it is backlit (corona, sticky flame, halo without umbra). Note that a haloed and umbraed monster is not considered backlit, but an umbraed and coronaed/sticky flamed monster is.
Subtract 2+random2(4) (or 1+1d4) if you can see the target and it is in an umbra and you do not have night vision.
If it is a melee attack and you are unarmed with confusing touch active, add random2(dexterity).
If it is a melee attack and you are unarmed and transformed, add random2(unarmed_hit_bonus) (you have these enumerated on the page already).
If it is a ranged attack made with portal projectile, add random2([Portal Projectile spell power when you last cast it]).
If it is a ranged attack and the defender has RMsl or DMsl, set the result to random2(result/[2 if deflect missiles, 1 if repel missiles]).

The result is your "to-hit". If this exceeds the monster's EV, that does not mean you will hit. See test_hit.

*color washed filter over a minotaur miserably failing to hit a quokka with a sword before giving up in frustration* "There has to be a better way!"

Seriously, this is awful and I wish I could go back to being ignorant about it. What is even the point of the first half if you are going to throw it all into a 1dResult - 1? This needs to be simplified at the very least (although improving it to make it meaningful or removing it almost entirely would be preferable).

[watertreatmentRL]

Yeah, there's something wrong with the way of thinking about numbers you see in crawl. What should happen when you define systems like this is you come up with some statistics and parameters - averages, variances, mins and maxes - you understand well and devise a way to turn those things you understand into formulas for damage, accuracy, whatever, uniformly. There are very nice ways to do this. Instead what seems to happen is you start by thinking about throwing dice like you do in dungeons and dragons, but then the results don't take into account all the things you want them to, so you add more dice or weird ways to roll dice, like the crawl classic 1d(1dN). Then at the end you're like, "What is all this? How do I know what I'm getting here statistically? Time for some Monte Carlo."

I remember reading at some point, probably dpeg said it, that the crawl 4.1 guy(s) was/were trying to redo crawl combat and this was an insurmountable challenge. Somehow, it was impossible reproduce the tactical feel of crawl combat with understandable formulas. Maybe the mistake is thinking in terms of formulas instead of picking a master formula up front and just plugging in the parameters that matter to you.

[advil]

I sort of agree that it should be redone, but as someone who undertook a similar (but much smaller/simpler) task with spell fail rates recently, I can tell you that it's really, really hard to do this kind of project well.

Factors that make it hard: (i) you have to to some degree understand what the current behavior is accomplishing if anything so you know how not to break it (across a lot of cases), (ii) lack of / inconsistent approaches to fixed point math, (iii) the fact that a lot of this code dates back to pre-dcss times so code archeology doesn't help with anything you might want to know, but what doesn't is more like an evolved system than anything designed, and (iv) the extreme complexity of testing the results. There's just no simple+easy solution to fixing all this stuff, even a tavern-style remove approach would have to deal with (iv) somehow.

Contributions are definitely welcome but I can also guess they would not be fast to merge, because of factor (iv).

[Speleothing]

I sort of agree that it should be redone, but as someone who undertook a similar (but much smaller/simpler) task with spell fail rates recently, I can tell you that it's really, really hard to do this kind of project well.

Factors that make it hard: (i) you have to to some degree understand what the current behavior is accomplishing if anything so you know how not to break it (across a lot of cases), (ii) lack of / inconsistent approaches to fixed point math, (iii) the fact that a lot of this code dates back to pre-dcss times so code archeology doesn't help with anything you might want to know, but what doesn't is more like an evolved system than anything designed, and (iv) the extreme complexity of testing the results. There's just no simple+easy solution to fixing all this stuff, even a tavern-style remove approach would have to deal with (iv) somehow.

Contributions are definitely welcome but I can also guess they would not be fast to merge, because of factor (iv).

Smash everything. 0.20 is looking to be a really shitty release anyway, so we might as well break save compatibility.

[Siegurt]

Something else to consider is "Easily understandable by a human" doesn't automatically translate to a better game.

A 3d shooter that calculates trajectories and speeds of projectiles and factors in things like target movement and windspeed might have a to-hit forumula that ends up being totally opaque to a human, that doesn't mean it's worse because of it.

In the case of crawl the question to ask is not "is the formula too opaque" but rather "Are there things that the formula does, that the game would be better off without" If the answer is "no" then a bunch of steps (which make perfect sense to a machine, after all) is fine, if there are things which are factored into 'to hit' that don't make sense, or just shouldn't be there, then by all means we should get rid of them.

[VeryAngryFelid]

Somehow, it was impossible reproduce the tactical feel of crawl combat with understandable formulas.

Is it really necessary for accuracy? I remember how I spent 19 attacks trying to kill a monster where fsim showed I was expected to kill it with just 2 attacks.
There are some nice games where you have N% chance to hit monster depending on your accuracy stat and monster evasion stat and they seem fine. You still can customize damage, especially since damage uses not that much easier formula than accuracy does in crawl.

[Shtopit]

Something else to consider is "Easily understandable by a human" doesn't automatically translate to a better game.

A 3d shooter that calculates trajectories and speeds of projectiles and factors in things like target movement and windspeed might have a to-hit forumula that ends up being totally opaque to a human, that doesn't mean it's worse because of it.

In the case of crawl the question to ask is not "is the formula too opaque" but rather "Are there things that the formula does, that the game would be better off without" If the answer is "no" then a bunch of steps (which make perfect sense to a machine, after all) is fine, if there are things which are factored into 'to hit' that don't make sense, or just shouldn't be there, then by all means we should get rid of them.

3D shooters give you much less freedom in building your character, though.

Crawl expects you to make choices. To make meaningful choices, however, you need to have some idea of what you are doing, and the game is occasionally very opaque. GDR is something of a secret. The fact that shields get less effective with each attack also isn't written anywhere, I think. Having to choose between e.g. Amulet of Air and a randart +4 slay, rF amulet is hard, if you don't know how inaccuracy or slay will affect your character. Same for a ring of slaying +3 or of +4 strength.

This is even more true because of Crawl's huge quantities of false positives and false negatives you get when experimenting: you sometimes have games in which you learn a spell at 30% failure, but your first 40 attempts at using it will have a 20% success rate. 40 attempts are a lot. If the little 30% weren't there, you would assume that your experimentation has been carried out and that that spell will need much more training, before you can expect a 30% failure rate.
Melee is just like that, with the difference that you don't get any reference about your current precision/damage rate.

Having a clearer idea of how stuff is calculated would help solve this problem. Option #2 (and, imho, the better option) is having, within the interface, a number describing your precision that takes everything into account - dex, slaying, amulets, might (I'm not clear if it really improves precision), armour, weapon and so on. And then a second number expressing your MDO (median damage output) for 10 auts, assuming you are hitting a dummy with 0 AC and 0 EV and 0 SH for 1000 auts with your current equipment. Spells also should have a number describing hit chance.

[watertreatmentRL]

1. "How do more human understandable game mechanics improve the game?" First, the design philosophy conveys a certain theoretical commitment to human understandable mechanics in its stance on spoilers. The fact is it is not easy to understand, for example, what umbra really does for you in terms of accuracy. The design philosophy says that's bad (and I agree). But it's not just about discoverability. Call it "good engineering practice" or whatever, the fact is having a system that has many moving parts that you don't really have an a priori understanding of just by looking at its parts constrains your ability to design around it. You don't want a Rube Goldberg machine when there's a nearly equivalent system you can plug in that is clean and easy to analyze.

2. "Hard to test/requires a lot of testing to replace..." The recent thread about smoothing the affect of magic skills on casting is instructive. You can turn complex formulas into data by tabulation, then do a regression to come up with something smoother or simpler that is substantially similar to the original. You don't really need to do a lot of playtesting for balance because you have rigorous methods of seeing how close you are to the original, you just need to test for bugs. The tabulation part is usually very achievable: Between exhaustive enumeration of possible values that go into a computation, judicious sampling, and separating independent probabilities, you can pretty much get any crawl calculation down to a manageable representative dataset.

[MainiacJoe]

Organisms have all sorts of suboptimal and misch-masched structures that result from a combination of incremental change and conservation of essential functions. Accuracy is an essential function of the Crawl engine that can't be monkeyed with too much, but it also must adapt to various changes in the environment as it changes (e.g. profane servitors come along in 0.10, and now it needs to be able to handle umbra). So really, the way accuracy is to exactly what we'd expect it to be. that doesn't mean it's a good thing, it's just the nature of an incrementally developed game.

[watertreatmentRL]

Here's the thing: The incremental way to change "take a set of parameters, throw a bunch of dice, do some math on them, and compare them" is throw another die, right? And that's basically what they did. The incremental approach to "we take a set of parameters, compute a probability, then compare it to a single random number" is come up with a formula that expresses the difference in that probability with or without umbra. My feeling is that a judicious programmer is going to come up with a more understandable rule following the latter process than the former.

[duvessa]

The idea that Crawl's current formulas are critical for balance is overblown and, at best, historically misinformed. Melee damage changes in pretty much every version - it wasn't that long ago that DCSS decided to literally double the effect of Str, and even the accuracy function in the OP has changed quite a bit over the years. See also the smoothing of the stepdown formula. Then there's the fact that weapon generation and base stats and spells and aptitudes etc. etc. change all the time. (daily reminder that spectral weapon is still allowed to exist)
Furthermore, a big part of the motivation to simplify these formulas is that doing so makes them much easier to balance. Nudging coefficients up and down is easier than coming up with new values for all 20 chance_breaks.
Regarding the to-hit vs. test-hit formula specifically, post-Lair monsters have almost universally bad EV and post-Lair players that use physical attacks have very high accuracy already, to the point that additional accuracy does almost nothing. The result is that the only place where changing this formula would really be sensitive is the early game. This means it's relatively easy to gather data about, and that you don't need to worry much about the high end of a new formula.
The existing one also doesn't produce an especially complicated distribution. The ultimate outcome is binary (you hit or you don't - unless you really care about when the "barely miss" message appears, I guess) so one has to wonder what exactly would be lost if you just did one dice roll in test_hit, instead of three dice rolls in test_hit and 4 to 8 in calc_to_hit.

All that said, this is certainly a lower priority than improving the interface and nerfing overpowered options.

[stickyfingers]

it wasn't that long ago that DCSS decided to literally double the

...damage output. Nobody noticed.

[duvessa]

I didn't play during meleebug, so I can't comment on how noticeable it was.

[Floodkiller]

I didn't play during meleebug, so I can't comment on how noticeable it was.

I had no clue in game, but my turncounts for wins were much lower than they should have been for autoexploring and clearing ever level with the combos/gods I was using. I would never have noticed if it wasn't announced.

[Hurkyl]

I didn't play during meleebug, so I can't comment on how noticeable it was.

Myself, I hadn't played crawl in some time when I played during melee bug, so it was easy to explain away that I was simply misremembering the lack of effectiveness of short blade damage. (and also misremembering the level of stabbing needed to kill various things)

[Siegurt]

it wasn't that long ago that DCSS decided to literally double the

...damage output. Nobody noticed.

I played exactly one game during this period, I realized that *something* was weird/wrong, things died way too easily. By the time I went to the forums to talk about it, it had already been reported/discussed/fixed, and I said "Oh, yes, that fits with why everything was easily crushed into a paste" -- Saying nobody noticed is inaccurate, someone noticed, and therefore it got fixed, if literally nobody had noticed, it would not have been fixed.