Problems and Pitfalls of Deterministic Combat

[XLambda]

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.

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.)

[miki151]

Do you mind explaining shortly why make a game deterministic in the first place? Sorry if it's been discussed before, it's a novelty for me

[XLambda]

Do you mind explaining shortly why make a game deterministic in the first place? Sorry if it's been discussed before, it's a novelty for me

Argh, other people can do this better than me, but here we go.

Non-deterministic combat comes from rolling dice in D&D. In that game, it's part of the fun. You know you need a 16 to hit that monster, and so it's fun to roll the dice and see what comes up.
In roguelike games you don't roll the dice on your own anymore. In fact you don't even see the rolls you make (with very few notable exceptions). There's no fun to be had there. So the real point of rolling is gone.

The other problem is that it tends to make games very random. Even if you play perfectly and get the right items, some bad combat rolls can really screw you up. Some folks dislike that, because it's unfair. You can't do anything about it. Especially in newer roguelikes people tend to dislike this kind of behavior.
In D&D, though, that's fine. The DM is the one who decides, and if he notices that you happen to have a streak of bad luck, that is really threatening you, he might do something about it. (Or not, as the case of a certain Eladrin shows. )

If you remove luck from the combat equation, the gameplay becomes more dependent on your equipment, your skills as a player and your ability to recognize critical situations before they happen. Which to some people is a good thing.

[miki151]

If you remove luck from the combat equation, the gameplay becomes more dependent on your equipment, your skills as a player and...

Let me finish that for you... becomes more boring  (sorry couldn't resist

If you fight in real life then one hit will miss, another will succeed. One may call it luck, another will say it's just physics. You may simulate real physics in a RL game, but it's much easier to rely on dice. I think that's why D&D uses them.

I used to play a lot of poker. That game has a lot of luck in it, but there are good players who can tame it and show profit. Coping with streaks of bad luck is a big part of the game. That's why I don't buy your argument. But if you think that determinism is best for your game then you should go for it, I'll be happy if you convince me to it

[XLambda]

If you remove luck from the combat equation, the gameplay becomes more dependent on your equipment, your skills as a player and...

Let me finish that for you... becomes more boring  (sorry couldn't resist

If you fight in real life then one hit will miss, another will succeed. One may call it luck, another will say it's just physics. You may simulate real physics in a RL game, but it's much easier to rely on dice. I think that's why D&D uses them.

I used to play a lot of poker. That game has a lot of luck in it, but there are good players who can tame it and show profit. Coping with streaks of bad luck is a big part of the game. That's why I don't buy your argument. But if you think that determinism is best for your game then you should go for it, I'll be happy if you convince me to it

Yeah, but games are not supposed to be realistic. They are supposed to be fun.

I don't say non-deterministic games are bad. But again, I am bad at explaining this. Here's a blogpost by Darren Grey which goes into it a bit more.

Also, deterministic does not need to mean boring. The blogpost I linked above in turn links to an article by Craig Stern (which you should also read) which says:

[...] Real-time games, as a general rule, have an easy time fostering mechanical unpredictability. Spatial navigation requires accuracy and timing; a real-time attack could miss or hit depending on a player’s physical input. The chance of making a mistake in the heat of the moment adds uncertainty, and thus tension.

Without this sort of real-time interaction, turn-based games must look elsewhere for their mechanical unpredictability. Many developers working on turn-based games mistakenly believe that unpredictability is necessarily bound up in randomness. Indeed, there is an assumption prevalent in the design community that any turn-based game without randomness will feel stale, predictable, devoid of tension.

This is a misapprehension, however. Randomness creates uncertainty, it is true, but so do other elements.[...]

But enough of this. The point of this thread is to discuss problems with deterministic systems, not defending their existence. If you are not convinced by my links we can continue this discussion in another thread.

[Quendus]

Here's a deterministic roguelike: http://forums.roguetemple.com/index.php?topic=2300.0

[miki151]

Sorry if I hijack your thread a little bit. So you're looking for some unpredictability, but without randomness. In other words, you want to substitute the RNG with more complicated (and possibly interesting) game mechanics. In case of combat, you might keep track of the creatures' balance, level fatigue, etc. This will only make sense if you give the player at least some hints about these parameters, otherwise it's just another RNG. Better enemy AI will also help here.

In case of lock picking, you will throw the baby out with the bathwater, IMO. I'm not a skilled thief and if you make me try to pick a lock, I will just stick it in, turn it and hope for the best. The outcome will be completely random to me (unpredictable is another word for random, isn't it?). I think you may safely use the RNG here without sacrificing any playability. Another possibility would be simulating lock mechanics, which could be interesting.

[Vanguard]

I have a big problem with excessively random combat, but that doesn't necessarily mean that going 100% deterministic is the right answer either.  There's something to be said for including randomness while minimizing its effect.  One method is to remove random missing while keeping random damage.  You know you'll do some damage on every turn, so you can plan ahead that much better, but you still need to be prepared for unexpected results.  Another method is to roll any random number twice, and use the average of the two for your final result.  That way it's still possible to hit for your minimum or maximum damage, but it becomes more likely for your attacks to get values near your average damage instead.

Completely deterministic systems are interesting in their own way, though.  It can be fun to come up with ways to apply nondeterministic rules in a deterministic system.  Like, in most roguelikes, dodging is a matter of random chance, but the same mechanic could be made to work in a deterministic game.  Let's say that the player and every enemy in the game have an "attacks per round" stat which determines how many times they get to try to attack every turn, and a dodge stat which determines how many times they can dodge in one turn.  If an enemy with 7 attacks per round attacks a player with 5 dodges per round, two of the hits connect.  You could institute a rule where at least one attack per round will always hit if you don't want an agile fighter to be completely invincible against slower enemies.

Imagine a deterministic combat system in which armor can reduce damage down to zero.
[...]
Now imagine a deterministic combat system in which damage cannot be completely reduced to zero, but to some lowest possible amount which is x.

There's a third option you've overlooked - you could omit damage reduction entirely.  If you still want to include armor, have it add to your HP directly.  It's a great way to make damage formulas and armor's effectiveness more intuitive.  More RPG developers should try it.

Really, though, I don't think this is a huge problem.  Plenty of roguelikes have negligible enemies, even if they don't hit for zero damage.  And assuming you do institute minimum damage, is it really be bad that being surrounded by eight rats is dangerous?  You seem interested in games that are heavily reliant on player skill.  Being surrounded on all sides is a mistake that could justify punishment, even if they are only low level enemies.

Even if you do go the route of damage escalation, it doesn't have to reach ToME's levels.  1 damage from rats, 20 damage from trolls, and 100 damage from the final boss still leaves all of the damage calculations low enough to easily figure out in your head.

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.

There are ways to solve this.  You could give, say, hammers a lot of damage all at once, and, give swords a damage over time effect which eventually outpaces hammers.  That would make swords preferable for hit and run tactics or drawn out fights against powerful enemies.  Hammers would be better at shutting weak enemies down in a hurry.  You could make weapons that damage an enemy's speed, defense, or attack power in exchange for weaker damage output.  You could make weapons that hit multiple targets.  You could make weapons that offer advantages in something other than direct combat, like the athames in Nethack. Weapons with counterattack effects.  Weapons that increase the user's speed or defense as well as their attack.  There are plenty of options.

[requerent]

1)

Firstly, 1-HP roguelikes can have combat systems. They can also be more complicated. Just because there is only 1-HP doesn't mean that there isn't a complex system in place. The sequence of moves and the situation in which a loss occurs isn't necessarily any different. 1-HP is more about how the feedback cycles work. For both styles, it's all about the sequence of salient decisions a player makes that result in victory or defeat. Losing HP as a form of mistake forgiveness hinders your ability to progress. In 1-HP, we can hinder the player in other ways- such as forcing the use of consumables or by putting them in a disadvantageous position relative, to, say, other enemies.

