[UMC] More (not full) Deterministic Luck
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
[UMC] More (not full) Deterministic Luck
I've read following two threads:
1st has the problem of being too deterministic. You can »save up« luck on a unit or %-evasion class for the more important attacks such as a leader or last-hit.
2nd has the problem of poisoning or slowing not being defined. it uses the default system.
I've also read the topic in which developers explain why they don't want a fully-deterministic game. The main argument against it is save-loading.
(( http://forums.wesnoth.org/viewtopic.php?t=21317 ))
I want to share a third approach:
If somebody thinks a player could manage to keep track of all these values to his own advantage, please suggest a better solution for the WHEN-issue.
- http://forums.wesnoth.org/viewtopic.php?t=40729
- Gentle approach to removing random
Author: @optimother
- Gentle approach to removing random
- http://forums.wesnoth.org/viewtopic.php?t=40947
- Biased Random Damage Mod
Author: @Crow_T
- Biased Random Damage Mod
1st has the problem of being too deterministic. You can »save up« luck on a unit or %-evasion class for the more important attacks such as a leader or last-hit.
2nd has the problem of poisoning or slowing not being defined. it uses the default system.
I've also read the topic in which developers explain why they don't want a fully-deterministic game. The main argument against it is save-loading.
(( http://forums.wesnoth.org/viewtopic.php?t=21317 ))
- My answer: I would be happier with random chances ((+- 10% for the strikes)) and the system explained below.
It is easier to remember the occasions when 3 units after each other, each elvish champions/heroes with 4-5 hits miss, just to die to the counter-attacks which always hit ((especially from orcish warriors)).
I don't mind 1 random unit per turn having luck and another having no luck (per side). But 2 enemies which are lucky and 3 allies which are not are an experience users should be saved from.
Especially when the individuals represent a platoon, occupying a whole hex at the size of a village.
I want to share a third approach:
- Count together the % of hit chances.
- Let the unit hit once per full 100%
- Let the unit miss 1 hit for each (full) missing 100%
- There may be 10..90% left, neither full for a hit or full for a miss.
- Each target starts with 50% luck.
- If 10 damage is inflicted to a 50 hp unit with 40% probability, it's 4 damage or 12.5% of the unit's hit-points (the luck that is added or subtracted from the bias).
- If luck is below 0% it always hits, if it is above 100%, it always misses.
- If it is between 0% and 100% (50% is default or after the unit was out of combat) it remains completely random.
- But if the strike misses, the target's luck will decrease by 12.5% (after the check for miss/hit), else it will increase by that amount.
- Whenever a unit's health is restored beyond it's maximum (or gradually after not fighting for the last 2 turns), the luck may restore itself back to 50%.
- 2 turns (( without fighting! )) should be enough to catch or lose track of a unit if not finish it or being stopped by enemy interceptors..
- that there is still a randomness involved (( maximum 1 streak in 2 turns )).
- That the luck is placed on the target, not the attacker.
- It is 1 single value, not 1 per evasion % of different terrain types.
- No problem to determinate wether poison or slow should take effect.
- No problem that rounding down values after resistances creates a bigger difference because of a lower resolution of the possible final damage-values table.
- Simplified example:
0=miss
1=hit
0011: worst case; luck++ by 50%
0101: second worst case; luck++ by 25%
0110: average case; luck== unchanged.
1001: another average case; luck== unchanged
1010: second best case; luck-- by 25%
1100: best case; luck-- by 50%
If somebody thinks a player could manage to keep track of all these values to his own advantage, please suggest a better solution for the WHEN-issue.