(Major rewrite to be more specific)


I'm prototyping a turn-based battle system. The theme is survival in a despaired setting with conflicting interests:

  • 2 players, attacker and defender
  • each player starts with an army of 20+ characters to choose each battle's party from
  • 6--8 characters per battle party on a 3x3 grid (distance can be used for tactics and variation)
  • character death is permanent
  • combatants will likely die, and the scenario is short, so there's not much point in complex leveling systems; characters do not improve that much over the course of 1 game
  • I want to ignore equipment for now; imagine everyone's fighting naked

With ~6 characters, it's not that much of a problem if one dies during a battle. Two deaths should feel impactful. 4 deaths are serious.

If your party is wiped out, the battle ends and both start selecting combatants for the next fight until one army is wiped out.

How do you figure out numerical representations for stats and effects?

It puzzles me how I should start setting base HP, damage output, evasion rates, and the like.

Established pen & paper make no "sense" but work. Looking at AD&D3 rule books, for example, gives me a sense of security: the rules work well enough, and the success of playing justifies how things are computed. This is a pragmatic argument: if it works, it's good, no matter how odd the formula looks. (I picked the example on purpose because there are newer revisions.)

It's all about numerical representations, but which?

I find it hard to imagine how to work with the full spectrum of random values on a computer. What do I need a random number of 65000 for? What could it mean? Even limiting myself to something that's easy to imagine, 1--100% (e.g. from 0.0 to 1.0, or 1 to 100), I cannot imagine how you come up with a rule like: I want a 70% chance to hit. Why 70%? Isn't that too high or too low? How do you find out good starting values?

  1. Sticking to this example: What's a good-enough hit chance, and how do you decide that? Maybe 80%+ so players don't feel like missing their foes all the time? Do you only find that out via experimentation? If you settle on 80%, do you then infer a character attribute like Accuracy to produce a 80% chance? (rand(1,100) > 20 is an 80% chance, so let's try Accuracy = 20? Probably rather the inverse, Accuracy = 1 and didHit = rand(1,100) > (20 - Accuracy) so the values increase when one gets better.)

  2. How do you come up with the amount of HP a character should have? And how do you calculate damage?

    • If an example character has 100 HP, a single attack dealing 1000 damage points is clearly overkill for regular battles. In some games, it could signal "you need to level up", of course, but that's not relevant my prototype. So the damage needs to be lower.
    • Absorbing, say, 20 damage points per hit at 100 HP seems manageable in a 1:1 fight. Then you don't have to heal every other turn and can deal damage yourself for a couple of turns. This could work.
    • But absorbing 20 damage points from 6 opponents each at 100 HP means a char gets killed immediately in the first turn if all attacks hit. That's not good.
    • What about special low-HP mechanics? I can imagine at <20% HP, characters have reduced damage output but better evasion rates "to save their lives". That sounds kinda cool at first, but it makes fighting more complex and looks like band-aid to a problem of insta-killing. The complexity to figure out possible outcomes becomes greater; it's harder to get a feeling for the mechanics.
    • So what do you do? Reduce base damage to 15 so 6 chars * 15 dmg < max HP to prevent insta-kills, or would you rather go with a more complex low-HP-mechanic and then try it out to see if it's fun?

Which calculations turn out to be fun?

From that I can derive a few pragmatic heuristics already:

  • Absorbing damage of around 1/5 of the max HP will result in tanking damage from 3+ hits, then you need to heal. 1/7 will keep characters alive longer, but 1/3 is probably too much to be playable. Longer lives might be desirable.
  • Insta-kill (100% damage) or even healing every odd round is an indicator of too difficult an opponent. It's probably more fun to tank a couple of hits so you can be effective yourself and change the outcome by inflicting damage, and not just manage not to die.
  • It could be fun and interesting to vary character behavior, e.g. characters react differently at low HP. Go berserk and do more damage and reduce evasion, or focus on survival via evading and reduce damage output.

Start with something like that and then adjust?

Is that all there is? Pragmatism?

I guess it boils down to: how do you estimate if your calculations turn out to be fun? How do you pick the first numbers to play-test with?

  • 1
    \$\begingroup\$ It's not clear to me what your criteria are for selecting an algorithm that fits your game's needs. Without this detail, we could suggest hundreds of different formulas, many of which might actually be very unsuitable for the experience you're aiming to create. Consider reviewing the game-design tag guidance for tips on what we need to concretely answer a question about designing a mechanic. Once this post has been edited to focus on a more specific design direction than "a bit varied but still balanced," we can reopen it. \$\endgroup\$
    – DMGregory
    Apr 3, 2019 at 11:55
  • 1
    \$\begingroup\$ I nominated the question for reopening. If it gets reopened, then the gist of my answer is going to be: "You are approaching this from the wrong direction. First you make up your mind how you want your combat gameplay experience to be, then you develop a mathematical model which leads to that gameplay". \$\endgroup\$
    – Philipp
    Apr 4, 2019 at 12:26
  • 1
    \$\begingroup\$ Great work adding detail! It looks though like you're asking what kinds of numbers to start with. As you've no doubt found in your play experience, there are great games with excellent combat dynamics across a huge range of different numbers. So there's not really a formula we can give you that says "start with a 10% miss chance" or anything like that. This is where the art of game is: on the subjective judgements you need to make about what rules will help create the feelings of play that you want. Start somewhere, even if it feels ludicrously naïve, test, and find out what's wrong. \$\endgroup\$
    – DMGregory
    Apr 4, 2019 at 12:43
  • 1
    \$\begingroup\$ I teach a college course on balancing game economies & mechanical systems, so the full set of considerations we might apply here goes beyond the scope of an answer on this site. Most of the work is iterative though: take a working, unbalanced system, analyze how it behaves, identify unwanted play outcomes, and find interventions to reduce them, or boost wanted game outcomes. Then test and repeat. If you try your battle system with your first guesses at values that seem OK to you, and find a specific problem that you want to correct, that's more the scope we can help you with here. \$\endgroup\$
    – DMGregory
    Apr 4, 2019 at 12:53
  • 1
    \$\begingroup\$ It looks like you've been able to reason your way toward a range of HP & damage numbers that make sense to you. It sounds like it would be worth prototyping with that starting point, and investigating whether the behaviour you observe in playtesting that prototype meets your goals. If it does not, then you'll have a specific problem identified: "My battle system currently works like X, with parameters Y. How can I change these to avoid problem Z?" and that's a great fit for the StackExchange Q&A model of evaluating correct/working answers. \$\endgroup\$
    – DMGregory
    Apr 12, 2019 at 13:18

1 Answer 1


If you want to emulate what pen and paper does, you can basically do the same things. If you want the player to "roll at least a 7" to hit something, that means that there is a 14/20 chance to hit - or 70/100, also known as 70%. That means you can generate a random number between 1 and 100, and if it's above 30, you register that as a hit, otherwise a miss. Same for your damage: instead of rolling 3 different dice as in your example, you just generate a number between 3 and 18, or whatever min and max values are good for your game and the current level. It's really all the same things, it's just that games hide these "dice throws" usually.

Now, as you mentioned, pure random numbers can feel unfair to the player, because human brains are bad at randomness and statistics. There are several approaches you can take here to combat that, and there's really no single approach that is better all the time. It depends on your game, what the numbers are for, how "fair" or "good" you want it to feel, how important the results of that check are, and so on.

  • You could hard code something like "if the player has missed 2 times in a row, the next strike is a guaranteed hit". This way, you avoid having any frustratingly long streaks of failure. Same could be done for damage numbers, saying that if they did damage below the expected value for the last three times, the next hit will do above average damage, or will be a crit, or whatever is appropriate.
  • You could generate a list of numbers ahead of time and process it to remove any extreme outliers, or modify long streaks of especially good or bad values. Then during the game, you pull numbers from that list instead of generating them on the fly.
  • If you show your % chances to hit like for example in the XCOM games, you could trick the player by showing a slightly lower chance than it actually is. This way, they should probably be pretty "lucky" a lot of the time.

These are only a few basic ideas, and others have gone into a lot more detail about that, for example here: How do I avoid "too" lucky / unlucky streaks in random number generation?

With regard to balancing, it's really a matter of playtesting, I suppose. You can try and come up with a calculated power value for each party (combined from HP, average damage, and other relevant values) to have a ballpark estimate of how strong they are and how big the difference is, but that will probably only get you so far - you'll have to do the finetuning by yourself.


Not the answer you're looking for? Browse other questions tagged .