>>110108496
getting along with this
the path planner is essentially Dijkstra's algorithm
i found this blog post to be quite insightful on the topic of grid path planners https://www.redblobgames.com/pathfinding/grids/algorithms.html
the corner graph vertices are effectively the waypoints
the routes and algos for this are owned by the engine, and the engine only depend on the world grid and it's blocked tiles (obstacles)
blocked tiles are provided by the system that knows about them, that system is also the one to set the dirty flag on the flow field
the path finding system calls engine code to re-build the routes if the world has been modified and then updates movement for applicable entities
invoked by the system, owned by the engine
this makes the path planning algorithm easy to replace if sneeded
void pathfinding_system_c::execute() const
{
if (world_.flow_field.dirty)
{
rebuild_routes(world_);
}
// Attaching a runner_arrived_s changes the arrivals store, not the set of entities, so it is safe inside for_each_alive.
world_.registry.for_each_alive(
[this](entity_s entity)
{
game_ns::runner_s const* const runner = world_.runners.try_get(entity);
world_position_s const* const position = world_.world_positions.try_get(entity);
game_ns::velocity_s* const velocity = world_.velocities.try_get(entity);
waypoint_s* const waypoint = world_.waypoints.try_get(entity);
if (runner != nullptr && position != nullptr && velocity != nullptr && waypoint != nullptr)
{
steer_runner(world_,
{.entity = entity, .runner = *runner, .position = *position, .velocity = *velocity, .waypoint = *waypoint});
}
});
}
the engine is integer arithmetic only, vertices are stored in a fixed order
the same grid and goals give the same vertices, so the system should be deterministic across hosts and peers
