It's hard to say, with the compute tasks you don't get frame drops but you can notice the dudes waiting for their pathfinding job to complete for a little bit with larger grids (>200x200). Frame lag would be driven by other systems like sprite rendering
Are you copying the entire grid for every entity pathfind query in every frame? That seems expensive. I would instead do 1 grid copy at the end of `fn wander()`. And spawn many tasks all sharing an immutable grid.
Yeah I am. That's one of the optimizations worth looking more into. You would need to put it behind a shared pointer. In practice the limiting factor is the raw cost of astar and not the clone in my quick profiling though so I haven't dug into that yet.
@@logicprojects Yes I agree. The overall cost is still dominated by astar. But the astar time cost can be hidden by the async nature. But the copying is not async to the game loop. So this causes the most amount of game loop lag.
Great videos. Can you suggest any ideas or resources on enemy entity field of vision. Such as a metal gear solid where enemies have a cone of vision to determine if your character is visible to them.
I'm moving into AR. I found a great middle ground, for now. Unity with C#, but calling into Rust libraries that I build. This would allow best of both worlds for now. Haven't done anything yet - still have lots of AR training ahead of me. I want to get past the basics. I hated the thought of losing Rust though - put so much time in. Gonna move back to Bevy once it gets OpenXR integration. this pathfinding is a perfect example. Run that on a whole bunch of items.
I haven't looked into much AR myself but I have started toying with bevy on Android. I'm excited to give it some more time when they have a prototype OpenXR ready
@@logicprojects - there's a lot of great training out there for Unity even if you don't plan on using it - shows you what you can do. Then when OpenXR comes to Bevy, all the concepts are solid. Can't wait for it to come to bevy, but I don't mind using unity for now.
@@logicprojects - It also looks like the "Component Model" is coming along, so should be able to use Rust compiled to Wasm inside a WebXR app in Unity. Don't know how far out that is. Not sure if Unity compiles to Web GPU (vs webgl) yet either, but likely soon if it doesn't support it already.
Hey, with the Grid struct, what happens if an Entity is despawned from the game? Do you have to go and manually find that entity in the grid and remove it?
I have systems in the grid plugin that should keep the grid accurate. Specifically in the grid.rs file in the source (in description) I have a remove_from_grid system that uses RemovedComponents to check for despawns and clean the grid. My main open problem is if 2 entities have the same location the only the most recent will be properly in the grid but I mitigate that with an error log message
It's not slower for the games I like to make that are more procedurally generated. If anything it's faster for me because the editor doesn't really get you much if you're not laying out scenes. Bevy is also missing some of the other built in editor tools like animation state machines and particles. There are plans for a bevy editor this year though!
Just wanna chime in here.. if you are building a 3d game with scenes where the position and orientations of the objects in the scene need to be taylored, I do not recommend doing that in bevy+rust, I recommend using something like blender to export a gltf (glb) and load that with bevy. @@logicprojects
May take a while until I start working on the pathing. But good ref still I wonder about the 3D which is tricky since I no clue how it works. I bet it a lot of work and depend how it build.
I'm sure there's a lot of resources out there. This crate is just the raw algorithms. I think Unity's navmesh is the general solution where each triangle in a mesh would be one of the graph points you feed into astar (if I understand it right)
Probably actually wouldn't be that bad. This grid is just entity references and I tested on maps larger than df. Multiple z levels would start to push it though, definitely a smarter connected components approach would be needed at some point
