Apex | Devpost

Pit Wall
Race Steward Console

Inspiration:

Apex was inspired by the new F1 movie and by the intensity of race-day decision-making it brings to life. Watching the pit wall pressure, split-second calls, and constant strategy adjustments made us want to build something that captures that same feeling. We wanted users to experience what it is like to be the one making the call under pressure, not just watching the race. That idea prompted us to create a simulator that combines the drama of F1 with data-driven strategy and live-race visuals.

What it does:

Apex is a real-time F1 pit wall simulator where you act as the strategist. You get a live Monza track map with 20 cars moving in real time, plus a full timing board showing gaps, intervals, sector times, tyre compounds, and pit counts updating constantly as the race unfolds.

When it’s time to make a call, Apex runs 10,000 Monte Carlo simulations to recommend pit windows, undercut or overcut options, and win probability based on the current race state and tyre degradation. A WebSocket chaos engine can trigger rain, crashes, safety cars, and penalties, which instantly force strategy changes and triggers context aware race engineer radio updates, and judges can follow everything through a synced iPad steward view while you manage the Apex AI car, number 20 APX.

Challenges we ran into:

One of the biggest challenges was balancing realism with speed. F1 strategy has a lot of variables: tire degradation, pit loss, traffic, weather, penalties, and race pace, and making that feel accurate while still running smoothly in real time was tough. Another challenge was presenting a lot of race data on screen without making the interface overwhelming. We had to keep the dashboard detailed enough to be useful, but clean enough for users to make quick decisions.

Accomplishments that we're proud of:

What we’re happiest about is that it feels like a real race instead of a scripted animation. Cars don’t “swap places” because we told them to, they move up or fall back because the pace changes, tyres go off, and a pit call actually costs time. When an undercut works, you can see it happen on the timing and on the map and it makes sense. We’re also proud of how it handles chaos without falling apart. When rain or a safety car hits, the whole sim reacts immediately, the strategy advice updates, and the radio calls change with it. And the judge's view being synced the whole time made demos way smoother because people could watch what we did without us having to explain every screen.

What we learned:

We learned a lot about simulation design, especially how to model uncertainty and tradeoffs in a way that still feels intuitive to the user. We also learned how important UI design is when working with real-time systems because even good data is useless if the user cannot read it quickly. On the technical side, we got more experience with probabilistic modeling, race logic systems, and building a polished end-to-end experience under hackathon time pressure.

How we did it:

train_engine.py uses a two-stage lap time modeling pipeline designed to generalize across circuits while still capturing lap-by-lap race behavior. In Stage 1, it fits a Ridge regression model on degree 2 polynomial features of TrackLength and Corners using a very small circuit-level dataset with 10 Grands Prix and one row per circuit. This stage predicts a base lap time for each circuit, which gives the system a stable estimate of overall pace and allows it to extrapolate to unseen tracks like Italy. Ridge is used here because, with only 10 data points, a regularized linear model is much safer for extrapolation than a tree-based model, which would likely overfit and fail to transfer well.

In Stage 2, the pipeline trains XGBoost on per lap features such as tyre life, compound, position, stint, fuel load, and other race state variables to predict the residual, meaning the actual lap time minus the Stage 1 base lap time. This setup makes the model more circuit agnostic because Stage 1 captures the track-specific baseline and Stage 2 learns the lap-by-lap deviations caused by tyre degradation, stint progression, traffic, and race conditions. XGBoost is used in this stage because it is very strong on tabular data and handles nonlinear feature interactions well.

Polynomial features are only used in Stage 1. The rest of the pipeline focuses on practical preprocessing and feature engineering, including removing invalid and pit laps, applying a 70 to 150 percent median lap time filter to remove outliers, estimating fuel load, filling missing stint and position values, and then using median imputation plus one-hot encoding for categorical features before training. At the end, the pipeline saves the Stage 1 Ridge plus polynomial feature bundle, the Stage 2 XGBoost model, and the preprocessor so the same transformations can be applied consistently during inference.

What's next for Apex:

Next, we want to make Apex even more realistic and competitive. -Add dynamic weather and safety car/virtual safety car logic -Improve tire degradation models using more advanced inputs -Support full race replays and custom scenarios -Add player vs player strategy battles -Include historical tracks and driver/car performance profiles -Train smarter strategy recommendations with more race data

Long term, we want Apex to become a game-like simulation and analytics tool for motorsport fans, students, and anyone who wants to experience what it feels like to run strategy from the pit wall.