Hacker News new | past | comments | ask | show | jobs | submit login

> IMO the best approach for business logic values is picking the smallest meaningful unit and representing it with integers.

How would you design an RTS unit stats system to avoid this AoE Monk HP bug using only integer types?




`(new_maxhp * old_hp) / old_maxhp` avoids the original problem when using integers. Though you still need to make sure your type is big enough to not overflow.

Or using fixed-point (which are a relatively simple abstraction over integers): `old_hp * (new_maxhp * old_maxhp)`.


They probably just added: return ROUND()... and went back to play


How much health precision do you need? Make hp an int. Or like a /64 fixed point.


Congratulations, you just introduced a new damage threshold / resistance threshold / etc where things effectively do no damage.

Fixed point would not have helped here. Integer would only have helped because dividing first would break immediately.


     max(1,...


Well, in this case, if a unit is converted to a different type and back, it would just keep its (absolute) value of HP (in this case 1), no need to scale anything.


You haven’t thought it through yet. In this case, HP _is_ an integer, and so is the MaxHP for the unit type. And yet the bug still occurs! Storing the HP as an integer does not prevent the problem from ever occurring, because fundamentally the user still expects HP to be proportional.

That is, suppose a unit is sitting there at full health, and you research a tech that increases that unit’s max hp? Should the unit now be at less than full health, as if it had been in combat? Users probably don’t like that.

Suppose it is at full health, and then it gets downgraded to a type with less maximum health. Does it stay at it’s current HP? Users probably won’t like being attacked with supercharged units that have extra HP; they’ll think that the other player was cheating somehow.

What if it is damaged and at half health, then gets upgraded. Should it be fully healed? Gain HP equal to the difference between the new and old maximum HP? Or should it gain half of that, so that it stays at half health?

Or perhaps HP is too limiting, and the game should do what Dwarf Fortress does. DF knows the approximate surface area of every body part (based on each creature’s body plan, plus individual stats such as strength, fatness, size, etc), and the size of every weapon. Every attack therefore deals damage to a certain area, measured in square inches, and individual body parts will be destroyed once a sufficient percentage of that surface area is damaged by wounds.

Or maybe you are designing this game in the 90’s, and you have to worry about squeezing unit updates for 200 units per player into the bandwidth provided by the average modem of the day (probably 28.8kbaud), so you stick to one integer because it’s the simplest think that can possibly work, and the number of bytes per update can be calculated in advance. And then some other schmuck gets stuck with the job of handling unit type changes (but be warned that the schmuck might be yourself in six months).


>That is, suppose a unit is sitting there at full health, and you research a tech that increases that unit’s max hp? Should the unit now be at less than full health, as if it had been in combat? Users probably don’t like that.

>Suppose it is at full health, and then it gets downgraded to a type with less maximum health. Does it stay at it’s current HP? Users probably won’t like being attacked with supercharged units that have extra HP; they’ll think that the other player was cheating somehow.

>What if it is damaged and at half health, then gets upgraded. Should it be fully healed? Gain HP equal to the difference between the new and old maximum HP? Or should it gain half of that, so that it stays at half health?

     if (oldHP == maxOldHP) { newHP = newMaxHP }
     else { newHP = max(1,scale(oldHP,oldMaxHP,newMaxHP))
not exactly complex


Sure, if you fully predict all bugs in advance and compensate for them, nothing is complex, but that's not really feasible.


>Sure, if you fully predict all bugs in advance and compensate for them, nothing is complex, but that's not really feasible.

Uhh, last time I checked, that was literally my job, and specifically what I went to school for!


Not exactly complex, but you posted too quickly to have found the best solution.

A better solution is to kill the unit when it drops below zero HP, not when it drops below 1.0; scaling will never move the current HP past zero in either direction. Having 0.9999994 HP instead of 1.0 HP would not cause any problems then; the unit is still one hit away from death in either case.

The best solution is probably to store the current HP as a percentage of the max, because then you never have to rescale it in the first place.


> The best solution is probably to store the current HP as a percentage of the max, because then you never have to rescale it in the first place.

Doesn't this solution make the more common calculations more expensive, complicated, and error-prone to make one rare calculation easier? It seems like far more of the operations on the unit's current HP will be "gets damaged by X hp" or "gets healed by X hp", both of which would require the equivalent of the above conversion to establish a result.


If you’ve changed HP to a percentage, why wouldn’t you also change the damage and other related numbers (such as damage reduction and so on) to percentages as well? Nobody would be dumb enough to store them in different units and then convert every time they manipulate them.


> why wouldn’t you also change the damage and other related numbers (such as damage reduction and so on) to percentages as well?

Because a sword might do 5HP of damage, not 10% of anyone's damage (whether they've got 50 or 5000HP). Otherwise, hit points are meaningless: 10 attacks with a 10%-damage weapon kills a lowly serf or a mighty dragon.

And because damage reduction might reduce a fixed amount of damage from an attack. Etc.


Obviously a dragon doesn’t get damaged at all by a puny little sword. You can’t just say that hitting a dragon with a sword a thousand times would kill it, when none of the attacks can get through the dragon’s armored hide. On the other hand, it will die immediately if pierced by an arrow provided that arrow hits the one spot where the hide is missing a scale. The dragon has 100% DR, except in that one spot.


> Obviously a dragon doesn’t get damaged at all by a puny little sword. You can’t just say that hitting a dragon with a sword a thousand times would kill it, when none of the attacks can get through the dragon’s armored hide.

https://www.youtube.com/watch?v=9VDvgL58h_Y


:D


> A better solution is to kill the unit when it drops below zero HP

Then you have the situation where units are displayed as having 0 HP but are still alive.


So what? The players already know that attacks deal fractional HP damage.


> The players already know that attacks deal fractional HP damage.

Top-end players who analyze the engine enough do.

Otherwise, they shrug and say "sometimes 1, sometimes 2 HP"

And even so, we're used to seeing 0/50HP and it meaning "dead" across many games. Seeing 0/50HP and it meaning "just a small amount of HP left" isn't ideal.

Not to mention that weird situations with 5.551115123125783e-17 HP remaining aren't great either (where a player may end up with effectively an "extra" hit point).


Again I say “so what?”. The unit is one hit away from death either way, and the player will know it.


At this point, with your Smaug-related comment, etc-- I've become convinced you're trolling.

But just to humor you: the desire is to have a system where floating point neither surprisingly kills nor gives characters extra hit points. There's a lot of subtlety in this. Schemes where all damage are percents don't preserve the essential pieces of RPG combat systems. Moving the threshold from 1 to 0 HP violates the conventions of the art and doesn't eliminate the problems (you can still end up with hit points epsilon away from 0, instead of 1).


The problem isn’t hitpoints that are an epsilon away from 1, it’s that an operation which looked innocuous moved the HP to an epsilon _below_ 1. That would never happen with 0, however, as multiplication and division of positive numbers always gives a positive result.

And in D&D, incapacitation happens when a character drops below 0 HP, and death happens once they drop below -10HP. There is no grand convention that all RPG games follow here; each game is making things up as they go. They picked badly when they designed Age of Empires, and that’s ok. It’s not the end of the world. Just know that we can do better if we are paying attention.

And I am serious when I ask “so what?”. Why is it so bad if the game displays 0/55HP? The players all know that fractional HP damage exists, and they can see that their unit is still alive, so what is the problem? They will be at least as amazed that their unit survived as they currently are when they see a unit at 1/55HP.

I am likewise serious about Smaug; there is no way that combat makes any sense if Smaug has a large number of hitpoints or that any weapon at all can damage him. Using hitpoints as an abstraction completely loses all of the flavor of Tolkien’s original descriptions. A better model is one using damage reduction and sensible internal organs; a strike that pierces the heart will kill even a dragon.


> however, as multiplication and division of positive numbers always gives a positive result.

Depends on what you do with subnormals and underflow, etc.

> There is no grand convention that all RPG games follow here

Computer RPGs have shown 0/812 for dead for ... forever.

> The players all know that fractional HP damage exists

I think most players will be confused. And for what, to make it "safe" doing floating point operations in the wrong order? (I doubt it's still safe, overall).

> I am likewise serious about Smaug; there is no way that combat makes any sense if Smaug has a large number of hitpoints or that any weapon at all can damage him.

Common mechanisms: an armor class that makes it hard to hit; a fixed amount of damage reduction so that a needle does nothing; a lot of hitpoints.

> and sensible internal organs;

It gets excessively complicated and annoying. Battletech is already excessively complicated, and doesn't go quite as far as you're advocating for here.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: