We made a game where your snake is the paddle and the bricks fight back. It shipped on web, mobile, and PC. It took two of us about three days. On and off, not crunching. And it's fun to play.

The mashup nobody asked for

Snake is about growth and spatial awareness. Arkanoid is about reflexes and angle prediction. They come from completely different design philosophies, and mashing them together sounds like the kind of pitch that gets politely declined.

But A Breaker Belt makes it work. You're a cosmic serpent, a living arc of neon current threading through an asteroid field of breakable blocks. Your head is the paddle. Your growing tail is both your greatest weapon and your most constant threat. The orbs ricochet off your body to shatter bricks, but one wrong turn into your own tail and you're done.

It's the kind of weird cross-genre experiment that usually dies before anyone gets to play it, because the development cost of finding out whether a weird idea works has traditionally been measured in months. Here it was measured in afternoons.

What actually shipped

The scope is what makes this interesting. This isn't a game jam prototype with placeholder rectangles and no sound.

The game runs 50 waves deep. That's not 50 variations of the same brick wall. The formations evolve from gentle onboarding arcs into fortress rings that demand angled shots through side gaps, then into layered diagonal mazes with one-tile-wide openings that require precision steering. Explosive bricks blow their neighbors apart. Phantom bricks flicker in and out of existence. Regenerating bricks heal back after you break them. Portal bricks teleport your orbs across the arena. Gravity wells bend your shots into slow, curving hymns. Laser emitters sketch red lines across the void. Mimic bricks look harmless until they decide they're not. By wave 15, you're navigating something that feels less like a puzzle and more like a living system that's learning your habits.

The music isn't a loop. It's a reactive soundtrack that builds with your gameplay. Bass, lead synth, pad, drums all running in E minor, and as the action intensifies, additional layers fade in. When things calm down between waves, ambient pads take over. The music breathes with you. A dedicated composer would spend weeks tuning that kind of responsiveness. Here it was part of the creative flow.

The sound effects aren't samples pulled from a free pack. Every brick shatter, orb bounce, and collision is synthesized in real time. Different pitch for head contacts versus tail contacts. Warm reverb for the spacey feel. When you chain a combo, the audio tells you before the screen does.

And then there's the storytelling. Each wave opens with a narrative beat delivered by AI-generated voice. Wave one: "They call it the Breaker Belt: a ribbon of engineered debris that circles the old star like a warning." By wave 38: "The Belt stops feeling like a wall and starts feeling like a mind. It tests not your reflexes, but your habits." It's 50 chapters of cosmic mythology that makes you care about why you're a snake breaking bricks in space.

The backgrounds evolve too. Early waves are calm indigo starfields with soft meteor rain. By mid-game, aurora bands and nebula clouds appear. Late game drops you into Ion Storm territory with sharp cyan streaks against near-black space. The game communicates progression through atmosphere as much as difficulty.

All of this runs on keyboard, gamepad, or touchscreen. Published to web, mobile, and PC from one codebase.

The team that wasn't needed

A game with this depth would typically need a game designer, a couple of programmers, an artist, a sound designer, a composer, a level designer, a narrative writer, and QA. Eight or nine people. Three to six months of coordinated work. Standups, Jira tickets, asset pipelines, platform-specific debugging.

Two of us made this in a long weekend on the Cinevva Engine.

The talent required didn't change. The ratio between creative intent and implementation overhead did. The time was spent deciding what the game should feel like, not fighting tools to make it happen.

Why this matters if you make things

The interesting question isn't whether AI tools can help make games faster. That's been answered. The interesting question is what happens to ideas that used to be too risky to try.

"Snake but you're the paddle in an Arkanoid arena" is not something a producer greenlights. A few indie devs have tried variations on itch.io (BreakSnake, SnakeOut, Snake Break), but they're all small game jam experiments. The genre fusion has never been given a real production pass with reactive music, AI narration, dozens of brick types, and 50 waves of escalating design. In traditional development, that kind of polish on a risky concept gets killed in a meeting before anyone writes a line of code.

When trying something weird costs an afternoon instead of a quarter's budget, the strange ideas get built. Some of them turn out to be genuinely good. A Breaker Belt is one of those.

Play it. Or make your own.

A Breaker Belt is playable right now on web, mobile, and PC. If it makes you want to build something, the Cinevva Engine is free to use. Describe what you want, iterate on what comes back, ship when it's ready. The music, sound effects, art, and 3D models are all built in.

Your weird game idea might be three days away from existing.

Play A Breaker Belt | Build your own game | Browse community games

Viewing source for spike {{ spikeId }}. Run it ↗

No spike specified. Use ?spike=01-terrain in the URL.

Loading source...

{{ error }}

← Back to series guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

We're building a multiplayer open world that runs entirely in the browser. No install, no app store, just a URL. The biggest risk up front was obvious: can a browser even render a persistent 3D world at playable frame rates while leaving headroom for gameplay, physics, and networking?

Most open world projects fail in a predictable order. First you get a nice concept. Then you get a pretty scene. Then you realize your frame budget is already gone before gameplay exists.

We wanted to answer the render budget question before investing in anything else. So Spike 1 skipped the pretty trailer and went straight to measuring.

Open Spike 1 in a new tab ↗ · View source

The setup was simple on purpose. A 512 meter terrain mesh, procedural height from layered sine noise with island falloff, a water plane, atmospheric fog, and 500 instanced objects. We used plain WebGL with Three.js, ACES tone mapping, and no shadows.

We didn't care how it looked. We cared whether the scene stayed stable while moving the camera through it.

Two things came out of this spike that shaped the whole project.

First, we confirmed we had real headroom on desktop if we kept the first pass disciplined. That gave us confidence to attempt the harder terrain architecture later.

Second, we created a baseline contract. Every next spike had to explain its cost relative to this scene. If a new feature looked good but cost too much, it did not get promoted.

That baseline discipline became critical later when we hit seam artifacts, mixed LOD transitions, and compute driven meshing. Without a stable reference, every bug looks bigger than it is.

In part 2 we move from rendering to input feel. Worker physics sounds great in architecture docs. It only matters if the character still feels immediate when you press a key.

Technology referenced in this chapter

Heightmap terrain. A 2D grid where each cell stores a single elevation value. The GPU displaces a flat mesh in the vertex shader to create the terrain surface. Heightmaps are compact (a 65x65 chunk is ~8 KB at 16-bit), GPU-friendly, and fast to render. The limitation is that they can't represent caves, overhangs, or any surface that folds back over itself. For background on heightmap constraints and what comes after them, see our landscape generation guide.

Three.js. The rendering library we used throughout this project. Three.js abstracts WebGL 2 (and later WebGPU) into a scene graph with cameras, lights, materials, and geometry objects. It provides InstancedMesh for rendering many copies of the same geometry in a single draw call, frustum culling, PBR materials, and post-processing. See Three.js on GitHub. For how Three.js fits into a browser open world stack, see our browser 3D tech guide.

InstancedMesh. A Three.js feature that renders N copies of the same geometry with a single draw call, each at a different position/rotation/scale. The per-instance transforms are stored in a matrix attribute buffer. This is how we rendered 500 objects in Spike 1 without 500 separate draw calls. For vegetation at scale, GPU-driven instanced culling takes this further. See our landscape guide on GPU vegetation culling.

Frame budget. At 60 fps, each frame has 16.67 ms for everything: JavaScript logic, physics, rendering, and compositing. A "budget check" spike measures how much of that time a baseline scene consumes, leaving a known amount for features added later. This approach comes from AAA open world development where GTA V, Skyrim, and Elden Ring all use aggressive LOD and streaming to stay within fixed frame budgets.

Part 1 of 12.
Next: Part 2 - Worker physics and the input lag fear
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

If you build browser multiplayer long enough, you eventually get this argument.

"Physics in a worker is clean architecture. Physics on the main thread feels safer."

Both can be true. What matters is control feel and latency under real input.

Spike 2 was built to answer that with measurements, not opinions.

Open Spike 2 in a new tab ↗ · View source

We reused the Spike 1 terrain and integrated Rapier in a dedicated module worker. Input state was sent to the worker every frame, simulation stepped there, and authoritative position came back to the renderer.

The key metrics were input to visible movement latency and physics step timing. We also watched for jitter under normal movement, sprint bursts, and jump cadence.

The result was better than expected. With our message shape and cadence, the worker boundary did not dominate latency. Controls still felt immediate, which was the only thing players would care about.

One challenge from this phase was interpretation risk. After a successful result, teams often overgeneralize and assume the architecture question is closed forever. It is not. We only validated one concrete scenario and hardware profile. Later spikes still had to recheck assumptions when GPU and streaming pressure changed.

This spike also gave us a process upgrade. We started exposing timing telemetry in HUD by default for interactive spikes. That changed team conversations from "it feels off" to "this path added 1.2 ms."

In part 3 we cover the less glamorous experiments that prevented expensive surprises later. Broadcast load, mobile constraints, and behavior generation reliability.

Technology referenced in this chapter

Rapier. A physics engine written in Rust that compiles to WebAssembly for browser use. It handles rigid bodies, colliders, joints, character controllers, and raycasting at 2-3x native performance. For open worlds, Rapier provides player character controllers (walking on terrain, climbing steps, sliding on slopes), object collision, raycasting for interactions, and trigger volumes. See Rapier documentation and our browser 3D tech guide on physics.

Web Workers. Browser threads that run JavaScript (or Wasm) off the main thread. Physics simulation in a worker means a heavy world.step() call doesn't block rendering. The main thread sends input state to the worker each frame via postMessage and receives authoritative positions back. The latency penalty is the two message hops (~0.1-0.5 ms each on desktop). The benefit is that the render thread never stalls on collision detection. Transferable objects (ArrayBuffer transfer) eliminate copy overhead for large position arrays.

WebAssembly (Wasm). A binary instruction format that runs at near-native speed in browsers. Rapier, Havok, and Recast all compile to Wasm. The physics step in Rapier-Wasm is typically 0.5-2 ms for a few hundred bodies, compared to 5-15 ms for equivalent JavaScript. Wasm modules load as .wasm files fetched alongside the JavaScript glue code. See WebAssembly specification.

