AI Disclosure: This article was written with AI assistance. All games mentioned were built using AI-assisted development tools.
The 3D Elephant in the Room
When you say "browser game," most people picture a 2D pixel platformer or a text-based idle game. 3D in the browser? That's Unity WebGL, right? A 50 MB download, a loading bar that tests your patience, and a game that barely runs on mobile.
It doesn't have to be that way.
I shipped three 3D browser games — each under 50 KB of code, zero install, loading in under a second. No Unity, no Unreal, no game engine at all. Just Three.js loaded from a CDN and vanilla JavaScript. This article is about what I learned making them work at that size, and why "no engine" turned out to be an advantage, not a constraint.
The Three Games
Three.js Low Poly Scene — 3D Demo
A static low-poly diorama. Trees, rocks, a sunset gradient sky. No gameplay — just atmosphere. Why ship a demo with no gameplay? Because it's a proof of concept: you can render a complete 3D scene, with lighting and materials, in under 4 KB of JavaScript. That's smaller than this article's header.
It also became the foundation for the other two. The lighting setup, the camera controls, the geometry helpers — all reused.
Poly Racer — Low Poly 3D Racing
A low-poly racing game. You drive a car around a track, dodging obstacles, collecting speed boosts. Three.js handles the 3D rendering; everything else — physics, collision, track generation — is hand-rolled in about 600 lines of JavaScript.
The key insight: racing games don't need realistic physics. They need predictable physics. A simple velocity vector, a steering angle, and a speed cap feels better than any physics engine I've tried. Players don't want realism — they want responsiveness.
Voxel Sandbox Builder
A Minecraft-inspired voxel sandbox. Place blocks, remove blocks, fly around an infinitely generating terrain. The terrain uses simplex noise for elevation, the chunks are instanced meshes for performance, and the whole thing runs at 60 FPS on a mid-range laptop.
This was the hardest to keep small. Voxel games are inherently data-heavy — a 32×32×32 chunk is 32,768 blocks. The trick is generating everything procedurally and only storing what the player has modified. A clean world costs 0 bytes of saved state. Only the diff from the generated baseline needs persistence.
Why No Engine?
Reason 1: Download Size
Unity WebGL builds start at 10–20 MB before you add a single asset. My largest 3D game is 50 KB — the entire game, not a loading screen. When someone clicks "play" on itch.io, the game is running before their cursor reaches the canvas.
Size isn't vanity. It directly affects bounce rate. I've watched analytics on my itch.io store: the 2D idle games (under 10 KB each) have the highest completion rates. The 3D games are bigger but still load instantly. A Unity build would add a 10-second loading screen, and 10 seconds is where mobile users leave.
Reason 2: Iteration Speed
With an engine, you wait for compilation. With raw Three.js, you save the file, refresh the browser, and it's there. During the AI-assisted development process, this tight loop was essential. I could prompt an AI to generate a function, paste it in, test it, and iterate — all within a single conversation turn. Compilation breaks that flow.
Reason 3: No Abstractions to Fight
Game engines are opinionated. They have their own scene graphs, their own component systems, their own input handling. When you disagree with them, you spend time working around their assumptions.
With raw Three.js, the only abstraction is the WebGL renderer. Everything else is yours. The camera is a camera object you move. Materials are objects you configure. Input is plain DOM events. When something breaks, you read your own code — not engine source code on GitHub.
The Performance Blueprint
InstancedMesh for Everything Repetitive
Voxel Sandbox Builder has thousands of blocks visible at once. Rendering each as a separate mesh would kill performance. THREE.InstancedMesh lets you render thousands of identical geometries in a single draw call. One mesh, one material, thousands of transforms. This is the single most important Three.js feature for performance.
const blockGeo = new THREE.BoxGeometry(1, 1, 1);
const blocks = new THREE.InstancedMesh(blockGeo, material, maxBlocks);
scene.add(blocks);
// Set each instance's position
const matrix = new THREE.Matrix4();
for (let i = 0; i < count; i++) {
matrix.setPosition(x[i], y[i], z[i]);
blocks.setMatrixAt(i, matrix);
}
blocks.instanceMatrix.needsUpdate = true;
That's a voxel world in 10 lines.
Frustum Culling Is Free — Use It
Three.js does frustum culling automatically. If you position your objects correctly and set reasonable bounding spheres, objects outside the camera view are skipped. The trick is not to disable it out of confusion when something invisible. Double-check bounding sphere sizes — a wildly oversized bounding sphere will cause Three.js to attempt rendering objects it shouldn't.
Mobile Means Low Poly
Low-poly isn't an aesthetic choice on mobile — it's a survival strategy. A scene with 500 polygons loads instantly. A scene with 50,000 polygons stutters on a mid-range phone. Poly Racer uses about 200 polygons for the entire car model. The track is procedurally generated segments with shared geometry. The total scene stays under 2,000 polygons at any time.
Procedural Everything
When you can't ship asset files, you generate them.
- Terrain: Simplex noise → heightmap → voxel columns. ~50 lines of code.
- Trees: A cylinder trunk + a cone foliage, placed with noise-based density. ~20 lines.
- Tracks: A spline path with obstacle placement along the curve. ~100 lines.
- Cars: A box body + 4 cylinder wheels, rotated based on steering input. ~30 lines.
Procedural generation has a reputation for being complex, but for small games, it's simpler than the alternative. Loading a 3D model means dealing with file formats, parsers, and asset pipelines. Generating a tree from two primitives means writing 20 lines and never thinking about it again.
What AI Assistance Actually Looks Like
These games were built with AI-assisted development. I want to be transparent about what that means — not because I'm ashamed, but because the conversation around "AI games" is full of misconceptions.
AI did not generate a game and hand it to me. What happened was closer to pair programming with a very fast, very literal-minded partner. I described the mechanic I wanted. The AI wrote a first draft of the function. I tested it, found the edge cases, described them back, and got a revised draft. We iterated.
The creative decisions — what the game is, how it feels, what the player does — were mine. The AI accelerated the implementation but didn't make the design choices. If I asked it to "make a racing game," it would produce something generic. The specificity came from my direction.
This is why I label every game and article with an AI Disclosure. Players deserve to know how a thing was made. Hiding it would be dishonest, and dishonesty is the fastest way to lose trust in an industry that runs on community goodwill.
The Cross-Platform Reality
All three 3D games run in any modern browser — desktop Chrome, Firefox, Safari, mobile Chrome, mobile Safari. No app store, no download, no plugin. Click a link, play the game.
This is the part I find most exciting. The web is the only truly universal gaming platform. No gatekeeper takes 30%. No review process takes six weeks. You ship, and it's playable worldwide instantly. itch.io handles the storefront. The games handle the rest.
Play Them
All three 3D games are playable right now:
- Three.js Low Poly Scene — 3D Demo — a quiet diorama
- Poly Racer — Low Poly 3D Racing — a minimalist racer
- Voxel Sandbox Builder — build and explore
Plus 8 more idle, narrative, and puzzle browser games, all at my itch.io store. The August Sale is live — 45% off all paid titles through August 31.
Start with the free ones. If a 3D game loads in under a second on your phone, that's the whole pitch.
AI Disclosure: All games were built with AI-assisted development tools. This article was written with AI assistance and reviewed by the developer. No AI-generated images were used — all 3D scenes are procedurally generated from primitive geometry.
Top comments (0)