[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:
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]
Informationen Zusammengetragen von Xanos
Quellen: Eigene Erfahrung & Beobachtung, Hinweise seitens Urban Games, Patchnotes, Codeanalyse zu Build 4832 von @eis_os