Netcode

Quark

We wrote our own netcode engine, then raced it against Unity DOTS Netcode for Entities (NfE). It used 6× less CPU.

6.2×
less CPU than Unity DOTS Netcode for Entities (NfE), predicting 512 entities
151×
less CPU with 16 entities in the world
0.41 ms
to update 128 players, every tick

What Quark is

Quark is the netcode engine slopaf's online games run on. It keeps every player's screen in step with what really happened and hides the delay of the internet.

The same core runs games in the browser and in native clients. Turbo Kart Rally, the first game on slopaf, runs on it today.

What it does

Server authority: Every outcome is settled on the server.
Client prediction: Your screen predicts what happens next and corrects itself when the server disagrees.
Lag compensation: The server can rewind the world to what the shooter saw before judging a hit.
Fog of war: Each player is sent only what they are allowed to see.
Delta updates: Only what changed is sent.
Browser and native: One core runs in the browser and in native clients.

By the numbers

128 Hz
Tick rate
Quark's own demo simulates and takes input at 128 ticks a second, with snapshots at 128, 64 or 32 a second.
60 Hz
Turbo Kart Rally, live on slopaf
Up to eight cars and 48 hazards simulated at 60 ticks a second, snapshots at 30, predicted on every screen.
0.41 ms
128 players, every tick
Working out what each of 128 players can see and sending it takes 0.41 ms a tick on four threads, 0.63 ms at the 99th percentile. About 5% of a 128 Hz tick.
12%
Of one core, on one thread
The same 128 players on a single thread: 0.95 ms a tick, about 12% of one core at 128 ticks a second.
0
Allocations per tick
Once a match is running, Quark's core allocates no memory during a tick.
8.4 ms
64 real connections
64 clients over WebSockets at 128 snapshots a second: the 99th-percentile gap between snapshots was 8.4 ms, with no failures.
41 KiB/s
Per player at full rate
Each of those 64 players received about 41 KiB a second. At 32 snapshots a second, 32 players got about 7 KiB/s each.
0.27 ms
256 players, 4,096 entities
A synthetic stress test: 256 players each watching a world of 4,096 entities, 0.27 ms a tick on eight threads.

Measured by us in September 2026 on one machine (AMD Ryzen 9 9950X, Windows 11, release builds), over loopback. Per-tick figures are the server's replication, deciding what each player sees and sending it, not a game's own simulation.

Measured against Unity DOTS Netcode for Entities (NfE)

Client prediction, CPU per step

6.2×

less CPU than Unity DOTS Netcode for Entities (NfE), predicting 512 entities eight ticks ahead.

CPU time per prediction step, Unity DOTS Netcode for Entities (NfE) against Quark, by number of predicted entities
Entities	Unity DOTS NfE	Quark	Less CPU
16	89 µs	0.59 µs	151×
128	101 µs	4.6 µs	22×
512	119 µs	19 µs	6.2×
4,096	435 µs	168 µs	2.6×

Same game state and the same number of simulation steps on both sides, checked entity by entity. The Unity side is the shipping Unity DOTS Netcode for Entities (NfE) package, not a stand-in.

This is the prediction step only: taking the server's latest state and predicting ahead from it, every step. No network, server, physics or rendering.

Machine: AMD Ryzen 9 9950X, Windows.
Unity side: Unity 6000.6.2f1, Netcode for Entities 6.6.0, Burst 2.0.0, release standalone player, one worker thread plus the caller.
Quark side: Release build, one thread.
Method: 128 ticks per second, predicting 8 ticks ahead, 1024 measured steps after warm-up, median of three runs. CPU time across every thread, per prediction step.