I read somewhere that you shouldn’t compare floats
Beware programming by hearsay. This is a good way to make mistakes for reasons you don’t understand. Instead, ask for clarification.
The full advice here is “be careful when comparing floats for exact equality.” Code like
if (playerCoinBalance == 0) is safe enough with integers, but with floats the player’s coin balance could conceivably be
1.401298E-45, which is a perfectly valid float that is exceptionally close to zero, but is not actually zero, so the
== comparison will return
false, even though the player can’t buy anything with one quattuordecillionth of a coin, and if we printed the balance in their inventory it would likely round to “0”.
But when you’re comparing ranges, you’re reasonably safe.
if (playerCoinBalance >= cost) will pass for any balance exactly at, slightly over, or way over the cost, just as desired. So, the trick for float comparisons is to think about ranges of tolerance, rather than exact equality.
That said, floats are not a good choice for solving the problem of players getting too much money. For two reasons:
They still have a maximum value, so you’ve just moved the problem, you haven’t solved it. If you go past
3.40282347E+38 (a little shy of a duodecillion), you spill out to
infinity, after which the player has unlimited money to spend.
They lose precision as the number gets larger. Once you exceed about 33 million, you no longer have integer precision with a 32-bit float. So while you don’t get an overflow error right away, you can get weird rounding artifacts: like I give you 5 coins, but your balance goes up by only 4 coins, because it got rounded to the closest representable value. Or you spend a coin without changing your balance, because
currentBalance - 1 isn’t a representable number.
As you point out, many games successfully solve this problem by enforcing a maximum cap on your balance – often something like 99, 999, 9999, or 99 999. (These numbers tend to make more intuitive sense to your players than 2 147 483 646, and also neatly cap how many digits / how much text field width you need to display the balance in base 10 in your UI, while making maximum use of that available real estate).
A benefit you get from this is that it discourages stockpiling money, and encourages spending. The player risks losing value if they continue earning while close to their cap, so it’s in their best interest to spend the money before it gets there. Just make sure the cap is clearly advertised to the player, so it doesn’t bite them by surprise.
You can even make a game mechanic out of the cap, as Legend of Zelda games do by letting you earn bigger and bigger wallets with higher caps as part of your character progression. This helps ensure the player is aware of the cap and not surprised by it, gives them opportunities to set and achieve goals with a major impact on their purchasing power, and lets you gate certain purchases behind these progression milestones by setting their cost just over one of the lower caps.
We can’t tell you what the right solution is for your game, but I don’t see any particular reason not to enforce a cap like this, in tandem with the game mechanics changes you have in mind for point 1, to reduce the likelihood that players stockpile that much in the first place.