Diskussion zur Peformance und fehlenden Features (Build 6181)

Irgendwann muss man die Berechnungen nun mal machen. Entweder, man man verteilt sie, dann schreien alle, dass die Framerate durchgängig zu niedrig ist. Oder man macht die Berechnungen selten, dann aber alle in einem Rutsch. Dann bleibt die Framerate annehmbar, aber alle regen sich über Ruckler im Moment der Berechnungen auf. Wie es aussieht hatte man anfangs die erste Lösung und nach anhaltender Kritik gab es die Umstellung auf die zweite Lösung.

Es gibt eine Lösung für alle Probleme Uninstall this Game so einfach ist das.

Ich finde auch, dass die Frage von @Duscha berechtigt ist, denn schliesslich war die Patchankündigung sehr wage betreffend des Inhalts.

Zitat von druckerpapier

Es gibt eine Lösung für alle Probleme Uninstall this Game so einfach ist das.

Naja, es gibt ja noch den einen Patch, der dieses Problem vielleicht aus der Welt schaffen könnte. Aber generell finde ich es schon befremdend, was hier geschrieben wird bezüglich Duschas Kommentar. Immerhin geht es hier um konstruktive Kritik, die das Spiel besser machen könnte und das ist ja im Interesse aller hier. Wer mit dem Problem nicht vertraut ist, sollte hier alle Beiträge mal Lesen oder zumindest ab Seite 12.

Zitat von Duscha

die Monatsendruckler gab es nicht von Anfang an.

Bei einer kleinen Map und Texturen auf niedrig hatte ich so gut wie keine Monatsruckler.

Klar ist die Kritik berechtigt, aber meint ihr, es ginge so einfach zu lösen? Wenn es das wäre, wärs 100%ig schon gemacht. Ich find es einfach unrealistisch in diesem Statium noch nach solchen Sachen zu fragen, die vor nem halben Jahr nicht gelöst werden konnten. Eventuell haben sie es ja geschafft, dann können wir uns freuen. Wurde ja von weiteren Performance-Verbesserungen gesprochen. Aber ich glaubs ehrlich gesagt nich. Und am Inhalt des Patches wird sich in den "letzten 5 Minuten" auch nix mehr ändern. Berechtigte Frage hin oder her. Entweder es is drin (jetzt schon) oder eben nich.

Also ich finde es nicht sehr konstruktiv, den Entwicklern Unvermögen und Unwilligkeit vorzuwerfen. Immer nur auf ein bekanntes Problem zu zeigen ist nicht konstruktiv. Meine Frage nach einem Lösungsvorschlag blieb ja leider unbeantwortet.

Also grundsätzlich finde ich die Frage schon berechtigt, ob an den Rucklern noch gefeilt wird. Ich halte nochmal fest, daß diese bei den Spielern sehr unterschiedlich stark ausgeprägt sind, was wiederum viele Ursachen hat. Fakt ist es, die Ruckler existieren bei etlichen Spielern und das macht dann natürlich auch keinen Spaß. Brauchen wir nicht weiter zu diskutieren, ist ne bekannte Tatsache.

Allerdings denke ich, daß daran nicht mehr viel zu verbessern ist mittels eines Patches. Diese werden einfach aufgrund der extrem aufwändigen Berechnung der einzelnen Bewohner verursacht. Da müsste man schon das komplette Berechnungsmodell verändern (bzw. vereinfachen). Was im Klartext heisst: Ein komplett neues Spiel entwickeln. Den Jungs von Urban Games ist allerdings durchaus bewusst, wie störend diese Ruckler sein können

Zitat von fjb

Dann schlag doch einfach mal einen besseren Algorythmus vor, anstatt immer nur zu behaupten, dass es schlecht implementiert ist.

Du bist lustig. Der Source Code von Train Fever ist nicht offen, also wissen wir nicht, was der Algorithmus genau macht, ergo kann ich auch schlecht einen besseren vorschlagen. Dass es so wie es jetzt ist suboptimal ist, ist keine Behauptung sondern eher offensichtlich.

Zitat von fjb

Also ich finde es nicht sehr konstruktiv, den Entwicklern Unvermögen und Unwilligkeit vorzuwerfen. Immer nur auf ein bekanntes Problem zu zeigen ist nicht konstruktiv. Meine Frage nach einem Lösungsvorschlag blieb ja leider unbeantwortet.

Ich glaube die Jungs sind sich des Problems bewusst und ich bin mir sicher, dass sie das mit TF2 in den Griff bekommen. Es ist eben problematisch, dass in einem bereits veröffentlichtem Spiel noch zu ändern, weil schlicht der Aufwand (zu) hoch ist.

Ich dachte wir wären uns mehr oder weniger einig, dass die Monatsendruckler vom Stadtausbau verursacht werden und nicht abhängig sind von der Menge der Bewohner selbst. Woher wollt ihr denn wissen, dass man das komplette Berechnungsmodell verändern muss? Seid ihr an der Entwicklung beteiligt? Wie aufwändig ein Umprogrammierung am Ende tatsächlich ist, können nur die Jungs von Urban Games abschätzen. Alles andere ist nur Spekulation.

Desweiteren stelle ich mal in den Raum: sind sie sich des Problems wirklich bewusst? Bisher haben sie dazu noch nichts verlautbaren lassen. Hinsichtlich eines finalen Patches werden sie sicher die verfügbaren Rescourcen genau verplant und die Prioritäten entsprechend gesetzt haben. Ich für meinen Teil kann gut und gerne auf zusätzliche Features verzichten. Die sind nicht mehr kriegsentscheidend. Entscheidend für den Verkauf des Nachfolgers wird auch die abschließende Bewertung von Train Fever sein. Werde ich meinen Freunden und Bekannten Train Fever und auch Train Fever 2(?) empfehlen, wenn das 'fertige' Spiel noch immer diesen Fehler beinhaltet? Ganz sicher nicht. Gerade dadurch leidet das Konzept als Sandkastenspiel, wenn mit fortlaufender Spieldauer die Perfomance abnimmt.

An der Stelle mag ich mit meiner Kritik in der Minderheit sein, aber ich vermute der Großteil der Spieler, die das auch sehr stört, haben das Spiel schon längst wieder deinstalliert und schauen hier im Forum auch nicht mehr vorbei. Den harten Kern kann so oder so nichts abschrecken - nur wird der am Ende genug Spielekopien kaufen um die zukünftige Entwicklung zu finanzieren?

edit: @mediziner Im Livestream zur Veröffentlichung zum Nordic DLC treten die Monatsendruckler ebenfalls auf. Also entweder betrifft das dein Rechner oder den von Stepke und da war auf der Karte auch noch nicht viel los. Ich behaupte das Probleme betrifft ALLE Spieler. Spätestens wenn man denn mal auf einer mittleren oder großen Karte bei fortgeschrittener Spieldauer angelangt ist.

Natürlich lese ich hier noch mit …

Ich glaube, Mediziner hat das gut zusammengefasst. Es ist uns absolut bekannt, dass es den Monatsruckler gibt und es viele betrifft bzw. auch berechtigt stört (ja, auch mich manchmal ;)).

Ob es ein Bug ist oder nicht, ist sicher eine Frage der Definition. Es ist kein „Fehler“ im Sinne von „etwas geht schief oder funktioniert falsch oder nicht“. Das Spiel lässt sich auch mit dem Monatsruckler einwandfrei spielen, der Spielfluss und Komfort ist aber natürlich ohne Frage eingeschränkt, das möchte ich absolut nicht abstreiten.

Wie DarkMo sagt: Gäbe es eine einfache Lösung, die in kurzer Zeit umsetzbar ist und garantiert, dass keine anderen Teile des Spiels der Gefahr ausgesetzt werden, nicht mehr korrekt zu funktionieren … dann wäre es schon umsetzt.

Ich kann euch versichern, wir schließen nicht die Augen bei diesen für manche „großen Problemen". Auch ist uns 100% bewusst, was sich die Community, also ihr, wünscht. Ich verbringen viel mehr Zeit mit lesen von Mails und Forumsbeiträgen, wie sich so mancher vielleicht vorstellt.

Wir wägen sehr genau ab, was (unter Berücksichtigung der Wirtschaftlichkeit) noch machbar ist und was nicht. Wäre uneingeschränkt viel Geld und Zeit da, dann würde auch noch uneingeschränkt weiter entwickelt werden.

Ich bitte also um Verständnis … wir müssen auch daran denken wie es weiter geht, aber wir geben wirklich unser bestes, damit auch Train Fever so viel Aufmerksamkeit bekommt, wie nur irgendwie möglich.

Guten Rutsch!
Tom

