Why Rust for Game Development
When we set out to build Droploop Online, we knew we wanted a language that could deliver native-level performance while targeting the browser. Rust was the clear choice. Its ownership model eliminates entire classes of bugs — no null pointer dereferences, no data races, no use-after-free — while producing code that runs as fast as C++. For a real-time multiplayer game where every millisecond counts, that combination is hard to beat.
Rust's ecosystem for game development has matured significantly. Crates like hecs provide lightweight ECS (Entity Component System) frameworks that give us the data-oriented architecture games need without the overhead of a full engine. Combined with strong compile-time guarantees, we spend less time debugging memory issues and more time building gameplay.
WebAssembly: Native Performance in the Browser
The magic that makes Droploop Online run in your browser is WebAssembly (WASM). Rust compiles directly to WASM, producing compact binaries that execute at near-native speed. This means the same game logic that could run on a desktop application runs inside a browser tab — no plugins, no downloads, no install wizards.
WASM is not just a compatibility layer. Modern browsers JIT-compile WebAssembly modules into machine code, and the performance gap between native and WASM continues to shrink with every browser release. For Droploop Online, this means smooth 60fps gameplay with complex ECS simulations, physics calculations, and real-time rendering all happening in the browser.
One of the key technical challenges was multi-threading. Browser WASM supports threading via SharedArrayBuffer, but this requires specific HTTP headers — Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy — to be set correctly. Getting these headers right while maintaining OAuth popup flows and cross-origin resource loading required careful architecture decisions that we will detail below.
Networking with WebSockets
Multiplayer games need fast, reliable networking. In browser environments, your options are limited compared to native applications. We cannot use raw UDP sockets or even QUIC directly from browser JavaScript or WASM. Instead, we built our networking layer on WebSockets, which provide full-duplex communication over a single TCP connection.
Our protocol uses bincode serialization — a compact binary format that is significantly smaller and faster than JSON. Every network message is defined in a shared protocol crate that both the server and client compile against, ensuring type safety across the wire. When we add a new message type or change a field, the compiler catches mismatches at build time rather than at runtime.
The server runs a dedicated game loop at a fixed tick rate, processing player inputs, simulating the game world, and broadcasting state snapshots to connected clients. Clients send only their input intentions — movement direction, fire commands, interaction requests — and the server resolves everything authoritatively. This server-authoritative model prevents cheating and ensures a fair experience for all players.
The ECS Architecture
At the heart of Droploop Online is an Entity Component System architecture. Every object in the game world — players, enemies, projectiles, items, doors — is an entity composed of small, focused components. Systems process these components in a defined pipeline of stages, each responsible for a specific aspect of the simulation.
We use a 16-stage pipeline that runs every server tick. Stages handle input processing, movement, collision detection, combat resolution, AI behavior, loot spawning, and state snapshot generation. Each component has exactly one stage that is allowed to write to it, which eliminates data race concerns and makes the system easy to reason about.
This architecture also enables clean code sharing between server and client. The shared crate contains component definitions, math utilities, and game constants that both sides use. The server runs the full simulation while the client uses the same types for rendering and prediction, keeping everything in sync without code duplication.
The SharedArrayBuffer Challenge
One of the trickiest technical hurdles was enabling multi-threaded WASM in the browser. WebAssembly threads require SharedArrayBuffer, which browsers only enable when specific security headers are present: Cross-Origin-Opener-Policy must be set to "same-origin" and Cross-Origin-Embedder-Policy to "require-corp". These headers lock down the page's security context.
The problem is that these headers break certain cross-origin flows. OAuth login popups, for example, rely on window.opener to communicate back to the parent page. With COOP set to same-origin, the opener reference is nullified. We solved this by serving the OAuth callback page on a separate route without the restrictive headers, using postMessage for secure cross-window communication after the OAuth flow completes.
This kind of browser security plumbing is invisible to players but critical for the game to function. Every asset, every script, every cross-origin request has to be compatible with the COEP/COOP policy or the game simply will not load.
Performance in Practice
The result of these technology choices is a game that loads in seconds and runs smoothly in a browser tab. Rust and WASM give us the performance headroom to run a full ECS simulation, render hundreds of entities, and process network updates every frame without dropping below 60fps on modest hardware. The binary protocol keeps bandwidth usage low enough for real-time multiplayer over typical home internet connections.
Droploop Online is the product of these decisions — a multiplayer 2D extraction shooter built from the ground up in Rust and WebAssembly, designed to run anywhere a modern browser runs. No downloads, no plugins, no compromises on gameplay quality.