Hallo

(05.06.2009, 10:16)Tuck schrieb: Da früher die Spielfläche nicht größer als 64x64 oder 128x128 war, ...

Bist du sicher, dass es so klein war? Mir war wie 256².

(05.06.2009, 10:16)Tuck schrieb: Heute suche ich mir auf den Riesenmaps ein Kraftwerk und ein Kohlebergwerk möglichst weit auseinander, schaffe eine Transportroute und es kann finanziell nichtmehr allzuviel schiefgehen.

... außer am Anfang des Spiels, da spielt das Geld, je nach den Einstellungen für den Maximalkredit sowie den Infrastruktur- und Anschaffungskosten für Fahrzeuge, sehr wohl eine Rolle. Aber das ist eine andere Baustelle.

(05.06.2009, 10:16)Tuck schrieb: Wie einige bereits erwähnt hatten, sollten bei dieser Erweiterung erstmal Schwerpunkte gesetzt werden.
Beziehen wir uns nur auf das optisch sichtbare Wetter und dessen Konsequenzen.
Dazu müsste erstmal geklärt werden, was das Spiel bereits bieten kann und was nicht.

...

Um hier mal meine Meinung kundzutun: Wetter mit seiner (auch zeitlich) kleinteiligen Struktur zu implementieren, halte ich für keine gute Idee. Das würde mMn zu zu viel Micromanagement (auch und gerade programmseitig) führen, auch wenn das nicht gewollt ist. Weiterhin gebe ich zu bedenken, dass bei der im Spiel implementierten natürlichen Spielgeschwindigkeit alle paar Sekunden Wetterwechsel stattfänden, was ich für eher hinderlich bis nervig hielte.

Aber: Wenn man das System etwas größer anlegt, nämlich auf Jahreszeiten, wie es mb ansprach, gefällt mir die Idee wieder. Für Frühjahr und Sommer fällt mir da auf Anhieb zwar nichts ein, aber im Herbst (regnerisch) könnte die Anfahrts- und Bremsgeschwindigkeit herabgesetzt werden, im Winter zusätzlich die Höchstgeschwindigkeit. Im tropischen Klima könnte man mit Regen- und Trockenzeiten arbeiten und zusätzlich, als Katastrophe, Sandstürme einarbeiten, die die Höchstgeschwindigkeit und die momentane Zuverlässigkeit rapide (sagen wir mal um 40%) herabsetzen.

Das Ganze in Kombination mit dem hier auch schon verlinkten Patch für ein anderes Pannenverhalten würde mir gefallen.

(05.06.2009, 10:16)Tuck schrieb: Und vielleicht sollte man dies gleich in openttd umsetzen, wenn es einfacher wäre. Aber da TTD zuerst rauskam, sollten dort entsprechende Erweiterungen auch zuerst rauskommen. ;P

Das (also "erst TTD") ist Quatsch. Wichtig ist dabei, wo das programmiertechnisch leichter zu implementieren ist, nicht, welches der Spiele die längere Geschichte hat. Ich vermute, dass unter dieser Prämisse OpenTTD vorne liegt.

(05.06.2009, 10:16)Tuck schrieb: Kann mir noch jemand beantworten, inwieweit sich ttd und openttd in der Programmierung unterscheiden. Wäre es ein großes Unterfangen dann etwas von TTD nach OTTD zu exportieren?

TTDPatch "enthält" das Originalspiel TTD, welches durch den Patch aufgebohrt wird (Bugs behoben, Features hinzugefügt). OpenTTD ist eine Neuentwicklung auf Basis von TTD. Das einfache Konvertieren dürfte somit recht kompliziert (und "uneinfach") werden, da sich der Code an vielen Stellen unterscheiden wird. Da zudem immer wieder betont wird, dass OpenTTD eine Reimplementation in C/C++ ist, vermute ich, dass TTD selbst (und der Patch? (habe dazu im manual auf Anhieb nichts gefunden; mb?)) in einer anderen Programmiersprache geschrieben ist. Das würde, so meine Vermutung zutrifft, eine Portierung in eine andere Sprache und somit erheblichen Aufwand erfordern.

Tschö, Auge