Inspiration
We were inspired by the gap between the UAM "gold rush" and urban reality. Dozens of companies are building incredible aircraft, but no one has a clear answer for how they will all coexist. The sky is not a road; you can't just paint lanes.
Our inspiration came from two places:
Formula E: The prompt mentioned it, and it's a perfect analogy. It's a race with high-tech vehicles where strategy (like battery management) is just as important as driver skill. We wanted to build the simulator that would let teams test those strategies.
Ant Colony Algorithms: A single ant is simple, but a colony displays complex, intelligent behavior. We realized we didn't need to simulate one hyper-realistic drone. We needed to simulate 10,000 simple drones, each following a few basic rules, to see what emergent, large-scale patterns (like "sky-jams") would appear.
What it does
AetherSim is a lightweight, agent-based simulator designed to model and "race" competing Urban Air Mobility (UAM) services—think air taxis, delivery drones, and eVTOLs (electric Vertical Take-Off and Landing aircraft).
At its core, AetherSim is not a heavy-duty physics engine or a video game. It's a strategic "what-if" tool. It allows a user (like a city planner, regulator, or a UAM company) to define a map, spawn thousands of moving "agents" (vehicles), assign them different operational strategies, and then bombard the system with events like passenger requests, weather alerts, and battery failures.
The output isn't a beautiful 3D render; it's a live, data-driven leaderboard that answers critical questions:
Which company's pricing strategy yields the lowest passenger wait time?
How does an "aggressive recharge" strategy (recharge at 50%) compare to a "run-to-empty" strategy (recharge at 10%) in terms of total flights completed?
What happens to city-wide airspace congestion if two competing services try to use the same "sky-highway" during rush hour?
AetherSim is designed to be the "digital twin" for a city's airspace before the first real vehicle takes off.
How we built it
- Core Engine: Event-Driven & Agent-Based
We chose an event-driven architecture over a real-time physics loop. This is the "lightweight" secret sauce. The simulation doesn't run in "ticks"; it jumps from one discrete event to the next.
The Event Queue: A central priority queue would manage all future events: (timestamp, event_type, payload). For example: (12:01:05, "PASSENGER_REQUEST", {from: 'A', to: 'B'}), (12:01:10, "BATTERY_LOW", {agent_id: 101}).
Agents: Each "air taxi" is just a simple object: { id, company, location, battery, status: 'IDLE' | 'FLYING' | 'CHARGING' }.
- The Environment: A Graph
The "city" isn't a 3D model; it's a directed graph.
Nodes: Vertiports, Recharging Stations, Key Waypoints.
Edges: Flight Corridors (with properties like distance, max_capacity).
- The "Strategy" Module (The "Secret Sauce")
This is the key to "competing" services. Each company in the simulation gets to upload a simple "strategy script" (e.g., a JavaScript file) that defines how its agents respond to events.
Example Event: onPassengerRequest(request, all_my_agents)
Company A Strategy ("Closest First"): Find the closest idle agent and dispatch it.
Company B Strategy ("Dynamic Pricing"): Find the closest agent, but if demand is high, increase the price by 20% first.
- Frontend: The "God-View" Dashboard
A simple React web app using Mapbox or deck.gl to visualize the agents (as 2D dots) moving on the map.
The main feature is the live-updating leaderboard, showing KPIs (Key Performance Indicators) pulled from the simulation backend via WebSockets.
The Proposed Tech Stack
Backend Engine: Go or Python (with asyncio) for a high-performance, event-driven simulation core.
Frontend Dashboard: React with TypeScript for a modern, type-safe user interface.
Data Visualization: deck.gl and Mapbox GL JS for high-performance 2D/3D visualization of thousands of agents on a map.
Real-time Communication: WebSockets (e.g., using Socket.IO or a managed service).
Strategy Engine: A sandboxed JavaScript (V8) environment embedded in the backend.
Deployment: Docker for containerizing the backend and frontend.
Challenges we ran into
Our primary challenge was one of design: balancing realism with performance.
Challenge: Realism vs. Speed
A full physics simulation for 10,000 agents is far too slow. A simple Excel model is too abstract.
Our Solution: The event-driven model was our breakthrough. We don't care about the physics of a 5-minute flight; we only care about two events: FLIGHT_START and FLIGHT_END. This allows us to simulate 24 hours of city-wide traffic in just a few seconds.
Challenge: Defining "Winning"
How do you score the "race"? Is it fewest crashes? Most passengers? Best energy efficiency?
Our Solution: Make the leaderboard configurable. The city planner (the user) defines the "winning" formula. A company $c$'s final score $S_c$ would be a weighted sum of KPIs, $k_i$, defined by the user:
$$S_c = \sum_{i=1}^{n} w_i \cdot k_i$$
For example, $w_1$ could be the weight for avg_wait_time (where a lower value is better) and $w_2$ could be the weight for total_flights_completed. This flexibility makes AetherSim a true simulator, not just a game.
Accomplishments that we're proud of
We're incredibly proud of the core conceptual design that makes AetherSim both powerful and feasible.
The "Lightweight" Event-Driven Model: Our biggest accomplishment was resisting the urge to build a complex physics engine. The event-driven approach is the key insight, allowing us to simulate days of complex, city-wide agent interactions in seconds.
The Pluggable "Strategy" Module: This is what makes AetherSim a true competitive simulator. The idea of letting "companies" upload their own decision-making logic (as a sandboxed script) is a simple way to model complex, competing behaviors.
The Configurable "Score" Formula: Designing the system around a user-defined scoring formula (like our $S_c$ equation) was a critical design win. It means the simulator isn't opinionated; it's a flexible tool that can be adapted to whatever metric a city planner or company cares about most.
What we learned
Through this hackathon, we learned that the most profound challenges in new tech (like UAM) are often systems-level problems, not just hardware problems. Designing this project taught us to think in terms of emergent behavior and competing strategies. We learned that a simple, lightweight simulation can provide more actionable insight than a complex, "realistic" one that is too slow to run "what-if" scenarios. AetherSim's value isn't in its realism; it's in its speed and its focus on strategy.
What's next for AetherSim
AetherSim is currently a robust architectural concept, and the path forward is clear.
Build the Core Engine: Develop the event-driven priority queue and the agent state-machine in Go or Python.
Integrate Real-World Data: Allow users to import city maps from OpenStreetMap (.osm) files to automatically generate the node and edge graph, instead of defining it manually.
Flesh out the Event Library: Add more complex, chaotic events, such as NO_FLY_ZONE_ACTIVATED, PRIORITY_PASSENGER_REQUEST (e.g., medical emergency), and VERTIPORT_CONGESTION.
Develop the Strategy Sandbox: Build the secure V8-based sandbox for executing company strategy scripts.
Seek Pilot Partners: Engage with municipal governments or UAM companies to refine the simulator's KPIs and test it against their real-world models.
Log in or sign up for Devpost to join the conversation.