Ich hab mir grad nen großen teil des Threads hier durch gelesen und musste doch ziemlich schmunzeln. Das der Monats-End-Ruckler unter anderem auf den Städtebau zurück zu führen lässt, hatte UG doch selber in den Patch-Notes am 30.01.2015 schon angemerkt. Aber es hat gefühlt 20 Seiten gebraucht, bis der erste auf die Idee gekommen ist, das mal zu überprüfen.
Wer mal eine Stadt umgebaut hat wird auch schon mal Minuten vor dem Spiel gesessen sein und es tat sich nix.
Aber ja, da ist sicher auch noch mehr, was da passiert, aber der Stadtausbau/ umbau ist wohl das größte Problem.

Ich für meinen Teil bin begeistert von der Performance von Trail-Fever, den Monats-End-Ruckler würde ich persönlich aber schon als Entwickler in die Kategorie "Bug" einstufen. Denn es ist definitiv etwas, dass den Spielspaß für viele dramatisch senkt und so was ist nie mals von einem Entwickler gewollt, maximal geduldet

Ich für meinen Teil freu mich nun auf das (letzte) Update und mit dem Wissen, dass es damit keine weiteren Updates gibt werd ich mich auch mal den ganzen tollen Mods wittmen

PS: @Duscha, Agenten-Basierte-Spiele wie Train-Fever verlieren immer mit fortlaufender Spieldauer an Performance. Das ist z.B. auch bei Cities Skylines so. Die einzige Lösung: Limitieren. Ein Kritikpunkt bei Cities Skylines übrigens, da dadurch Leute mit besserer Hardware ihre Hardware nicht ausreitzen dürfen. Es gibt hier also keine Lösung, die alle zufrieden stellt.

MFG PMV

Ein Bug ist eine offensichtliche Fehlfunktion. Hier benötigt das Spiel schlicht zu viel Zeit für Berechnungen. Aber das ändert auch nix daran, daß es mit den zur Verfügung stehenden Mitteln nicht lösbar ist. Allerdings wird im nächsten Titel da vermutlich deutlich mehr Wert darauf gelegt werden, daß so etwas nicht auftritt.

Zitat von DarkMo

Klar ist die Kritik berechtigt

Natürlich gibt es mit TF das ein oder andere Problem. - Aber:
Tf kostet gerade mal 15 - 20 Euro. Wenn ich bedenke, was ich mir für den Preis schon alles an Schrott gekauft habe...
Aber da gab es nie einen Ansprechpartner (Forum) wo man sich hätte beschweren können.
Also für den Preis und für das erste Game von UG ist das eine tolle Leistung.

Generell verbrauchen Aufbauspiele mit der Zeit mehr Ressourcen und sie werden je nach PC auch langsamer. Bei AoE habe ich das bspw. auch wenn zu viele Katapulte um sich herschießen und eine monstermäßige Schlacht von statten gehen. Darüber hinaus empfinde ich den uckler als weniger schlimm, da nervt mich eher der Baumodus, der mir warum auch immer eine Fehler anzeigt.

Zitat von pdca_cycle

Du bist lustig. Der Source Code von Train Fever ist nicht offen, also wissen wir nicht, was der Algorithmus genau macht, ergo kann ich auch schlecht einen besseren vorschlagen. Dass es so wie es jetzt ist suboptimal ist, ist keine Behauptung sondern eher offensichtlich.

Natürlich kennen den Source von Train Fever nur die Leute von UG. Aber Du könntest ja mal erzählen, wie Du es machenwürdest, wenn Du es implementieren solltest.

Man kann auch sagen, dass die meisten rechner heute suboptimal sind. Die Leistung eines einzelnen Rechenkernes steigt nur mäßig. Die große Leistung moderner CPUs liegt darin, mehrere Kerne zu bündeln. Das ist gut für parallelisierbare Aufgaben und ganz schlecht bei Dingen, die sich nicht sinnvoll parallelisieren lassen. Train Fever gehört zu letzterem.

Auch wenn wir den Source von Train fever nicht kennen, so kann man ein ähnliche Spiele heranziehen, die sehr ähnliche Probleme haben und die offenliegen. Das offensichtlichste Beispiel dürfte OpenTTD sein. Im folgenden werde ich mich auf dieses Spiel beziehen.

