Most browser racing games move a sprite at a turn rate. Sliplap integrates a vehicle model at a fixed 120 Hz — the same model, in the same files, on the server and in your browser at the same instant. This is what that means and why it is the reason the game is worth playing.
Feel it for yourself — freeDownforce rises with the square of speed, and so does drag. The practical consequence is the thing that makes an open-wheel car strange to drive: a corner that is impossible at 150 km/h is flat at 280. Grip is not a property of the corner, it is a property of how fast you are going through it, and learning to trust that is most of learning the game.
Sit in the wake of the car ahead and your drag falls. The tow is worth roughly 30 km/h by the end of a long straight — Highwood tops out at 368 km/h alone and considerably more behind somebody. That is how overtaking actually happens here, and it is simulated rather than scripted.
A slip-angle model with a real peak. Below the peak, asking for more steering gives you more cornering force. Past it, you are not gripping harder — you are sliding, and the force is going down while your input goes up. There is no assist quietly catching that for you.
The model is load-sensitive, which is the detail that makes the car feel like a car: the grip a tyre produces does not rise linearly with the weight on it. Load one axle hard and you lose more at the other end than you gain. This is why trail-braking into a corner rotates the car, and why doing too much of it spins you.
Four-corner suspension, so braking loads the front axle and unloads the rear, and cornering loads the outside. Brake and steer at the same time and the rear has less grip available exactly when it needs to follow the front. The practical rule that falls out of this — get your braking done in a straight line — is not a tip somebody wrote into a tutorial. It is a consequence of the model, and you can feel the moment you break it.
Full brake at low speed flat-spots the fronts, and a locked tyre does not steer. The car goes straight on regardless of where the wheel is pointing. It is the most common way a new driver misses an apex, and the fix — release, then reapply — is the real one.
A seven-speed gearbox with a torque curve, shifting itself. You do not manage gears, but you can hear and feel where you are in the rev range, and a corner exit taken in the wrong part of it costs you the following straight.
| Figure | Value |
|---|---|
| 0–100 km/h | 2.05 s |
| Top speed, alone | 306 km/h |
| Top speed, in the slipstream | 338 km/h |
| 300–100 km/h braking | 70 m, at 5.4 g |
| Physics rate | 120 Hz, fixed |
| Server snapshot rate | 30 Hz |
| Tightest corner in the game | 13 m radius, at Undercroft |
These are measured off the simulation, not estimated. So are the reference lap times on the circuits page — a quasi-steady lap simulation drives each circuit's own geometry with the same model the game uses.
This is the least visible decision in the game and one of the most important. If the physics advanced by whatever time the browser happened to take to draw the last frame, a car at 90 m/s would corner differently on a 144 Hz monitor than on a 60 Hz one — and lap times would stop being comparable between players, which would quietly destroy the only progression the game has.
So the step is always 1/120 s, accumulated, and what you see is interpolated between ticks. Your monitor's refresh rate changes how smooth it looks and nothing about how the car behaves.
The physics lives in one directory that both the browser and the server import unchanged. That is what makes the netcode work:
The only thing your browser ever transmits is which keys you are holding. There is no message that says where your car is — which is why a speed hack is not something the game detects but something it cannot express. The cost of that design is real work; the benefit is a leaderboard that means something.
A bot is a player without a socket. It holds a slot and a grid box like anyone else and, once a tick, produces the same four-field input a keyboard produces, through the same physics step. There is no separate bot physics, no rubber-banding and no lap-time table — a bot is quick because it brakes late and uses the road, and slow for the reasons a person is. It is also why an AI lap time is comparable with a human one.
All of the above is a few hundred microseconds a tick. The expensive part of a racing game is drawing it, which is why there are three quality tiers, temporal anti-aliasing, and a resolution governor that trims render scale to hold 60 fps instead of stuttering. The circuits, trees, grandstands, textures and engine notes are generated procedurally when the page loads rather than downloaded, which is how the whole game fits in about a megabyte.
Drive itNext: how to be quick, the circuits and their measured lap times, or how this compares to other browser racing games.