Kostenberechnung im Spiel

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Ich probiere gerade eine kleine Anpassung der Kauf- und Betriebskostenberechnung des Spiels. Bevor ich da aber in eine möglicherweise falsche Richtung losrenne, würde ich gerne von jemand Kundigem ein paar Fragen beantwortet haben.


    1. Basiert diese Berechnung auf einem Skript irgendwo in den Spielverzeichnissen oder ist das tiefer drin im Programm?


    2. Wenn sie skriptbasiert ist: ist sie statisch und wird einmal zu Spielstart basierend auf dem, was in der .mdl steht, erledigt (wie so viele andere Dinge) oder ist sie dynamisch und findet jedes Mal statt, wenn man ein Fahrzeug im Depot angeboten bekommt?


    3. Gibt es eine Variable, in der das momentane Datum im Spiel abgelegt ist?


    Das Ziel ist für die Ankaufskosten eine Formel, die durchschnittlich Ähnliches wie die Vanillaformel ergibt - beim Erscheinen jedoch soll das Modell etwas teurer sein und bis zum Ende seiner Herstellung langsam immer billiger werden. Und für die Betriebskosten hätte ich gerne eine Formel, die nicht nur die bekannten drei Dinge (Gewicht, Geschwindigkeit, Kapazität) berücksichtigt - ein Faktor wie der Treibstoffverbrauch pro Stunde ist hier auch hochgradig relevant und wäre schnell in eine .mdl eingepflegt.


    Im Moment kann das Skript nur den Kaufpreis gleich dem in der .mdl hinzugefügten Treibstoffverbrauch pro Stunde setzen, aber wenn die drei obigen Fragen beantwortet sind, dann schreibt sich der Rest möglicherweise ziemlich schnell. Falls aber die Antwort auf Frage 2 ist, daß die Rechnung statisch ist, dann kann man die Zeit lieber anders investieren...

    A couple of thoughts here:

    1. You could take advantage here of the fact that most players will use the same map for days, if not months, at a time. You could make your calculations each time the game is loaded, and, at a minimum, players would see different values each real time day. Not a perfect solution by any means, but it would add a little variety.

    (Edit: I guess this would be dependent on the game date being available in the postRunFn. Not sure if it is...)


    2. The game now allows us to book financial transactions of types other than "other." You can, for instance, book a transaction and classify it as a vehicle purchase.

    At load time, you could modify the description field of vehicles in question to include a table of availability years and related prices. The published sticker price would not change, but presumably players who wanted to use the mod would understand to look in the description field to know what they were actually going to pay.

    When a vehicle was purchased, you would then generate an additional transaction for the difference between the price from the model file and the one you have calculated.

    If you wanted to get really fancy, you could take advantage of the fact that we can specify customized data blocks in the metadata. You could support an advanced pricing table, allowing mod authors to specify the availability blocks and related prices when they published their mod. You would then apply default calculated values only if the advanced pricing table was not specified by the author.

    Einmal editiert, zuletzt von doug ()

    Gefällt mir 2

    doug, thank You for Your thoughts.


    Ad 1.: True, having the prices recalculated each time the game is loaded would be sort of a workaround. It of course reaches a limit if a hardcore player runs the game for an entire day and never reloads in the meantime. This may cost him some money as the price reduction over the ingame years will never be implemented for lack of reloads. And, as You say, it does require finding a variable containing the ingame year. Up to now, I have found the ingame time only coded in animations for clocks, it does not come in a readily accessible format. The quest goes on.


    Ad 2.: Again true, this would take some modifications to the .mdl. I have already added a fuel consumption figure to a .mdl that will influence the operating costs and use this as a trigger for the mod as well: if it is missing, the game can calculate its numbers on its own, but if it´s there, it´s time for my mod to go to work. Other numbers will be added as warranted in the process of building the formulae: for diesel vehicles something like liters/100km and corresponding data for steam, electric or oat driven vehicles will be needed, as will be some maintenance factor: lower for basic technical levels, higher for sophisticated designs.


    Also, game balancing needs to be minded and can well be a killer for this attempt. Causing massive costs that can never be offset by income will render the mod unusable; making vehicles too cheap to run will kill the balance as well by resulting in much too high income. It´ll be probably best to make basic, outdated technology cheap to purchase but expensive to run, while high end technology may cost more to buy but will pay for itself over some years by its lower operational costs, and to adjust all this to the unchanged ticketing income.


    The mod is still in its very early stages and I cannot promise any success for now...

BlueBrixx