Probability of dying on the next turn

[bel]

I am thinking of making a nice feature: probability of dying on the next turn.

Briefly: whenever you take an action, and there are monsters on screen, the game will calculate the probability that you would die after that action.

This is harder than it looks because a monster could torment you, and then some other monster could maul you to death. Or some monster could banish you etc. Also damage numbers in crawl combat are insane.

However, we can calculate a lower bound:

• Ignore torment, hexes, debuffs etc.
• Play out your action. (I think the game considers your action first, and only then the monsters get their turn?) For instance, if you cast a spell or swing an axe, you calculate the damage done on every monster. Do this 10000 times. In each scenario, there will be some subset of monsters still remain alive.
• For each scenario, calculate the total damage done by all alive monsters. This will include weapon damage and spell damage - modified by the chance of casting the particular spell instead of casting another spell, moving or meleeing. Do this calculation 10000 times.
• Check if total damage is more than your HP (for each 10000 trials). If yes, then increment a counter.
• Probability of death = counter / (10000 * 10000).

If the probability of your death on each successive action is p1, p2 etc. then the "total probability of you dying in the whole game" is [1 - (1 - p1) * (1 - p2) * ...]. We can get a lower bound on this number because p1, p2, ... are lower bounds on each turn.

I imagine that this lower bound could be fairly close to the actual probability. We could check, if we had a big enough sample.

[stormdragon]

What do you intend to do with the result of this calculation? Present it to the user? If so, where?

How often would you do this calculation? Monte Carlo is very expensive; for me there are a few seconds of delay between the request and result of an fsim. If this was done after every input in the game, the lag would be unbearable.

[bel]

I was thinking of displaying it to the user on each turn (and the cumulative chance at the end of the game).

It's definitely possible that the lag would be too much. However, we might not need to go the full fsim route. It is my impression that fsim is too "realistic". For instance, after an fsim fight with a caustic shrike, I'm usually covered in acid. I'm not really looking for a realistic "fight" scenario here, but just the damage numbers.

[pedritolo]

Instead of inferring the dist through a monte carlo, wouldn't it would be more useful to just know the worst case damage, which should be deterministic per monster.
Perhaps, in the actors queue, the order is irrelevant as long as you play out multiplicative damage effects (like tormentors) 1st, then play out the rest regardless of order. Maybe i'm missing something and it's more complicated than I thought.
In any case, it could indeed be a useful tool.

Edit: ah yes, status effects like corrosion, confuse, paralysis, will affect the order. Maybe even that can be accounted for?

[VeryAngryFelid]

The idea is good but technically impossible to implement I think. Monte carlo is too time-consuming, using max damage will result in permanent display of 100% chance to die on every floor of Depths, using "average" (every roll gets average value) damage is not great help because of damage spikes, using median damage requires serious math or monte carlo again.
We don't even display max damage for monster spells despite it was proposed a long time ago and is much easier to implement than OP.

[bel]

It's possible that monte carlo is too time consuming. The problem with directly calculating crawl damage distributions is that crawl damage formulae are insane. Just using max damage will not work.

[stormdragon]

Instead of inferring the dist through a monte carlo, wouldn't it would be more useful to just know the worst case damage, which should be deterministic per monster.

No. If all you know is the worst case damage, you can calculate whether or not it's possible to die, but you don't know the odds. For example, let's say a monster can do max 20 damage. The player might have 15 hp; if all we know is the worst case damage, all we can say is "yes, the player might die". The damage distribution needs to be taken into account in order to determine the odds of that monster doing 15 or more damage, and say "the player has x% chance of dying".

Since the damage and accuracy formulas are known, it is possible to calculate the odds of losing a certain amount of HP without Monte Carlo; that would allow this proposal to work without lag, and it would make fsim a lot faster. The trouble is, the algorithm would be huge, and might be hard to maintain.

[VeryAngryFelid]

Since the damage and accuracy formulas are known, it is possible to calculate the odds of losing a certain amount of HP without Monte Carlo; that would allow this proposal to work without lag, and it would make fsim a lot faster. The trouble is, the algorithm would be huge, and might be hard to maintain.

Not only that, there won't be any guarantee the calculations are initially correct or are still updated properly after any change to main code. We had double melee bug for several weeks (as far as I remember). Current fsim at least guarantees the calculations are the same as ones used by main game.

[sanka]

If anyone plans to do something like this then she should not implement max/average/min etc. functions separately for each expression.

Instead, write a new type representing distributions that implements all operations you need to build distributions (like sum, multiplication, etc.), and all operations you want to do with distributions: let you sample (roll the dice), and calculate the minimum, maximum, expected value, variance, etc. whatever you need. Then all you need is to implement these methods once, and instead of writing arithmetic expressions directly you specify the dice rolls with this new type.