I began diving deeper on the underlying grid in relation to the grid points and sparse nodes. It ended up simplifying the code. The issue is that the grid is hexagonal, which means that constant x, y, or z, all run in diagonal lines. Trying to treat it as a rectangle means things weren’t syncing up. What I ended up doing was iterating directly over the x’s and z’s. The result was a parallelogram, which (strictly speaking) the player will never directly see, as the actual game level grid points defined won’t typically be the full grid.

It did raise the question for me about the relationship between the number of screen steps and the grid. I originally planned to have the game level editor input the number of screen “steps”, and then it would compute the grid from that. But the grid being slanted makes it ambiguous about the grid should be. And perhaps some levels want a much smaller grid than screen space (e.g. if the background is quite extensive beyond the grid).

So now I’m thinking I might just make them separate. They already are internally. I’ll just have to expose them that way.

In some ways, it simplifies things. I don’t have to work out the “right” way to relate the two, given there might not even be one.

That will come tomorrow, hopefully. Go with editing the number of screen steps and then move onto sizing the underlying grid.

Another Sunday bites the dust. And it’s getting so dark and dismal these days. It’s not even close to winter yet.