Layout optimization algorithm

It took an entire day, but I did it. Hadronize will now automatically adjust 5 different layout variables in order of priority to make everything fit on screen.

I think that the algorithm is probably the most complicated part of this entire project. I’m going to try to explain it really simply in this devlog, but if you want to see how it actually works, I wrote a bunch of comments that explain the priority pipeline in this file.

So basically, every time a new layout update is triggered, the layout manager calculates a brand new layout plan from scratch. Once it’s finished calculating, it applies the layout plan onto the actual layout variables that are used to move the quarks on the screen. If I modified the layout variables directly, the rapid-fire modifications while calculating would trigger a bajillion reactive updates from Svelte which would slow the page down.

Anyways, the way that the layout plan is calculated is that it starts by assuming ideal conditions: there is more than enough room for everything to fit comfortably. So it does the calculations using the preferred ideal variables, it modifies the plan, and then it actually checks to see if anything is overlapping. If there is any overlap, it tries to resolve it using the least-disruptive adjustment it can make. If that doesn’t work, it tries the next least-disruptive adjustment. And so on. Also, each time it moves up the chain of disruptiveness, it tries to use the ideal variables for all of the less-disruptive adjustments. If that makes sense.

Here are the adjustments that it can make, in ascending order of disruptiveness:

1. Increasing the radius of the ring of quarks of a single chamber
2. Adjusting the radius of the ring of chambers around the center of the screen
3. Switching chambers to use count mode, which is when it only displays the number of quarks of each flavor rather than displaying each quark individually.
4. Switching the global layout from ring mode to grid mode. This is the thing that I built last devlog.
5. Decreasing the size of all quarks

I’m pleased to report that when I tested it on my phone, everything worked perfectly. I still haven’t implemented mobile input yet, but I started a 6-player game of all bots, and the layout planner managed to keep all of the quarks visible all of the time, even when a single chamber had more than 20 quarks. Never once did I see two chambers overlap with each other or go partially offscreen, which used to happen 100% of the time on small mobile screens. It just changed layout modes and decreased the quark size whenever it started to run out of room.

Anyways, I’m not going to merge the new layout planner just yet because I’m not 100% sure how stable it is, but I’ll do that soon. Next up is mobile input.