-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional project examples #126
Comments
Hey there :) you're on a roll! :D As long as the new examples are properly documented, clean looking and not all included in the addons (just the visualization demo), I don't see a reason why not! Although I'm unsure you could show performance difference in a demo and if it's interesting. The read me would need to be updated as well in order to direct people to the example ! Finally, the main scene could show a basic menu directing to each of the example! |
Great, then I'll get to work! I agree that there are some uncertainties to how effectively any performance comparisons can be made, but at the very least it should still be a helpful reference for those who want to see the implementation differences between DijsktraMap and AStar. And I'm sure we can make the demos interesting! I like the idea of making a main scene as a navigation to the other demos, will do! |
Maybe let's just do those one by one, easier to review and the review will probably be useful for the other demos as well |
Hey there! I was recently testing out the WIP Godot 4 compatible version of DijkstraMap, trying to fix up some of the outdated GDScript, and as part of that effort I spent some time looking through the 3 project examples included here. I think they all do a good job for what they are;
As nice as these examples are, I think there could be some value in creating additional ones to show more of DijkstraMap's aspects and practical applications, like:
I would propose the addition of two new example projects to the repository (which I would be interested in developing in the Godot 4 branch):
recalculate()
calls because each one would be starting at and going to different positions than the others. This is probably a good use case for the proposed "remote" dijkstra map #98 Remote feature, but it can be implemented without it until then. It would be nice to implement it such that the units are as loosely coupled from the map as possible while still sharing a 'base' DijkstraMap for its points. Ideally, the user would be able to select tiles to draw with, which would then invalidate the existing paths for each unit and force recalculation. Some caching strategy could be used to reduce the total amount of recalculations needed when the map changes or a point is reached.Are there any concerns about the scope(s) of these demo types, or whether they should be included in the repo? If it all sounds good, I could start working on them within the next week!
The text was updated successfully, but these errors were encountered: