28th of March 2024
Good evening!
Yesterday I wanted to fix the outstanding, since day 1, bug where sometimes the gems that you rotate flip around to wrong positions on release. I have an inkling that I know what causes it, but all my previous fixes have not been successful. The current version checks the closest hexagon empty hexagon cell to attach the held gem to, and then in a round robin fashion does the same for all the others. If the gems happen to be on the edge of the cells, some of the intended cells get to be filled before the correct has it's chance to get attached to it, and the gems "flip".
It's very difficult to reproduce, so I opted to figure out some debug visuals to help me understand the problem. I figured out a way to go thru the gems so that everytime the gems cross the cell threshold, the assigned cells just rotate around. This works well, in theory, and actually, when testing practice, it seemed to do the trick too!
...however. If the change isn't from one cell to the next, but for instance, from top to bottom (which you can do if you go through the center gem fast enough), it goes haywire.
So yeah, that's a problem. I think I could fix this method of handling the gems too, but I feel like this one is a lost cause. So, the next idea: First, when starting rotation, get the vector from the anchor gems cell to the next cell. Then, when I am calculating the correctly assigned cells, rotate that vector with the same rotation that has been done to the rotating gems. Now, get the anchorgems cell normally, by just translating world position to cell position. This is gem 1, or the anchor gem, or the one gem you are "holding". Now, get the world position of this cell position, to get the cell center position. Now, add the vector to this center world position, and get the cell position for this position now. This is gem 2. Then rotate the vector by 60 degrees (360/60). Rinse and repeat.
I feel like this is a lot easier to implement and also would result in a definitively zero amount of position-flipping gems. I'll be trying to implement this today, and maybe fix some other bugs too.
Oh yeah, I'm going to be making a change to my versioning. Currently I have X.Y.Z where X is either 0 or 1, 1 meaning release, Y is the current development milestone, and Z is the build/commits since version number. Well, I'm not actually going to change that, but how Y behaves: currently I've been adding new features to the same Y version, and then when I feel like it's "done enough", I'll increase Y to the next level. However, that feels a bit like I can't "trust" the Y version number to really mean anything. For instance, a 0.2.1 is a LOT different from 0.2.90. So, going forwards, I'm trying to have an odd Y to mean "we are implementing new and possible experimental features", so basically what is happening now with all Y version, but even would then mean "the features we introduced in Y-1 are now 'good enough' and this is the 'official' release".
What this means is that I'll be promoting the current version to 0.4, and once I start working on something like improved account handling and some menu stuff, or Android ads, or puzzle mode, I'll increase the version number to 0.5, implement them within that version number and once I feel they are good enough, I'll promote that to 0.6, which denotes that "it's preliminarily done" but I'll keep fixing bugs on it.
To put it short: Odd ones (like 0.5) are unstable, and even ones (like 0.6) are stable - not that stability has anything to do with (or well, maybe a little).