A 3D game engine
for the web.
Mayhem is our real-time 3D engine for the open web, built for large worlds and big crowds in any genre. It renders, animates, collides, destroys and streams a 128-player battle today, and it loads from a link with nothing to install.
Production numbers
These are shipped numbers, not lab benchmarks. Every figure below is running in production today in our reference title.
Frame-rate figures are engineering targets that every change is measured against; achieved frame rate varies with hardware. Internal figures as of 1 Nov 2026.
Open standards underneath.
Everything above them is ours.
Mayhem sits on the web's open graphics stack (three.js on WebGL 2, KTX2/Basis textures, Draco and Meshopt geometry, WebAssembly decoders, worker threads). The systems on top, and the shared simulation that the client and server both run, are written in-house.
Rendering 128 players at full detail
Big lobbies follow a visual-parity rule: a 128-player match must look like a 32-player one. Mayhem gets there by moving work onto the GPU instead of cutting quality.
- GPU skinning and instancing draw every body in a full lobby without per-character draw-call cost
- Compressed GPU textures (KTX2/Basis) stay compressed in video memory, not just on the wire
- Screen-space ambient occlusion, tone mapping and post effects tuned per device tier
- Device-tiered quality ladder: one codebase scales from gaming desktops to integrated GPUs and phones
Character animation
Characters blend motion-captured locomotion with procedural layers, so a player's intent is readable from across a map and their body reacts physically when hit.
- Motion-capture locomotion clips drive the base gait, packed in a compact binary format
- Procedural strafe gait and hand posing keep feet planted and weapons gripped in any direction
- First- and third-person rigs derived from one skeleton, so what you see matches what others see
- Real ragdoll physics for the body parts that were not blown off
One collision system shared by everything
Movement, projectiles, vehicles and bots all query the same triangle-accurate collision mesh. A bullet, a tank tread and a bot's path all agree on where the wall is, on the client and on the server.
Mesh-accurate collision
True triangle-mesh collision for large Blender-built levels, alongside fast box colliders for simple geometry.
Vehicle dynamics
Dedicated hull, spring, ground and contact solvers for wheeled, tracked, hover and air vehicles.
Ballistics
Hitscan and simulated projectiles with travel time, gravity and splash, judged with lag compensation by Turbine.
Destruction and gore
Physical destruction is part of the game's identity, and it is never cut for performance. The engine budgets for it instead.
- Dismemberment with physical gibs and limb debris
- Blood atlas and decals that wrap onto skinned, moving characters
- Surface-projected decals on world geometry, with correct layer ordering
- Vehicle wrecks and persistent battlefield damage across a match

Ground, hover and air vehicles
26 vehicle types across 10 classes: ground, hover and air, with crewed seats for drivers, gunners and passengers. Drop pods insert squads straight into the fight.








Bots that drive, fly and take objectives.
Server-side AI fills lobbies at every size, from a 1v1 warm-up to a 128-seat Conquest, and plays the same rules as humans.
- Navigation graphs built on worker threads and baked into the server image, so a match starts warm
- Squad tactics that act on what teammates have seen, not on hidden information
- Drivers, gunners and pilots, including transport and convoy behaviour
- Difficulty tiers and lobby backfill so a match is always full
World and asset pipeline
Arenas are authored in Blender against a strict export contract, compressed, content-hashed and streamed on demand. Only the arena you are playing is ever loaded.
Blender contract
Separate collision and visual layers, named and validated on export. Hundreds of pipeline scripts automate the bake.
GLB + KTX2
Draco and Meshopt geometry, Basis-compressed textures and lightmaps, decoded by WebAssembly.
Hashed packs
Content-hashed arena packs are cached forever, and static files are Brotli-compressed once at build, not per player.
Lazy load
One arena per match is loaded and released, keeping memory flat on phones in long sessions.
An in-game map editor, already shipping.
Forge lets players build maps inside the game using the same world builder the engine uses for official arenas. It is the seed of the Mayhem Editor.
Performance measured on the slowest frames
Averages hide stutter. Every performance change in Mayhem is judged against a 10 ms frame on p99 and 1% lows, on real hardware tiers, with automated rails that fail the build when a change regresses.
| Area | How Mayhem handles it |
|---|---|
| Frame budget | 10 ms target on desktop (100 fps), 60 fps on phones in 128-player lobbies; judged on p99 and 1% lows |
| Memory | One arena resident per match; previous arenas released on exit; GPU textures kept compressed |
| Load | Content-hashed packs cached across visits; Brotli precompressed at build; nav baked ahead of time |
| Threads | Decoders and heavy builds run in workers and WebAssembly, off the main thread |
| Scaling | Device-tiered quality ladder chooses settings per GPU class; one codebase for desktop and mobile |
| Regression control | 1,400+ automated verification rails covering netcode, maps, performance and security |
Next: Turbine, the netcode
Rendering 128 players is one problem. Keeping all 128 of them in sync, and fair, is the other.