Input-to-visual latency. The time between a keypress and the resulting visual change on screen. For movement to feel "immediate," this needs to stay under ~80 ms. In a worker physics setup, the chain is: keydown event (main thread) -> postMessage to worker -> physics step -> postMessage back -> renderer applies position -> next vsync. Each hop adds latency, which is why measurement matters more than architecture diagrams.

Part 2 of 12.
Previous: Part 1 - We started by trying to break it
Next: Part 3 - The unflashy spikes that saved us
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

This part has fewer shiny screenshots and more architecture insurance.

After Spikes 1 and 2, we ran three risk checks that looked small but had product level impact.

First was broadcast fan out with Durable Objects. We tested multi client position distribution at game-like tick rates and tracked latency distribution, CPU per tick, and delivery integrity. If this had failed, we would have moved to early sharding instead of single island ownership.

Second was mobile constraint validation. Not a desktop preset renamed to mobile, but an explicit low-cost profile from the same baseline terrain.

Open the mobile profile in a new tab ↗ · View source

We reduced segment density, object count, render resolution pressure, and fog range. The question was simple. Can this world remain readable and responsive on mobile class constraints without rewriting the entire renderer.

Third was behavior generation reliability for creator workflows. We evaluated valid JSON rate, semantic correctness against expected primitives, and response latency. If this had failed, we would have moved to strict form based behavior authoring.

The key insight from this chapter is that these unflashy spikes changed architecture faster than visual spikes did. They set hard boundaries on network topology, mobile promises, and tool UX.

In part 4 we return to visible terrain work and test movement-time streaming behavior, not just static loading screenshots.

Technology referenced in this chapter

Cloudflare Durable Objects. Edge-deployed stateful serverless instances with built-in persistence and WebSocket support. Each Durable Object holds authoritative state for a world shard (or chunk). Players connect via WebSocket and receive position broadcasts from other players in the same shard. When the player moves to an adjacent chunk, they connect to that chunk's Durable Object. Durable Objects auto-persist state to disk and scale to thousands of concurrent instances. See Cloudflare Durable Objects docs and our browser 3D tech guide on multiplayer networking.

Spatial sharding. Dividing the world across server instances by geographic region. Each shard owns a rectangular area of the world grid. As player density shifts, shards can split or merge. Players near a shard boundary see both shards' content through cross-shard visibility queries. This is how EVE Online handles thousands of players in one universe.

WebSocket broadcast fan-out. Distributing real-time position updates from one server to many connected clients. At game-like tick rates (20-30 Hz), each player generates ~800 bytes/second of position data. With 200 players in view, that's ~160 KB/s per client. The server must serialize, filter by relevance (spatial interest management), and push to each connection within the tick budget. See our networking guide for delta compression and update frequency tradeoffs.

Mobile rendering constraints. Mobile GPUs have 1/5 to 1/10 the throughput of desktop GPUs, ~1 GB memory limit (vs 2-4 GB on desktop), and thermal throttling under sustained load. A mobile quality profile reduces segment density, object count, render resolution, draw distance, and shadow quality. The goal isn't parity with desktop but maintaining readability and responsiveness. See browser 3D performance numbers for real GPU benchmarks.

Part 3 of 12.
Previous: Part 2 - Worker physics and the input lag fear
Next: Part 4 - Streaming before fancy terrain
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Streaming is where "looks good" projects usually fall apart.

You can hide a lot in a still frame. You cannot hide a 40 ms hitch while crossing a chunk boundary.

We intentionally tested streaming before we built advanced terrain representation. That gave us clean signal on load and unload behavior.

Spike 6 validated neighborhood churn with simple chunk content.

Open Spike 6 in a new tab ↗ · View source

Then we moved to the real terrain path in Spike 11. Height chunk streaming with worker side decode and progressive refinement from 17 to 33 to 65 sample grids.

Open Spike 11 in a new tab ↗ · View source

The sequencing mattered more than we expected. If we had started directly with compressed height chunks, every hitch would have been ambiguous. Decode issue, texture upload issue, or geometry update issue. Spike 6 removed one uncertainty layer before Spike 11 added complexity.

A practical lesson from this chapter carried into later spikes. Upload stalls must be measured directly, not inferred from average FPS. Average FPS hides frame spikes, and frame spikes are what users actually feel.

In part 5 we move into the visual cost chapter where vegetation, terrain shaders, and cascaded shadows compete for the same frame budget.

Technology referenced in this chapter

Chunk-based streaming. The world is divided into a grid of independent chunks (typically 64x64 meters). As the player moves, chunks on the trailing edge unload while chunks on the leading edge stream in. This is how Skyrim's cell system works: a 5x5 grid of cells loaded around the player, swapping as they move. The browser version adds network latency to the equation, making predictive pre-fetching based on player velocity critical. See our streaming architecture guide.

Progressive heightmap refinement. Send terrain at low resolution first, then refine. A 17x17 grid (the minimum for a 64m chunk at 4m spacing) is ~200 bytes compressed and renders a visible surface instantly. Then stream the 33x33 refinement (adds detail), then the full 65x65 resolution. Each level adds samples without replacing previous data. This maps directly to geometry clipmap LOD rings where distant terrain uses low-resolution data and close-up terrain uses full resolution. See progressive chunk loading.

Delta encoding and compression. Heightmap data compresses well because adjacent cells have similar values. Delta encoding stores the difference between each cell and its predicted value (average of neighbors), clustering values near zero. Combined with zlib or brotli, a 65x65 chunk drops from 8.4 KB raw to 1-2 KB compressed. At reduced precision for distant chunks (8-bit instead of 16-bit): 0.5-1 KB. See terrain data compression.

Predictive pre-fetching. Loading chunks before the player arrives. At walking speed (5 km/h), pre-fetch 2 chunks ahead (128m). At running speed (15 km/h), pre-fetch 4 chunks. The load ring shifts with velocity direction. A priority queue sorts pending requests by urgency and cancels requests for chunks the player has moved away from. See predictive pre-fetching.

Part 4 of 12.
Previous: Part 3 - The unflashy spikes that saved us
Next: Part 5 - Budgeting the pretty stuff
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

This was the chapter where visual ambition met arithmetic.

We split rendering cost into separate spikes because bundled results are hard to diagnose. If you turn everything on at once, you only learn that the frame is slow. You don't learn which feature ate the budget.

Spike 7 targeted vegetation density and animation cost. The approach was runtime scattering from 32x32 density maps per terrain chunk, feeding large InstancedMesh sets. Each grass blade and shrub cluster got vertex-shader wind driven by a scrolling noise texture. The key number we watched wasn't triangle count but draw call overhead and vertex throughput on mid-range GPUs. We found that batching instances into fewer meshes mattered more than reducing per-blade polygon count.

Open Spike 7 in a new tab ↗ · View source

Spike 8 pushed terrain material complexity. Multi-layer blending weighted by slope angle and altitude, optional triplanar projection for cliff faces, and per-layer normal maps. The shader was doing slope-based splatting with four texture layers, each needing a diffuse and normal sample. That's eight texture fetches per fragment before you add any lighting. We profiled on integrated Intel GPUs specifically to find the floor. The takeaway was that triplanar projection on vertical surfaces was worth the cost, but adding a fifth splat layer wasn't.

Open Spike 8 in a new tab ↗ · View source

Spike 9 focused on cascaded shadow map cost under realistic terrain and object load. CSM with three cascades was baseline. We tested with low-angle sun positions specifically because that's where cascade pressure gets worst. The far cascade covers a huge frustum slice, and shadow map resolution per texel drops fast. We measured the GPU time difference between two and four cascades, then between 1024 and 2048 shadow map resolution. The result was that three cascades at 1024 gave us acceptable contact shadows near the camera without exceeding 2ms of GPU time on our target hardware.

Open Spike 9 in a new tab ↗ · View source

The hard part in this phase was product discipline. Some effects looked excellent and still had to be constrained because they consumed too much of the frame budget relative to their visual impact.

Our rule became simple. A feature moves forward only if it can explain its cost with measured frame-time data.

That sounds obvious. It's not common in fast prototype cycles where everyone is excited about the next visual win. Keeping this rule early made architecture decisions around clipmaps and volumetric zones much cleaner later, because we already knew the per-feature cost of everything competing for the same 16ms.

In part 6 we hit the first major terrain architecture pivot with geometry clipmaps.

Technology referenced in this chapter

InstancedMesh and GPU vegetation. Three.js's InstancedMesh renders N copies of the same geometry with one draw call. For vegetation, a density map (32x32 per chunk) drives runtime scattering of grass blades and shrub clusters into instance buffers. Wind animation runs in the vertex shader using a scrolling noise texture. At scale, WebGPU's ComputeInstanceCulling eliminates off-screen and distant instances before rasterization, and IndirectBatchedMesh packs multiple vegetation types into a single buffer drawn with multi-draw indirect. See our landscape guide on GPU vegetation culling.

Triplanar mapping. Standard UV-mapped textures stretch on steep slopes because UV coordinates compress. Triplanar mapping projects textures along all three axes (X, Y, Z) and blends based on the surface normal. Cliff faces get the X or Z projection (no stretching), flat ground gets the Y projection. The blending is smooth and automatic with no UV unwrapping required. For PBR terrain, the same blending weights apply to albedo, normal, roughness, and ambient occlusion channels. See triplanar mapping details.

Slope and altitude-based material splatting. Instead of hand-painted splat maps, materials are assigned procedurally in the fragment shader based on terrain properties. Flat ground at low altitude gets grass, steep slopes get rock, high altitude gets snow (only on surfaces flat enough for accumulation), near sea level gets sand. The transitions use smoothstep for smooth blending. In our implementation, each terrain chunk evaluates four texture layers with diffuse and normal samples per layer, resulting in eight texture fetches per fragment before lighting. See slope and altitude material assignment.

Cascaded Shadow Maps (CSM). CSM splits the camera's view frustum into 3-4 distance ranges (cascades). Each cascade renders a shadow map from the sun's perspective at a resolution matched to its distance. Close cascades get high-resolution shadows (detailed contact shadows under trees and buildings), far cascades get lower resolution (broad mountain shadows). The terrain shader samples all cascades and selects the appropriate one per fragment. Performance cost: 3-4 cascades at 1024x1024 add ~0.5-1 ms for shadow map rendering plus ~0.2-0.3 ms for sampling. See shadows for terrain.

