Week 2

Highlights:
  • This week was mostly filled with gaining a deeper understanding of the implementation details of Path-finding that is implemented.
  • After finding out that even a simple form of path finding was not working, I changed focus into trying to figure out what was wrong and trying to fix it.
  • I was able to implement a simple form of slope inclusion into the path costs (without facets) and opened a PR.
  • I was able to draft up an optimisation to the current path-finding that would allow us to know whether the target node would even be reachable before even trying to start the pathfinding algorithm. (PR will be finalised after discussion with casals)
  • I was able to narrow down the issue with empty paths being returned to the fact that walkable blocks were not being connected or initialised with their neighbours. I believe that this is happening because the NavGraphSystem is not keeping track of the added blocks (which are added in DC. Example, while filling the floor beneath houses). The entities then request a path from a point that supposedly seems like a point in the air (for the NavgraphSystem atleast).Hence, no path is returned.(Simply because there are no connected walkableblocks to the block in the air.) I opened an issue with my findings. (Hopefully resolve this soon).

Blockers:
  • Integrating SteepnessFacet information into pathfinding.
  • Taking a lot of time to understand the nooks and crannies of the implementation of pathfinding.
  • A way for testing paths.

I was of the impression that MetalRenegades did have some sort of primitive path-finding system incorporated into MR. However, only a direct-line travel exists with some jumping (and a lot of getting stuck in weird places). That explains the gooeys jumping against the walls. So I decided that fixing this was the most important because only afterwards would I be able to test the amount of time it takes for paths and things like that. The issue happening currently is probably related to the NavGraphSystem unable to detect the changes that happen through DC placing the blocks. (For example, while filling )

With respect to integrating slopes into pathfinding. I was unable to actually integrate the steepnessfacets into pathfinding itself because the regions that were defined within the module is different from the actual regions and I wasnt able to figure out a way to plug it in. Hence I implemented a much simpler version that would approximately give the right value.

This week, I also came across this idea where we could mark all the reachable nodes with a particular id. Thus, only if both the start and end nodes had the same id, would the search even start thus saving us a lot of time. However, this has an added complexity when dealing with NavGraphChanged events as the whole region would have to be again filled with ids. For example, if a region was seperated due to blocks being placed, then the different regions would have to be given seperate ids. Again, if a block was removed, or a connection between regions was made, both the regions must now have the same price. These would require utility functions again which would run a simple flood fill on the regions. (But there might be some interesting edge cases).