You know when I said that there’s an instance where there’s tiles that have the identical z value? Yeah I think I’ve may of found a workaround for it.

What I plan to try out is that instead of just adding the z and y values, I’ll separate the two into sprite z and sprite y variables,

Imma get a little 🤓 for a second bear with me

Trigger warning for a lot of math read with caution brain frying will be possible

Which sprite z will be the z position on the grid starting from 0, and it’ll multiply that by 180, the reason why it’s 180 is that for the tiles there’s about 6 tiles in the y direction, and the tile size is 30(idk why I decided to make it 30 instead of 32, but it is what it is ig) and 30 multiplied by 6 is 180!

For the y is much more simple, it will just be the y of the tile which is already in 30s, and if I need to scale the player’s hight up by tiles, I’ll just have to add 30*the number of tiles up, lets just say 2 for example

So 30*3 is 90, and if the player is in row 0 in the z direction, which will be 0, the players z order will be 90

Which the z order in the next row will be 180, which 90 is less than 180 so the player won’t be on top of that tile!

Which if I was using the current way that the z order is set up the player would be in front of that tile

Basically to shorten it all up, I’ll just have to create another tile system for displaying objects, for the tiles will be easy, but for the players and other objects, I might have to do a bit more calculations to get things down, but I can proudly say that I’m on the right track!

I’m not gonna try it out right now, I still gotta think more about this before I even plan on doin it, but I feel this might actually be the solution