Ammler (in tt-forums) schrieb:The needed part to get it working with newgrfs is splitting base costs of terraforming and foundations. Those are bound together in openttd trunk.

[Um [höhere Kosten für Erdbewegungen] mittels newgrfs zu realisieren ist es nötig vorher die Kosten für Erdbewegungen und Trassenunterbau zu trennen. Beides ist nur gemeinsam in TTD/TTDPatch/OTTD (mittels "basecosts") zu verändern. (transl. mb)]

MMn ist dies nicht zwingend notwendig. Warum sollte der Trassenunterbau (Fundamente, Aufschüttungen, "buildonslopes") so viel billiger sein als Absenken oder Aufschütten eines Spielfeldes? Ausserdem fallen diese Kosten pro Feld nur einmal an, während grossflächige Erdbewegungen üblicherweise Kosten für viele Felder, und das durchaus auch mehrfach, verursachen.

MMn soll auch das Bauen von Strecken auf "slopes" an Hängen eine teure Sache sein und bleiben. Natürlich billiger als der Bau von Tunneln, aber eben auch teuer. Der Bau von realen Eisenbahnstrecken im Gebirge war und ist ein teures Vergnügen. Dies ins Spiel zu übertragen ist nicht nur "realistisch", sondern dient vor allem dem Spielvergnügen.

Wem das zu teuer oder zu anstrengend ist soll doch im Flachland spielen.

Gruß
Michael

(Weiss jetzt nicht genau, weshalb du das hierher verschoben hast, wäre ja wenn schon ein Thema zu den NewGRFs Specs, also in TTDPatch Graphics.)

Teuer ja, aber nicht gleich teuer wie Terraforming, bei wwottdgd haben wir z.B. einen patch benutzt der die Kosten für Gleise auf Fundamente 8 mal teurer gemacht hat als normale Gleise. Terraforming war etwa 32 mal teurer.

Edit. Nur theoretisch: wäre es denn technisch möglich eine weitere base cost einzuführen, z.B. "foundations"?

Edit2: eigentlich ist die ganze Diskussion um Kosten eh meistens ziemlich schnell sinnlos, da man ja nach ca. 10 Spieljahren es nicht mehr schafft das verdiente Geld zu investieren.

Grüsse
Ammler

(28.07.2009 12:02)Ammler schrieb:  (Weiss jetzt nicht genau, weshalb du das hierher verschoben hast, wäre ja wenn schon ein Thema zu den NewGRFs Specs, also in TTDPatch Graphics.)

Mir war so ... Das kann natürlich auch weiter verschoben werden. Ich glaube ich wollte dir helfen deine Aussage noch einmal zu überdenken bevor die rein technische Diskussion beginnt.

Zitat:Teuer ja, aber nicht gleich teuer wie Terraforming [...]

Wie gesagt. Bei "buildonslopes" fallen die Kosten ja nur für ein tile an, bei entsprechenden Erdbewegungen aber meistens gleich für mehrere tiles. Abgesehen davon sehe ich nicht ein warum der Bau von "slopes" zwingend billiger sein sollte als das (einfache) Abgraben/Aufschütten von Erde?

Zitat:Nur theoretisch: wäre es denn technisch möglich eine weitere base cost einzufügen, z.B. "foundations"?

Technisch ist alles möglich. Dazu müsste ein Programmentwickler mal den Aufwand abschätzen, auch für TTDPatch. Und zum anderen sollte man sich überlegen ob dieses Feature wirklich erforderlich ist. Was wären denn die weiteren Auswirkungen auf existierende .grfs, auf den Spielfluss, Vorlieben, etc?

Gruß
Michael

Hmm, ich gebe dir recht, Fundamente dürfen auch teuer sein, Wir hatten halt terraforming so teuer gemacht, dass man es wirklich nur noch benutzt wenn zwingend nötig ist. Das hat aber auch davon abgehalten. Bauwerke mit Fundamenten zu bauen, z.B. Brückenköpfe und so entstanden hässliche "workarounds".

Natürlich wäre meiner Meinung nach z.B. Fundamente ein zusätzlicher basecost der falls nicht vorhanden auf die existierende terraforming bezieht. Damit wäre die Kompatibilität gewährleistet.

