1 · The big picture
The program is a pipeline. Data flows left to right, and every box has exactly one job.
Blue = what you build first. Orange = the algorithm. Green = what the evaluator sees.
The most important idea on this page
Keep static and dynamic apart. The Network describes the map, like a printed railway map. It never knows which drone is where. Positions and bookings live in the planner and simulation. Most "I'm stuck" moments in Fly-in come from mixing the two.
What each box may and may not do
| Part | Does | Never does |
|---|---|---|
| Parser | Reads text, checks every syntax rule, reports line N: reason, builds the Network. | Pathfinding. Printing the simulation. |
| Network (models) | Stores zones and connections. Answers small questions: "neighbours of X?", "capacity of X?", "cost to enter X?". | Reading files. Knowing about turns or drones. |
| Planner | Finds routes, books capacity per turn, decides who waits. | Parsing. Printing. |
| Simulation / Display | Steps through turns, prints D1-zone lines, adds colour. | Deciding routes. |
Why split it like this?
You can test each box alone
The models work without the parser (you build a map by hand). The parser works without the planner (you just print the Network). If something breaks, you know which box it is.
It's what "object-oriented" means here
Each box is one or more classes that own one kind of state. In the evaluation, "which class owns this data?" should always have one obvious answer.
The same map, in each box
# 1. Map file (text)
hub: waypoint1 1 0 [color=blue]
# 2. After the parser: an object in the Network
Zone(name='waypoint1', x=1, y=0, zone_type=ZoneType.NORMAL, color='blue', max_drones=1)
# 3. In the planner: a booking
"waypoint1 holds D1 at turn 1, D2 at turn 2"
# 4. In the output
D1-waypoint1
D1-waypoint2 D2-waypoint1