Tile rework

[Adephx]

Doddler hi. I've skimmed through the code and as it seems that this project includes both the server and the complete client overhaul. Do you think that it would be feasible to scale down the main tile system, by let's say a factor of 5, which would offer a vastly increased freedom of movement and skill positioning. As long as we approximate tiles correctly, I can't think of a reason why this shouldn't be achievable. The fundamental game mechanics would essentially remain unchanged, with the new 5x5 tile system occupying the same space as one old tile, allowing for the central tile to serve as a pivotal position.

[Doddler]

I found the idea fascinating enough that I chose to give it a try. You can see the results over at https://twitter.com/RoDoddler/status/1765655554712879484?t=rR7RaBLMOVeFCQ6ZJOvODQ&s=19

I did it with a quick and dirty hack: because so much of the client relies on your world position matching your position on the map, after subdividing the map's navigation grid I chose to scale up the world/objects so the grid would remain 1 tile for 1 unit and the world itself be larger to effectively give the grid a smaller tile size. I also needed adjustments to the server for an increased max view/move distance, movement speed, and changing the animation speed of walking on the client sprite animator, but it's not too bad and I was able to get it working in just 2 hours. I don't think the pathfinding will hold up to the larger grid size though.

It's not in a state to commit at the moment, a bunch more work would need to be done and I'm not sure if I will focus on that in the short term. A lot of stuff is tied to that world position = map position thing which makes a clean implementation pretty hard at the moment. At some point I'd like to fix the client to support walk areas that aren't tied to their world positions with arbitrary positions and scales, and at that point it would be pretty easy to support any kind of grid size you wanted.

I will push the code I used to subdivide the walk mesh though, it will not run by default but it will be around for the future or to whomever may want to try making it work themselves.

[Adephx]

"Also for some unexplained reason I ended up with a 1.4Gb map file." If you scaled up the world/objects by a factor of 5, could it be that baking the lightning onto the textures also increased their size by a factor of 5, as I assume we are talking about raster not vector images?

"I don't think the pathfinding will hold up to the larger grid size though" Just throwing out ideas, but we could always add a new function to translate between the new grid and the pathfinding. The new grid is essentially the same, we just multiply everything by 5 and redirect the path to the nearest pivot point of the 5x5 grid. Should be simple enough as long as we don't perceive the new grid as one big grid, but a grouping of 5x5 tiles instead. It's not perfect, but path would be at most one old tile away from the correct position.

[1][1][1][1][1]
[1][1][1][1][1]
[1][1][1][1][1]
[1][1][1][1][1]

vs

[5*5][5*5][5*5][5*5][5*5]
[5*5][5*5][5*5][5*5][5*5]
[5*5][5*5][5*5][5*5][5*5]
[5*5][5*5][5*5][5*5][5*5]
[5*5][5*5][5*5][5*5][5*5]

[Doddler]

Aah, about the size, I did figure that one out. I hadn't baked lighting so that wasn't that (and cutting the unit size in the lighting settings accordingly would probably be enough). Main issue though is that the walk grid has it's own mesh as well in the same way the ground does (you can hit tab to see it), and it's increased size made some mistakes more obvious.

Main one how large the map becomes with each vertex containing too much data. With the way I had it set up, each vertex was 64 bytes (12b position, 12b normals, 8b uv, 16b tangents, 16b color). A map the size of prt_fild08 is 400x400, scaling it up by a factor of 5 gives you 2000x2000. That's 4m tiles, 8m triangles, 16m vertices, and at 64 bytes each gets you up to 1Gb. I can cut that down to 20 bytes (normals, tangents, colors are unnecessary), and compression mostly saves it as the map complete on disk (with lighting data) remain in the 10mb-40mb size, but it's still a lot of mesh. It's not a big impact performance wise, they aren't rendered and the collision mesh is only used for raycasts and unity handles that pretty well.

That said, the walk mesh has no real need to be 1:1 with what they represent, it's primary use is cursor/ray intersections and keeping characters grounded, there's no reason you couldn't just merge continuous surfaces into larger polygons and shrink it drastically. If you don't make any changes to the walk areas you at very least should end up at the same size the original mesh was.

But going farther back, you don't necessarily need to stick to a grid at all. A lot is tied to it, but in theory there's nothing that wouldn't allow you to travel fractional distances on a tile. Would take a lot of refactoring to make that work but it's an option as well.