Part 5 of 12.
Previous: Part 4 - Streaming before fancy terrain
Next: Part 6 - Clipmaps changed the plot
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Before Spike 10, our mental model was still "bigger world means more geometry." After Spike 10, the model became "constant geometry budget, camera-centered ring updates." That shift changed the project trajectory.

The idea behind geometry clipmaps is straightforward. You render terrain as a set of concentric rings centered on the camera. The innermost ring has the highest vertex density. Each ring outward doubles the spacing between vertices and covers twice the ground. The total triangle count stays roughly constant no matter how far you can see, because you're always rendering the same number of rings with the same mesh resolution.

Open Spike 10 in a new tab ↗ · View source

The practical trick was geomorphing at ring boundaries. When a vertex transitions from one LOD ring to the next, its height has to blend smoothly between the high-res and low-res sample. Without that, you get visible pops every time the camera moves and rings shift. We handled this with a blend factor based on the vertex's distance to the ring edge, interpolating height in the vertex shader.

One subtle lesson came from camera movement testing. It's easy to judge clipmaps in static screenshots and miss transition artifacts. We spent time running constant-speed traversals through ring boundaries and watching for temporal noise. Screenshots lied. Motion told the truth.

This spike also gave us a clean architectural boundary. Near-field terrain could become dynamic and expensive over time, with volumetric editing, higher material complexity, and physics interaction. Far-field terrain could stay stable, predictable, and cheap. That separation became the backbone of every architectural decision from this point forward.

If you're evaluating clipmaps for your own project, test stress loops, not beauty shots. Long traversal paths, changing camera altitude, and repeated boundary crossings are what expose the real problems.

In part 7 we add volumetric meshing and move from "terrain as a surface" to "terrain as editable volume." That was the point where this project stopped being a renderer and started becoming a world editor.

Technology referenced in this chapter

Geometry clipmaps. Introduced by Losasso and Hoppe at SIGGRAPH 2004 (paper), geometry clipmaps render terrain as concentric square rings centered on the camera. Each ring is twice the area of the previous one at half the vertex resolution. The total vertex count is constant: roughly N^2 * levels. With N=256 and 8 levels, that's ~500K vertices regardless of world size. The CPU updates heightmap data for each ring as the camera moves. The vertex shader reads height from a texture and displaces the flat grid. See our landscape guide on geometry clipmaps and GPU Gems 2, Chapter 2.

Geomorphing. The biggest visual artifact in terrain LOD is popping: vertices suddenly jump when a patch switches LOD level. Geomorphing eliminates this by blending vertex positions between LOD levels over a transition zone. Each vertex stores both its current-LOD height and its coarser-LOD height. A morph factor based on camera distance smoothly interpolates between them: morphedHeight = mix(fineLodHeight, coarseLodHeight, smoothstep(lodNear, lodFar, distance)). The transition zone is typically the outer 20% of each ring. At normal camera speeds, the transition is invisible. See geomorphing details.

CDLOD (Quadtree-Adaptive Clipmaps). An improvement on fixed-ring clipmaps by Strugar (2014, paper). Instead of concentric rings with uniform resolution, CDLOD uses a quadtree that adapts to terrain complexity. Flat areas use coarse nodes, while areas with high detail (cliffs, ridges) get finer subdivision. This matters for creator worlds where different chunks have vastly different complexity. See CDLOD in our landscape guide.

Part 6 of 12.
Previous: Part 5 - Budgeting the pretty stuff
Next: Part 7 - Marching cubes and the first real caves
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Heightmaps are great until you need overhangs.

The moment you want carved tunnels, floating rock lips, or cave ceilings, a pure heightfield pipeline starts blocking you. A heightmap stores one Y value per XZ coordinate. It's physically incapable of representing any surface that folds back over itself. We needed a volumetric representation.

Spike 12 implemented marching cubes on the GPU using WebGPU compute shaders. The algorithm evaluates a signed distance field (SDF) on a 3D grid and extracts a triangle mesh at the zero-crossing surface. Each grid cell is classified into one of 256 cases using a lookup table, and the corresponding triangles are emitted. We ran this on four active 64-cubed chunks simultaneously and tested animated SDF edits with per-frame remesh.

Open Spike 12 in a new tab ↗ · View source

The first win was confidence in the compute pipeline itself. A single dispatch could evaluate the SDF, classify cells, and emit vertices into a GPU buffer without any CPU readback. The second win was discovering how fast "it works" turns into artifact hunting. Missing triangles were rarely a marching cubes theory problem. They were table index mismatches, incorrect draw ranges reading past the active vertex count, or edge-case interactions near chunk boundaries where neighboring SDF samples weren't available.

This spike forced us to think in zones. Near the camera, you want volumetric freedom so players can carve, dig, and see caves. Far from the camera, you want clipmap efficiency where a flat heightmap is cheaper and perfectly adequate. That duality became the backbone of the architecture we kept refining from Spike 13 onward.

One of my favorite debugging moments was the wireframe toggle while edits were running. Watching topology form and dissolve in real time made quality tradeoffs immediately visible. You could see where vertex density was high enough, where it got too coarse, and exactly where LOD transitions would eventually need Transvoxel support to avoid cracks.

In part 8 we cover the integration challenge. Keeping raw compute-driven meshes and Three.js scene graph logic in one stable rendering pipeline was harder than the isolated demo suggested.

Technology referenced in this chapter

Marching cubes. An algorithm for extracting a triangle mesh from a 3D scalar field (Lorensen and Cline, 1987). Each cell in a regular 3D grid is classified by sampling the field at its 8 corners. The sign pattern produces a case index (0-255), and a lookup table maps each case to a set of triangles. Vertices are placed on grid edges by interpolating between the two corners. The algorithm is embarrassingly parallel since each cell processes independently, making it ideal for GPU compute. See our landscape guide on SDFs and marching cubes.

Signed Distance Fields (SDFs). A volumetric representation that stores, at every point in 3D space, the signed distance to the nearest surface. Positive values are outside, negative are inside, and the zero-crossing is the surface. SDFs can represent arbitrary 3D shapes: caves, arches, overhangs, and floating geometry that heightmaps can't express. Editing is natural: adding material is a min() on the distance field, removing (digging) is max() with a negated shape, smooth blending uses smoothMin(). See SDF terrain representation.

WebGPU compute shaders. GPU programs that run general-purpose computation, not tied to the rasterization pipeline. A compute shader dispatches workgroups of threads that execute in parallel. For marching cubes, each thread processes one grid cell: sample the SDF, classify the cell, look up triangulation, interpolate edge vertices, and append to a mesh buffer using atomic counters. No CPU readback is needed because the output buffer is used directly as vertex data for rendering. Will Usher's webgpu-marching-cubes demonstrates real-time 256^3 grid processing in the browser. See our landscape guide on WebGPU-driven LOD.

Hybrid heightmap + SDF architecture. The practical approach for browser terrain: heightmaps cover the entire world (cheap, compact), while SDF volumes exist only in chunks that need caves, overhangs, or creator-carved features (5-10% of chunks). Near the camera, volumetric freedom allows carving and caves. Far away, heightmaps provide efficient flat terrain. See hybrid terrain representation.

Part 7 of 12.
Previous: Part 6 - Clipmaps changed the plot
Next: Part 8 - Integration without losing our baseline
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Integration is where projects get messy. You have working pieces in isolation. You connect them and suddenly every bug looks like it could be anywhere.

Spikes 13 and 14 were our answer to that trap. Spike 13 established a clean Three.js WebGPU baseline. Just a renderer, a scene, a camera, and a simple mesh. No terrain, no compute, no effects. We confirmed that Three.js's WebGPU backend initialized correctly, that the render loop was stable, and that TSL (Three.js Shading Language) node materials worked as expected. Only after that checkpoint passed did we start adding layers.

Open Spike 13 in a new tab ↗ · View source

Spike 14 was incremental hardening. We added one capability at a time: first camera controls, then lighting, then the compute-generated mesh from the marching cubes pipeline, then buffer plumbing to feed GPU output directly into Three.js geometry attributes. After each addition, we verified that the previous layer still behaved correctly.

Open Spike 14 in a new tab ↗ · View source

That sounds slow. It was slow for exactly one day, and it saved us multiple days soon after when seam logic and policy switching got complicated.

The specific category of bug that justified this discipline was hairline artifacts. Thin slivers that looked like geometry corruption but were actually stale data. The compute shader would write N vertices into a buffer, but the draw call would still be configured to render N+M vertices from the previous frame. Those extra vertices contained garbage from the old dispatch. The visual result was flickering razor-thin triangles that appeared and vanished unpredictably.

You don't beat that class of bug with intuition. You beat it with controlled deltas where you know exactly what changed between the last working state and the current broken state.

The WebGPU integration also taught us about buffer lifecycle. GPU buffers in WebGPU are immutable once mapped for a specific usage. If you need to resize a vertex buffer because the marching cubes output grew, you have to create a new buffer and update the binding. There's no realloc. Getting that lifecycle right, destroying old buffers without racing against in-flight GPU work, required explicit fence management that doesn't exist in WebGL.

In part 9 we move into Transvoxel seam work. That chapter starts with a scaffold on purpose. By this point we had fully internalized the lesson that rushing integration produces mysteries, and controlled setup produces debuggable problems.

Technology referenced in this chapter

WebGPU. The successor to WebGL, providing low-level GPU access in the browser with compute shaders and indirect rendering. WebGPU's two critical features for open worlds: compute shaders enable GPU-side terrain generation, foliage placement, and culling; indirect rendering lets the GPU decide what to draw based on compute output, eliminating CPU bottlenecks in dense scenes. Available in Chrome, Edge, and Firefox on desktop. See WebGPU as a performance unlock.

Three.js Shading Language (TSL). Three.js's node-based shader system that replaces raw GLSL/WGSL with composable JavaScript expressions. TSL nodes like texture(), positionWorld, smoothstep(), and fog() build a shader graph at runtime that compiles to the appropriate backend (WebGL GLSL or WebGPU WGSL). TSL makes it possible to write material logic once and target both renderers. The node graph is evaluated per-frame, so dynamic uniforms and conditional branching work naturally.

