1

**Programming / Problems and Pitfalls of Deterministic Combat**

« **on:**May 31, 2013, 04:47:45 PM »

I've recently spent some time thinking about how a good deterministic combat system should be set up. (Note that my definition of 'combat' also includes interactions that aren't necessarily combat, such as picking locks etc.) I'd like to share my thoughts, and discuss some particularly problematic points that I've come across. Most of this is related to an actual WIP implementation.

For a combat system, I'd say that there is a certain degree of complexity you can go into. The goal should be to keep it simple enough so that the player can actually predict the result of one turn of combat, but complex enough to not make it trivial. 1HP games are a particular offender in this area, as they don't actually have a combat system, so anything relating to combat (like skills, talents and equipment choices) that you would expect to be interesting is going to be extremely reduced and abstract. The other extreme would probably be

This is directly related to the previous point. I've never been a fan of complicated time systems. Things like +10% movement speed in

I feel that the most elegant time system is the chess-like - you always know how many squares the enemies can move and how many attacks they get, and barring OHKO situations you will always have a chance to react to your enemies' actions.

I can't think of a big deterministic CRPG/roguelike right now. So basically every mechanic we import from a non-deterministic system needs to be converted into a deterministic mechanic. One particular example I'd like to present here is the lock-picking problem.

In most games featuring this mechanic, your chance to pick a lock is based on your stats (say, dexterity and the lock-picking skill). So if you have a lower chance to pick a lock, it will take longer for you to open that door. Anyway, if you have the skill and thus the possibility to pick locks, even if your chance is only 1%, you will be able to do it with a finite number of attempts. However, in some situations (say, the player is poisoned or about to be attacked by enemies) this is not feasible and the player is forced to find another solution (or hope that fate smiles upon him, heh).

A naive port of this mechanic to a deterministic system would result in you being able to always pick locks below a certain difficulty level, and being completely unable to pick locks above that level. This results in completely different behavior than in a non-deterministic system.

One method for solving the lock-picking problem in a deterministic system would be to assign the lock a pseudo-HP bar. Every attempt reduces the pseudo-HP by a certain amount, allowing the player to predict when the door will be open but still consuming the time that the task would take in a non-deterministic system. Of course one can discuss whether this is an elegant solution or not. But it approximates the actual behavior of the lock-picking mechanic in non-deterministic systems much closer than the naive port outlined above.

This is just one problem, but it shows that one sometimes has to change a mechanic quite a bit to achieve a close approximation of behavior.

This is something I've run into personally just a few days ago. In almost every roguelike you have your basic beginner monster that is only a threat on level 1 or 2. Later on, they will have a hard time hitting you through your +5 chain mail, but there's still a realistic - albeit low - chance for them to hit and do some damage.

Imagine a deterministic combat system in which armor can reduce damage down to zero. Since the system is deterministic, and the damage enemies do more or less fixed, this completely trivializes all enemy types where damage <= armor reduction. In other words, those rats I throw at you on DLvl5 will be completely uninteresting because they don't even have a chance to pierce your armor.

Now imagine a deterministic combat system in which damage cannot be completely reduced to zero, but to some lowest possible amount which is x. In this case, even completely trivial enemies, like the rats above, can become incredibly dangerous if encountered in large numbers. A situation in which the player is surrounded by, say, 8 rats leads to a loss of 8*x HP every turn (not considering the effect of killing some of them), which may or may not be a lot of damage. The only way to make a couple of rats not hit harder than your average troll is to scale up damage considerably. But this in turn leads to situations like in

I haven't really found a good solution for this problem yet, and would appreciate ideas.

One of my favorite decisions in non-deterministic combat systems is choosing whether to equip the longsword(3d4) or the glaive(1d12). (I just made those up, they are not from any game). The longsword, in this example, does more damage in average, but the glaive has a much higher chance of doing its maximum damage, possibly finishing off a low-HP enemy in one attack.

This differentiation is completely lost if you switch to a deterministic system. Barring damage types, there can be only one best weapon, and that is the one that does the most damage. So unless you assume a bash/slash/pierce damage system (which of course leads to the golf bag problem), it's hard to differentiate, say, an axe from a sword. For a game that aims to have a high variety of items, that's bad news. And I still haven't really found a way around this.

I kind of like Rogue. It's just the right mix of normal enemies (that require just physical strength and good equipment to beat) and puzzle enemies (that require some specific setup of items and/or tactics to defeat). What I can't stand are games that are too puzzly. We are still roguelike players, not puzzle-game players. Of course there is some interest in puzzles to present a tactical challenge to the player, but this should not be the entire point of the game.

In deterministic roguelikes there is often this tendency to go overboard with the tactical challenges, turning the whole level into 'something that needs to be solved'. This moves focus away from things a dev can spend a very long time working on and putting a lot of love into - clever and beautiful procedural content generation, interesting theme and immersive setting, emergent narrative...

I guess I just don't want deterministic roguelikes to end up being variants of Aaron Steed's

**1) Keeping the system understandable**For a combat system, I'd say that there is a certain degree of complexity you can go into. The goal should be to keep it simple enough so that the player can actually predict the result of one turn of combat, but complex enough to not make it trivial. 1HP games are a particular offender in this area, as they don't actually have a combat system, so anything relating to combat (like skills, talents and equipment choices) that you would expect to be interesting is going to be extremely reduced and abstract. The other extreme would probably be

