Fly-In
A drone traffic controller that moves a fleet through a graph where every hub and every edge has a capacity limit.
The problem
Hubs hold a limited number of drones, edges carry a limited number per turn, and restricted zones take two turns to cross. Send every drone at once and you get gridlock; send them one by one and you waste turns. It looks like pathfinding, but it’s a scheduling problem.
What I built
A command-line tool that reads a small map format and prints a turn-by-turn schedule, with an optional 3D replay. Each drone is planned with A* over space and time, and its route is stamped into a shared reservation table that every later drone has to respect.
- map.txt
- Parse & validatePydantic models
- Backwards Dijkstratrue turn cost from every hub
- Space-time A*one drone at a time, reserving (place, turn)
- Turn-by-turn log
The thinking
Planning all drones together explodes, because the search space is the product of every drone’s options. Planning them one at a time, against the reservations of those before, keeps it tractable. The side effect: when two drones want the same corridor, the second shifts back one turn and a convoy forms without any code asking for it.
What I learned
The heuristic decides whether A* is fast. Straight-line distance is the wrong guide when one edge costs two turns, so a backwards Dijkstra from the goal computes the real turn cost from every hub before any drone moves.
What I’d do differently
Planning one drone at a time is greedy, not optimal. An early drone can box in a later one. I’d add a re-plan step that reshuffles the order when that happens.
Numbers
43 turns
to land all 25 drones
Hardest map — 54 hubs, 70 edges.
0
collisions or capacity violations
By construction; every conflict is a reservation miss.
~55 ms
to plan the whole fleet
Warm run, 25 sequential searches on the hardest map.