GPU buffer lifecycle in WebGPU. WebGPU buffers are created with specific usage flags (VERTEX, STORAGE, COPY_DST, etc.) and can't be resized after creation. If a marching cubes dispatch produces more vertices than the buffer can hold, you must create a new buffer, update the binding, and destroy the old one. Destroying a buffer that's still referenced by an in-flight GPU command causes errors. Explicit fence management (via device.queue.onSubmittedWorkDone()) ensures the old buffer isn't destroyed until the GPU finishes using it. This lifecycle discipline doesn't exist in WebGL, where the driver manages memory implicitly.

Incremental hardening. A process discipline for integration: establish a known-good baseline, add one capability at a time, and verify the previous layer still works after each addition. This approach is slower for one day and saves days during later debugging because each regression can be traced to a specific, controlled change. The baseline-then-increment pattern is common in AAA open world development where systems are integrated in a specific order to manage risk.

Part 8 of 12.
Previous: Part 7 - Marching cubes and the first real caves
Next: Part 9 - Transvoxel started with a scaffold
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Seams are where confidence goes to die.

Everything can look stable until two resolutions meet. A chunk at LOD 0 sits next to a chunk at LOD 1. Their meshes are generated independently. Where they share a boundary, the vertex positions don't match because the lower-resolution chunk has half the grid density. The result is visible cracks, T-junctions, and flickering edges.

The Transvoxel algorithm solves this by generating special transition cells along the boundary face between two chunks at different resolutions. These cells sample from both the high-res and low-res grids simultaneously and produce triangles that stitch the two surfaces together. The algorithm uses its own lookup tables, separate from the regular marching cubes tables, with 512 transition cell cases.

We had enough integration scars by this point to know better than to rush the implementation.

Spike 15 had one job: build a seam test rig we could trust before touching the full algorithm. We set up a controlled environment where two chunks of known SDF data sat side by side at different resolutions, with visualization controls to toggle the main mesh, the seam mesh, wireframe, and normals independently.

Open Spike 15 in a new tab ↗ · View source

Once the test rig was stable, Spike 16 validated table-driven transition cell generation on a single face. We picked one axis-aligned face (+X boundary), implemented the transition cell evaluation for that face only, and compared the output against reference data from the Transvoxel paper.

Open Spike 16 in a new tab ↗ · View source

We tested one face at a time on purpose, because transition table wiring has many independent failure modes. Case index computation depends on sampling the correct vertices from both grids. Vertex indexing within a transition cell uses a different numbering scheme than regular marching cubes cells. Winding order has to be consistent with the main mesh or backface culling will eat your seam triangles. If you test all six faces at once, every symptom looks random. If you test one face thoroughly, you get meaningful, debuggable failures.

Another subtle win from this phase was tooling investment. We built visibility toggles, seam-only rendering, and color-coded LOD indicators early. Those controls felt like overhead at the time. Later, when corner cases got ugly, they paid for themselves over and over because we could isolate exactly which seam cells were misbehaving.

By the end of this chapter we weren't "done with seams." We were in a position where seam bugs could be reasoned about instead of feared.

In part 10 the real roller coaster starts. Mixed LOD corners, winding flips, partial overdraw ghosts, and those moments where you're sure the algorithm is wrong and then discover the bug is a draw range reading past the active vertex count.

Technology referenced in this chapter

The Transvoxel algorithm. Designed by Eric Lengyel (transvoxel.org), Transvoxel solves the hardest problem in volumetric terrain LOD: seams between chunks at different resolutions. When a high-res chunk sits next to a low-res chunk, the marching cubes meshes don't align at the boundary, producing visible cracks. Transvoxel inserts special transition cells along boundary faces that bridge the resolution difference with additional triangles matching both sides. The algorithm uses its own lookup tables (separate from regular marching cubes) with 512 transition cell cases, reduced to 73 equivalence classes. It's patent-free and has been used in shipped games (Space Engineers, Astroneer). See our landscape guide on Transvoxel.

Transition cells. Special cells generated at the face between two LOD levels. Unlike regular marching cubes cells that sample 8 corners from one grid, transition cells sample from both the high-res and low-res grids simultaneously. The high-res face has 9 sample points (3x3), while the low-res face has 4 (2x2). The cell classification and triangulation use dedicated tables that produce triangles connecting vertices at both resolutions. The vertex numbering scheme is different from regular MC cells, which is a common source of implementation bugs.

LOD transition seams. The boundary between two mesh resolutions where topology mismatch causes visual artifacts. Without stitching, a LOD 0 chunk (1m grid) next to a LOD 1 chunk (2m grid) produces T-junctions: the fine mesh has vertices along the boundary that the coarse mesh doesn't share, causing cracks where light bleeds through. Transvoxel, geomorphing, and skirt geometry are three approaches to fixing these seams. For volumetric terrain, Transvoxel is the standard solution because geomorphing only works for heightmaps. See LOD for volumetric terrain.

Part 9 of 12.
Previous: Part 8 - Integration without losing our baseline
Next: Part 10 - Seam chaos and the corner boss fight
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

If the earlier parts felt methodical, this chapter felt like combat.

Spikes 17 through 22 were our corner-case era. Dual-LOD marching cubes, heightmap-to-MC boundary seams, mixed-resolution corner chunks where three or four LOD levels meet, GPU seam generation, and fallback mode behavior. Each spike addressed a specific failure scenario we'd encountered or anticipated.

Spike 17 tested dual marching cubes with two LOD levels active simultaneously. The challenge was that a single chunk's neighbors could be at different resolutions on different faces. The transition cell logic from Spike 16 worked for one face at a time, but when a chunk needed transition cells on multiple faces, the vertex buffer management got complicated. Each face's transition cells had to be generated and appended without overwriting the others.

Open Spike 19 in a new tab ↗ · View source

The first repeated villain was winding order. Several times we thought we had topology problems, then found orientation problems. Backface culling was eating valid seam triangles because the winding was flipped relative to the main mesh. Same root cause, different visual symptom depending on camera angle. The fix was enforcing a consistent winding convention in the transition cell emission code and verifying it with a double-sided material toggle.

The second villain was false confidence from partial correctness. A seam could look perfect from one camera angle and break when LOD roles swapped between higher and lower resolution chunks. The transition cell is asymmetric. It samples from the high-res side and the low-res side differently. If you get the "which side is high-res" logic backwards for one configuration, you only see the bug when the camera moves to a specific position.

Then came one of our favorite recoveries. We were chasing a seam cutoff artifact on heightmap tiles and blaming the transition logic. Burned two days on it. The real culprit was stale overdraw. Higher-resolution geometry from a previous frame was still living in the buffer tail after the chunk downscaled to a lower LOD. The draw range was still set to the old, larger vertex count. Once we clipped the draw range to the active vertex count reported by the compute shader's atomic counter, the "mystery seam issue" disappeared.

That was a great reminder that rendering bugs often masquerade as meshing bugs. The geometry was correct the whole time. The draw call was just reading past the end of valid data.

By Spike 22 we were testing hybrid fallback where chunks could switch from marching cubes to heightmap mode under specific conditions, like when the chunk contains no volumetric edits and sits far enough from the camera. This gave us a more practical path than an all-or-nothing policy. Near-field edited chunks use MC for volumetric freedom. Far-field unedited chunks use heightmaps for efficiency.

Open Spike 22 in a new tab ↗ · View source

This chapter was the steep drop of the roller coaster. Frustrating and productive at the same time. Many of the individual fixes were small, sometimes a single line changing a comparison operator or an offset. But the understanding they produced about how LOD transitions, buffer management, and draw ranges interact wasn't small at all.

In part 11 we cover the stabilization layer that came after the chaos: policy-based chunk modes and the transition from reactive bug-fixing to explicit system rules.

Technology referenced in this chapter

Dual-LOD marching cubes. Running marching cubes at two resolution levels simultaneously, with transition cells stitching the boundary. The challenge is that a single chunk's neighbors can be at different resolutions on different faces, requiring independent transition cell generation per face. Each face's transition cells are appended to the vertex buffer without overwriting the others. Atomic counters track the total active vertex count across all faces.

Winding order. The vertex order within each triangle determines which side is the "front" face. Consistent winding (typically counter-clockwise when viewed from outside) is required for backface culling. When transition cells emit triangles, the winding must match the main mesh's convention. Getting it backwards causes backface culling to eat valid seam triangles, which looks like missing surfaces from certain camera angles. A common debugging technique is toggling side: THREE.DoubleSide on the material to confirm whether artifacts are winding issues or genuine topology gaps.

Heightmap-to-MC fallback. A hybrid chunk mode where far or unedited chunks use heightmap terrain (cheap, flat surface) while near or edited chunks use marching cubes (volumetric, supports caves). The fallback decision depends on distance from camera and whether the chunk contains SDF edits. The seam between a heightmap chunk and an MC chunk requires its own transition geometry, similar to Transvoxel but bridging two different representations rather than two LOD levels. See hybrid heightmap + volumetric overlays.

Draw range and atomic counters. In GPU-driven mesh generation, the compute shader writes vertices into a buffer and increments an atomic counter to track how many vertices were emitted. The draw call must use this counter as the vertex count, not the buffer capacity. If the draw range isn't clipped to the active count, stale vertices from previous frames (still living in the buffer tail) produce ghost geometry: thin slivers and flickering triangles that look like topology errors but are actually rendering artifacts from reading past valid data.

Part 10 of 12.
Previous: Part 9 - Transvoxel started with a scaffold
Next: Part 11 - Policy mode, not hardcoded mode
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

After the seam chaos chapter, we needed to stop reacting and start governing.

Spike 23 replaced ad-hoc behavior with explicit policy rules. Instead of chunks doing whatever their local state suggested, a central policy system now made the decisions. Which LOD level does this chunk get? Is it rendered as heightmap or marching cubes? Does it need transition cells, and on which faces? The answers came from a policy function that evaluated distance to camera, edit history, and neighbor resolution states.

Open Spike 23 in a new tab ↗ · View source

The distance-based LOD assignment used concentric rings around the camera, similar to the clipmap concept but applied to the chunk grid. Ring 0 chunks get full-resolution MC. Ring 1 gets half-resolution MC. Ring 2 and beyond get heightmap mode. The adjacency constraint was critical: if two neighboring chunks differ by more than one LOD level, the policy forces the lower-detail chunk to upgrade. This prevents seam cases that the Transvoxel tables can't handle, since transition cells are defined for a 2:1 resolution ratio only.

The HM/MC switching logic checked each chunk's edit bitmap. If a chunk had any volumetric edits (caves, tunnels, terrain sculpts), it stayed in MC mode regardless of distance. Unedited chunks could drop to heightmap mode when they moved far enough away. This hybrid approach gave us volumetric freedom where it mattered and efficiency where it didn't.

This spike looked smaller from the outside than some earlier ones. In practice it was a major quality-of-life improvement for development.

When your system can explain why a chunk switched mode, you spend less time guessing. We added color-coded overlays: green for heightmap chunks, blue for MC chunks, orange for transition-active faces. When seam visibility has dedicated render controls, visual debugging ambiguity drops. When draw ranges are explicitly tied to active vertex counts from the policy system, stale geometry ghosts stop wasting your afternoon.

We also overhauled camera behavior in this spike. Earlier spikes had simple orbit controls fine for screenshots but useless for reproducing bugs. Spike 23 added WASD fly camera with configurable speed, altitude lock toggle, and position readout. That sounds minor. It meant the difference between "I saw a bug somewhere near that ridge" and "the bug appears at position (142, 12, -67) facing northwest."

The key insight from this chapter is that policy didn't reduce complexity. It organized complexity. The same number of edge cases existed. But now each edge case had a name, a trigger condition, and a place in the code where you could set a breakpoint. That's a different kind of win, and it's what determines whether a system can keep evolving or collapses under its own weight.

By the end of Spike 23, we had a near-field behavior layer that was predictable enough to connect to a far-field clipmap ring strategy without constant fear of interaction bugs.

In part 12 we cover Spike 24, where ring transitions, skybox fog, and Three.js version-level shader integration close out this chapter of the project.

Technology referenced in this chapter

Distance-based LOD policy. A central function that assigns LOD level and rendering mode to each chunk based on distance to camera, edit history, and neighbor states. Concentric distance rings determine the base LOD: ring 0 = full-res MC, ring 1 = half-res MC, ring 2+ = heightmap mode. The policy function runs per frame as the camera moves and triggers chunk transitions. This replaces ad-hoc per-chunk decisions with a predictable, debuggable rule system. See GPU-driven LOD selection for the compute shader equivalent.

Adjacency constraints. The Transvoxel algorithm handles 2:1 resolution ratios only. If two neighboring chunks differ by more than one LOD level (e.g., LOD 0 next to LOD 2), the transition tables can't produce valid seam geometry. The policy system enforces this by upgrading the lower-detail chunk when the LOD difference exceeds 1. This constraint propagation can cascade: upgrading one chunk may force its neighbors to upgrade as well. The implementation is a simple iterative pass that converges in 2-3 iterations for typical grid configurations.

Edit bitmap for mode selection. Each chunk maintains a bitmap recording whether it contains volumetric SDF edits (caves, tunnels, sculpts). Chunks with any edits stay in marching cubes mode regardless of distance, preserving the creator's modifications. Unedited chunks drop to heightmap mode when far enough from the camera, saving compute and memory. The bitmap is a single flag per chunk but can be extended to track edit density for more granular mode decisions.

Debug visualization overlays. Color-coded chunk rendering where green = heightmap mode, blue = MC mode, orange = transition-active faces. Per-chunk overlays with LOD level numbers, mode labels, and wireframe toggles. These are development tools, not shipped features, but they pay for themselves repeatedly when debugging LOD transitions and seam artifacts. Combined with a WASD fly camera that reports exact world position, they turn "I saw a bug somewhere" into "the bug appears at (142, 12, -67) with this LOD configuration."

Part 11 of 12.
Previous: Part 10 - Seam chaos and the corner boss fight
Next: Part 12 - Rings, sky fog, and what we would do again
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

New here? Use the series guide. It explains what a spike is and links all parts.

Spike 24 was supposed to be "add clipmap rings to the terrain." It became a full finale that touched rendering, shaders, module infrastructure, and visual integration all at once.

The core terrain task was generating concentric clipmap rings in the vertex shader. Each ring is a flat grid mesh centered on the camera, with vertices displaced by heightmap samples. The inner ring uses full resolution. Each subsequent ring doubles the vertex spacing and covers a larger area. The tricky part is the boundary between rings: where a high-resolution ring meets a low-resolution ring, edge vertices on the finer mesh need to snap to the midpoint of the coarser mesh's edge. We did 2:1 edge morphing by detecting boundary vertices (those whose grid coordinate is odd along the ring edge) and interpolating their height between the two neighboring even vertices. This produces watertight seams without transition geometry.

Open Spike 24 in a new tab ↗ · View source

Then came the fog and sky integration. We wanted distant terrain to fade into the actual sky color, not a flat constant. That meant the fog shader needed to know what color the sky would be in the direction of each fragment. We loaded an equirectangular HDR skybox texture and sampled it in the fragment shader using the view direction from camera to fragment, converted to equirectangular UV coordinates via TSL's equirectUV node. The fog factor was distance-based using positionView.z.negate() for camera-space depth, blended with smoothstep between a near and far distance.

Module wiring turned out to be more annoying than any of the geometry. We upgraded to Three.js 0.183.1, which restructured the build outputs. The three/tsl import needed to resolve to three.tsl.js, and TSL internally imported three/webgpu as a bare specifier. Both mappings had to be explicit in the HTML import map. Missing either one produced cryptic "does not provide an export" or "failed to resolve module specifier" errors with no indication of which mapping was wrong. Once both were in the import map, the shader graph loaded correctly.

We also had a skybox orientation issue where the texture rendered upside down. The fix was flipY = true on the equirectangular texture, which is the Three.js default for loaded textures but was set to false in our initial code.

The original fog implementation sampled the sky at a near-constant direction, producing a thin horizon-colored band instead of a natural gradient. The fix was computing the actual camera-to-fragment world direction per pixel using positionWorld.sub(cameraPosition).normalize() and passing that into equirectUV for the fog color lookup. This made terrain fragments fade into the sky color that's actually behind them, which looks correct from any camera angle.

Underneath all the individual fixes, the core outcome held. We now have a terrain system that combines near-field volumetric editing (marching cubes with Transvoxel seams), mid-field heightmap chunks, and far-field clipmap rings, all governed by a policy layer that decides mode, LOD, and transition behavior.

If I had to name the patterns I'd repeat on the next project, they'd be these:

Start with risk spikes before feature work. Spike 1 killed the "can we even render fast enough" question before we invested in content pipelines.

Freeze known-good baselines before integration jumps. Spikes 13 and 14 saved us days of bisecting regressions.

Force policy and observability before optimization marathons. Spike 23 turned mystery bugs into named conditions with trigger rules.

Test under motion, not screenshots. Clipmap pops, seam flicker, and streaming hitches all hide in still frames.

Measure frame-time cost per feature, not average FPS. Averages hide the spikes that users actually feel.

And publish the messy parts. The wrong turns, the stale-buffer ghost hunts, the two days blaming transition logic when the draw range was wrong. Those are the parts people can actually learn from.

External reality check: Vuntra City devlogs

After finishing this series, we reviewed the @VuntraCity devlogs as an external implementation check against our own open-world assumptions. It's a native UE5 project, not a browser stack, but the system patterns map well enough that the comparison is useful.

The first signal is that traversal speed has to be treated as a streaming control, not just gameplay. In Vuntra City, high-speed transit is intentionally routed above most interiors, and detail range scales with movement speed to avoid spawn churn and stalls (transport system, performance techniques). That matches our policy-layer direction: movement mode should directly influence chunk radius, interior activation, and allowed work per frame.

The second signal is architecture. Their maps and address system required separating world topology from rendered objects so global queries can run for unloaded regions (maps and addresses). That's the same separation we need in browser for world search, quest routing, moderation scans, and POI indexing without forcing render-bound data paths.

The third signal is simulation tiering. Their million-NPC design keeps coarse schedule state cheap and global, then spends expensive behavior budget only near the player (million-NPC overview, system deep dive). That reinforces our own AOI-first simulation model, where near-field fidelity and far-field determinism are separate concerns with separate budgets.

And the fourth signal is design quality, not raw scale. Their strongest exploration moments come from weighted distributions, rare outliers, and diegetic navigation clues instead of constant UI overlays (procedural environment notes, no minimap loop). For us, this is a reminder that technical systems should be tuned to produce discoverable variation, not just maximal throughput.

Technology referenced in this chapter

Clipmap ring geometry. Each ring is a flat grid mesh centered on the camera with vertices displaced by heightmap samples. The inner ring uses full resolution. Each subsequent ring doubles vertex spacing and covers a larger area. The tricky part is the boundary: where a high-res ring meets a low-res ring, edge vertices on the finer mesh snap to the midpoint of the coarser mesh's edge. The technique originates from Losasso and Hoppe's SIGGRAPH 2004 paper (PDF) and is detailed in GPU Gems 2, Chapter 2. See our landscape guide on geometry clipmaps.

2:1 edge morphing. At the boundary between two clipmap rings, the finer ring has vertices at positions the coarser ring doesn't share. Boundary vertices whose grid coordinate is odd along the ring edge are detected and their height is interpolated between the two neighboring even vertices. This produces watertight seams without dedicated transition geometry. The interpolation runs in the vertex shader: morphedHeight = mix(heightLeft, heightRight, 0.5) for boundary vertices, using the same geomorphing framework described in our guide.

Equirectangular skybox mapping. A single 2D image that maps the full sphere of sky directions using longitude-latitude projection. The horizontal axis covers 0-360 degrees, the vertical axis covers 0-180 degrees. In Three.js, setting texture.mapping = EquirectangularReflectionMapping with SRGBColorSpace enables this as a scene background. In TSL, equirectUV(direction) converts a 3D view direction into the 2D UV coordinates for sampling the texture.

Per-fragment fog color from sky. Standard fog blends fragments toward a single constant color. For a scene with a detailed skybox, this looks wrong because the sky color varies by direction. The fix is to compute the camera-to-fragment world direction per pixel (positionWorld.sub(cameraPosition).normalize()) and sample the skybox at that direction for the fog color. Each fragment fades toward the sky color that's actually behind it, producing correct blending from any camera angle. The fog factor uses smoothstep(nearDist, farDist, viewDepth) with positionView.z.negate() for camera-space depth.

Import maps for ES modules. A browser-native mechanism (<script type="importmap">) that maps bare module specifiers (like three/tsl) to actual URLs. When Three.js 0.183.1 restructured its build outputs, three/tsl needed to resolve to three.tsl.js and TSL internally imported three/webgpu as a bare specifier. Both mappings had to be explicit in the import map, or the browser produced "does not provide an export" or "failed to resolve module specifier" errors.

Further reading

For deeper coverage of the technologies used throughout this series, see our companion guides:

• Landscape Generation with Dynamic LOD and Streaming for Browser Open Worlds covers heightmaps, SDFs, marching cubes, Transvoxel, geometry clipmaps, geomorphing, streaming architecture, terrain materials, and vegetation rendering.
• Browser 3D Open World Tech for Multiplayer Creator Worlds covers rendering stacks, WebGPU, physics, networking, multiplayer architecture, and lessons from Skyrim, The Witcher 3, Breath of the Wild, and GTA V.

Thank you for following this twelve-part ride.

Part 1: We started by trying to break it
Part 2: Worker physics and the input lag fear
Part 3: The unflashy spikes that saved us
Part 4: Streaming before fancy terrain
Part 5: Budgeting the pretty stuff
Part 6: Clipmaps changed the plot
Part 7: Marching cubes and the first real caves
Part 8: Integration without losing our baseline
Part 9: Transvoxel started with a scaffold
Part 10: Seam chaos and the corner boss fight
Part 11: Policy mode, not hardcoded mode

Part 12 of 12.
Previous: Part 11 - Policy mode, not hardcoded mode
Series guide: /blog/2026-02-25-open-world-browser-series-guide

By Oleg Sidorkin, CTO and Co-Founder of Cinevva

This page is the navigation hub for the full series.

If you arrived from one random part, start here.

March 2026 update: we added an external implementation cross-check from the Vuntra City devlogs in Part 12 and expanded the companion browser open world tech guide with the same findings.

What "spike" means in this series

A spike is a short, focused experiment.

Each spike tests one risky question. We keep scope tight, measure what matters, and decide what to do next. Think of it as a learning instrument, not a polished feature.

In this project, spikes are mostly standalone pages under /spikes/* that you can run live.

Read the series in order

1. Part 1: We started by trying to break it
2. Part 2: Worker physics and the input lag fear
3. Part 3: The unflashy spikes that saved us
4. Part 4: Streaming before fancy terrain
5. Part 5: Budgeting the pretty stuff
6. Part 6: Clipmaps changed the plot
7. Part 7: Marching cubes and the first real caves
8. Part 8: Integration without losing our baseline
9. Part 9: Transvoxel started with a scaffold
10. Part 10: Seam chaos and the corner boss fight
11. Part 11: Policy mode, not hardcoded mode
12. Part 12: Rings, sky fog, and what we would do again

Live spike map

Start with these if you want to click through the technical timeline directly.

Spike 1 terrain and instancing · source
Spike 2 worker physics · source
Spike 3 Durable Object broadcast load test ran as a service script, not a standalone page
Spike 4 mobile quality constraints, tested via Spike 1 query param
Spike 5 LLM behavior reliability, ran as a script, not a standalone page
Spike 6 chunk load and swap · source
Spike 7 vegetation from density maps · source
Spike 8 terrain material cost · source
Spike 9 cascaded shadows budget · source
Spike 10 clipmaps and geomorphing · source
Spike 11 heightmap chunk streaming · source
Spike 12 WebGPU marching cubes · source
Spike 13 WebGPU integration baseline · source
Spike 14 incremental hardening · source
Spike 15 seam scaffold · source
Spike 16 first Transvoxel face · source
Spike 17 dual MC LOD · source
Spike 18 heightmap seam · source
Spike 19 mixed-resolution corner · source
Spike 20 GPU corner seam · source
Spike 21 GPU MC corner seam · source
Spike 22 MC to HM fallback · source
Spike 23 policy-based chunk modes · source
Spike 24 clipmap rings and sky fog · source

By Mariana Muntean, CEO of Cinevva

We made a game where your snake is the paddle and the bricks fight back. It shipped on web, mobile, and PC. It took two of us about three days. On and off, not crunching. And it's genuinely fun to play.

That last part is the thing worth paying attention to.

The mashup nobody asked for

Snake is about growth and spatial awareness. Arkanoid is about reflexes and angle prediction. They come from completely different design philosophies, and mashing them together sounds like the kind of pitch that gets politely declined.

But A Breaker Belt makes it work. You're a cosmic serpent, a living arc of neon current stitched from drift-metal vertebrae and comet silk, threading through an asteroid field of breakable blocks. Your head is the paddle. Your growing tail is both your greatest weapon and your most constant threat. The orbs ricochet off your body to shatter bricks, but one wrong turn into your own tail and you're done.

It's the kind of weird cross-genre experiment that usually dies before anyone gets to play it, because the development cost of finding out whether a weird idea works has traditionally been measured in months. Here it was measured in afternoons.

What actually shipped

The scope is what makes this interesting. This isn't a game jam prototype with placeholder rectangles and no sound.

The game runs 50 waves deep. That's not 50 variations of the same brick wall. The formations evolve from gentle onboarding arcs into fortress rings that demand angled shots through side gaps, then into layered diagonal mazes with one-tile-wide openings that require precision steering. Explosive bricks blow their neighbors apart. Phantom bricks flicker in and out of existence. Regenerating bricks heal back after you break them, forcing you to prioritize targets instead of sweeping left to right. Portal bricks teleport your orbs across the arena. Gravity wells bend your shots into slow, curving hymns. Laser emitters sketch red lines across the void. Mimic bricks look harmless until they decide they're not. By wave 15, you're navigating something that feels less like a puzzle and more like a living system that's learning your habits.

The music isn't a loop. It's a reactive soundtrack that builds with your gameplay. The underlying system runs a bass line, lead synth, pad, kick, snare, and hi-hat in E minor at 140 BPM, and as the action intensifies, additional percussion and synth layers fade in. When things calm down between waves, ambient pads take over. The music breathes with you. A dedicated composer would spend weeks tuning that kind of responsiveness. Here it was part of the creative flow.

The sound effects aren't samples pulled from a free pack. Every brick shatter, power-up pickup, orb bounce, and collision is synthesized in real time. Different pitch for head contacts versus tail contacts. Warm reverb for the spacey feel. Lowpass filtering to keep things satisfying without getting harsh. When you chain a combo, the audio tells you before the screen does.

And then there's the storytelling. Each wave opens with a narrative beat delivered by AI-generated voice. The writing has genuine personality. Wave one: "They call it the Breaker Belt: a ribbon of engineered debris that circles the old star like a warning." By wave 38: "The Belt stops feeling like a wall and starts feeling like a mind. It tests not your reflexes, but your habits. You break the habit. The Belt notices." It's 50 chapters of cosmic mythology that makes you care about why you're a snake breaking bricks in space.

The backgrounds evolve too. Early waves are calm indigo starfields with soft meteor rain. By mid-game, aurora bands and nebula clouds appear. Late game goes full Ion Storm with sharp cyan streaks against near-black space. Wave 15 and beyond, you're in Event Horizon territory: deep void punctuated by slow-moving nebula filaments and faint black hole lensing. The game communicates progression through atmosphere as much as difficulty.

All of this runs on keyboard, gamepad, or touchscreen. Published to web, mobile, and PC from one codebase. No separate builds. No porting.

The team that wasn't needed

Here's the part that should make any game developer pause.

A game with this depth of content would typically need a game designer, a couple of programmers, a 2D artist, a sound designer, a music composer, a level designer, a narrative writer, and QA. That's eight or nine people. At a modest indie pace, you're looking at three to six months of coordinated work. Standups, Jira tickets, asset pipelines, platform-specific debugging.

Two of us made this in a long weekend on the Cinevva Engine.

The talent required didn't change. The ratio between creative intent and implementation overhead did. The time was spent deciding what the game should feel like, not fighting tools to make it happen.

Why this matters if you make things

The interesting question isn't whether AI tools can help make games faster. That's been answered. The interesting question is what happens to ideas that used to be too risky to try.

"Snake but you're the paddle in an Arkanoid arena" is not something a producer greenlights. A few indie devs have tried variations of this mashup on itch.io (BreakSnake, SnakeOut, Snake Break), but they're all small game jam experiments. The genre fusion has never been given a real production pass with reactive music, AI narration, dozens of brick types, and 50 waves of escalating level design. In traditional development, that kind of polish on a risky concept gets killed in a meeting before anyone writes a line of code.

When trying something weird costs an afternoon instead of a quarter's budget, the strange ideas get built. Some of them turn out to be genuinely good. A Breaker Belt is one of those.

Play it. Or make your own.

A Breaker Belt is playable right now on web, mobile, and PC. If it makes you want to build something, the Cinevva Engine is free to use. Describe what you want, iterate on what comes back, ship when it's ready. The music, sound effects, art, and 3D models are all built in.

Your weird game idea might be three days away from existing.

Play A Breaker Belt | Build your own game | Browse community games

Related:

• Vibe coding is the new game jam — how AI tools collapse the gap between idea and prototype
• Game Jams & Hackathons — the jam format that makes weird mashups possible
• Web Game Engines Comparison — engines for shipping to web, mobile, and PC

By Mariana Muntean, CEO of Cinevva

We have a music generator on the Cinevva platform so game creators can make game soundtracks and SFX without licensing headaches. What happened next, we did not plan for. People started making music because they wanted to make music. Not for games or projects. Just music production.

Bella Bay made over 100 tracks in two weeks

I'm not exaggerating. One of our creators, Bella Bay, generated over 100 tracks in about two weeks. When you listen through them on Cinevva Radio, you can hear the progression. The early tracks are experiments. The later ones sound like someone who found their style. That kind of creative acceleration doesn't happen when you're fighting your tools. It happens when the tools get out of the way.

Bella Bay isn't an outlier in spirit, just in volume. All across the platform, people started treating the music generator not as a utility for game assets but as a creative instrument. Producers experimenting with genres they'd never tried. People iterating on a sound until it clicked. Bedroom artists who'd never had access to a full production toolkit suddenly had one and went all in.

So we built a radio

It had to be done.

We had all these tracks sitting in people's accounts with no collective space. No way to discover what others were making. No way to stumble onto a track that changes your afternoon.

Cinevva Radio is now live. Eight stations. 362 community-created tracks and growing every day. Every single song was made by someone on the platform. You open it and something is playing. You don't have to search. You don't have to decide. You just listen.

Soundstage is our biggest station. 111 tracks of cinematic and epic scores. I honestly didn't see that coming. People love making dramatic, film-style music.

Discovery caught everything that doesn't fit neatly into a genre. 78 tracks. Latin beats next to Afrobeats next to country next to something that defies description. This station is wild.

Main Stage is pop and vocal tracks. 56 tracks with full lyrics and vocals. People are writing love songs, breakup songs, worship music, ballads. Some of it is genuinely catchy.

Voltage is rock and metal. 53 tracks. Guitar riffs, punk energy, grunge, hard rock. I keep this one on while working.

Lo-Fi Cafe is exactly what it sounds like. 25 chill ambient tracks for studying, working, or just vibing.

Electric Dreams has 22 electronic and synth tracks. Synthwave, techno, EDM, drum and bass.

Ivory Tower is classical and orchestral. 10 tracks. Piano pieces, string arrangements, symphonic stuff. Small but growing.

The Cipher is hip-hop and rap. 7 tracks so far. Newest station, still finding its voice.

What you see when you listen

When you open Cinevva Radio, it's a live stream. Think of it less like a playlist app and more like an actual radio station. Tracks play continuously. You can react in real time, chat with other listeners, and see who made each track.

Creators get credited on screen while their track plays. Their name, their prompt, the genre. If you hear something you like, you know who made it. It's community-created content with a discovery layer on top. No algorithms deciding what's worthy. No gatekeepers. You made a track, it goes on the station that matches its genre, and people hear it.

This is bigger than a feature

For decades, music production required expensive software, years of training, and access to equipment most people couldn't afford. What we're seeing is a different kind of creator. People who think in descriptions and feelings rather than notes and time signatures.

"Rainy night jazz with a broken piano" is a creative direction. The person who wrote that prompt made an artistic choice. They directed the mood, the instrumentation, the emotional register. They just don't happen to play piano.

I don't think that makes their output less valid. I think it means the definition of "musician" is stretching. And watching someone like Bella Bay go from zero to a hundred tracks in two weeks tells me the creative drive was always there. The tools just weren't.

What's next

We're working on community profiles where producers can showcase their catalog and build a following. The charts page already shows community creations across all tools, and we want to bring that same energy specifically to music.

But right now, the radio is live. Go listen. And if you want to make your own tracks, the music generator is free to use. Your track might end up on the air.

Listen to Cinevva Radio | Make music | Browse community creations

Related:

• Frontier Open-Source Gen AI Models — the AI music and audio models behind the scenes
• Web Audio API for games — building interactive audio in the browser
• Vibe coding is the new game jam — how describing intent becomes the primary creative input

By Mariana Muntean, CEO of Cinevva

AI has essentially commoditized raw logic and computational ability. The skills we used to worship, the mental math, the pattern recognition, the ability to grind through complex algorithms, AI does all of that now. Faster. Better. Without getting tired. Do we still need to know it? Absolutely, but perceptions change. Now everyone needs to adjust to the new era - an era of intuitive intreaction and outcomes.

According to Jensen Huang, NVIDIA's CEO, what matters now is the ability to sense a "vibe" and see around corners before the data appears. The intersection of technical literacy and deep empathy. The intuitive understanding that silicon can't touch.

I've never heard anyone with his credibility say something that validated my entire life trajectory quite so directly.

The SAT and the system that wasn't built for me

A few years back I took the SAT and failed. I'm not proud of it, but I also didn't try again. Something felt fundamentally wrong about the whole thing, and I couldn't shake that feeling no matter how much people told me to just study harder and take it again.

Looking back, I think I was right.

The SAT is designed for the American education system. That sounds obvious, but the implications run deep. American high schools teach to specific patterns, question types, and ways of framing problems. Students grow up marinating in that style of standardized testing from elementary school onward. By the time they hit the SAT, they've internalized the rhythm.

International students don't have that advantage. We come from systems with different educational philosophies. European schools often emphasize depth over breadth, essay-based examination over multiple choice, oral defense over bubble sheets. Asian systems have their own standardized tests, but they measure different things in different ways. South American, African, Middle Eastern educational traditions each carry their own logic.

When you drop an international student into the SAT, you're not just testing their knowledge. You're testing how quickly they can adapt to a foreign testing culture while simultaneously demonstrating mastery of content. You're testing cultural fluency as much as academic ability.

I was expected to prep for this over a summer and ace it. Learn an entire testing culture, unlearn my own educational instincts, and perform at a level that would impress American admissions officers. All in a few months.

I chose not to.

When you're young, you're smart in different ways. Intuitive ways. I was clearing a path for myself, even if I couldn't articulate exactly why at the time. Something in me knew this system wasn't mine.

Following the creative thread instead

I studied game development and design because I loved the idea of using creativity and visual effects to build virtual worlds people could play and interact with. I loved the intersection of art and technology, storytelling and interactivity.

What I found shocked me.

Games require serious technical depth. Physics simulations, collision detection, vector math, lighting calculations, optimization. I knew that going in. The math and engineering aren't obstacles to game development. They're part of what makes games work.

The problem was the gap between creative vision and implementation. The engines and tools dominating the industry were designed by engineers for engineers. Everything ran on "ifs" and "thens" and node-based blueprints. You wanted a vortex effect? Learn shader programming. Specific lighting mood? Dig into material graphs. Character movement that feels right? Debug character controller or physics parameters for hours.

If you're a visual person, if you think in vivid colors and moving images, if ideas come to you as fully formed scenes with sound and texture and emotional weight, you had to translate all of that into technical language before you could build any of it. You see a world in your mind, complete with lighting and atmosphere and the way characters move through space. Then you sit down at your computer and spend the next six hours debugging why your character falls through the floor.

The technical foundation matters. But the tools forced creators to live in implementation details instead of abstracting that complexity away. Game creation should feel like telling a story or directing a movie where people get to participate. That's the magic of the medium. Instead it felt like taking an engineering exam before you could even start.

Movie directors don't spend years learning physics engines before they can express their vision. They get a budget and a team that handles the technical execution. But in indie game development, you rarely have a budget. What you have is time and access to tools. And if you're a technical person, you can build a killer game. But only if.

This is how we got titles like Limbo, made by a small team with a singular artistic vision and the technical chops to execute it. Or Undertale, created largely by one person who happened to have the right combination of creative instinct and programming ability. Or Stardew Valley, where Eric Barone spent years teaching himself everything from pixel art to music composition to C# programming.

These games succeeded against enormous odds. But for every Limbo there are millions of creative visions that died because the tools demanded technical fluency their creators couldn't provide. Less than 3% of indie game developers ever achieve meaningful success. How many brilliant games never got made because their creators hit a wall of "ifs" and "thens" and gave up?

The barrier to entry wasn't creativity. It was technical gatekeeping built into the tools themselves.

Building what should have existed

So 5 years ago I started building something different.

The pitch was simple: game development should be accessible to anyone with a creative vision. You shouldn't need a computer science degree to express yourself through interactive media. The tools should adapt to how creative people actually think, not the other way around.

VCs from Sequoia, Pear, Draper, and dozens of other firms told me it wouldn't work. It's B2C. The market isn't there. Indies don't pay for anything. You can't simplify game development without sacrificing capability. Gamers want complex games, and complex games require complex tools. Millions of excuses dressed up as market analysis.

People told me I was crazy. Maybe I was. But I kept coming back to the same question: why should multimillion dollar budgets be a prerequisite for creative expression? Movie directors and celebrity game producers have teams and resources. Everyone else gets a code editor and a prayer. I wanted to build the thing that closes that gap. You describe what you want, and it happens in front of your eyes. Every part of me knew this was right. I could feel it in every cell of my body.

Today thousands of people use Cinevva daily for 3D game assets, games, music, levels and experiences. Millions of views on projects created so far. Growing every single day. A two-minute pitch to Sand Hill Road isn't exactly the format for "I failed the SAT but trust my intuition."

What intuition actually means

Huang wasn't just making a philosophical point. He was describing a real shift in what constitutes valuable intelligence.

For decades, we optimized for the wrong things. We built educational systems that rewarded memorization and calculation. We designed standardized tests that measured pattern-matching against previously seen problems. We hired people based on credentials that proved they could survive four years of academic gatekeeping. AI just made all of that less special.

What AI can't do, at least not yet, is sense what's missing. Feel when something is off. Intuit what people need before they can articulate it themselves. Read a room. Understand context that isn't captured in any dataset.

I poured my time, international life experience, money, and intuitive knowledge into building Cinevva. That's a mix hard to obtain in college. Hard to test for on the SAT. Hard to capture in any credential system designed before AI made raw cognitive horsepower abundant.

Sixteen or twenty years ago, computer scientists decided what tools should look like and how they should work. They built for themselves, for people who thought like them. The rest of us were expected to adapt. That era is ending. The people who will shape what comes next are the ones who understand what humans actually want. Who can feel when something is wrong and when something is right. Who build for people instead of for technical elegance.

I trusted something in myself that the system told me was worthless. And I was right.

Related:

• The job market is transforming — from credentials to skills
• Online Game Development Courses — skills-first paths that bypass traditional gatekeeping
• Everyone wants to be the AI game engine now — the industry shift toward tools that adapt to how people think

By Oleg Sidorkin, CTO of Cinevva

AI in games turned into a genuine minefield somewhere around mid-2024. Jobs disappearing. People convinced they're next. Copyright questions that not even the lawyers can untangle. Endless aesthetic debates that loop back on themselves. Steam drowning in stuff nobody asked for. And underneath everything, this nagging worry every creator has now: "am I actually making something here, or just... typing prompts?"

We run a platform. You learn one thing fast doing that.

Nobody likes feeling tricked.

These numbers surprised us

We figured AI adoption would grow. Not like this though. Here's where things landed by late 2025:

Sources: Tom's Hardware / Totally Human Media analysis, GDC 2025 Developer Survey, Unity 2025 Gaming Report

What actually happened to make players this skeptical

This didn't come from nowhere. Real things went wrong. And people remember.

Voice actors found out they'd been cloned — on launch day

Tomb Raider 4-6 Remastered shipped with AI-generated versions of the original voice performances. The actors learned about it the same moment everyone else did. Launch day. The publisher eventually patched the voices out after legal pressure built up. That eleven-month SAG-AFTRA strike? This exact scenario was driving it.

"AI slop" became a thing people say now

Call of Duty: Black Ops 6 quietly added AI disclosure to its Steam page. After it was already out. Players had noticed the weirdness — visual glitches scattered everywhere. One loading screen character had six fingers. "AI slop" turned into shorthand for anything that looks... off. Hollow. Like nobody cared enough to check.

An award nomination vanished

Clair Obscur: Expedition 33 got its Game of the Year nomination pulled at the Indie Game Awards. The shipped game didn't use AI though. The problem was AI placeholders during development — internal stuff that never made it to players. Final assets were entirely human-made. Didn't matter. Weeks of arguing about where exactly the line should be.

Teams that never touched AI had to prove it

Chessplus and Peak both got hit with AI accusations. Neither used any. Both were award nominees. Both development teams ended up digging through old screenshots and layer files just to demonstrate their work was handmade. The Peak team put it best: "We might be slop, but we're human-made, locally-sourced artisanal slop."

Studios went in completely opposite directions

SNK — Discord moderators walked out after AI-looking visuals showed up in a Fatal Fury: City of the Wolves trailer. Games Workshop — banned AI entirely across all Warhammer properties. Larian Studios — said they used AI only for very early concept sketches on Baldur's Gate 3, nothing in the final game. Tim Sweeney — declared Steam's AI labels worthless and said to scrap them. Valve — shot back that devs complaining about AI labels usually worry their work looks "low effort."

Finding games turned into a trust problem

Stuff gets made faster than anyone can properly evaluate it now. The questions changed:

What am I even looking at here? Who made this? Am I going to regret the time I spend on it? Does any of this match what the trailer promised?

There's probably no grand resolution coming. No definitive ruling on AI versus human-made.

What's more likely: filters, real transparency, and incentive structures that push toward honesty.

Small studios stuck in the middle of all this

Indie developers landed in a strange spot.

The upside is genuinely hard to dismiss: You iterate faster. Costs drop when four people are making everything. Solo devs can actually finish things now. Localization stops eating your entire budget.

The downside is just as real: Output that feels generic. Training data and IP concerns that lawyers won't touch yet. Shipping systems you don't fully understand — some people call it comprehension debt. Getting grouped in with the flood of low-effort releases. Nearly half of surveyed developers think AI makes games worse overall.

Unity's 2025 report says 79% of developers feel positive about AI tools. Sounds pretty definitive. The reality is messier. Teams doing this well tend to use AI for the boring parts — grunt work, rough passes, QA tedium. Creative direction? That stays human.

Where Cinevva lands: neutral on AI, strict on honesty

We don't turn games away for using AI. We don't give them special treatment either.

The rule is simple: if AI was involved, say so. Players decide what they care about. Filters actually work then.

• AI-generated content policy

Filters work better than arguments

The AI debate in games isn't reaching consensus anytime soon. Probably never will. But individual preferences? Those are clear enough.

Some players specifically want human-directed art. Writing that came from a person. Visible craft.

Others genuinely don't care. Fun is fun.

Filters let both groups find what they're looking for. Nobody has to win.

Payment models matter more than anyone's opinion

When revenue ties to playtime instead of unit sales, you make money by:

Getting players hooked fast. Keeping their attention. Delivering what your marketing said you would.

Quality becomes the obvious path. How you made it matters less.

Overpromise in your trailer? Players leave immediately. Retention tanks. Show them exactly what they're getting? They stick around. Playtime builds. Revenue comes. The economics sort themselves out.

What 2026 probably brings

More rules — EU AI Act keeps expanding. US protections for voice and likeness growing, especially after SAG-AFTRA.

Specialized tools — AI built specifically for small teams. Designed to keep humans steering.

Smarter labels — "Made with AI" is too crude. Expect distinctions between AI-assisted workflows and AI-generated final assets.

Audiences splitting — Some players will deliberately seek out traditionally-made games. Others won't give it a thought. Both groups are large enough to build for.

Platform competition — How storefronts handle transparency and discovery becomes a real differentiator.

What actually moves things forward

Arguing won't settle the AI question. What does:

1. Players picking based on what genuinely matters to them
2. Creators being honest about how they work
3. Platforms building tools that help both groups find each other

That's the post-AI economy. Not warring camps. Trust holding the whole thing together.

Related:

• AI-generated content policy
• For game creators
• FAQ
• Frontier Open-Source Gen AI Models — the specific models and how they work
• Open source has an AI pollution problem — what happens when AI output floods open-source projects

By Oleg Sidorkin, CTO of Cinevva

I watched my cousin graduate with honors in 2023. Computer science degree from a good state school. Solid GPA. He spent fourteen months applying to jobs before landing one. Meanwhile, a friend who dropped out sophomore year to build indie games had three offers within a month of deciding to look.

That's not an anomaly anymore. That's the pattern.

The numbers finally caught up to what we've been feeling

By 2025, 90% of HR leaders reported hiring outside traditional four-year degrees (Fortune). A quarter of U.S. companies dropped bachelor's requirements entirely (HR Dive). And here's the part that stings if you just finished paying off loans: 94% of employers say skills-based hires outperform those hired on credentials (Forbes).

Verizon now says 99% of their roles don't require a degree. Sergey Brin admitted Google hires "tons" of people without bachelor's degrees. IBM made half their U.S. openings degree-optional through their "New Collar" program.

This isn't companies being charitable. They figured out that degrees weren't predicting who'd actually be good at the job.

Why the old system broke

The honest answer? Degrees became a lazy filter.

When you're hiring and you've got 400 applications, requiring a bachelor's degree cuts the pile in half. It doesn't tell you who can actually do the work. It tells you who had the money, the time, and the family stability to sit in classrooms for four years. That correlation with ability was always weaker than we pretended.

And now three things happened at once:

The skills moved too fast. Game engines, AI tools, web frameworks. By the time a curriculum committee approves a course on something, that thing is already outdated. A four-year degree teaches you theory from four years ago. In tech, that's ancient history.

Portfolios became undeniable. Why guess whether someone can code when you can look at their GitHub? Why wonder if they can ship a game when their itch.io page has five finished projects with player reviews?

Companies got desperate. The talent shortage is real. Excluding everyone without a degree means excluding people who might be exactly what you need. Some hiring managers figured this out the hard way, after watching self-taught developers run circles around their credentialed hires.

The game industry saw this coming

I think games have been ahead of the curve here, and it's worth understanding why.

Studios never really cared where you went to school. They cared what you shipped. A polished 48-hour jam game tells a hiring manager more than a four-year game design degree ever could. It proves you can finish things under pressure. It proves you made hard decisions about scope. It proves the game is playable, not just theoretical.

If you're trying to break into games in 2026, here's what actually matters (Dice, CombineGR): two or three polished, playable demos. Case studies explaining what you did and why. Evidence that you finish things. Fluency with at least one major engine, shown through real projects.

Hiring managers aren't looking for potential. They're looking for proof.

The uncomfortable part nobody talks about

Here's something that frustrated me when I dug into the research.

A Harvard/Burning Glass study found that companies dropping degree requirements often didn't actually hire more non-degreed candidates. The increase was only about 3.5 percentage points (Forbes). The policy changed. The hiring practices lagged.

That means if you're going the non-traditional route, you still have to work harder. The door is more open than it used to be, but you're not walking through on equal footing yet. Your portfolio needs to be undeniable. Your projects need to speak louder than someone else's credential.

It's not fair. But knowing it helps you prepare.

What I'd tell someone starting out right now

If you're in school, don't stop. But understand that the degree alone isn't enough anymore. Build things on the side. Do game jams. Get a Google Career Certificate or Unity certification. Treat the degree as one credential among several, not the credential.

If you're not pursuing a degree, you have a different path but not necessarily a harder one. Build aggressively. Ship things. Document everything. Your GitHub, your itch.io page, your personal site. That's your credential now.

Either way, practice explaining your work. Not just what you built, but why you made the choices you made. What you'd do differently. What you learned. Interviewers remember people who can articulate their thinking.

This is bigger than hiring

What's happening here isn't just a shift in how companies fill roles. It's a shift in what we collectively value.

For decades, credentials served as a filter. Expensive, time-consuming, but legible. If someone had a degree, you could assume certain things. It was a signal, not a direct measure, but it was good enough.

That signal is breaking now. Technology makes it possible to see what someone can actually do. Remote work proved that outputs matter more than where you sat. AI is making theoretical knowledge less valuable than practical application.

I find this genuinely hopeful, even if the transition is messy. The question used to be "where did you study?" Now it's "what can you build?"

That's a better question.

Sources

• Fortune: 90% of HR leaders hiring outside traditional degrees
• Forbes: 90% of companies make better hires based on skills
• Forbes: Companies dropping degree requirements but hiring few non-degreed workers
• HR Dive: Employers eliminating degree requirements
• Computerworld: Tech firms move away from college requirement
• Dice: Aspiring video game designers in 2025
• CombineGR: 2025 Global Gaming Employment Outlook

Related:

• How to succeed in game jams
• Online Game Development Courses — skills-first learning paths for every budget
• Agentic AI code tools — the tools reshaping what skills matter
• The intuitive mind — why intuition matters more than credentials