Secondly, check out Brogue. It has very straightforward and transparent 'bump combat' mechanics. The game tells you your odds (by looking at an enemy) and indicates to you how much damage you deal. The value here is that you're essentially given a range of risk to deal with. So long as you're always accounting for the bottom-line, you won't lose (but the price for winning isn't always consistent), however, you can roll the dice if you need to bet your luck against something.

https://sites.google.com/site/broguegame/

2)

Arbitrary timing systems are bad. Brogue is a good example of a timing system that is mostly not arbitrary. I advocate a powers of 2 system, whereby all time-costs are relative to each other. That way actions never get out of sync. The simplest example of the advantage here is that an enemy with an attack delay of 100 vs you with an attack delay of 150 will never appear to be getting a free 'hit' every other turn. This is bad because the player isn't always aware of when that 'extra' turn is going to be taken by the enemy.

3)

Like you say-- attack locks with lock-picking skill. That way success is a function of time. Now you just need to make time meaningful. Brogue, again, does this via nutrition. There is a finite amount of food produced in the dungeon. If you dawdle too long you die.

Alternatively- introduce consumables that provide a risk-reward scenario. Also, don't guarantee that things behind the door are necessarily good.


4)
Arbitrary scaling is something that I personally look down upon. As a property of your mechanics, why do you even need +5 gear to be in the game? Why not add new options, abilities, decisions for the player to make? You can also invert the meaningfulness of gear-- Plate Armor might be great against dragons but terrible against rats. Turn the game into a cost-benefit analysis instead of binary jumps in improvement. Emphasize decision-making instead of gear, stats or XP.

5)
Again, check out Brogue. Each weapon fulfills a different use-case or provides flavor/variety/novelty, however they are not distinct enough to warrant carrying around many different weapons. IE. A War Hammer attacks twice as slow but deals double damage. The sneak attack in brogue deals 3x damage. The opportunity cost of more tactical decisions is sometimes worth the clumped damage. We can make this even more meaningful by introducing other abilities that may converge in a meaningful way with our equipment.

Synergy, Opportunity Cost, and Options are what make things interesting.

6)
For every discrete challenge, the breadth and depth of potential solutions within the player's decision-tree more or less describes both how much of a puzzle the game is and how difficult it is. Whether it feels like a puzzle or not is a combination of novelty and the degree of information provided to the player. One 'solution' to the problem of feeling too puzzling is to make it so that puzzle solutions are 'ideal' but not necessary. Effectively using traps to defeat certain enemies or taking advantage of the map might speed things up, but not give the player more advantages apart from time and style points.

If a player doesn't have enough information to precisely calculate what the result of his actions are, then it won't feel deterministic. Also-- AI is another point of concern. AI can make erratic decisions if you design it that way. This will automatically make a game non-deterministic even if the combat system is.


Brogue is a game in which losing is entirely your fault. The dice-rolling under the hood is more of a way to buffer the difficulty in a forgiving way more-so than a punishing one. In this way-- losing IS deterministic, but winning isn't necessarily deterministic. That said-- Brogue is quite difficult.

[zasvid]

In my opinion the biggest pitfall is that deterministic combat can easily encourage exploring your decision tree to find a successful path through before doing anything in the game. If you couple that with serious consequences of failure (like permadeath), your game turns into a puzzlebook to solve with pen and paper and player performing the minimax algorithm (with pruning, hopefully)*.

This is something you have overlooked in your pitfall #6, I think. No matter what you as developer focus on, you'll probably get puzzles. Multiple-solution puzzles, but puzzles nonetheless. You'd have to put a lot of hidden information that is released to the player every turn (and digested automatically) and impossible to just make into spoilers (so probably randomised at the game's beginning) to encourage actually playing the game and not just thinking about it.

So, yeah, I second the recommendation to check out Brogue and ponder on it.

*though designing a computer game that encourages you to do something different than stare at the computer all the time might be a noble goal in and of itself.