Inspiration

Since this years theme is centered around building what we truly love, our team decided to pursue our deep passion in Transit. We all take the train every day. Transit is part of how we get to school, meet people, and move through our city. We share a transit background, and with this opportuinity we are given at stormhacks, we wanted to play a role in how things operate. We wanted to include ourselves in the decisions behind each trip: why a platform gets crowded, why one train fills up faster than another, and what would happen if service changed.

We wanted to use our technical skills to contribute to a system we already depend on.

That became Headway: a prototype for exploring rail capacity decisions and understanding their consequences before changing real service.

What It Does

A crowded platform presents a simple question with a complicated answer: what should an operator change?

Longer trains, shorter intervals, and different fleet allocations affect capacity differently. Each option also depends on available vehicles, platform length, boarding time, and operating constraints. There is just so many nuance aspects to consider when determining the best choice.

Our simulator models those connections. It calculates:

Train movement
Passenger queues
Boarding
Seated occupancy
Standing occupancy

It then saves the results for analysis and replay.

The intended workflow lets a planner compare scenarios and inspect the same recorded outcome through:

Charts
A 2D network
A Godot 3D station view

The first study uses a Vancouver-inspired corridor with explicit modelling assumptions. It is a prototype for scenario exploration; its synthetic demand is not a validated prediction of actual ridership.

How We Built It

We originally planned a project built entirely in Godot .NET and C#, with Blender assets. As we refined the idea around transit planning, we needed a desktop workspace for settings, comparisons, and reports alongside the visual simulation.

We adopted:

Tauri with a React/TypeScript interface
An independent Rust simulation core
A separate Godot viewer

Rust could connect directly to Tauri’s backend, avoiding an additional .NET service and runtime. Godot retained its role in presenting trains, stations, doors, and sampled passengers.

Our most consequential decision was to separate calculation from playback. The engine calculates operations and records their history; the viewer reads that history. Rewinding a scene therefore preserves the original passenger counts and outcomes.

We built validated scenario inputs, passenger accounting, replay services, analytics, and report exports around those shared records. Blender supported the station and train asset workflow, including modifications to an existing Mark V model.

In a recorded benchmark, a synthetic 24-hour scenario with six trains and twenty fare readers took approximately 4.04 seconds to calculate and record. Storage, rendering, and cloud processing were measured separately.

What We Learned

Our pivots taught us to let the user’s decision shape the architecture. Once we focused on agency planners, reproducible results and understandable comparisons became central requirements.

We also learned how closely transit systems connect. Adding capacity changes physical train length. Passenger exchanges affect dwell time, which affects service delivery and the queues that follow. All of this was fascinating to learn and it definetly fueled our burning passions for Transit.

Even a simple accounting rule became essential:

$$

\text{Passengers onboard}

\text{Seated passengers} + \text{Standing passengers} $$

That relationship must remain consistent across the engine, reports, and replay.

Performance depended on how we grouped passengers, scheduled events, and recorded data. Choosing Rust alone did not establish speed; representative benchmarks did.

Challenges We Faced

Keeping multiple views consistent was difficult. A chart, a train cutaway, and a station replay needed to agree on the:

Run
Timestamp
Vehicle
Passenger counts

Shared contracts and archived state gave us a common reference.

We also had to balance visual detail against calculation and storage costs. Recording richer door, weather, and fare-gate behaviour made inspection more useful, but increased archive size and memory use.

The current prototype has verified simulation, analytics, and recorded viewer components. Complete desktop integration, copied-package acceptance, and the live cloud reporting pipeline remain unfinished.

We want to keep developing this because these decisions affect our own daily journeys. Our goal is to help people inspect a proposed service change, understand its tradeoffs, and explain the result. Even after this competition, our team - Hackberry Labs, will continue to create, build, iterate our software Headway. We are grateful for the opportuinity to compete in this competition. As highschoolers from different schools, we were able to build new connections and through this event we've also created so many fun memories.