I’m developing a turn-based combat game with movement reminiscent of typical turn-based combat games (eg. Baldur’s Gate 3). I’m currently struggling with unit movement and a problem I’ve tried to tackle for a couple of days. I’m posting a drawing I threw together since I believe it should correctly demonstrate my problem, but I can produce code snippets upon demand as well.
I’ve tried cropping the path based on eg. LOS raycasting, but that doesn’t really solve the problem as I’d need to consider eg. the number and direction of the points leading up to the target. I feel I need a more robust solution to this problem.
I’ve also tried tweaking navigation mesh parameters, such as error margins and cell sizes, but that hasn’t really helped either. Furthermore, retrieving the path using NavigationPathQueryParameters3D.query_path doesn’t really help as the parameters i’m using results in the same path as using map_get_path.
I’m fairly new to Godot but I have spent a substantial amount of spare time in Unity. I’m acquainted with how navigation works in Unity, and have implemented such a system before, since Unity may provide the path with respect to obstacles, unlike Godot.
Edit: Apologies for the shitty resolution. I could probably have upscaled it, but it should at least be readable
Update: I also posted on Reddit, where I was adviced to expand upon the raycasting approach, but to raycast from every point in the path generated by the navigation server. I guess this’d require me to design a potentially recursive function for traversing the path and continuously re-evaluating it before finally returning it to the player.
This sort of raises further questions on my end on whether I’m missing some best practices on how to design turn-based navigation in Godot.
Sorry this question slipped under the radar because it was not posted in the navigation sub section (only had the tag so did not show in the overview). So this answer is likely more for people that find this through search on a later date.
Games like Baldurs Gate 3 use a (tactical) grid and not a navigation mesh system.
A navigation mesh never can have the cell resolution and detail for such gameplay. If you try to create a navigation mesh with such detail you would create an inferior version of a grid so what is the point, use a grid from the start.
You can find information on the Baldurs Gate system in detail if you look at their previous two games Divinity Original Sin 1 & 2 that uses the same technical logic base. Their entire editor has documentation as the editor kit was public. You will not find something like this build-in in Godot because it is tailor-made for that very specific game type. All tactical games use something similar because it makes sense for that game type. The closest build-in in Godot would be using something like AStar2D/3D/Grid but if you want to recreate something close to what Baldurs Gate 3, Divinity Original Sin, or even XCOM games do you want to use a custom grid.
The Unity obstacles are not the same as Godot obstacles. In Godot obstacles are purely for avoidance by default. The Unity obstacles are objects baked to the navigation mesh because Unity (and Unreal for that matter) use the ReCast Detour kit and that makes a hard distinction between static level geometry from collision shapes and your runtime changed surfaces. Something that in Godot does not matter, geometry is geometry, an you would not need any special object for, e.g. you would just bake a normal collision shape.
