03-08-2007, Friday-21:03:00
Der Bonus ist natürlich sinnvoll, damit schnellere Transporte sich auch lohnen (wie Kasei darlegt). Es ist nur (m.M.n.) nicht so sinnvoll
1. mit der Zeit das ökonomische Gefüge zu verschieben (egal ob Inflation oder Deflation), weil der Spieler dann an Stellen nachbessern muss, die eigentlich noch gut funktionieren. Bei steigendem Passagieraufkommen (größere Netzabdeckung + Städtewachstum) muss man natürlich auch so die Kapazität anpassen, z.B. mit größeren oder schnelleren Fahrzeugen; wie beschrieben gibt es Fälle (Zeiträume), in denen sich die meisten Fahrzeuge nicht mehr lohnen, weil es ein besonders schnelles Gefährt gibt. Das ist ungünstig für die Vielfalt.
2. nur nach potentieller Höchstgeschwindigkeit zu berechnen (und eigentlich auch die Berechnung pro Fahrzeug auf der Route), statt nach tatsächlicher Geschwindigkeit Start-Ziel (und sei es mit Umwegen).
Edit: Es ist für die Realitätsnähe auch wünschenswert, dass eine minimale Verkürzung der Reisezeit z.B. durch ein besonders schnelles Flugzeug keine wesentlich Rolle spielt, weil Wartezeiten und Beschleunigungsabschnitte mit einberechnet werden, aber dafür muss man eben nach Reisezeitbeginn rechnen (bzw. die Geschwindigkeit entsprechend berechnen), und sei es von Halt zu Halt.
Eine Größenänderung bei ware_t ändert zunächst einmal definitiv den Hauptspeicherbedarf und auch die CPU-Cache-Nutzung. Die CPU-Last selbst ist vielleicht gar kein so großes Problem (egal ob der Inhalt umkopiert wird oder nicht).
Eine größerer Rechenaufwand sollte mit variabler Referenzgeschwindigkeit wirklich nicht entstehen, weil diese nur bei Einführung eines neuen Fahrzeugs (entsprechend mit Tabelle) neu ermittelt werden muss - globale Variable pro Wegetyp (Edit: und eine separate Bestimmung für Straba etc. ist auch möglich).
1. mit der Zeit das ökonomische Gefüge zu verschieben (egal ob Inflation oder Deflation), weil der Spieler dann an Stellen nachbessern muss, die eigentlich noch gut funktionieren. Bei steigendem Passagieraufkommen (größere Netzabdeckung + Städtewachstum) muss man natürlich auch so die Kapazität anpassen, z.B. mit größeren oder schnelleren Fahrzeugen; wie beschrieben gibt es Fälle (Zeiträume), in denen sich die meisten Fahrzeuge nicht mehr lohnen, weil es ein besonders schnelles Gefährt gibt. Das ist ungünstig für die Vielfalt.
2. nur nach potentieller Höchstgeschwindigkeit zu berechnen (und eigentlich auch die Berechnung pro Fahrzeug auf der Route), statt nach tatsächlicher Geschwindigkeit Start-Ziel (und sei es mit Umwegen).
Edit: Es ist für die Realitätsnähe auch wünschenswert, dass eine minimale Verkürzung der Reisezeit z.B. durch ein besonders schnelles Flugzeug keine wesentlich Rolle spielt, weil Wartezeiten und Beschleunigungsabschnitte mit einberechnet werden, aber dafür muss man eben nach Reisezeitbeginn rechnen (bzw. die Geschwindigkeit entsprechend berechnen), und sei es von Halt zu Halt.
Eine Größenänderung bei ware_t ändert zunächst einmal definitiv den Hauptspeicherbedarf und auch die CPU-Cache-Nutzung. Die CPU-Last selbst ist vielleicht gar kein so großes Problem (egal ob der Inhalt umkopiert wird oder nicht).
Eine größerer Rechenaufwand sollte mit variabler Referenzgeschwindigkeit wirklich nicht entstehen, weil diese nur bei Einführung eines neuen Fahrzeugs (entsprechend mit Tabelle) neu ermittelt werden muss - globale Variable pro Wegetyp (Edit: und eine separate Bestimmung für Straba etc. ist auch möglich).