2026-05-26 · StudioMeyer
A 3D town built from cubes that runs in your browser
How a small Mediterranean town is rendered in the browser, where the camera flies, and why we picked cubes before sprites.
The first thing you see when you open the live town is a small 3D grid with coloured cubes walking around on it. It is on purpose that we did not start with detailed character models or photorealistic buildings. We picked cubes because they let us ship the foundation in days instead of weeks, and because cubes that move on their own already feel alive.
The 3D scene runs entirely in your browser. There is no game server doing the rendering and streaming it down. Your laptop is doing the work, and what arrives over the wire is just the data that says where everyone is and what they are doing right now.
The pieces that make the scene
At the bottom of the stack is Three.js, the standard library for 3D in the browser. On top of Three.js we use React Three Fiber, which lets us write the scene as React components instead of imperative scene-graph code. So a building is a React component, a citizen is a React component, the camera is a React component. That sounds simple and it is, but it changes everything about how fast we can iterate.
On top of React Three Fiber we use Drei, which is a small library of helpers like camera controls, instanced meshes, HTML overlays. Drei is what makes the camera fly smoothly when you drag with your mouse and what fades in the loading overlay when assets are streaming in.
For citizens and buildings we use a Three.js feature called instanced meshes. Instead of creating one separate object per citizen, we create one cube template and tell the GPU to draw it nine times in nine different colours at nine different positions. The same trick works for buildings. Up to sixty-four buildings draw in essentially one draw call. That is why the scene runs at sixty frames per second on a five-year-old laptop.
Why cubes and not sprites or real models
We had three options. Pixel sprites like classic Settlers and Stardew Valley. Low-poly 3D meshes from Kenney or similar libraries. Or cubes and primitives. Each has a different cost curve.
Sprites would have meant building a tile system, handling depth-sorting, drawing variations per building type. Real low-poly meshes would have meant downloading a few hundred megabytes of GLTF assets and dealing with shading and lighting on each one. Cubes are basically free. The grid is a plane, the buildings are coloured boxes, the citizens are coloured boxes with a small idle-bob animation. We shipped the whole 3D foundation in a weekend.
Kenney meshes are queued for later. Once we are sure the simulation is stable enough to not crash mid-season, the cubes will be swapped out for proper buildings with windows and roofs and small chimneys.
How the data gets there
The simulation runs on our server in Germany. Every two hours another month of game time happens, and at the end of each month the new world state lands in our Postgres database. A small piece of Postgres machinery called LISTEN and NOTIFY pings our web server the moment something changes. The web server keeps a long-running connection to your browser open, and pushes the new data down within a second.
Your browser then takes that data and updates the positions of the cubes. No reloads, no polling, no clicking refresh. The scene reacts live.
The website around the scene
Around the 3D scene we use Next.js 16 with React 19. Next.js is the framework that gives us routing, server-side rendering, and the API endpoints that talk to Postgres. React handles the UI components like the citizen profile panel and the live news feed. Tailwind handles all the styling without us writing a single CSS file by hand.
For form validation and data parsing we use Zod, which makes sure that anything coming in from the simulation matches the shape we expect. If a buggy run sends down a malformed action, Zod catches it before it crashes the scene.
What is still missing
A lot. The cubes do not walk yet, they just idle in place between updates. The buildings do not have animations like smoke from chimneys or windows lighting up at night. There is no day-night cycle. There are no particle effects when something dramatic happens. Sound is completely absent.
All of this is on the roadmap. We picked the simplest possible foundation first because we needed to know whether the simulation itself produced enough drama to be worth watching. The answer turned out to be yes, so now we get to add the polish that makes it look like a real little town instead of a coloured grid.