Hi,
Yes one per frame. Terrain editing is the main feature of the game so i’m currently aiming for the terrain to reflect user height and surface edits in real time. I expect i could cut out some of the work. It’s a golf game where the grid graph contains the navigation cost for players walking and surface desirability for hitting the ball to. I’d actually like to separate this into separate grid graphs. This means that it needs to be updated as the surface (green, fairway, rough) are painted.
As height is painted i need to make some nodes unnavigable so that players can’t walk up steep slopes as well as keep the nodes at the correct height (is this necessary?).
Thanks
Do they edit the terrain at the same time as they are playing?
Otherwise, you might be able to just wait while the player edits the terrain, and then when they are done you recalculate everything in the affected region.
Think of it a bit like cities skylines terrain editing where it’s realtime whilst the simulation continues.
I probably could stragger the nav updates over many frames but I’d rather only do it if I have to. So at the moment are you suggesting there is nothing further i could do except reduce the workload per frame?
If I can optimise the rest of my terrain editing per frame costs i might be able to swallow the cost of the astar update.
Thanks
Other than that, no I don’t think so, I’m afraid. I’ve optimized that code quite a lot already.
Ok thanks,
I do still find it strange that you couldn’t repro but who knows what the differences in the projects is.