Game Design, Programming and running a one-man games business…

Long numbers and dumb coding in Production Line

I have a few reports of a bug in production line where people have got VERY good at the game and amassed tens of billions of dollars. Nothing actually crashes, but financial reports start filling up with gibberish like $-1,-4,-2,-0,-1,-3,-5 and so on. The cause is simple, the fix difficult(ish) and the wider implications worthy of comment.

Firstly, as most coders can already guess, its because I’ve gone outside the max limits on the data type I’m using. I use a ‘float’ for financial figures in the game (mainly because some items get percentage reductions due to global events and competition, so I need decimals) and because *somewhere* I must be casting it to an int (no idea where yet) the numbers I can represent are limited to -2,147,483,648 to 2,147,483,647 because an int is 4 bytes. If I was using only a float, things would be super different. More details here.

Anyway, although generally speaking numbers like that are big enough, in a financial sim, restricting any possible number to a max value of $2billion is not ideal. My game is not ‘realistic’ in costs, and its rare that players finances will exceed $100 million, let alone 2 billion, but obviously it happens now and then and the game kinda screws up.

The fix is easy. I just need to replace that datatype, but the actual implementation is a bit more messy, because that means old save games need converting or handling as I load those numbers in (right now the game only knows how to load ints, floats and strings and likely casts to ints somewhere). I also have to go through every place where those numbers get locally stored by any GUI code and ensure I’m not using ints there either, and of course I need to change my display code so it handles floats properly and converts them to strings properly.

TBH its likely only a days work, but assuming another day to test it, and then a few days of ‘unstable build’ roll-out to the hardcore before folding it into the main code branch, all this means that this will be a fix coming after release on Thursday, and NOT today :D

Perhaps the more interesting topic is how do you deal with edge cases and marginal cases with a sim/strategy game. I know from experience that people WILL push these games to the extreme and WILL break them. I’ve had negative reviews from people with >100 hours playtime because their extreme playtime has led to discovering exploits, and edge cases that allow them to ‘break’ the game.

Anyway, this is a real issue because making a balanced, playable, fun, reliable game that works for 99% of the playerbase takes 99% of the effort, and making it work perfectly in EVERY edge case is…another 99% of effort. Generally speaking, its way better to concentrate on fixes, features and changes which make the game better for the 99% than to fixate on the extreme edge cases, especially as a time-limited indie who can never do everything.

I’ll fix the numbers thing post-release, but I have to admit that are likely some other real edge cases that I never will. This is also true of any of my games, like Democracy 3, or Gratuitous Space Battles. There are probably obscure edge cases and tactics that you can discover in all my games that ‘break’ them, after 100+ hours of gameplay. Thats not shocking. I’m always going to make the majority of players who play in the ‘usual’ way my primary focus. Edge case fixes are something I like to do, and want to do, but you can never get them all, or fix them all. You will go mad trying to do so.

Do not forget that there are companies like EA/DICE where thousands of players will scream that ‘X’ is unbalanced or ‘Y’ breaks the game and has not been fixed!, and yet presumably those companies have 50x the manpower I do. The likelihood is that they have data that shows this is only true in 0.1% of cases, and their dev time is better spent elsewhere. I have no illusions that players will accept that as an answer, but that will not stop it being the case!


4 thoughts on Long numbers and dumb coding in Production Line

  1. Ironically I’ve heard players in Payday2 lament that they should balance weapons for the game for the uber-ultra-extra-double hard difficulty that literally only a tiny minority of players can do.

  2. And when it happens for 0.1% out of seven million, then one of those 7000 will find out how it is done, publish it online and suddenly 50% of the players are doing it.

    And then one person streams the exploit and gets banned.

    But the devs fixed 7 game breaking crash bugs that potentially affected 3% of the player base, and gets screamed at. Oh, well. Good thing your manager is a nice person and your fans civilized :)

  3. Obvious backwards compatible fix (assuming your savegame is binary, otherwise just throw in more digits if text): split the values into two its 32-bit halves, then append the upper halve at the end of the existing data… not pretty, but at least makes it easier to have a parser that can handle both the old format and new format (first read lower half as usual, and if upper half is found, then OR that into the value)

Comments are currently closed.