Day 4: Debugging Movement

Debugging is rarely fun... but always necessary
Status: Completed Read year: 2025
Image of a grumpy cat dressed up like a clown.
A grumpy cat, who was also probably debugging movement.

Today, I imported the menu system into the actual project and started thinking about what else I need in there (e.g. the ability to call that code and change panels from other places and vice versa).

I mentioned "infrastructure" in my Day 2 post but that's not a term people often associate with games. But it's a critical piece. The infrastructure is all the stuff you need to build the stuff, basically. And, not terribly unlike programming, if you do your job right, nobody notices, because everything just works.

With the menu imported (but nothing beyond that), while playing my game over and over (I'll talk about that another day), I noticed a speed disparity between desktop WebGL and mobile WebGL... (not to mention the editor, which is much faster than either)

I've run into this a little bit in the past where the game would run faster on fast machines and slower on slow machines... (we call that "technical debt" in the industry) and that's not terribly uncommon and usually easily fixed with Unity's Time.deltaTime but I was not going to be so lucky, as I'd find out in a few days...

💡
Technical Debt refers to issues in a project we're aware of, but delay addressing until "later" -- and it absolutely, positively, will ALWAYS show up later.

While time.deltaTime usually does the trick, sometimes it's harder to implement than other times (and this is one of those times where it's harder) but this actually made the speed problem worse. (at least in the editor)

Now, sometimes, some of them go SUPER slow, even though the speed isn't different, according to debug logs.

Sometimes, it's just time to shut it down and go to bed...