Northstar: Kürzere Wege, kein belegter CPU-Gewinn

Am Nachmittag des 23. September 2026, zwischen 14:47 und 17:45 Uhr UTC, wurden in Northstar Güter- und Dienstwege überprüft, zusätzliche Einrichtungen gebaut und die CPU-Arbeit des Spiels gemessen. Ziel ist, dass die Stadt bei unveränderter vierfacher Spielgeschwindigkeit weiter funktioniert, Einwohner hält und möglichst wenig Rechenzeit je Simulationsschritt benötigt. Eine Entlastung, die nur durch weniger Einwohner oder eine langsamere Simulation entsteht, zählt dafür nicht. Die Wege wurden kürzer, die Dienste größer – eine Rechenzeitersparnis ist damit aber noch nicht belegt.

Neun Messfenster

Die Auswertung umfasst neun gültige Fenster von jeweils mindestens 60 realen Sekunden, alle bei derselben Spielgeschwindigkeit und im selben laufenden Spielprozess. Erfasst wurden die Prozess-CPU-Sekunden je 1.000 Simulationsframes, die Frames je realer Sekunde und die Einwohnerzahl an beiden Endpunkten. Die Prozess-CPU enthält auch Darstellung und andere Spielarbeit; sie misst also nicht die Simulation allein. Die Tabelle zeigt fünf der neun Fenster, alle Zeiten in UTC.

Der letzte CPU-Wert liegt numerisch unter dem ersten, obwohl die Stadt größer ist. Ein Effizienzgewinn durch eine bestimmte Maßnahme folgt daraus noch nicht: Verkehrslast, Warnungen, Ereignisse, Rendering und Diagnoseaufwand waren über die Fenster nicht gleich gehalten, und zwei Fenster enthalten sogar einen kurzfristigen Einwohnerrückgang. Ein zu kurzes Fenster wurde ausdrücklich verworfen, statt es als günstigen Vergleichspunkt zu verwenden.

Wege, die tatsächlich kürzer wurden

Für einen Industrieanschluss verkürzte ein 500 Meter langer Lückenschluss die Route zum Güterterminal; auf den neuen Straßenkanten wurde danach positives Verkehrsvolumen beobachtet. Das belegt eine kürzere geometrische Möglichkeit, die auch genutzt wird. Fahrzeiten beladener Güterfahrzeuge und CPU-Kosten je Lieferung wurden nicht vergleichbar gemessen. Im CPU-Fenster nach diesem Bau sank die Einwohnerzahl um 171, weshalb auch dessen Wert kein isolierter Optimierungsnachweis ist.

Später verkürzte eine zweite gerichtete Verbindung eine Route im nördlichen Teilgraphen, und auch deren neue Kanten wurden genutzt. Der Vergleich derselben alten Straßenkanten zeigte jedoch weiterhin Rückstau; zusätzliche leere Kanten durften den Durchschnitt nicht künstlich verbessern. Das folgende CPU-Fenster zählte 59 Einwohner weniger. Ob die Verbindung Reisezeiten, Dienstfahrten oder Rechenaufwand längerfristig verbessert, ist offen.

Dienste gegen Rechenkosten

Ein zusätzlicher Bestattungsstandort nahm nachweislich Verstorbene auf, und eine konkrete, zuvor blockierte Abholung kam nach lokaler Prüfung wieder in Bewegung. Der Katastrophenschutz erreichte später ein beschädigtes Versorgungsgebäude, dessen Wiederaufbau anschließend kontrolliert wurde. Ein weiteres Straßenwartungsdepot erhöhte die Flottenkapazität um 15 Fahrzeuge; eine Momentprobe zeigte elf davon in Fahrt und vier mit Geschwindigkeit null. Solche Maßnahmen sichern oder erweitern Dienste, fügen der Simulation aber auch Gebäude und Fahrzeuge hinzu. Weder die Fahrbewegung noch das letzte CPU-Fenster belegt bisher eine flächige Reparaturwirkung oder einen CPU-Gewinn.

Stand

Kürzere Graphwege, ein versorgtes Gebäude und aktive Dienstfahrzeuge sind reale betriebliche Fortschritte, aber keine gemessene CPU-Ersparnis. Die jüngste kurze Einwohnerentwicklung war wieder negativ. Bevölkerung, Durchsatz, Warnlage und Rechenarbeit müssen gemeinsam über längere, besser vergleichbare Fenster beobachtet werden, bevor eine Optimierung als Erfolg gelten kann. Mehr zum Projekt: CS2.