Zeitsprung vorab simulieren
Verfasst: 03.02.2022 10:38:44
Es wird Zeit für mich vom stillen Mitleser zum Schreiber zu wechseln, denn:
Mir ist neulich aufgefallen, dass die aktuelle Implementierung des Zeitsprunges ziemlich ineffizient ist, weil doch eine nicht geringe Anzahl Computer jeden Tag annähernd die gleichen Berechnungen ausführen. Als (angehender) Physiker, also jemand der tagtäglich mit Simulationen zu tun hat, kam mir also die Idee, dass es wohl besser wäre den Zeitsprung (zumindest für noch nicht aufgegleiste Züge) vorab zu simulieren und zu speichern, oder wenigstens einen Cache von bereits ausgeführten Zeitsprüngen anzulegen. Dieses Vorgehen würde dann auch sicherlich die schon existierenden Performance-Probleme, wenn auch nicht lösen, dann aber geschickt umgehen (*hüstel* Maschen *hüstel*). Auf jeden Fall wäre es eine Entlastung für etwas schwächere Computer.
Folgende drei Gegenargumente sind mir schon eingefallen:
1. Das macht doch bestimmt viel zu große Dateien!
Ich habe mal anhand des TCP-Protokolls überschlagen, wie viel Speicherplatz die Daten eines Zuges benötigen (ich verbitte mir an dieser Stelle jeglichen Kommentar zu meiner Freizeitgestaltung ), das Ergebnis sind ca. 3 KB. Wenn man davon ausgeht das ein Fahrplan 100 Züge enthält und der Fahrplan 12 Stunden Lang ist (=720 min), dann gibt das eine Dateigröße von (nur) 216 MB. Ich habe auch mal grob für den gesamten Bestand überschlagen und komme (nach oben hin geschätzt) auf 13 GB. Das ist zwar fast doppelt so viel wie Zusi jetzt einnimmt, aber für ein Spiel heutzutage (wo AAA-Titel jenseits der 100 GB liegen) immer noch ein Witz.
2. Dann bringt aber der Chaos-Wert nichts mehr und der Fahrplan verhält sich immer gleich!
Das stimmt natürlich, wobei man da ein bisschen Nachhelfen kann indem man die Position der KI-Züge (darf man die so nennen? NPC-Züge vielleicht?) mit einer Normalverteilung variiert, deren Standardabweichung vom Chaos-Wert abhängt (im übrigen eine Methode die ich auch für andere Dinge vorschlagen würde, wie zum Beispiel die Dauer des Fahrgastwechsels oder eine zufällige Fahrstraßenverzögerung um einen etwas umnachteten Fdl nachzustellen, aber das ist ein anderes Thema). Man kann außerdem auch die aktuelle Funktion des Zeitsprungs behalten, sodass Puristen ("Ich will aber das MEIN Computer das simuliert") so verfahren können wie bisher. Allerdings glaube ich nicht, dass es davon noch viele geben würde, denn
3. Bringt das überhaupt zeitliche Vorteile, wenn man so große Dateien lesen muss?
Ja! Ich habe mal Python drangesetzt eine 216 MB große Datei zu lesen (und mir sogar einen bestimmten Satz von 100 x 3 KB herauszusuchen) und das ganze hat ca. 1s gedauert. Also wenn Python das so schnell auf die Reihe kriegt, dann kann das jede kompilierte Sprache auf jeden Fall.
Ich habe im übrigen schon mal nach einem ähnlichen Vorschlag im Forum gesucht und bin nicht fündig geworden. Sollte ich also etwas übersehen haben bitte ich um Nachsicht.
Dann bleibt mir nur noch denen zu danken, die sich diese Textwand wirklich durchgelesen haben, ich bin gespannt auf eure Reaktionen.
Beste Grüße,
Simon
Mir ist neulich aufgefallen, dass die aktuelle Implementierung des Zeitsprunges ziemlich ineffizient ist, weil doch eine nicht geringe Anzahl Computer jeden Tag annähernd die gleichen Berechnungen ausführen. Als (angehender) Physiker, also jemand der tagtäglich mit Simulationen zu tun hat, kam mir also die Idee, dass es wohl besser wäre den Zeitsprung (zumindest für noch nicht aufgegleiste Züge) vorab zu simulieren und zu speichern, oder wenigstens einen Cache von bereits ausgeführten Zeitsprüngen anzulegen. Dieses Vorgehen würde dann auch sicherlich die schon existierenden Performance-Probleme, wenn auch nicht lösen, dann aber geschickt umgehen (*hüstel* Maschen *hüstel*). Auf jeden Fall wäre es eine Entlastung für etwas schwächere Computer.
Folgende drei Gegenargumente sind mir schon eingefallen:
1. Das macht doch bestimmt viel zu große Dateien!
Ich habe mal anhand des TCP-Protokolls überschlagen, wie viel Speicherplatz die Daten eines Zuges benötigen (ich verbitte mir an dieser Stelle jeglichen Kommentar zu meiner Freizeitgestaltung ), das Ergebnis sind ca. 3 KB. Wenn man davon ausgeht das ein Fahrplan 100 Züge enthält und der Fahrplan 12 Stunden Lang ist (=720 min), dann gibt das eine Dateigröße von (nur) 216 MB. Ich habe auch mal grob für den gesamten Bestand überschlagen und komme (nach oben hin geschätzt) auf 13 GB. Das ist zwar fast doppelt so viel wie Zusi jetzt einnimmt, aber für ein Spiel heutzutage (wo AAA-Titel jenseits der 100 GB liegen) immer noch ein Witz.
2. Dann bringt aber der Chaos-Wert nichts mehr und der Fahrplan verhält sich immer gleich!
Das stimmt natürlich, wobei man da ein bisschen Nachhelfen kann indem man die Position der KI-Züge (darf man die so nennen? NPC-Züge vielleicht?) mit einer Normalverteilung variiert, deren Standardabweichung vom Chaos-Wert abhängt (im übrigen eine Methode die ich auch für andere Dinge vorschlagen würde, wie zum Beispiel die Dauer des Fahrgastwechsels oder eine zufällige Fahrstraßenverzögerung um einen etwas umnachteten Fdl nachzustellen, aber das ist ein anderes Thema). Man kann außerdem auch die aktuelle Funktion des Zeitsprungs behalten, sodass Puristen ("Ich will aber das MEIN Computer das simuliert") so verfahren können wie bisher. Allerdings glaube ich nicht, dass es davon noch viele geben würde, denn
3. Bringt das überhaupt zeitliche Vorteile, wenn man so große Dateien lesen muss?
Ja! Ich habe mal Python drangesetzt eine 216 MB große Datei zu lesen (und mir sogar einen bestimmten Satz von 100 x 3 KB herauszusuchen) und das ganze hat ca. 1s gedauert. Also wenn Python das so schnell auf die Reihe kriegt, dann kann das jede kompilierte Sprache auf jeden Fall.
Ich habe im übrigen schon mal nach einem ähnlichen Vorschlag im Forum gesucht und bin nicht fündig geworden. Sollte ich also etwas übersehen haben bitte ich um Nachsicht.
Dann bleibt mir nur noch denen zu danken, die sich diese Textwand wirklich durchgelesen haben, ich bin gespannt auf eure Reaktionen.
Beste Grüße,
Simon