Day 6 - Yep, you guessed it...

Still debugging the movement issue... but... that is literally the core mechanic of my game. It's got to be right.

I have 2 similar functions that are used for different purposes... sometimes, it's helpful for me to add visual debugging cues, so I made all the cubes from one routine to be yellow, and all the cubes from the other to be blue. This turned out to be really helpful:

So then I knew that the blocks rolling around in general were using one routine, and the blocks climbing down into place were using another. I thought that was the case, but this was a very simple way to tell.

I should stop here and tell on myself at this point... I'm using a not great code practice of having 64 objects (for an 8x8 image) with a code routine on every single one of them. I've tried some larger image formats in the past, but it was just too much. How much better would this be if I moved all that code to just one routine that looped through all the blocks and moved everything at once?

It's really hard to say.

And that's kind of the part that sucks. I do know if I want to move to larger images, I'll have to do that. I hope that I can get away without doing that for this, because that would mean another big re-write of the block movement code.

(...and we're currently on major iteration 5... for this unreleased game... starting to see why it's been on my hard drive for most of a decade and not released yet?)

But back to the blue and yellow blocks... allow me to get philosophical about the code for a minute here.

While it's amazing to be able to create your own debug tools...
you have to balance that vs making the game better (or finished)

Is it worth the time? Is it worth spending 10 minutes?

Yes, almost always.

Is it worth spending 10 hours just to debug one aspect of the game? That's a lot harder to answer, unless you've already got 5 hours in, and don't see a way this gets resolved anytime soon.

At the one hour... or two hour mark... it's a LOT harder to say, "yes, this will be worth going down the rabbit hole to build a bunch of extra debug stuff that I literally may never use again"

But at the same time.. you can put developer debug stuff into production builds.

Not Debug.Log statements, of course (that'll make your game slower than molasses in winter) – but one of the large project I launched had a fairly elaborate system that would allow me to turn on a bunch of debug stuff on anyone's phone if I or my business partner were standing there. Tap here, then tap here, then tap here, and if you tapped those 3 things in sequence and touched nothing else while doing so – then it brought up debug info.

Side bonus: people were always amazed when we did that.

Back to this...

my first question: can I do something that gives me a good value on mobile?
second question: how does that value work on desktop?

As it stands now...

• block movement in the editor is still fastest (and it should really probably be slower, for a variety of reasons, every time)
• desktop webGL is optimal at 0.75 speed
• mobile webGL moves at an optimal 0.5 speed... but it's lagging BAD. it takes almost a full second after the block lands before the sound triggers. that's bad.

So my terrible conclusion at the end of day 6 is that something is lagging it all out terribly bad.

I know debug log statements are off in the project, so that's not the issue. It could be the new code I added to try to smooth things out... Not sure if day 7 will be more debugging or if I should get back to the menu system.