Um etwas zum transpotieren zu haben braucht es Fracht. Intern wird das in Form von Frachtpaketen gehandhabt. Bei Train fever wird es ähnlich sein, da sieht man die Frachtpakete sogar visualisiert laufen. Passagiere gelten dabei als eine Frachtart. Nun gibt es Produzenten und Konsumenten der Fracht. In OpenTTD wird Fracht produziert, sobald in der Nähe ene passende Haltstelle bedient wird. Die Fracht "beamt" dann dorthin. Die Fracht sammelt sich dort und wird abgeholt oder sie verfällt. Die Frachtpakete werden dann einem Fahrzeug zugeordnet und bei dessen nächsten Halt in der Nähe eines passenden Konsumenten entladen. Sind die zwei Haltestellen nahe bei einander, so fährt die Fracht nur ein kurzes Stück mit, der Gewinn ist gering. Im Stadtverkehr fahren Passagiere nur von einer Haltestelle bis zur nächsten. Auch kann man so keine Fracht von einem Fahrzeug auf das nächste umladen, da sie entweder sofort von einem Konsumenten geschluckt wird, oder sie das Fahrzeug gar nicht erst verlässt.

Um Umladen trotzdem zu ermöglichen, gibt man einem Fahrzeug den Befehl, seine gesamte Fracht in einer Station zu entladen. Zusätzlich muss man dem Fahrzeug verbieten, in dieser Station Fracht zu laden. Es würde sonst seine gerade entladene Fracht sofort wieder laden. Bidirektionales Umladen geht nicht. Das wird problematisch, wenn man bedenkt, dass Passagiere auch Fracht sind. Man kann also keinen Umsteigebahnhof bauen.

Nun gab es mehrere Ansätze, dieses Problem zu beheben. Einer davon war, dass zu Beginn des Spieles jedem Produzenten ein Konsument fest zugeordnet wird. Das geht gut bei Industrien aber eher schlecht bei Häusern, die ja während des Spiels entstehen. Das zweite Problem ist, dass man immer genau das zugeordnete Paar aus Produzent und konsument verbinden muss, sonst steht keine Fracht zur Verfügung. Das macht gerade den Beginn des Spieles unglaublich schwierig, weil kaum Fracht ein Fahrzeug benutzen will.

Der neuere Ansatz ist jedem neu erzeugten Frachtpaket einen im verbundenen Netz möglichen Empfänger zuzuweisen. Dabei werden in einem vorgegebenen Verhältnis Konsumenten in unterschiedlicher Entfernung vom Produzenten gesucht. Auch hier fährt nicht so viel Fracht wie in der ursprünglichen Fassung des Spiels mit jedem Fahrzeug, da ja nicht jedes Frachtpaket mit dem erstbesten Fahrzeug mitfährt. Außerdem müssen regelmäßig die möglichen Verbindungen erfasst und bewertet werden, sonst werden neue Linien nicht bedient. und während dieser Berechnungen kommt es, je nach Leistung der CPU des Rechners, zu mehr oder weniger starken Rucklern. Das Frachtmodell von Train Fever ist diesem Ansatz vermutlich sehr ähnlich aber schon deutlich optimiert.

Die Monatenderuckler entstehen durch den Ausbau der Städte, kann man oberflächlich sagen. Aber was passiert da im Hintergrund? Neue Häuser sind neue Produzenten und Konsumenten. Würde nicht regelmäßig eine Neuberechnung stattfinden, so würden sie nicht bedient. Es würden keine neuen Passagiere reisen wollen. Auch müssen neuen Linien in die Berechnungen einbezogen werden, sonst würde keine Fracht, kein Passagier sie nutzen. Nun könnte man meinen, dass nur die neuen Häuser und neuen Linien berechnet werden sollen. Dann würde es aber nur zwischen den neuen Häusern Reisende geben, und damit würden wieder nur wenige Frachtpakete auf die Reise gehen. Train Fever muss also alles neu berechnen, um auch von alten Häusern aus neue Reiseziele zu ermöglichen, weil die Züge und Busse zu neu angeschlossenen Orten sonst über Jahrzehnte fast leer blieben. Bei der Neuberechnung wird versucht, wohl immer die möglichst größte Entfernung für ein Frachtpaket zu ermitteln, um dem Spieler bei optimalem Netz den möglichst größen Gewinn zu ermöglichen. Das ist einer der Unterschiede zur Lösung vom OpenTTD. Allerdings finden sich trotzdem häufig genug auch verbindungen im relativen Nahbereich.

Und nun bin ich gespannt auf Ideen zur Verbesserung.

Ach alles halb so wild!
Mein Jahresenderuckler geht schon 21 Stunden und 35 Minuten!

Was machen da die 15sek

@fjb

Schöne Ausführung und einen Lösungsansatz dazu habe ich auch parat, hatte dies schon seit Monaten mehrmals beschrieben, im Bezug zum Stadtinformationsfenster.
Das Stadtinfofenster weist eine Über- und Unterdeckung der einzelnen Stadtbereiche (Industrie/Wohn/Geschäft/Freizeit) aus.

