Public entry point for Vibe Heist. Orchestrates submodules for the WebGPU engine, web portal, and the private game client. (In Development)
Vibe Heist is an ambitious, high-fidelity, open-world driving and action game designed to run natively inside a standard web browser tab. Rejecting standard web game development cliches (such as DOM-driven visuals or using React state to manage frame logic), the project implements a cutting-edge native-performance architecture. By dividing the system into an independent physics simulation core ('the Brain') written in Rust and compiled to WebAssembly (WASM), and a visual rendering engine ('the Eyes') written in TypeScript utilizing Babylon.js on the next-gen WebGPU standard, the game fully decouples state calculations from presentation. The two layers communicate asynchronously over a lock-free, zero-copy shared memory bridge leveraging SharedArrayBuffer and Atomics, achieving silky smooth 60+ FPS simulation speeds with virtually zero garbage collection stutter or thread synchronization latency.
Sub-1ms simulation updates (typically 0.15ms - 0.40ms per step in WASM) at 60Hz physics frequency.
Interpolated 60fps to 240fps rendering depending on screen refresh rate, with 0% garbage collection jank during gameplay loop.
$0 server compute hosting cost, leveraging client-side WebAssembly execution (serverless launcher hosted on Vercel CDN).
Decoupled Multi-Threaded Engine: Strictly separates game logic and physics simulation (running at a fixed 60Hz timestep in a background Web Worker) from presentation and rendering (running up to 240Hz on the main thread), ensuring simulation determinism and preventing screen refresh jank.
Zero-Copy Shared Memory Bridge: Custom memory layout leveraging SharedArrayBuffer and atomic thread signaling to cast WASM memory heaps directly as JavaScript Float32Array views, completely avoiding main-loop allocations and slow postMessage JSON serialization.
Next-Generation WebGPU Renderer: Native WebGPU visual pipeline driven by Babylon.js v8.26 with shaders written in WGSL, supporting advanced visual techniques like percentage closer filtering (PCF) shadow generation, depth buffer testing, and custom emissive lighting materials.
Raycast Vehicle Physics in Rust: Custom multi-wheeled vehicle simulation utilizing Rapier3D's DynamicRayCastVehicleController, with configurable four-point raycast suspensions, mass calibration, linear/angular damping, and handbrake-induced oversteer steering drift.
Exhaustive situation-action-result breakdowns showcasing problem-solving and architectural execution.
Garbage collection (GC) pauses and communication overhead when transferring heavy game state vectors (1,500+ entities) between a background physics thread and the main rendering thread caused severe frame drops (jank) in the browser.
Designed a zero-allocation SharedArrayBuffer memory bridge. Calculated strict byte strides and offsets (e.g. PED_STATE_OFFSET, CAM_STATE_OFFSET) to project the Rust SimEngine memory layout directly into WebGPU-aligned Float32Array views on the main thread. Synchronized thread reading/writing atomically using Atomics.
Low-level component relationships, system boundaries, and runtime flows.
The Vibe Heist engine is designed around a strictly decoupled, asymmetrical multi-threaded architecture that communicates via shared memory. The main thread handles presentation, input gathering, and WebGPU draw-call dispatch, while a dedicated Web Worker acts as the simulation thread (the WASM physics host). Inside the Web Worker, the Rust SimEngine runs a fixed 60Hz game loop (approx. 16.6ms intervals) utilizing Cargo packages like Rapier3D and Nalgebra to calculate physics steps, vehicle coordinates, player trajectories, and 1,500 agent crowd positions. 1) Input Phase: The main thread catches mouse movements and keyboard events, encoding buttons and camera angles into a shared RingBuffer using atomic write indices. 2) Simulation Phase: The Worker thread drains the RingBuffer atomically, passes these inputs into the physics engine, computes the state step, and writes the resulting translations, rotations, camera targets, and instanced ped matrices directly into a SharedArrayBuffer via raw WASM heap pointers. 3) Presentation Phase: Rather than waiting, the main thread reads the SharedArrayBuffer, interpolates between the last two physics frames to support high screen refresh rates (e.g. 144Hz), and immediately uploads the raw floats to WebGPU buffers via Babylon.js Thin Instances, keeping drawing overhead down to a single CPU-to-GPU memory transfer.
Developing Vibe Heist demonstrated that a native-grade, high-performance open-world game is entirely feasible in modern browsers when standard web overhead is systematically bypassed. A major takeaway is the power of zero-allocation game loops: by reusing Float32Array memory views and avoiding the generation of temporary vectors (e.g., 'new Vector3()') or serialization buffers in the update cycle, garbage collection pauses can be eliminated. Furthermore, building lock-free multi-threaded architectures in WebWorkers using SharedArrayBuffer and Atomics requires extreme precision regarding memory alignment and byte-stride layouts, but pays massive performance dividends that make modern browser standards like WebGPU shine at full capability.
Boid-Flocking ECS Crowd Simulation: High-performance pedestrian simulation calculated inside the WASM thread, driving up to 1,500 independent agents utilizing collision avoidance (ped-to-ped, ped-to-player, ped-to-vehicle) and block/ramp height adjustments.
Hardware-Accelerated Instancing: Main thread rendering uses Babylon.js Thin Instances to batch and draw thousands of active crowd meshes in a single GPU draw call, minimizing CPU overhead and WebGPU API bottlenecking.
Next.js 16 Launcher Integration: Built a secure, high-performance launcher website using Next.js 16 and Tailwind CSS v4, supporting seamless launcher mechanics and static delivery targets.
Completely eliminated serialization overhead, dropping state transfer time from 12ms to 0ms (zero-copy), and reduced garbage collection pauses to absolute zero during active gameplay.
A noticeable frame rate mismatch occurred because the core physics simulation runs at a fixed, deterministic 60Hz timestep in Rust, whereas the rendering thread scales dynamically with high-refresh-rate monitors (144Hz to 240Hz), causing visible visual stuttering.
Developed a time-interpolated rendering layer. Tracked the worker's atomic frame counter and write indices. In the main Babylon.js render loop, implemented linear interpolation (lerp) for positions and camera targets, and spherical linear interpolation (slerp) for rigid-body rotation quaternions, smoothly bridging states between the last two completed physics cycles based on high-resolution timing deltas.
Achieved perfectly fluid visual rendering that natively matches the monitor's high refresh rate, while preserving the mathematical determinism of the fixed 60Hz Rust physics simulation.
Simulating and rendering a dense crowd of 1,500 active pedestrians on the web typically causes severe CPU congestion from loop overhead and GPU draw-call bottlenecks.
Offloaded boid-style crowd flocking, obstacle avoidance, and raycast height queries on blocks/ramps entirely to Rust. Combined this high-speed calculation with WebWorker thread decoupling, then updated instance matrices directly on the GPU using Babylon's Thin Instances.
Allowed the browser to simulate and render 1,500 dynamic agents in real-time with full shadow casting, keeping browser CPU thread utilization under 15% and keeping framerate locks stable.
