I build multiplayer games and the engine underneath them: authoritative servers, binary protocols, and physics that cannot desync. The browser is the distribution platform. No installs, no launchers.
the studio
Top Quark Studios
Games with charge. Duskspire and everything after it ships under the TQ banner.
site coming soon
2026 · in development · OpenAI Buildweek
C++WebSocketBinary Protocol
Duskspire
A web-based game holding 100 simultaneous players in one shared world. A C++ authoritative server owns everything that matters: movement, projectiles, collision, combat, transformations, interactions, and a shared boss encounter. The wire protocol is binary over WebSocket, on revision 22, with live bandwidth, queue, backpressure, and ingress metrics on a /stats endpoint.
One hundred players is the constraint every design decision answers to.
The core bet: one C simulation core, compiled twice from the same source. Native for the authoritative server, WASM for in-browser client prediction. The physics is cross-platform deterministic, so the two builds are bit-identical and prediction cannot drift from the server. Verified, not assumed: 600 simulation steps across 251 bodies on two seeds, every step hashed on both builds, every hash equal.
30 Hz
server tick · snapshots every 2nd tick
8 B
full input command on the wire
500
bot connections in the load swarm
166 KB
gzipped WASM simulation module
1.6×
WASM cost vs native, same source
100%
step hashes matched, native vs WASM
Inputs drive the clock: the server consumes exactly one queued input command per tick and acknowledges its sequence number, so client prediction and server simulation advance 1:1 and network jitter is absorbed by the input queue instead of desyncing the world. Load testing uses headless bot swarms that import the real client packages. No mocks.