How to develop RPG Damage Formulas?

  • I'm developing a classical 2d RPG (in a similar vein to final fantasy) and I was wondering if anyone had some advice on how to do damage formulas/links to resources/examples? I'll explain my current setup. Hopefully I'm not overdoing it with this question, and I apologize if my questions is too large/broad

    My Characters stats are composed of the following:

    enum Stat
        HP = 0,
        MP = 1,
        SP = 2,
        Strength = 3,
        Vitality = 4,
        Magic = 5,
        Spirit = 6,
        Skill = 7,
        Speed = 8, //Speed/Agility are the same thing
        Agility = 8,
        Evasion = 9,
        MgEvasion = 10,
        Accuracy = 11,
        Luck = 12,

    Vitality is basically defense to physical attacks and spirit is defense to magic attacks.

    All stats have fixed maximums (9999 for HP, 999 for MP/SP and 255 for the rest). With abilities, the maximums can be increased (99999 for HP, 9999 for HP/SP, 999 for the rest) with typical values (at level 100) before/after abilities+equipment+etc will be 8000/20,000 for HP, 800/2000 for SP/MP, 180/350 for other stats

    Late game Enemy HP will typically be in the lower millions (with a super boss having the maximum of ~12 million).

    I was wondering how do people actually develop proper damage formulas that scale correctly? For instance, based on this data, using the damage formulas for Final Fantasy X as a base looked very promising. A full reference here but as a quick example: Str = 127, 'Attack' command used, enemy Def = 34.

    1. Physical Damage Calculation:
    Step 1 ------------------------------------- [{(Stat^3 ÷ 32) + 32} x DmCon ÷16]
    Step 2 ---------------------------------------- [{(127^3 ÷ 32) + 32} x 16 ÷ 16]
    Step 3 -------------------------------------- [{(2048383 ÷ 32) + 32} x 16 ÷ 16]
    Step 4 --------------------------------------------------- [{(64011) + 32} x 1]
    Step 5 -------------------------------------------------------- [{(64043 x 1)}]
    Step 6 ---------------------------------------------------- Base Damage = 64043
    Step 7 ----------------------------------------- [{(Def - 280.4)^2} ÷ 110] + 16
    Step 8 ------------------------------------------ [{(34 - 280.4)^2} ÷ 110] + 16
    Step 9 ------------------------------------------------- [(-246)^2) ÷ 110] + 16
    Step 10 ---------------------------------------------------- [60516 ÷ 110] + 16
    Step 11 ------------------------------------------------------------ [550] + 16
    Step 12 ---------------------------------------------------------- DefNum = 566
    Step 13 ---------------------------------------------- [BaseDmg * DefNum ÷ 730]
    Step 14 --------------------------------------------------- [64043 * 566 ÷ 730]
    Step 15 ------------------------------------------------------ [36248338 ÷ 730]
    Step 16 ------------------------------------------------- Base Damage 2 = 49655
    Step 17 ------------ Base Damage 2 * {730 - (Def * 51 - Def^2 ÷ 11) ÷ 10} ÷ 730
    Step 18 ---------------------- 49655 * {730 - (34 * 51 - 34^2 ÷ 11) ÷ 10} ÷ 730
    Step 19 ------------------------- 49655 * {730 - (1734 - 1156 ÷ 11) ÷ 10} ÷ 730
    Step 20 ------------------------------- 49655 * {730 - (1734 - 105) ÷ 10} ÷ 730
    Step 21 ------------------------------------- 49655 * {730 - (1629) ÷ 10} ÷ 730
    Step 22 --------------------------------------------- 49655 * {730 - 162} ÷ 730
    Step 23 ----------------------------------------------------- 49655 * 568 ÷ 730
    Step 24 -------------------------------------------------- Final Damage = 38635

    I simply modified the dividers to include the attack rating of weapons and the armor rating of armor.

    Magic Damage is calculated as follows: Mag = 255, Ultima is used, enemy MDef = 1

    Step 1 ----------------------------------- [DmCon * ([Stat^2 ÷ 6] + DmCon) ÷ 4]
    Step 2 ------------------------------------------ [70 * ([255^2 ÷ 6] + 70) ÷ 4]
    Step 3 ------------------------------------------ [70 * ([65025 ÷ 6] + 70) ÷ 4]
    Step 4 ------------------------------------------------ [70 * (10837 + 70) ÷ 4]
    Step 5 ----------------------------------------------------- [70 * (10907) ÷ 4]
    Step 6 ------------------------------------ Base Damage = 190872 [cut to 99999]
    Step 7 ---------------------------------------- [{(MDef - 280.4)^2} ÷ 110] + 16
    Step 8 ------------------------------------------- [{(1 - 280.4)^2} ÷ 110] + 16
    Step 9 ---------------------------------------------- [{(-279.4)^2} ÷ 110] + 16
    Step 10 -------------------------------------------------- [(78064) ÷ 110] + 16
    Step 11 ------------------------------------------------------------ [709] + 16
    Step 12 --------------------------------------------------------- MDefNum = 725
    Step 13 --------------------------------------------- [BaseDmg * MDefNum ÷ 730]
    Step 14 --------------------------------------------------- [99999 * 725 ÷ 730]
    Step 15 ------------------------------------------------- Base Damage 2 = 99314
    Step 16 ---------- Base Damage 2 * {730 - (MDef * 51 - MDef^2 ÷ 11) ÷ 10} ÷ 730
    Step 17 ------------------------ 99314 * {730 - (1 * 51 - 1^2 ÷ 11) ÷ 10} ÷ 730
    Step 18 ------------------------------ 99314 * {730 - (51 - 1 ÷ 11) ÷ 10} ÷ 730
    Step 19 --------------------------------------- 99314 * {730 - (49) ÷ 10} ÷ 730
    Step 20 ----------------------------------------------------- 99314 * 725 ÷ 730
    Step 21 -------------------------------------------------- Final Damage = 98633

    The problem is that the formulas completely fall apart once stats start going above 255. In particular Defense values over 300 or so start generating really strange behavior. High Strength + Defense stats lead to massive negative values for instance. While I might be able to modify the formulas to work correctly for my use case, it'd probably be easier just to use a completely new formula. How do people actually develop damage formulas? I was considering opening excel and trying to build the formula that way (mapping Attack Stats vs. Defense Stats for instance) but I was wondering if there's an easier way? While I can't convey the full game mechanics of my game here, might someone be able to suggest a good starting place for building a damage formula?


    I think you've done the right thing in first setting what kind of stats, HP etc you want. This is part of the player experience and the math should fit 'around' these values. With so many stats though, the player should intuitively know what stats will affect his magical, physical attacks, etc. So the first big question is what stats correspond to an attack, and what stats defend against these stats (For ex PhDef defends _only_ against PhAtk).

    The huge thing is balance, it would probably be a good idea to create an interactive program (say in C# or something quick) where you can change stats and see what kind of results you get. If you can change the formulae at run time, that would also help :)

    Consider using Excel to do this. Seems well suited to the task and you wouldn't have to write a line of code.

    The most important question is: Which formula gives players the most *fun*? (searched the page for "fun" and non of the answers mentioned it :P) If it stats or damage go up too fast players get insensitized, if it goes up to slowly they get bored. Players need to feel happy when they gain a level, so they need to feel like they put work into it and also that it will have some noticeable effect on their game performance. (that's my 2 pence)

    "(Def - 280.4)^2" huh? Well, I would expect things to get weird not for Def > 255 or Def > 300 but pretty much exactly for Def > 280.4 ;) After that, higher def will effectively mean a lower def at this point of the formula while continuing to behave as expected at other points. BTW, you can just plot this stuff with Wolfram Alpha or so. Fix enough variables to keep only two and you'll get a nice surface plot.

    Speed and Agility are not the same thing, speed is a property of motion, agility is a property of the body on how it control its motion through its structure

    @Christian He wrote that stats have a fixed maximum of 255, so as long as the max is respected, the formulas shouldn't need to work over 255.

    @Dronz I was referring to "In particular Defense values over 300 or so start generating really strange behavior." So yeah, that doesn't surprise me and I pointed to the root of the problem. It's also not "values over 300 or so" but "values over 280.4 exactly".

  • Creating formulas like this requires knowledge of elementary mathematical functions - the things you learned about in Algebra and Pre-calculus class.

    Once you have those mastered, just ask yourself (replace "value" with "damage," or "health," or "speed" or whatever):

    Then just tweak it (add/multiply stuff, change the base-value, etc) until it feels right. A graphing calculator will help you visualize how changes to the parameters will affect the function.

    By the way, the problems you are experiencing are due to integer overflows.

    Use variable-types that are large enough to hold the numbers you're working with. Sizes differ by platform in C++, but using the 32-bit Visual Studio compiler, unsigned int is 32-bit, while unsigned __int64 (MS-specific) is 64-bit. Also consider using a double.

    Additionally, try to reorganize your operations so that you don't encounter such large numbers in the first place (for example, rather than MDef * MDef / 110, do (int)((float)MDef / 110 * MDef)).

    If you're running into integer overflows, conversion to float - which only reliably supports 24 bits of integer part - is going to have a different set of accuracy problems.

    @Joe: I've rolled back your edit; I specifically chose `__int64` over `uint64_t` because `stdint.h` is not available on Visual Studio 2008 and below, and I didn't want to confuse the poor boy any more than he already is.

    @BlueRaja: I don't see any evidence the asker is using Visual Studio, and it's present in every other standard toolchain (including Visual Studio 2010).

    You left out one important variant as well, I think: If you want the damage to have an upper bound which you can get close to, but never quite reach, you can use a sigmoid function.

    @Martin: read again, I didn't leave that out :)

    @BlueRaja: Ah, ok, I missed that. Mostly because the distinctive difference of that one (the fact that it has an asymptotic upper bound, as opposed to all the others) wasn't mentioned.

    Good advice about the sigmoid. I know the ingredients to make a damage formula, I was curious though if there was a better way then just having a vague idea of "a polynomial" and throwing values around until something sticks

    user127817: All that's really important is how the function grows. For the rest, just test it until it feels balanced. If you feel the character is too powerful, lower his damage. If you feel it takes too long to kill a particular boss or enemy, lower that enemy's health or armor. And so on.

    Logistic function is the my answer to every RPG needs! It gives you better control for the curve. This answer have helped me a lot in game cooking. Download apps like Grapher Free for Android to visualize the curves.

  • My Characters stats are composed of the following:

    There's your real problem: you defined your stats before defining what those stats actually mean. You're putting the cart before the horse.

    Look at how D&D (tabletop) works. "Strength" doesn't mean anything by itself; it only means something because there's a rule that says, "Add your strength bonus to your melee attack." That rule is part of D&D's combat rules. Without the combat rules, "Strength" is generally a meaningless quantity.

    The first question you need to ask yourself is this: how much differentiation do I want between characters? Again, look at D&D. There, they have 6 basic stats. These stats define different dimensions of play for characters. A character with a high Dexterity will have different options from a character with low Dexterity.

    But the reason for even that difference all comes back to rules. A high Dexterity means bonuses to ranged attacks; you can hit more often with ranged attacks. So just between Strength and Dexterity, you have two dimensions of play: ranged vs. melee.

    Intelligence and Wisdom also form something of a pairing, but these interact more with specific classes. Int makes Wizards and other arcane spellcasters better (or possible under some rulesets), Wisdom is vital for Clerics and other divine spellcasters. Because divine and arcane spells have different spell lists, these two stats are involved in different dimensions of play.

    You need to define the basic rules around stats before you can define growth progression functions and the like. You don't need specifics; you don't need to say that "each point of strength is added into the random roll to determine if a melee attack hits." What you need are meta-rules like "dexterity makes ranged attackers better." You can figure out exactly how it makes them better later on.

    There are different ways to progress characters. A common old-school Final Fantasy trick was to simply use the character's level as part of their damage computations. This could be simply multiplying the level by the appropriate stat, or it could mean applying a function to the character's level. Say, a quadratic progression, so that the rate of a character's damage would increase per level.

    However you want your combat functions to work, they need to take into account progression. Your functions need hooks for progression.

    D&D has a funny way of progression. It is part class-based; every time you go up in level, you get new class features and a flat bonus to your to-hit, based on your character class. However, some class features got better by themselves. Spells in D&D would have progression built into them. A spell might do 1d4 damage per 2 levels of a spellcaster above the first. So every other wizard level makes that spell better.

    D&D also used item-based progression heavily. Until 4th edition, item-based progression was mainly for fighting characters, but even in older editions, spellcasters had items that gave them stat buffs or other adjustments (or flat out gave them spells).

    So items are another thing your combat functions need to take into account. Do items just buff one or more stats while equipped, or do they do other things as well? D&D was a bit odd, in that stats rarely changed; weapons simply did XdY damage, possibly with a bonus based on one of your stats. And that was that. So your only way to do more damage in battle was to find a better weapon. In many videogame RPGs, they take level into account in addition to a weapon.

    "_There's your real problem: you defined your stats before defining what those stats actually mean. You're putting the cart before the horse._". I strongly disagree; the numbers in themselves are just a way to inform the player of his power, etc. it _is_ part of the game design. If you proceed the other way round, you could end up with an end boss with 147hp... who wants that really?

    Well, Sarevok (in Baldurs Gate) only had 135 HP ...

    @3nixios: What does it matter if the end boss has 147Hp? What matters is whether the last boss is challenging, interesting, and above all _rewarding_ to defeat. A boss with a lot of Hp isn't interesting; it's a waste of time. A boss that can mess with your party, that requires special tactics that change from moment to moment, that requires that you must to use every ability you have to its maximum potential, _that_ is what makes for a great final boss. I'll take the interesting 147Hp boss over the boring block of Hp any day.

    @Nicol Bolas I totally agree with you, I was trying to support why I believe that the starting point has to be from the stats. The stats a player starts with are the primary indication and gameplay that the player plays with during the game. I agree that huge HP bars for bosses aren't necessary, it gives the player a better indication of what is the best setup against the boss, what stats weapons etc. are more effective. The amount of course is irrelevant to the way you calculate it, because you can just divide or multiple your final calculations by a constant _c_ and be done with it.

    @3nixios: But that's part of my point. Dexterity in D&D exists to allow a differentiation between melee specialist characters and ranged specialists. If there were no concept of melee and ranged attacks (and in many FF games for example, there isn't), then this distinction would not need to exist. You could get away with 5 stats instead of 6. Defining a Hp range is one thing, but defining what basic _stats_ you have is another. Stats require rules before you can make sense of them, and you have to know what you intend a stat to do before you can say that having that stat is a good idea.

    @Nicol Bolas I think I may have misread your opening statement... my bad... very bad... +1? I totally agree with this, and assumed that he defined the stats according to the rules he had already defined for the game. In which case, I thought you were talking about the _values_ he had given to the stats (255 max), which I believe has to be done empiracly before trying to do the math. Basically the formulae _fit_ your design.

    @3nixios: His Evasion and MgEvasion stats are a good example. Obviously one deals with physical attacks, while the other deals with magical ones. That creates a distinction: you can use high evasion to make a character strong against physical attacks but they'll still have a weakness against magical ones. That makes sense. But why is no similar distinction made for "Accuracy?" Do spells simply always hit? If you're trying to make a distinction between physical and magical attacks, wouldn't it make more sense to have two accuracy stats?

    Well I know what my stats affect and why. I was curious about the proper way to develop the mathematical relationship between the stats (i.e. Strength + Weapon Attack Rating and Vitality + Armor Rating are an offensive/defensive pair). I was using accuracy as an overall accuracy rate for all attacks (and is paired with evasion/mg.evasion depending on whether the attack is physical/magic in nature), but you make a good point that seperating them might be a good idea. Thanks

    I really like this answer, helped me change my view on making RPG games completely.

    Metal slimes had 4 hp and they were tough as hell to defeat!

    If you archive to get a greate balanced and stable system you can allways add multipliers for the displaying values to make the numbers look much bigger.

  • Your formulas seem pretty complicated. I'm not sure how professional RPG developers handle this, but I'd recommend on focusing on simplicity. Try to find the simplest possible formula you can that still incorporates the range of stats you want to use. For instance, could you have stats modify each other prior to damage calculation, rather than modifying the damage during the calculation? Once you've got a formula in mind, I'd try graphing it for a wide range of possible values to see how it will behave as players level up. Obviously the fewer variables you have, them more feasible this will be.

    Additionally, BlueRaja provided an important explanation of why you might be seeing unexpected values at higher stat levels. Using unsigned types and checking for overflows will be important.

    +1 for simple. Anyone can make rigorously complicated stuff, that doesn't make a good game though.

    "Simple" can also require less calculations, which means fewer CPU cycles are needed (and those spare CPU cycles can then be used for other aspects of game play, graphics, etc.).

    @Randolf unless you're running on an Apple 2 or something, it's highly doubtful that removing a multiply or a divide here and there is going to affect performance in any measurable way.

    @Tetrad: "Here and there" certainly won't be noticeable, but for code that is run repeatedly and often, this can make a difference, especially as more features are added later that require more calculations and whatnot -- it will compound, so if it's possible to start out with the more optimal solutions, this can really pay off in the long-run.

    @Randolf A big battle in an RPG might mean something like 10 damage calculations per second, a modern CPU can do several billion operations per second. You can safely assume that the performance impact of any such "visible" maths is negligible. Simple in this case is for the sake of those who design and those who play the game, not for our computers.

    @eBusiness: A big battle yielding only 10 damage calculations per second? I think our ideas of "big" must be wildly different. When you have thousands of players on simultaneously (for which I've purposely excluded computer-controlled characters), these become major factors because "10 damage calculations per second" will simply be insufficient. As for a small game with a minor battle scenario between a handful of players, you're right in that it won't be noticeable (and such a game may not need to scale into something massive).

    @Randolf Richardson Big as in the maximum you'd expect to happen in a common RPG. For the sake of the argument, it shouldn't be a significant load in a common MMO either, but if you optimise and cull to the point where it becomes a significant part of the calculations, networking will be the bottleneck determining how many players a server can service.

    @eBusiness: Optimization of the protocol (and not wrapping everything up in XML like all the cool kids like to do these days) certainly helps, but having a proper amount of bandwidth does too. This all underlines my original point about the value of optimization though, which unfortunately seems to be a unpopular idea these days despite its importance.

    @Randolf Richardson: I just think you might be missing the target a bit in this case. For an MMO a good fast no-fat protocol is paramount, and heavy tasks like physics need to be designed with performance in mind. But damage calculation is core gameplay, it should be designed with gameplay in mind, if you bring performance concerns into such a question you risk compromising the gameplay part. Talk about performance when it matters, you risk giving the impression that this is an important area to optimise, thus stealing the attention from the real performance sinners.

    @eBusiness: Optimization is important everywhere. It's simply the degree of importance that matters -- optimization is certainly possible without negatively impacting game play. If you've got the time or option to optimize anything, then why not do so? I suspect that we generally agree on these matters, but for some reason things went off course.

    @Randolf: If you have the time to optimize a simple math formula, then you have the time to be doing something far more useful than that.

    @Nicol Bolas: Are you implying that optimization isn't useful?

    @Randolf: I'm implying nothing; I'm _saying_ that optimizing something that isn't a bottleneck is a waste of time.

    @Nicol Bolas: +1 because your point is certainly a good one (and important in the context of time management), but I don't entirely agree -- optimizing something that has the potential to become a bottleneck at some point in the future is _not_ a waste of time. (There are other benefits to optimization as well, such as code simplification, the elimination of bugs, etc., which can be [at least partially] incorporated into other processes such as code review so that it doesn't require a lot of extra time. I think that code optimization techniques are not very well understood by many people.)

    @Randolf: I have seen very few useful optimizations that make code simpler. Most optimizations introduce complexity and obfuscation by forcing the code away from proper abstractions. And consequently, optimized code is often harder to debug. Worrying about things that _could_ become a problem takes away precious time from worrying about things that actually _are_ a problem.

    @Nicol Bolas: Then you've only seen one aspect of optimization, and I hope that you do get exposure to other types of optimizations at some point because there really is a lot to be gained. For one very simple example in ASM, one can shift all the bits to the right to multiply by 2 or 4 with less time. Another example would be to use multiplication before a loop starts instead of adding repeatedly within a loop (effectively reducing X number of calculations down to just one calculation) where the result isn't needed until afterward. There are countless ways that optimization is sensible.

  • Late game Enemy HP will typically be in the lower millions (with a super boss having the maximum of ~12 million).

    This I have a problem with. You should build your bosses around what you think your players should be able to handle. You're building your players and combat formula around what you want your bosses to be like.

    Once you get your combat mechanics and roles built, then you can decide on how you want to design your bosses as it should be a good balance between the damage the players can deal/absorb vs what the boss can deal/absorb.

    +1 the enemy's health should be based on what the player can reasonably handle at that point, not the other way around.

  • Those numbers you quoted are likely derived from a just tweaking a simulation, over thousands of runs.

    So you should write a simulation create a level 20 character, and see how he fares through 200 battles or so against the enemy types he's supposed to be fighting at that point. Do it again for a level 30 character (in presumably the next section of the world).

    It'll take a while to get right, but writing automated simulations will definitely make this much easier than just guessing and manually playing it out.

  • I think you make the mistake that you want to create a formula without having a proper design in mind.

    First start with a design, then start thinking about representing the design in formulas. The clearer your design the easier it should be to find simple and/or precise formulas.

    Try to implement "types" of enemies, e.g. "armored" => a player attack if it is of type physical is reduced by 50%. Do not make a battle flow to abstract, think about what is relevant and what is not.

    If your design says "armored enemies" are weak against magic but strong against physical damage, represent that in code. But remember that you have do a lot of testing, because the values won't work magically the first time you write the code. Try to create a design, put the logic into code, always check whether this the technical representation of what you had in mind and if it isn't change the values until it is.

    I was already encompassing that sort of thing - armor rating scales down physical attack damage unless the attack is flagged as armor piercing or uses a % based damage formula

  • Although my design have not left Spreadsheet phase, I have came to one conclusion about designing math for RPG:

    Keep them as simple as possible. In design that I'm working on, I used very simplistic formulas, that are adequate to semi class-less system. Ie. Fireball Spell have damage of 30. The forumal is:

    BaseSpellDamage * Attribute (5 * 6)

    We can also add modifiers like this:

    Result = (BaseSpellDamage * Attribute) (5*6)
    Result = Result + (Result * 50%) (30 = 30 + (30 * 50%))

    So end result would be 45 damage. I found that using precentage multipliers is very easy, and very scalable solution to work with. Instead of coming with some odd numbers with complex math to figure out the result we want.

    Now we can calulcate damage reseistance, that will just calcucate defense against set type of damage. There are two approaches and I honestly haven't decided which would suit better, but they both are simple and viable:

    DamageResult = Resistance * Damage ( 50% * 45)

    So the end result will be 22damage taken (I just cut the partial result).

    Other formula:

    DamageResult = Damage - Resistnace (45 - 22).

    So end result will be 23. If it happen that resistance is bigger than damage taken then character just doesn't recieve any damage. Of course it's up to you to make sure that such situation have no place, except for when you want it be the case.

    Although I must admit that precentage scaling is somewhat easier to balance and scale. But this also depends on your base numbers. Precentage scaling will work best if you start from 100 and up. If you are operating on small numbers (anything below 100 to be honest), it can get awkard as you will start getting floating point results, that will be hard to balance and actually do anything interesting with them.

    Probably optimal solution in that case is to use both approaches when they see to fit. Or if you are fan of big numbers start from 1000.

    And at the closing ends. I haven't come to this conclusions completly on my own. I have actually spend quite some time reading various RPG manuals (Hero, DnD). Especially DnD was helpful, as it operates on similiar principles but instead of attributes it's using levels for it's formulas, they can be sometime more complex. Than what I presented here.

    In anycase, the best advice is: try to keep them as simple as possible. Do not use any advanced math, or long equations, as they are prone to errors, that are hard to spot, when you have to deal with 87234 other things at the same time.

  • As others have mentioned, the Final Fantasy X formula is pretty complex. Generally for that series the later the game, the more complicated the formula. It's probably easier to base your damage formula on another game entirely. But in general, I think it's worth discussing from a very general level what kind of damage formulas you can find in the world, and how you can make a game based around them. The first thing you need to decide is how much damage do you want to be able to do at the end of the game, and what kind of stats do you want the player to be able to have? Once you have that, you can pick a formula system, and then optimize the formula and weapon values to reflect those ranges over time.

    Purely Stat-Based

    This is a good idea if you want your characters to be flexible in terms of what levels of enemies they can challenge. A formula like this is only going to depend on the player's stats, their equipment, and the stats of the enemies. These formulas are usually fairly simple. Final Fantasy Legend II (See for instance, has weapons that do damage based on the simple formula:

    (Stat+StatBonus)*WeaponStrength - Defense*4

    A formula like this is good if you want a very simple method of estimating damage, or a quick jumping off point for modifying damage based on other factors like skills and elemental weaknesses.

    To show how broad this kind of formula can truly go, consider the damage formula for Inflation RPG, an Android and IOS game (See The formula is heavily both stat and equipment dependent. Each piece of equipment has two stats - a bonus to the ATK stat, and a multiplier value. Some pieces of equipment have low multipliers, but high bonuses, others have low bonuses but high multipliers. For a character with only 10 ATK, the Battle Axe with it's 5000 ATK Bonus but low 145% multiplier is a great choice. The total damage is (10+5000)*1.45 = 7264, but the Estoc, with 0 bonus and a multiplier of 300% is a poor choice - the damage is (10+0)*3 = 30. Later in the game, a character with 5000 attack would prefer switching weapons.

    Stat- and Level-Based:

    A good example of this is Final Fantasy V, VI, and Final Fantasy XII (See, for example). The formula for swords in FFXII is:

    DMG = [ATK x RANDOM(1~1.125) - DEF] x [1 + STR x (Lv+STR)/256]

    and the damage formula for staves is:

    DMG = [ATK x RANDOM(1~1.125) - DEF] x [1 + STR x (Lv+MAG)/256]

    They're very similar, but notice that the sword formula only depends on the strength and level, while the staff formula depends on strength, magic and level. The advantage to this kind of formula is that it allows the player two avenues of growth - building their stats, or building their levels. The downside is that it also penalizes characters both ways as well. What this really ends up doing is allowing the player to level up to increase their damage output (for FFXII this amounts increasing their damage output by ~4% per level around level 50 when you factor in stat gains) to help customize the difficulty to their comfort level.

    Fixed Damage:

    Fixed-damage formulas do not depend on the character's stats or level, they depend only on the internal damage formula of the weapon itself. They can still vary over a range, but they deal the same damage regardless of the user (barring any other special effects or character traits). They're best used if the weapon is going to do fixed-damage and the ability to equip the weapon depends on either stats and/or level. Diablo 2, for example, does this, as do many roguelikes which have weapons that depend on die rolls. That being said, 'fixed damage' does not imply "non-random" - and in fact there's usually some element of randomness to the damage done.

    This is a good methodology if you want to have weapons that are easy to transfer between characters or to carefully control the damage output that characters at certain points in the game can do if you know what equipment they have access to (via drop tables, chests, and steal tables).

    Another place you'll run into this is with certain types of equipment or items in Final Fantasy. 1000 Needles, for instance, always deals 1000 damage. In Final Fantasy Legend II, martial arts deal damage based on the formula:

    Damage = WeaponStrength*(90-UsesLeft) - 4*Defense

    Final Fantasy XII has somewhat fixed damage for guns as well, dealing damage according to the formula:

    DMG = [ATK x RANDOM(1~1.125)]^2

    Although the damage is somewhat random, it only varies by 26.5 percent over the total range, so you're guaranteed to do a certain level of damage on average over time. These types of attacks are useful for characters who have both low stats and low levels in games that normally account for those factors in dealing damage. Plus, they ignore the defense of the target (although the formula could be easily reworked to fit in defense if you so desired).

  • all games in the final fantasy series have had a stat cap of 255 because of the problem you are encountering. at level 100 stats would be 255.

    you say about increasing stats with abilities and equipment and I remember seeing this in the games but the way this is done is in the formula. there is an extra step that checks for ability and equipment modifiers and applies them after the stats have been used.

    in your case it would be step 21: apply ability modifiers step 22: apply equipment modifiers step23: final damage.

    if you are interested google for final fantasy formulas, they are out there. I have copys of the actual battle mechanics including AI for final fantasy 4, 6, 7 and 9. people cracked them from the original games when they were creating roms for emulators. There not that hard to find if you look hard enough.

    the biggest thing for creating formulas is testing. set up a script to run your battle wit ai on both side and run several hundred battles. vary the monsters and the stats and see if it works or if lv 40 kills everything, it is entirely possible that a boss is actually impossible to kill lol. a tip would be to turn off all animation as it is impressive how fast AI's can battle when no one is watching.

  • I was wondering how do people actually develop proper damage formulas that scale correctly?

    The first 2 things are:

    • decide what you mean by 'correctly' - what is your idea of 'correct damage'?
    • decide what you mean by 'scale' - what values are going to change, and what effect do you want those changes to have?

    Once you know that, you have enough information to use the mathematical formulas that BlueRaja mentioned in his answer. Just remember there is no such thing as a 'proper' damage formula - just one that matches your design for the type of experience you want your players to have.

    This is an extremely unhelpful comment. It sums up to "I don't know" and because of that it is a waste of everyones time. Flagging for deletion.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM