FableCity: eine Stadtsimulation, die in Millionen denkt

Das Problem

City-Builder stehen vor einem brutalen Trade-off: jeden Bürger einzeln simulieren und bei 100k Einwohnern ersticken, oder alles faken und das emergente Verhalten verlieren, das das Genre ausmacht. Der Big-Studio-Benchmark kämpft schon jenseits weniger hunderttausend Agenten. Die Designfrage: Wie weit skaliert eine Stadtsimulation, wenn man Per-Agent-Simulation komplett verweigert?

Was wir gebaut haben

Ein City-Building-Spiel in Godot 4, gebaut um einen aggregierten Simulationskern. Bevölkerung, Beschäftigung, Verkehrslast, Versorgung, Bodenwert und Nachfrage werden als interagierende statistische Kohorten modelliert, nicht als einzelne Agenten. Drei Millionen Bürger sind nicht drei Millionen Pathfinding-Jobs, sondern ein Satz gekoppelter Gleichungen über Bezirks-Aggregate, die trotzdem glaubwürdiges Makroverhalten erzeugen: Pendlerdruck, Gentrifizierungswellen, kaskadierende Blackouts.

Die Engineering-Disziplin, auf der das Projekt läuft:

• Ein Performance-Gate statt Performance-Hoffnung. Die automatisierte Testsuite enthält harte Perf-Checks; eine Änderung, die das Frame-Budget reißt, lässt den Build durchfallen. Optimierung ist kontinuierlich, keine Panik kurz vor dem Release.
• Jedes Feature beim Start sichtbar. Eine stehende Regel: Jedes neue System muss sofort in der Standard-Starterstadt beobachtbar sein. Keine Features, die nur in Code-Reviews existieren.
• Deterministische Simulationsticks. Die Simulation läuft in festen, deterministischen Schritten. Das macht Regressionstests aussagekräftig und Desyncs debugbar.

Warum das in einem Portfolio aus Business-Software steht

Weil es dieselbe Disziplin in anderer Haut ist: eine performancekritische Domäne, ein Datenmodell, das unmögliche Skalierung möglich macht, und automatisierte Gates, die Qualität vor Regression schützen. Wenn wir eine Ökonomie mit 3 Millionen Bürgern auf einem Desktop reaktionsfähig halten, übersteht Ihr Dashboard auch den Traffic am Montagmorgen.