Currently 1 chunk is spawned at setup, but they should be streamed in depending on player position.

Also requires (now or eventually) the ability to shift the center point of the simulation to a different point on the planet (which is measured using f64's ).

This might be worth forking petgraph. A PR could then be made to suggest this feature be upstreamed to petgraph, but I'm not sure if the additional complexity would be desirable to the maintainers.

My idea is to create structs that track the state of the algorithms, (starting with AStar, since that's what I'm using now), and have methods that step the algorithm little by little.

Navmesh graph is implemented for the heightmap, now I need to be able to select a random node in the graph and find its position in the world. Also needs to extend to other nav graph node types and connections between them in the future.

• Start with heightmaps. Pickup bubbles will benefit immediately.

• Replace leafwing_abilities with bespoke ability system
• Primary fire
  • (might still shorten range and widen effect)
• Secondary fire
  • Thinking bow-and-arrow like
• Tertiary fire
  • Battle axe/warhammer like
• Ability pickups?
• Movement abilities

Tracking issue for multiple enemy types and prerequisite issues for them.

• Dummy/Mining probe
  • Currently spawning capsules in the middle of the world,
  • New mesh
  • Spawn on terrain -- requires #16
• Quadcopter
  • Mesh
  • Mid-air pathfinding
• Rover
  • Mesh
  • Stitched chunk pathfinding
• Hopping/Jetpack enemy
  • Mesh
  • Land-air-land paths

At a bare minimum, entities need to be able to travel from one chunk's heightmap to another. Ideally, they will also be able to find floating islands, buildings and other structures, and vehicles they could reach as well. This results in a combinatorial explosion of possible edge types. I do not want to use dynamic dispatch in this case, because the possible kinds of edges will be known at compile time, and dynamic dispatch would completely eliminate the compiler's ability to inline and optimize edge filters. Also, matching on an enum would force all possible combinations to be handled, while a trait might hide unhandled cases.

Proposal

Rather than just matching on all possible pairs of edge targets, I believe a sort of manual jump table would be possible. Something like this:

// Could be 2 separate structs, but genericness ensures both are kept in sync.
struct EdgeFilters<H, S, F, V> {
    heightmap: H,
    structure: S,
    floating_island: F,
    vehicle: V,
}

// Would probably want to make a macro for this:
type EdgeFilter = EdgeFilters<
    EdgeFilters<fn(&HeightmapNode, &HeightmapNode) -> bool, fn(&HeightmapNode, &StructureNode) -> bool, /*...*/>,
    EdgeFilters<fn(&StructureNode, &HeightmapNode) -> bool, fn(&StructureNode, &StrutureNode) -> bool, /*...*/>,
    /*...*/,
    EdgeFilters<fn(&VehicleNode, &HeightmapNode) -> bool, /*...*/, fn(&VehicleNode, &VehicleNode) -> bool>,
>;

This would also allow built-in filter functions like

fn all(a: &impl Node, b: &impl Node) -> bool { true }
fn none(a: &impl Node, b: &impl Node) -> bool { false }

// usage:
// ...
heightmap: all,
// ...

to be re-used.

Then the only match statement would need to be in the nav graph traversal code. All custom filters would simply fill out the matrix of function pointers, being forced to handle every case with the correct type parameters.

Of course having to manually specify at least 16 function names for every single AI agent would be tedious. Struct update syntax would help a lot, but I'm not sure I would want to allow ..default(), because then we're back to being able to forget to handle specific cases. Perhaps constants could be defined instead, like:

pub const ABSOLUTELY_ALL_EDGES: EdgeFilter = EdgeFilters::</*...*/> { heightmaps: ALL_EDGES, /*...*/ };

This would allow terse definitions, while making it clear what the "default" behavior will be. Of course I'm not even sure if bool is what will be returned. This probably needs to be used to handle costs as well.