3D Studio
A creation tool where non-programmers build 3D worlds with visual scripting and play them together in real time, at 10 million users. Editor, authoritative server, and the schema between them live in one repository — with sandboxed user scripts, server-side physics, and an assistant that answers in the studio's own API rather than in generic JavaScript. I also shipped several web games on top of the platform, together passing a million plays.
- Role
- Engineer — studio & realtime runtime
- Domain
- Creation tools for young makers
- Reach
- 10M+ total users
- Games shipped
- 1M+ combined plays
- Runtime
- Three.js · Ammo physics · Colyseus
- Deploy
- Kubernetes · Helm · ECR, 3 environments
- Status
- Shipped
Outcomes
What was
broken
The problem as it actually presented itself, and the constraints that shaped every decision after it.
Browser 3D tooling forces a choice between a rendering library with no authoring story and a heavyweight editor that ships megabytes to every player. Neither works for a product whose users are learning to build and whose players are on school laptops.
Multiplayer makes it harder. If physics runs on each client, positions disagree and someone is always wrong. If user scripts run unsandboxed, one creator's infinite loop takes down everyone in the room.
And the users asking 'how do I make the door open when the player touches it' are not going to read API documentation. The help had to answer in the studio's own vocabulary, inside the studio.
What it
runs on
Models, retrieval, serving, and the operational layer that keeps it honest in production.
- Three.js
- enable3d / Ammo
- Blockly
- Ace + acorn
- Colyseus rooms
- Server-side Ammo
- Shared schema package
- Threaded chat
- Studio-API answers
- Syntax-highlighted output
- Agora voice/video
- vm2 sandbox
- Helm + ECR rolling deploys
How it
works
The pipeline end to end — each stage, and why it earns its place in the latency budget.
- 01
One schema, both sides
Editor and server both consume a shared package that defines scene and room state, so client and server can never drift into two definitions of the same world. Serialization uses a compressed JSON format to keep scene payloads small over the wire.
- 02
Browser editor
Three.js rendering with enable3d wrapping Ammo physics, an asset library, a property panel, and Blockly for block-based scripting — with a code escape hatch for users who outgrow blocks, parsed and formatted so the transition is not a cliff.
- 03
Authoritative multiplayer
Colyseus rooms run the same Ammo physics on Node, so collisions and positions resolve server-side and clients render a state they do not get to argue with. Load tests live alongside the room code rather than in someone's local scratch directory.
- 04
Sandboxed user scripts
Creator-written script runs inside a sandbox, parsed and rewritten through an AST before it executes. A user's mistake is contained to their own logic instead of taking down the room it is running in.
- 05
In-editor assistant
A threaded assistant — one conversation thread per user — answers in the studio's own scripting API, with syntax-highlighted, copy-ready code blocks and a documentation tab beside it. It answers the question the user actually asked, in the vocabulary of the tool they are holding.
- 06
Ship pipeline
A single deploy script builds images, pushes them to the registry, publishes Helm charts, and rolling-updates the target namespace across development, staging, and production. Any subset of services can ship independently.
Decisions
and their cost
Every choice below bought something and gave something up. The second half is the part worth reading.
Server-authoritative physics
Running Ammo on Node costs server CPU and adds a round trip to every interaction. Client-authoritative physics costs correctness, and in a shared world correctness is the product. The latency is hidden with interpolation; disagreement cannot be hidden at all.
Blocks with a code escape hatch
Blockly alone caps what advanced users can express; raw code alone loses beginners at the first semicolon. Supporting both means maintaining two authoring paths, and it is the only version where a user can grow inside the tool instead of leaving it.
Sandbox every user script
Sandboxed execution with AST-level parsing is slower than running code directly and it is non-negotiable when one creator's script executes in a room full of other people's sessions.
Assistant scoped to the studio's own API
A general coding assistant answers in generic JavaScript that does not exist in this engine — confidently, and uselessly. Scoping it to the studio's API and documentation made it narrower and made its answers actually runnable.
How it was
measured
Nothing shipped on intuition. Each number below is produced by a repeatable harness that gates deploys.
Total users on the studio platform.
Several web games built on the platform, combined play count.
Ammo runs on Node inside the room; clients render resolved state.
Shared schema package consumed by both editor and server.
AST-parsed and executed in isolation from the room runtime.
Visual blocks and raw code, over the same underlying scene API.
Rolling updates per service across dev, staging, and production.
Room load tests versioned alongside the multiplayer server.
Guardrails
and safety
What stands between a good demo and something you can leave running unattended.
User scripts execute in a sandbox with AST-level parsing, isolated from the room runtime and from other players' sessions.
Physics and state are resolved server-side, so a modified or lagging client cannot rewrite the shared world.
The shared schema package makes client/server state drift a compile-time problem rather than a runtime mystery.
Deploys are rolling updates per service, so a bad build degrades one component instead of taking down a live room.
Room load tests are versioned with the server code and run before capacity changes.
The in-editor assistant answers within the studio's documented API surface — it suggests, it does not mutate the scene directly.
What I'd
carry forward
The parts that generalise — earned the expensive way, on this build.
In a shared world, authority is the architecture. Every question about lag, cheating, or desync resolves back to who is allowed to be right.
Give people a ladder, not a wall. Blocks with a code escape hatch let users grow inside the tool instead of hitting a ceiling and leaving.
Scope an assistant to your API. Narrow and correct beats broad and plausible, especially when the user cannot tell the difference until they run it.
Sandboxing is not optional the moment other people's sessions are in the blast radius.