FableCity: symulacja miasta, która myśli w milionach

Problem

City buildery stoją przed brutalnym kompromisem: symuluj każdego mieszkańca i dław się przy 100 tysiącach populacji, albo udawaj wszystko i strać emergentne zachowania, dla których ten gatunek istnieje. Benchmark wielkiego studia męczy się już powyżej kilkuset tysięcy agentów. Pytanie projektowe: jak daleko może się skalować symulacja miasta, jeśli całkowicie odmówisz symulowania per agent?

Co zbudowaliśmy

Grę o budowaniu miasta w Godot 4, zbudowaną wokół agregatowego rdzenia symulacji. Populacja, zatrudnienie, obciążenie ruchem, media, wartość gruntów i popyt są modelowane jako oddziałujące na siebie kohorty statystyczne, a nie pojedynczy agenci. Trzy miliony mieszkańców to nie trzy miliony zadań pathfindingu, to układ sprzężonych równań na agregatach poziomu dzielnic, który wciąż daje wiarygodne zachowania makro: napór dojazdów, fale gentryfikacji, kaskady blackoutów.

Dyscyplina inżynierska, na której jedzie projekt:

• Bramka wydajności, nie nadzieje na wydajność. Automatyczny zestaw testów zawiera twarde checki perf; zmiana, która wypada z budżetu klatki, wywala build. Optymalizacja jest ciągła, a nie paniką przed premierą.
• Każda funkcja widoczna od startu. Stała zasada: każdy nowy system musi być natychmiast obserwowalny w domyślnym mieście startowym. Żadnych funkcji istniejących tylko w code review.
• Deterministyczne ticki symulacji. Symulacja posuwa się w stałych, deterministycznych krokach, co czyni testy regresyjne sensownymi, a desynci debugowalnymi.

Dlaczego jest w portfolio oprogramowania biznesowego

Bo to ta sama dyscyplina w innej skórze: domena krytyczna wydajnościowo, model danych dobrany tak, by niemożliwa skala stała się możliwa, i automatyczne bramki, które nie pozwalają jakości się cofać. Skoro potrafimy utrzymać responsywną gospodarkę trzech milionów mieszkańców na desktopie, twój dashboard przeżyje poniedziałkowy poranek.