NewGRFs haben nur Base costs zu verhändern, die auch das newgrf betreffen. Ist doch auch so? Das einzige newgrf, dass z.B. diese basecosts unabhängig verändern ist das von pikka. (Meins ist zu banal um zu erwähnen.)

Betreffend der Multisetfähigkeit von OpenTTD, habe ich auch eine Lösung dazu, leider bin ich da jedoch der einzige. Ich würde die "spezifiischen" basecosts einfach nur dem jeweiligen set vererben. Anderes set benutzt wieder default, oder was z.B. mit der override properity definiert ist.

Da stosse ich bei Belugas und petern leider auf taube Ohren.

Grüsse
Ammler

Ammler schrieb:[...] Wir hatten halt terraforming so teuer gemacht, dass man es wirklich nur noch benutzt wenn zwingend nötig ist.

Um eine spezielle Spielweise zu "erzwingen" ist dies mMn der falsche Weg.

Zitat:Das hat aber auch davon abgehalten. Bauwerke mit Fundamenten zu bauen, z.B. Brückenköpfe und so entstanden hässliche "workarounds".

Wenn nun nur noch die reinen Erdarbeiten extrem teuer gemacht werden dann werden den Leuten eben andere "workarounds" einfallen. Ich spreche aus eigener Erfahrung.

Zitat:NewGRFs haben nur Base costs zu verhändern, die auch das newgrf betreffen. Ist doch auch so? Das einzige newgrf, dass z.B. diese basecosts unabhängig verändern ist das von pikka. (Meins ist zu banal um zu erwähnen.)

Du meinst das *eigene* newgrf? Würde ich auch so sehen, aber basecosts sind global und bei gleichzeitiger Verwendung verschiedener .grfs wird es immer Probleme geben, egal wie die basecosts jetzt neu aufgeteilt werden.

Überhaupt glaube ich dass dies ein typisches Multiplayer-Scheinproblem ist. Bei der "kriminellen Energie" die es dort anscheinend zu verhindern gilt wird auch die Einführung neuer bascosts nicht zum gewünschten Ergebnis führen.

Gruß
Michael

Die ganze Kostensache ist doch sowieso nur für Multiplayer.

Im SP mode spielt ja wie gesagt Geld ziemlich schnell sowieso keine Rolle mehr. Mit den standard base costs muss man ja ziemlich doof sein, wenn man pleite geht. (oder Anfänger)

Also die Basecosts sind ein Paradebeispiel dafür, was für riesige Designprobleme man hat, wenn man globale Variablen und modularisierten Aufbau miteinander verbinden will.

Die Foundation- von den Terraformingkosten zu lösen halte ich für ein richtiges Ziel, aber eigentlich ist es nur das rumdoktorn an einem Symptom, wenn das ganze Konzept von Basecosts eigentlich ersetzt werden sollte (z.B. um einige Basecosts nur lokal im GRF zu verändern).

Die Kompatibilitätsprobleme von Fahrzeugsets etc. werden nicht von alleine verschwinden.


Globale Variablen sind einfach schlechtes Design, aber da bin ich auch nicht der erste, der das sagt.

Mal ne Frage
was sist MMn

MMn - Meiner Meinung nach

killermoehre

Eddi schrieb:Also die Basecosts sind ein Paradebeispiel dafür, was für riesige Designprobleme man hat, wenn man globale Variablen und modularisierten Aufbau miteinander verbinden will.

Richtig. Aber es ist auch klar dass sich dieses Problem erst stellt seitdem durch newgrfs diese "Modularisierung" eingeführt worden ist. In Original-TTD ist dieses Problem nicht-existent. Und als vor Jahren TTDPatch diese globalen Variablen eingeführt hatte, gab es lediglich marginale Probleme da TTDPatch eben nicht diesen "multipool" bug hat. In TTDPatch durfte jeder Fz-Set die Basiskosten sozusagen quasi-lokal verändern.

Eddi schrieb:Die Foundation- von den Terraformingkosten zu lösen halte ich für ein richtiges Ziel, aber eigentlich ist es nur das rumdoktorn an einem Symptom, wenn das ganze Konzept von Basecosts eigentlich ersetzt werden sollte (z.B. um einige Basecosts nur lokal im GRF zu verändern).

Wie soll denn die Veränderung der Basiskosten lokal in konkurrierenden newgrfs gelöst werden?

Trennung von "terraforming"- und "foundation"-Kosten halte ich übrigens nach wie vor für entbehrlich, es gäbe bessere Anwärter für eine Revision des Basiskostensystems.

Allerdings habe ich jetzt gelernt dass dies im Kern ein "Multiplayer-Problem" (also wieder ein exklusives OTTD-Problem) ist.

Gruß
Michael

Sorry, ich sehe überhaupt kein Problem, die Fahrzeug (multiengine pool) bezogenen base costs auf die jeweiligen sets zu begrenzen. Das einzige Argument, dass die devs petern und Belugas dazu gegen halten ist: BASE.

Wenn man weitere Kosten einführt, kann man diese doch als Option einführen, also nur aktiv, wenn auch definiert.

MB, du gibts mir doch recht, wenn man TTD mit Herausforderung spielen möchte ist das Preissystem vollkommen zerknorkst

Gruess
Ammler

Ammler schrieb:[...] MB, du gibts mir doch recht, wenn man TTD mit Herausforderung spielen möchte ist das Preissystem vollkommen zerknorkst

Da hast du völlig recht.

Deshalb ja auch die vielen Preis/Kostenänderungen in zu vielen newgrfs. :|

Eine komplette Überarbeitung der ökonomischen Grundlage dieses Spiels ist bereits seit Jahren überfällig. Was dies bisher verhindert hat ist mE der fehlende Konsens, besonders in Detailfragen.

Gruß
Michael

(29.07.2009 20:27)mb schrieb:  "multipool" bug

sorry, da muß ich dir widersprechen, das Problem tritt durchaus auch ohne "multipool" auf, z.b. wenn man ein LKW-, ein Bus- und ein Straßenbahnset lädt (bei denen damals die Modularisierung [theoretisch] erreicht wurde, indem die zur Verfügung stehenden Fahrzeug-IDs auf die Fahrzeugtypen aufgeteilt wurden). Das Problem ist eben nicht "multipool", was sowieso nur ein Minifeature zu einem tiefergründigen Aufräumprozess ist, sondern die "etablierten" Mißstände vor allem in der Denkweise der NewGRF-Autoren ["wenn ich ein Fahrzeugset programmiere, hab ich die alleinige Kontrolle über alle Fahrzeuge"], die jetzt inetwa so reagieren wie die Kirche auf den Buchdruck. Das ist aber ein anderes Thema.

Was das Preissystem eigentlich braucht ist eine progressive Kostenkomponente, damit 100 Züge zwar 100-fachen Umsatz, aber nicht gleichzeitig 100-fachen Gewinn erwirtschaften. Wenn einem die Verwaltungskosten über den Kopf wachsen, wird es dann echt schwer, 1000 Züge gewinnbringend zu betreiben, von weiterer Expansion ganz zu schweigen.

Alle anderen Kostenänderungen durch Basecosts ändern nämlich an der Komplexitätsklasse der Einkommensfunktion nix, alle Kosten sind immernoch linear. Das führt unweigerlich irgendwann dazu, daß man mehr verdient, als man in der gleichen Zeit ausgeben kann, oder es führt dazu, daß man nichtmal eine Strecke fertigstellen kann.

Auch die Terraformingkosten müssen schlußendlich eine nichtlineare Komponente bekommen, es sollte bezahlbar bleiben, einen einfachen Bahndamm aufzuschütten, um Straßen kreuzungsfrei überqueren zu können, eine Schlucht im Gebirge zu schlagen sollte recht teuer sein, und einen ganzen Berg zu plätten sollte astronomische Kosten verursachen.

(30.07.2009 01:06)Eddi schrieb:  Alle anderen Kostenänderungen durch Basecosts ändern nämlich an der Komplexitätsklasse der Einkommensfunktion nix, alle Kosten sind immernoch linear.

Dabei sind in der Realität die Kosten üblicherweise degressiv.

Die Anschaffungskosten bei Massenproduktion vielleicht, aber nicht die Verwaltungskosten...

