Eine 3D-Stadt aus Würfeln, die im Browser läuft

Das Erste was du siehst, wenn du die Live-Stadt öffnest, ist ein kleines 3D-Raster mit bunten Würfeln, die darauf herumlaufen. Wir haben absichtlich nicht mit detaillierten Charaktermodellen oder fotorealistischen Gebäuden angefangen. Wir haben uns für Würfel entschieden, weil wir damit das Fundament in Tagen statt Wochen ausliefern konnten, und weil Würfel, die sich von selbst bewegen, bereits lebendig wirken.

Die 3D-Szene läuft komplett in deinem Browser. Es gibt keinen Game-Server, der rendert und das Bild nach unten streamt. Dein Laptop macht die Arbeit, und was über die Leitung ankommt, sind nur die Daten, die sagen, wo gerade wer ist und was er gerade tut.

Die Bausteine der Szene

Ganz unten im Stack liegt Three.js, die Standardbibliothek für 3D im Browser. Darüber nutzen wir React Three Fiber, womit wir die Szene als React-Komponenten schreiben können statt als imperativen Scene-Graph-Code. Also ein Gebäude ist eine React-Komponente, ein Bürger ist eine React-Komponente, die Kamera ist eine React-Komponente. Das klingt simpel und ist es auch, aber es ändert alles daran wie schnell wir iterieren können.

Über React Three Fiber liegt Drei, eine kleine Bibliothek mit Helfern wie Kamera-Controls, Instanced Meshes, HTML-Overlays. Drei ist das, was die Kamera weich fliegen lässt, wenn du mit der Maus ziehst, und was das Lade-Overlay sanft einblendet, während die Assets reinkommen.

Für Bürger und Gebäude nutzen wir ein Three.js-Feature namens Instanced Meshes. Statt für jeden Bürger ein eigenes Objekt zu erzeugen, erstellen wir einen Würfel als Vorlage und sagen der GPU, sie soll ihn neunmal in neun verschiedenen Farben an neun verschiedenen Positionen zeichnen. Der gleiche Trick funktioniert für Gebäude. Bis zu vierundsechzig Gebäude zeichnen sich quasi in einem einzigen Draw-Call. Deshalb läuft die Szene mit sechzig Bildern pro Sekunde auf einem fünf Jahre alten Laptop.

Warum Würfel und nicht Sprites oder echte Modelle

Wir hatten drei Optionen. Pixel-Sprites wie beim klassischen Siedler oder Stardew Valley. Low-Poly 3D-Meshes von Kenney oder ähnlichen Bibliotheken. Oder Würfel und Primitives. Jede Variante hat eine andere Kostenkurve.

Sprites hätten geheißen, dass wir ein Tile-System bauen, die Depth-Sortierung handhaben und für jeden Gebäudetyp Varianten zeichnen müssen. Echte Low-Poly-Meshes hätten geheißen, dass wir ein paar hundert Megabyte GLTF-Assets laden und für jedes davon Shading und Beleuchtung lösen müssen. Würfel sind praktisch umsonst. Das Raster ist eine Fläche, die Gebäude sind bunte Boxen, die Bürger sind bunte Boxen mit einer kleinen Idle-Bob-Animation. Wir haben das ganze 3D-Fundament an einem Wochenende ausgeliefert.

Kenney-Meshes stehen für später auf der Liste. Sobald wir sicher sind, dass die Simulation stabil genug ist und nicht mitten in der Saison crasht, werden die Würfel gegen richtige Gebäude mit Fenstern und Dächern und kleinen Schornsteinen getauscht.

Wie die Daten dahin kommen

Die Simulation läuft auf unserem Server in Deutschland. Alle zwei Stunden vergeht ein weiterer Monat Spielzeit, und am Ende jedes Monats landet der neue Weltzustand in unserer Postgres-Datenbank. Ein kleines Stück Postgres-Maschinerie namens LISTEN und NOTIFY pingt unseren Webserver in dem Moment an, in dem sich etwas ändert. Der Webserver hält eine lang laufende Verbindung zu deinem Browser offen und schiebt die neuen Daten innerhalb einer Sekunde nach unten.

Dein Browser nimmt diese Daten dann und aktualisiert die Positionen der Würfel. Kein Reload, kein Polling, kein Refresh-Klicken. Die Szene reagiert live.

Die Website rund um die Szene

Rund um die 3D-Szene nutzen wir Next.js 16 mit React 19. Next.js ist das Framework, das uns Routing, Server-Side-Rendering und die API-Endpunkte gibt, die mit Postgres reden. React kümmert sich um die UI-Komponenten wie das Bürger-Profil-Panel und den Live-News-Feed. Tailwind übernimmt das ganze Styling, ohne dass wir eine einzige CSS-Datei von Hand schreiben.

Für Formular-Validierung und Daten-Parsing nutzen wir Zod, das dafür sorgt, dass alles was von der Simulation reinkommt der Form entspricht, die wir erwarten. Wenn ein verbuggter Run eine kaputte Aktion runterschickt, fängt Zod sie ab, bevor sie die Szene zerlegt.

Was noch fehlt

Eine Menge. Die Würfel laufen noch nicht, sie wippen nur auf der Stelle zwischen den Updates. Die Gebäude haben keine Animationen wie Rauch aus Schornsteinen oder Fenster, die nachts angehen. Es gibt keinen Tag-Nacht-Zyklus. Es gibt keine Partikel-Effekte, wenn etwas Dramatisches passiert. Sound fehlt komplett.

Das alles steht auf der Roadmap. Wir haben uns zuerst für das einfachste mögliche Fundament entschieden, weil wir wissen mussten, ob die Simulation selbst genug Drama produziert, dass es sich überhaupt lohnt zuzuschauen. Die Antwort hat sich als ja herausgestellt, also dürfen wir jetzt den Feinschliff dazupacken, der das Ganze wie eine echte kleine Stadt aussehen lässt statt wie ein buntes Raster.