Day 5: More Debugging

More debugging. Not exciting, but REALLY important for giving the users a good experience.

After narrowing the problem down to a couple of places... I've determined that, like in Physics, sometimes observing the behavior (via debug) does, indeed, change the behavior.

I think that this might be happening because of several things:

• deltaTime in the wrong place (before the call)
• the ceil command that multiplies duration * 30 (probably a throwback to the original code)
• this might be happening because it's on a bunch of objects, which is not a great practice, but it's too late to change at this point (I've tried) if I want this game out this year

I still need to determine if it fixed the speed issues between mobile and desktop and check back with some of the people where it was way too fast or way too slow.

Here's a preview of what I watched for... probably hours... BUT... and hear me on this, game devs... if you want your game to be full of bugs when the user plays it, you'll have to play LONG PAST the point where you're tired of playing it, to find those bugs, and fix those bugs.

First note (that I already knew, but you may not) – outputting LOTS of text via Debug.Log will 100% slow down your game, ESPECIALLY on the device. DO NOT leave those debug log statement in there when you ship.

pro tip: I don't delete, them, either... I just put them behind a boolean that defaults to false, so I can turn them back on later if needed, like these examples:

The good news is that with all that crazy debug output... I started to least see where the problem was... comparing 0.005 and 0.2 and you'll know that one of these things is not like the other.

If you want to make a really quality piece of software... this is just part of the deal.

If you don't play your game to excess and find the issues before your players do... you'll be sunk before you even get started.