Und die Kosten sollen ja auch spielbar sein, nicht realistisch, TTD ist kein Simulator.

Hmm, wurde glaub auch schon mehrfach gesagt, geschrieben, geschrien, gelacht, geweint, gebrüllt...

Ammler schrieb:Und die Kosten sollen ja auch spielbar sein, nicht realistisch, TTD ist kein Simulator.

Hmm, wurde glaub auch schon mehrfach gesagt, geschrieben, geschrien, gelacht, geweint, gebrüllt...

Was wurde "schon mehrfach gesagt, ..., gebrüllt"? Dass die Kosten spielbar sein müssen? Klar, selbst dieser thread war bis 17:36 schon ein halbes Jahr alt. In dieser Zeit kann schon einiges gebrüllt werden.

Oder meinst du dass die Kosten nicht "realistisch" sein sollten? Und dass das schon mehrfach gebrüllt wurde? Da stimme ich dir zu (dass es gebrüllt wurde). Nur bleibt immer im Dunkeln was da mit "realistisch" gemeint ist (bemerken wie ich dies Wort ständig in "" setze?). Im Prinzip ist nämlich überhaupt nichts "realistisch", noch nicht einmal in der physikalisch beschreibbaren Welt, geschweige denn im Finanzwesen. Da ist alles beliebig.


Ich schlage mal ganz offiziell vor den Begriff "realistisch" hier abzuschaffen, und stattdessen "vorbildgerecht" zu benutzen. Dann wird auch gleich ganz klar dass ein am Vorbild orientiertes Spieldesign per definitionem grössere Ausbauchancen besitzt als ein Spiel dass sich lediglich an der Maximierung von "fun" (hiess das so? ) orientiert.

Gruß
Michael

(27.01.2010 20:34)mb schrieb:  Ich schlage mal ganz offiziell vor den Begriff "realistisch" hier abzuschaffen, und stattdessen "vorbildgerecht" zu benutzen. Dann wird auch gleich ganz klar dass ein am Vorbild orientiertes Spieldesign per definitionem grössere Ausbauchancen besitzt als ein Spiel dass sich lediglich an der Maximierung von "fun" (hiess das so? ) orientiert.

Ich stimme dem Antrag zu! Vorbildgerecht ist ein "schönes" Wort; na ja schön vielleicht nicht, aber treffend.

Und in dem Rahmen finde ich eben, daß es nicht sehr vorbildgerecht ist, wenn ein kompletter Zug mit zwei Fahrten seine Anschaffungskosten verdient.

Im übrigen sinken natürlich auch die Verwaltungskosten bei steigenden Umsätzen, bessser gesagt bei steigender Beschäftigung, auf die verkaufte Einheit bezogen. Das Stichwort dazu heißt Fixkostendegression.

Ich bin mir nicht sicher, aber ich glaube ich hab das nicht nur einmal dargelegt, mir geht es weder um "realistisch" noch um "fun", sondern um die Spielbalance. Ein "Problem" derzeit ist, daß man unweigerlich irgendwann eine Grenze überschreitet, ab der man mehr verdient als man ausgeben kann. Das ist mit "Basecosts" und dergleichen nicht zu lösen, da dadurch allerhöchstens die Grenze verschoben wird. Deswegen braucht das Kostensystem eine progressive Komponente, damit auch bei 100 oder 1000 Zügen das Geld immernoch eine Rolle spielt.

Das einzige was derzeit progressiv ist, ist die Inflation (Kosten steigen 1% schneller als Einkünfte), aber was weniger exponentielles wäre vielleicht vorteilhaft.

Die Preise wird man aber auch nicht "Vorbildgerecht" machen können, sie sind doch nur "gradmesser" für MP Spiele oder Wettbewerbe, solange die Teilnehmer die selbe Einstellungen nutzen.

Vielleicht könnte man satt realistisch "relativ" verwenden, die Preise sollten zueinander in einem guten "relativen" Verhälthnis sein, sprich, Einkommen mit Bus, Zug oder Schiff, deshalb auch die BaseCosts pro NewGRF, das wurde glaub nun auch in OpenTTD umgesetzt, so richtig testen konnte ich das jedoch noch nicht.