Okay, more debug lines, more mostly-complete-but-still-requires-work contributions.
This time, enemy pathfinding. There are many different approaches to this. For example, you could choose the A* algorithm (as this PR does), or other search algorithms. Then you need to decide how to break the world down into navigatable space for the algorithm. This PR uses a grid which maps directly to the tiles, instead of a more efficient nav-mesh. This is because my experiments with nav-mesh'es were not as successful. It does have the added perks that it is simple to add in features such as "enemies walk slowly over sand, so prefer roads" by adding specific costs to each terrain based on the tile type. This is not implemented yet though.
Then there are countless ways in which the process can be optimised. This PR tries to minimise the amount of times each enemy needs to recalculate its route by following along an existing route until the tank moves elsewhere. In practice, this means only once every several frames. However, future improvements would include only recalculating not just when the tank moves to a different tile, but when it moves several tiles away. It could also be done on a background thread so as to not slow down the rest of the game as it happens (it is not crucial in most scenarios to have it running from the first frame an enemy is spawned).
There are some edge cases, where it falls over when you go near the edge of the map and it tries to wrap around to the other end in error. The code is also not super well structured, because sometimes you need to know the world coordinates of the object in world coordinates, and other times you need the "vertex" in the pathfinding grid. It would be good to tidy this up a little bit.
Soon, we should add some debug key-bindings to enable/disable the Debug.DrawDebugLines feature. Better yet, once in debug mode, we could optionally have "[P] to show pathfinding results, [G] to show pathfinding grid, [C] to show collision bounds" (etc).
Okay, more debug lines, more mostly-complete-but-still-requires-work contributions.
This time, enemy pathfinding. There are many different approaches to this. For example, you could choose the A* algorithm (as this PR does), or other search algorithms. Then you need to decide how to break the world down into navigatable space for the algorithm. This PR uses a grid which maps directly to the tiles, instead of a more efficient nav-mesh. This is because my experiments with nav-mesh'es were not as successful. It does have the added perks that it is simple to add in features such as "enemies walk slowly over sand, so prefer roads" by adding specific costs to each terrain based on the tile type. This is not implemented yet though.
Then there are countless ways in which the process can be optimised. This PR tries to minimise the amount of times each enemy needs to recalculate its route by following along an existing route until the tank moves elsewhere. In practice, this means only once every several frames. However, future improvements would include only recalculating not just when the tank moves to a different tile, but when it moves several tiles away. It could also be done on a background thread so as to not slow down the rest of the game as it happens (it is not crucial in most scenarios to have it running from the first frame an enemy is spawned).
There are some edge cases, where it falls over when you go near the edge of the map and it tries to wrap around to the other end in error. The code is also not super well structured, because sometimes you need to know the world coordinates of the object in world coordinates, and other times you need the "vertex" in the pathfinding grid. It would be good to tidy this up a little bit.
Here is a little (grainy) demo:
https://github.com/rblackmore/IGE.TankShooter/assets/248565/7a53c1be-1209-4716-a66c-ac395a267ba9
Soon, we should add some debug key-bindings to enable/disable the
Debug.DrawDebugLinesfeature. Better yet, once in debug mode, we could optionally have "[P] to show pathfinding results, [G] to show pathfinding grid, [C] to show collision bounds" (etc).