Nur kann diese Über- bzw. Unterdeckung mit der Eröffnung einer "neuen" Linie nicht bedient werden, da durch das Einrichten einer "neuen" Linie die Städte sich komplett neu umbauen, um eine Verbindungen "Agent(Paket)/Konsument" für eine "längst mögliche Strecke zu Profit" ein zu richten.

Für eine Wirtschaftssimulation natürlich eine völlig unlogische Herangehensweise, da .... warum soll "Agent A" seinen "Arbeitsplatz A" wechseln, um zu einem weit entfernten "Arbeitsplatz B" zu fahren ?

Arbeitslose / Freizeit- und Geschäftssuchende ja, denn die benötigen ja noch ein Ziel(Konsument).
Ein Stadtwachstum (neue Bewohner) richtet sich entsprechend nach einer vorhandenen "Überdeckung" als Zielzuweisung aus.

Meiner Meinung nach reduziert sich dadurch der rechnerische Aufwand erheblich und eine nachvollziehbare Spiellogik wird ersichtlich.

Darüber hinaus könnte man ein Wachstum der unterschiedlichen Zonen und Städte insgesamt als Spieler beeinflussen, indem unterschiedliche "Güterarten" (4) in die Städte geliefert werden.
Dies generiert automatisch eine Über- und Unterdeckung, die jede Stadt sich individuell entwickeln lässt und nicht synchron, wie es bisher der Fall ist.
Des weiteren lässt sich eine Kalkulation (des Spielers) des Transportbedarfs für die Fahrzeuge weit einfacher voraus berechnen.

Eben logisch und nachvollziehbar, passend zum Stadtinformationsfenster.

Das klingt im ersten Moment logisch, aber dann gäbe es eine reihe von Problemen. Dein Ansatz funktioniert nur, wenn man Städte mit entgegengesetzter Unter- / Überdeckung verbindet. Bei zwei Städten mit gleicher Abweichung würde kaum jemand die Verbindung nutzen. Auch sonst wäre die Anzahl der Passagiere vermutlich deutlich geringer als bei der jetzigen Lösung. Das hatte ich schon im letzten Abschnitt meiner vorherigen Antwort angesprochen. Natürlich ist das nicht mehr als eine Vermutung, aber sie basiert auf meinen Erfahrungen mit ähnlichen Implementierungen in OpenTTD.

Die Anzahl der Passagiere ist natürlich anfangs geringer, steigt aber mit dem Zuzug neuer Bewohner.
Das jetzige Problem ist ja auch das mit dem einrichten des ÖPNV dieser komplett über den Haufen geworfen wird, wenn einen Stadt/Stadt Verbindung eingerichtet wird.

Städte mit gleicher Abweichung (Unter- Überdeckung) benötigen ja keine Verbindung, wie im realen Leben auch.
Linien werden im realen eingerichtet wo ein Bedarf besteht und nicht nach dem Motto: "Da hätte ich gerne".

Ich habe es schoneinmal irgendwo geschrieben, man müßte nur den Stadtausbau und die Neuberechnung der vorhandenen Bewohner begrenzen und kontingentieren.
Man hat ja eine gesamte Einwohnerzahl auf der Karte. Der Stadtausbau selbst ist ja nur indirekt für die Berechnungen verantwortlich, wie ihr schon geschrieben habt.
Es müssen immer für alle Sims neue Möglichkeiten berechnet werden. Und diese Rechenlast steigt natürlich mit der Anzahl der Verbindungen und der Anzahl der Sims immer weiter an. Würde man jetzt die Sims in Kontingente von meinetwegen 5000 einteilen (willkürlich festgelegt über die Karte verteilt), und jeden Monat nur ein Kontingent berechnen, gäbe es diese Ruckler nicht.
Man könnte auch festlegen, das wenn ein Sim sich eine neue Verbindung gesucht hat, er diese zwei Jahre lang nutzt.
Ebenso muß das maximal mögliche gleichzeitige Stadtwachstum stark begrenzt werden.
Ich habe auf meiner Karte ca. im Jahr 2080 die letzte nicht an den Verkehr angeschlossene Stadt an die Bahn angebunden. Diese ist dann zum Monatswechsel schlagartig auf die dreifache Größe gewachsen.
Was die Möglichkeiten der Umsetzung meiner Vorschläge angeht entzieht sich natürlich bei weitem meiner Kenntnisse.