RMMV Damage Formula - ideas and help

Math.round(formula) rounds up down if less than 0.5 and up if equal or more of. As you use 1.5, it is always at either .0 if even or .5 if odd, so either no rounding or rounding up.

Math.floor(formula) always rounds down

Math.ceil(formula) always rounds up

And... there is a way to truncate it with one decimal, yes, but wouldn't that just be the same as if multiplying both the hp and damage by 10? sounds counterproductive to the original idea to me...

Either way, seems like you can do Math.round(formula, decimals) but it can do the math wrong, so most people instead fp Math.round(formula * 10)/10 and the like instead.

You know that's not meaningful, right? A value multiplied by 1 is just itself, so you can simply say a.atk - b.def :wink:

The problem is that RPG Maker does not natively allow decimal damage. The executeDamage function rounds the result of damage formulae before they get to the player.

In order to get around this you'd have to either manually round within the formula as Yorae described above (wrap your entire damage formula inside of Math.floor()) to get to the integer you want, or use a plugin that modifies the game to allow decimal values for HP.

Yeah, multiplying by 10 seems like a much better way of doing what I was trying to do, thanks! Seems like it would be a waste of time trying to mess around and force it to work with 1 decimal place rounding with plugins etc.

I... did not, but should've lol :aswt:

Thanks for the advice both of you, I'm really terrible with numbers stuff.

I was wondering what people thought about this kind of a level scaling base formula for player damage.
Math.max(1,(x * ((a.level + 1) / 100) + (a.atk*y)) / b.def);
Where x = a larger base number like 300 or 500 (just as an example) <-- Being the max base number once lvl 99 is reached.

And y = a multiplier to vary the impact of atk or mat. (example 1.25, 1.5, 2, 3)

I used to divide by b.def because my goal for monster stats was to keep them low, for easier balance.

Of course, the variables would be based on how big you actually want your numbers to be.

You're forgetting that (x * stuff) is divided by b.def, so if b.def is very large then the output will be less than 1.

Other than that, it looks okay. I'm not a fan of including a.level directly in the formula, because higher level should mean higher stats and it's easier to work with those stats directly, but if you feel this works best for your game, go ahead.

You're right, I misread the parentheses - I thought the second portion of the attack * impact was being divided by b.def, not the whole thing.

Yeah I strayed away from level during my last couple builds. But I've been tooling around with this formula for better scaling. Because I don't have the traditional fire, fire 2, fire 3 skill scheme.

Ultimately, I guess my opinion is that I don't see the point of having level contribute to your damage when you have other parameters.

Given that you're using atk (and presumably mat) and def, and those parameters presumably increase with your level, I don't see a reason to "double dip" and count the user's increasing level in addition to their increasing atk.

That is true about double dipping. Thats why I try to post a little while Im still tooling my formulae hehe.

Would it not be better to use Math.ceil(formula) instead of Math.max(1, formula)?

And about using level in the formula, I personally only think it is a good idea if you also give level to the enemies. In which case, it would be better to also use the target's level for the defense.

I prefer math.max for my formulae because I don't allow 0 damage in my project. As some encounters are designed around having impossible defenses that will only allow 1 damage unless you have a specific weapon.

but with that formula it would never reach 0 or negative, and math.ceil would always round upwards. meaninf no matter how small, 0.000001 would still be rounded up to 1
Also, your formula is still missing rounding, so why not round it right away instead of separately.

Yeah with that specific one that would work because it uses division. I'vebeen playing around with divisors to lower stats on enemies. My normal formulae use a multiplier for the Def portion.

What's wrong with the auto rounding the MZ engine already does? I like the up and down rounding.

MZ does auto-rounding? I never... well, never tried finding out, since MV did not.
Seriously, every formula that involved division you had to put some rounding to avoid decimals in the damage

That said, just looked into it and... it uses Math.round. Which means that anything above x.5 would be the same as Math.ceil (roundign up), but bellow it would become Math.floor (rounding down).

Actually it did, in the exact same method - makeDamageValue() :wink:

Some common plugins (e.g. Yanfly...Core or Battle Engine) have the option to disable that for decimal damage, but it does round by default.

Correct, so if Oggy wants that behavior but a minimum damage of 1 for his damage formula, the Math.max() approach works well.

Does anyone know how 'a.atk' in formulas is determined when a character is dual-wielding (Victor's Engine)?

Does it sum their right and left attack together, take the higher (or lower) of the two values, or take the right attack value (which comes first)?

That's better asked in a thread about that plugin (or in Plugin Support), rather than an existing one about damage formulae :wink:

The default engine simply sums the ATK bonuses from all equipment, but some dual wielding plugins change that. For example, Ramza's looks at which of the two weapons is actually being used and only applies the ATK bonus from that hand.

Not really. Only if Variance is set to 0 and made in the formula itself.
But both Math.max and Math.ceil would need this.

Also, just read Variance's calculation.
I thought it would be something like Math.randomInt(1+variance*2)-variance,
it is actually Math.randomInt(variance+1)+Math.randomInt(variance+1)-variance
The +1s are because randomInt generates an int between 0 and (given number -1), thus why the doubled one still is just 1+.
IS making two separate randomInts any better than putting them combined in a single one?

Even with using the MZ engine variance, the engines rounding plus Math.max() has always had the expected output.