Erklärung zu der Berechnung, Mehrkernnutzungnutzung und Wartezeit am Monatsende

[Blockierte Grafik: http://ftp.train-fever.net/flaggen/de.png] Ein kurzer Überblick über Berechnung, Mehrkernnutzung (Multicore) und Wartezeit am Monatsende, Stand Build 5080
English Version can be found here.

Zuerst ein mal das offensichtliche: Train Fever nutzt mehrere Threads. Das eigentliche Spiel, beziehungsweise das, was uns auf dem Monitor angezeigt wird nenne ich im folgenden ein mal "Hauptthread". Je mehr Berechnungen der Hauptthread parallel zum eigentlichen Spielgeschehen berechnen muss, desto geringer wird die Framerate (FPS).

Mittlerweile hat es Urban Games geschafft, einige Berechnungen aus dem Hauptthread auszukoppeln, und in anderen Threads unterzubringen, die parallel laufen, und vom Betriebssystem auf andere Prozessorkerne verteilt werden können. Wichtig hierbei im allgemeinen: Ein Thread kann auch auf mehreren Kernen ausgeführt werden, aber die Ausführung bleibt sequentiell, das heißt, es gibt keinen Geschwindigkeitsvorteil, sondern nur einen Last-Ausgleich für den Prozessor. Mehrere Threads können auch auf einem Kern laufen, teilen sich dann aber die Berechnungszeit. Im Idealfall werden alle Threads parallel ausgeführt.

Mit steigender Komplexität des Spielstandes, sprich der Anzahl der Personen bzw Fahrzeuge, steigt natürlich auch der Berechnungsaufand des Spiels. Früher hat sich der größere Berechnungsaufwand vor allem durch geringere FPS bemerkbar gemacht. Seit dem mit Build 5068 nun auch die Wegfindung in einen eigenen Thread verschoben wurde, sollte die FPS Zahl im allgemeinen gestiegen sein, dafür klagen nun einige Spieler über längere "Wartezeiten" / "Lags" am Monatsende. Dies lässt sich wie folgt erklären:

In Train Fever gibt es die Besonderheit, dass der "Monat" als Zeiteinheit gewählt wurde. Am Ende jedes Monats (im Spiel) müssen alle Berechnungen abgeschlossen sein, ansonsten kann der nächste Monat nicht beginnen. Dadurch, dass die Berechnungen ausgelagert werden, läuft das Spiel selbst zwar wieder flüssiger und dadurch auch schneller, die Berechnungen selbst müssen aber natürlich immer noch durchgeführt werden. Wenn der Berechnungsaufwand zum Beispiel für die Wegfindung nun ca zwei Minuten beansprucht, der Monat aber bereits nach 1 Minute 30 Sekunden vorbei ist, muss der Hauptthread noch 30 Sekunden auf die Fertigstellung der Wegfindungsberechnung warten - ein 30-sekündiger Lag tritt auf. Pausiert man das Spiel nun, oder beschleunigt man es, verändert man zwar die Dauer des "Monats", die Berechnungen brauchen aber in Echtzeit immer ungefähr gleich lang. D.h. wenn man dauerhaft auf 4-facher Geschwindigkeit spielt, wird man im Schnitt deutlich längere Wartezeiten zum Ende des Monats erhalten. Pausiert man innerhalb des Monats das Spiel hingegen, ist es sehr wahrscheinlich, dass die Berechnungsthreads bereits vor Ende des Monats ihre Arbeit vollendet haben, und das Spiel ohne Wartezeit weiter läuft.

Zu beachten ist: Parallelisierung von Aufgaben beschleunigt die Aufgabe an sich nicht. Wenn die Wegfindung früher den Hauptthread um 2 Minuten mehr pro Monat ausgebremst hat, wird die Berechnung in einem eigenen Thread auch immer noch (mindestens) 2 Minuten dauern. Solange die Berechnungsdauer kürzer ist als ein Monat, führt das Auslagern natürlich nur dazu, dass die FPS besser ist, sobald die Berechnung aber länger dauert hat man leider die Wartezeit. Oder noch ein mal anders gesagt: Wenn euer Spiel vor Build 5068 so stark geruckelt hat, dass die Monate deutlich langsamer vergingen, ist damit zu rechnen, dass der Monat jetzt zwar wieder schneller umgeht, der Berechnungsaufwand aber immer noch der selbe ist, und die Zeit dann am Ende des Monats abgewartet werden muss. Natürlich hat die Wegfindung nun einen "eigenen" Thread für sich, aber durch Abhängigkeiten zwischen Threads und den allgemein großen Aufwand, können diese Berechnungen vor allem auf großen Karten mit vielen Personen und vielen Möglichkeiten (durch ein großes Verkehrsnetz) ziemlich lange dauern.

Dieser Beitrag soll euch hierbei nicht zu einer gewissen Spielweise bringen (z.B. innerhalb der Monate öfter zu pausieren oder allgemein nicht vorzuspulen), sondern nur versuchen, die Hintergründe verständlich zu erläutern.

Zum Abschluss noch ein kleiner Hinweis: Wer trotz neuestem Patch immer noch geringe FPS hat, sollte - falls noch nicht geschehen - die Texturqualität auf "niedrig" schalten. Zwar langweilen sich moderne Grafikkarten bei Train Fever, haben aber auf großen Karten mit vielen Objekten aufgrund des unglaublichen Speicherhungers von Train Fever nicht genügend Grafikspeicher.

Update zum Build 5112:

Zitat von Urban Games

Most important, players reported freezes at the end of each game month. We have identified the problem and it is fixed now. Because since the last update, the game runs faster during the months, on certain systems (parallel) simulation calculations which need to be finished at the end of each month were still in progress and caused these freezes.

Auf Deutsch heißt das: Die von mir Beschriebenen Auswirkungen wurden von Urban Games gefixt - es wurde also versucht (auf welche Art auch immer) die Lags am Monatsende zu unterdrücken. Nach einem kurzen Testlauf auf meiner großen, vollen Karte im Jahr 2055 kann ich das durchaus bestätigen. Selbst auf maximaler Geschwindikeit bleiben die Ruckler unter maximal 1-2 Sekunden und sind somit quasi Behoben. Vielen Dank an Urban Games an dieser Stelle, für die schnelle und gute Arbeit.
Zusätzlich wurde angekündigt, das "Hauptstraßen-Feature" in zukünftigen Versionen zugunsten eines "Sandkastenmodus" ausschaltbar zu machen, dazu aber in anderen Themen mehr.

[line][/line]

Natürlich müsste das restliche Spiel (Balancing) auf die geänderte Monatszeit angepasst werden aber ja, das wäre eine Möglichkeit, die Monats-Ende Lags zu umgehen.
Alternativ könnte man auch den Weg wählen, nur alle 2 (oder alle 3) Monate die Berechnungen neu zu machen.

Beide Optionen lassen sich aber nicht modden, sondern können nur von den Entwicklern umgesetzt werden.

@0815san, Kommt auf die Art der Berechnungen an. Wenn zum Beispiel nur alle zwei Monate jeder Person auf der Karte eine neue "Arbeitsstätte, Freizeit, Einkaufsmöglichkeit" zugewiesen wird, dauert es zwar länger bis neue Linien genutzt werden, aber die Berechnung wird effektiv wirklich halbiert. Wenn man zum Beispiel aber halb so oft die Leute "auf ihren Weg" schickt, hat man natürlich deutlich weniger Verkehr auf den Straßen und weniger Andrang im ÖPNV - das wäre ein so starker Eingriff in das Balancing, dass man entweder die Einwohnerzahl verdoppeln müsste (Damit hätte man nichts gewonnen) oder aber man müsste das ganze Spiel neu balanzieren -> So etwas wird also sicherlich nicht gemacht.

Trotzdem gibt es sicherlich einige Berechnungen, die man seltener ausführen könnte, auch wenn man eventuell einen geringen Grad an Realsimus oder Reaktionsfreudigkeit einbüsen würde.

Der erste Anhaltspunkt sollte aber immer die Frage sein: Wie kann ich die Algorithmen verschnellern, effektiver machen oder allgemein austauschen?
Einfaches Beispiel zur Wegfindung: Muss man für jede Person einzeln den Weg berechnen oder berechnet man nicht lieber die Wege nur dann, wenn sich etwas am Verkehrsnetz ändert, und die Personen greifen dann auf einen viel schnellen Algorithmus zurück, der auf Basis der vorberechneten Daten einen Weg aussucht. Auch dann: muss ich alles neu berechnen oder eventuell nur einen lokalen Teil?
Ich will Urban Games sicherlich nicht vorwerfen Ineffiziente Algorithmen zu nutzen, allein schon aus dem Grund das ich nicht weiß, wie sie die Berechnungen durchführen. Aber eventuell (hoffentlich) lässt sich da ja an einigen Stellen noch etwas verbessern. Natürlich nur solange es "im Rahmen" bleibt, UG soll sicherlich nicht ganze Teile des Spiels neu schreiben müssen.

@Angry_CJ: Die Probleme "verschwinden" dadurch nicht, sondern man "versteckt" sie natürlich nur. Und spätestens wenn man auf einer ausreichend großen Karte mit 4-facher Geschwindigkeit spielt tauchen sie auch irgendwann wieder auf

Die Veränderung der Monatsdauer hat ja zum Glück auf die 20-Minuten-Regel (sofern diese nicht an die Monate gebunden ist) keine Auswirkung. Man braucht einfach nur länger bis neue Fahrzeuge erscheinen. Was angepasst werden müsste sind die Unterhaltskosten und Preise: Wenn ein Monat doppelt so lange dauert, ansonsten alles aber gleich schnell bleibt (das wäre ja der Sinn, sonst würden alle nur noch auf 2-facher Geschwindigkeit spielen) verdient man natürlich doppelt so viel während alle kosten gleich bleiben. Also entweder die Fahrkartenpreise halbieren (einfacherer Weg) oder die restlichen Preise steigern. Theoretisch sollte es also Möglich sein, die Frage bleibt: ist da intern eventuell noch etwas verstrickt / zusammenhängend und: Will UG die Monatsdauer überhaupt ändern? Im Hinterkopf behalten sollte man auch noch den Fakt, dass man dann natürlich auch doppelt so lange braucht um von 1850 bis in das Jahr 1950 ( oder gar 2000) zu kommen. Und für Neulinge sind die anderen Startjahre noch gesperrt!

Du hast am Ende bereits selber gesagt: die 20 Minuten sind Realzeit… nicht Spielzeit
Es geht darum, nur den Monat langsamer laufen zu lassen, als andere dabei so zu lassen, wie es ist. 20 Minuten bleiben 20 Minuten und die Züge legen im 20 Minuten die gleiche Strecke zurück. Ob nach diesen 20 Minuten auf den Kalender dann 20.01. oder 9.2. oder was auch immer steht kann den Leuten in TF und der Wegfingung ja egal sein. Wenn die 20-min Regel nicht an die Realzeit, sondern intern an die angezeigten Tage und Monate gekoppelt ist, müsste man die Zahl auch nur entsprechend skalieren.

Das gesamte Spiel mit einer Zeitlupe verstehen bringt nichts. Wenn die Züge nur noch umher schleichen beschleunige ich als Spieler natürlich mehr. Die Züge müssen schon genau so schnell bleiben wie die sind. Also auf 1-facher Geschwindigkeit in 20 Real-Minuten die selbe Strecke fahren wie bisher.

Zum Vorschlag @Tom: Ja, das korrespondiert zu meinem Vorschlag, "unwichtige" oder zumindest "unbemerkte" Berechnungen seltener auszuführen, und sich dadurch ganz einfach Rechenzeit zu sparen, ohne die Algorithmen selbst ändern zu müssen.

Zum "Verhalten": Bei meiner großen, stark bebauten Testkarte habe ich kurz vor dem Patch zufällig gesehen, wie eine Autobahn zwischen Zwei Städten zu einem großen, zweispurigen Parkplatz geworden ist. Seit dem Patch konnte ich dieses Phänomen nicht mehr entdecken. Ob das nun mit dem Patch zusammenhängt, habe ich bisher nicht weiter analysiert. Da ich noch eine alte .exe im Backup habe, könnte ich das bei Zeiten mal näher Untersuchen.

Ja, in einem älteren Build wurde das eingeführt und das konnte ich auch bemerken/bestätigen. Da für die 50xx Builds aber davon nichts in den Patchnotes stand fragt @Tom ja nach, ob jemand anderes die selben Beobachtungen gemacht hat

@eis_os: Meine Antwort dazu per PN, ich will ja nicht das es hier ausartet.

Theoretisch ja, praktisch nicht ratsam, da das mit verschiedenen Systemen wieder starke Fehlerquellen aufwirft.