Well, I did say I was going to separate this out from the previous one... if you're disappointed after having already read this as part of a two-part post, then I'll just have to make it up to you with more graphics from my game. How does that sound? You'll have to wait until next time, though :p (Sorry, I have nothing I would consider worth showing you, at the moment.)
The thing that really annoys me that gamers, especially ones who have never touched software or programming, tend to do is complain about delays. Some times it literally cannot be helped, as demonstrated in my previous post by my 5 hour bug fix-athon. Conveniently, I have a second example to share, here.
This is a simple command I want the game to run when something on screen is interacted with: <user variable> *= 1.5;
User Variable, in this case, is equal to 1. That translates to little more than 1 * 1.5. Simple, right? Wrong... Well, not really. The script itself is simple enough, but life is never simple enough. What happens when I run that script? I get 150. 1 * 1.5 = 150. For some reason, the first time the script is run, "user variable" is treated as 100 instead of 1 despite being displayed as 1, but only if the number it's being multiplied by is a fraction, and only on the first time. The second time, it's 225, because it ran just fine. But it gets head-explodingly more improbable if I change it from multiply to add. 1 + 1.5 = 2.5... but what does the script think the answer is? 250. What happens if I do it again? 250 + 1.5 = 4. That's not a typo... Two-hundred and fifty plus one and a half equals four. Pressed again? 4 + 1.5 = 550... 550 + 1.5 = 7... 7 + 1.5 = 850, and so on. You might be thinking "Maybe something is else is being added or multiplied, or maybe something sets the variable?" Nope. I tried using a completely new variable. Same result. I even looked to make sure it's only being run once. The variable itself is being set to the correct number, but what's being displayed is something entirely different.
Remember how I said it was only with a fraction? Whole numbers work perfectly... It's only when it comes up against a fraction that it acts up, and I don't have a clue in hell as to why. Not even a professional software engineer friend of mine had any idea what's going on. We spent two hours looking into it, and neither of us can figure it out.
So, next time a game is delayed... hopefully you'll understand why. We don't have a magic wand, for crying out loud. When something's not working, sometimes there's no rhyme or reason for it, and sometimes, no matter what we do, a script just refuses to work. Gamers complain that we delay the game, but if we don't delay the game to fix the bug, you'd complain about the same bug the delay was intended to fix.
Sorry if I come off harsh. I have a pounding headache. If you know what it's like to have to debug a script, you understand. It takes a lot of mental energy to debug, and the longer one has to do it, the more drained you get and the more tired out your mind becomes. The more tired your mind becomes, the more trouble you're going to have continuing to debug. Right now, I feel like rearranging my keyboard layout with my face, and I'm 0% closer to fixing this bug than when I first discovered it 4 hours ago, and I have just one more idea left to try, to solve it. When a code refuses to be fixed, we then have to scrap the script entirely, think of a new way of pulling it off, and build it again, hoping new bugs don't pop up. We developers can code all day long, but the part we dread is a script that doesn't work. When a script doesn't work, we waste time that could go into anything else, and toil away to fix the one that has a problem. Sometimes it's no so bad. Usually, by toying around with the code, we can get hints or narrow it down enough that we figure out what's going on. Other times, there are no hints, and no narrowing takes place. No matter what you try, all you can do is stare at a code that almost seems to hate you, and all that you are.
Imagine yourself walking through a maze carrying a 50lbs bucket of bricks. It may seem like no problem at all, at first, but the more wrong turns you take, the longer it takes to finish, and the more fatigued you become. That's a great analogy for debugging.
And I'm indie. I get to go to bed whenever I want. Take a few days off and come back to it later when I have an alternate way of accomplishing what I want. I can't imagine what it's like for AAA devs who are on a deadline and have to work in an office long into the night to get done on time.
Update: I got it! Remember that 'hint' thing I was talking about? I tried my last remaining idea: moving the display to a different script entirely, and figured out what it was. You ready for it? It was the font. That's it. The font I was using was set up to use only letters, numbers, and some of the special characters. Just by chance, excluded from the range of characters it was permitted to use were "/" and ".". So when it went to display the decimal point, it lacked the period with which to do so, and what is 1.5 without the period? 15... I don't know where it was getting the zero from to make it 150, but that's what was happening. And now it all makes sense.
Do you see now? Do you see what we put up with? All I had to do was adjust the font to allow it to use the two missing special characters, and just like that, it was solved. 4 hours of modifying script, testing, changing variables around, and all it turned out to be, in the end, was the character range of the font was two characters too narrow. And if I hadn't realized that, if I hadn't had that one last idea to try, and if it hadn't clicked in my mind at the very last second, I would never have been able to solve to problem.
If anyone ever tells you they think game development is easy, link them to this post.