*ToME4*, where the entire game is basically one big awesome (semi-deterministic) combat system.**2) Providing a chance to react**This is directly related to the previous point. I've never been a fan of complicated time systems. Things like +10% movement speed in

*ToME4*are very hard to actually make intelligent use of, and even the better time systems, like the one in*Sil*, still require a certain amount of calculation just to find out who can move how many times next turn. One area where this is very apparent is the ghoul race in*ToME4*. The ghouls have a speed penalty of 20%, so every few turns the enemies get two turns. Since this is not only annoying (essentially turning a 2HKO into a 1HKO) but also hard to keep track of, the ghoul race is rarely used by normal players.I feel that the most elegant time system is the chess-like - you always know how many squares the enemies can move and how many attacks they get, and barring OHKO situations you will always have a chance to react to your enemies' actions.

**3) Approximating the intention of the non-deterministic interaction**I can't think of a big deterministic CRPG/roguelike right now. So basically every mechanic we import from a non-deterministic system needs to be converted into a deterministic mechanic. One particular example I'd like to present here is the lock-picking problem.

In most games featuring this mechanic, your chance to pick a lock is based on your stats (say, dexterity and the lock-picking skill). So if you have a lower chance to pick a lock, it will take longer for you to open that door. Anyway, if you have the skill and thus the possibility to pick locks, even if your chance is only 1%, you will be able to do it with a finite number of attempts. However, in some situations (say, the player is poisoned or about to be attacked by enemies) this is not feasible and the player is forced to find another solution (or hope that fate smiles upon him, heh).

A naive port of this mechanic to a deterministic system would result in you being able to always pick locks below a certain difficulty level, and being completely unable to pick locks above that level. This results in completely different behavior than in a non-deterministic system.

One method for solving the lock-picking problem in a deterministic system would be to assign the lock a pseudo-HP bar. Every attempt reduces the pseudo-HP by a certain amount, allowing the player to predict when the door will be open but still consuming the time that the task would take in a non-deterministic system. Of course one can discuss whether this is an elegant solution or not. But it approximates the actual behavior of the lock-picking mechanic in non-deterministic systems much closer than the naive port outlined above.

This is just one problem, but it shows that one sometimes has to change a mechanic quite a bit to achieve a close approximation of behavior.

**4) Granularity and the problem of the killer rat**This is something I've run into personally just a few days ago. In almost every roguelike you have your basic beginner monster that is only a threat on level 1 or 2. Later on, they will have a hard time hitting you through your +5 chain mail, but there's still a realistic - albeit low - chance for them to hit and do some damage.

Imagine a deterministic combat system in which armor can reduce damage down to zero. Since the system is deterministic, and the damage enemies do more or less fixed, this completely trivializes all enemy types where damage <= armor reduction. In other words, those rats I throw at you on DLvl5 will be completely uninteresting because they don't even have a chance to pierce your armor.

Now imagine a deterministic combat system in which damage cannot be completely reduced to zero, but to some lowest possible amount which is x. In this case, even completely trivial enemies, like the rats above, can become incredibly dangerous if encountered in large numbers. A situation in which the player is surrounded by, say, 8 rats leads to a loss of 8*x HP every turn (not considering the effect of killing some of them), which may or may not be a lot of damage. The only way to make a couple of rats not hit harder than your average troll is to scale up damage considerably. But this in turn leads to situations like in

*ToME4*. where the player can end up having several thousand HP, with enemies possibly having tens of thousands of HP. Which of course makes the system harder to understand and handle for a human player.I haven't really found a good solution for this problem yet, and would appreciate ideas.

**5) The missing distribution**One of my favorite decisions in non-deterministic combat systems is choosing whether to equip the longsword(3d4) or the glaive(1d12). (I just made those up, they are not from any game). The longsword, in this example, does more damage in average, but the glaive has a much higher chance of doing its maximum damage, possibly finishing off a low-HP enemy in one attack.

This differentiation is completely lost if you switch to a deterministic system. Barring damage types, there can be only one best weapon, and that is the one that does the most damage. So unless you assume a bash/slash/pierce damage system (which of course leads to the golf bag problem), it's hard to differentiate, say, an axe from a sword. For a game that aims to have a high variety of items, that's bad news. And I still haven't really found a way around this.

**6) Not making it too puzzly**I kind of like Rogue. It's just the right mix of normal enemies (that require just physical strength and good equipment to beat) and puzzle enemies (that require some specific setup of items and/or tactics to defeat). What I can't stand are games that are too puzzly. We are still roguelike players, not puzzle-game players. Of course there is some interest in puzzles to present a tactical challenge to the player, but this should not be the entire point of the game.

In deterministic roguelikes there is often this tendency to go overboard with the tactical challenges, turning the whole level into 'something that needs to be solved'. This moves focus away from things a dev can spend a very long time working on and putting a lot of love into - clever and beautiful procedural content generation, interesting theme and immersive setting, emergent narrative...

I guess I just don't want deterministic roguelikes to end up being variants of Aaron Steed's

*Ending*where the block things are orcs and trolls. (Not that*Ending*is a bad game, btw.)