gistfile1.md

Preamble - can be skipped IMHO

There are many ways to play the game.

But the economy could be refined to be more fun.

The original game economy has travelled a long way with us.

• the original game economy
  • was balanced around 256x256 maps
  • didn't contain transfer networks

The basics of cargo payment, vehicle costs and other costs are well established.

The need to provide flexible gameplay (original style, sandbox model train, competitive server, GameScript story etc) is well established.

But there are a few common confusions / annoyances relating to the economy.

• complex transfer networks can lead to negative leg profit, which can feel like failure, but are not within the player's control given the network topology
  • player can turn off the news messages, but not the wall of angry red -£999 profit display in vehicle lists etc
• cdist pax networks are like playing Mini Metro or Dwarf Fortress
  • failure is inevitable, stations will eventually choke with 3k or 4k waiting pax
  • balancing newgrf vehicle run costs is very hard
    • in point-to-point, or a network with short travel times between any node, cargo will not be very aged, and the vehicle will get a relatively high leg payment
    • in a network with long travel times between nodes
      • cargo will be very aged on later legs, so the vehicle leg payment will be relatively small
      • vehicles at the start of the chain will have handled cargo which is much less aged, and will have received a relatively much higher payment for their leg; the vehicles near the end of the chain will have that high payment deducted from their leg
  • adjusting vehicle cargo aging rates does not lead to good gameplay outcomes with complex cdist networks
    • the established convention is to nerf some vehicles by using a very fast aging rate to get a difference to other more luxurious vehicles (adding a bonus to more luxurious vehicles won't show up on a lot of journeys as the travel time is not enough)
    • for some network topology, this can show up not on the nerfed vehicle, but on the next leg, where profits are much lower as cargo is already highly aged; this is logical and mathematically correct, but very hard for the player to intuit or diagnose, and tends to lead towards wrong conclusions about which legs to adjust
• IRL contains multiple types of pax vehicle with varying roles
  • e.g.
    • fast, high comfort
    • high capacity, low comfort
    • medium speed, medium comfort, etc.
  • vehicle newgrfs repeatedly try to replicate this, but the game will tend to the following optimum choice for complex cdist pax networks:
    • first choose highest capacity
      • then choose speed
        • then choose loading time
    • run costs will tend to be not very relevant unless set so high that the vehicle is effectively unusable
  • IRL the vehicles distinguish at high level by travel distance and how much ticket price can be charged
    • newgrf has no way to provide distinctions on this basis
    • there are some very nice other elements newgrf can affect like loading time, but they are local and marginal in their effect
  • in newgrf, it's very tricky to provide 'bonus' mechanics for vehicles like restaurant cars, observation cars or cruise ships, which could add depth and variety to the game
• some people would like a sandbox option for OpenTTD, without worrying about profit

These can be listed as separate concerns, but they are connected; solving each aspect in isolation will yield a fragmented result.

Proposals

Give newgrf more capability to modify vehicle profit, within the current economic model

• non-controversial: expose vehicle vars relating to distance and time, for example
  • time since last cargo unload/load
  • amount cargo has aged on this leg
  • tiles travelled since last station visit
  • these are examples only, generally it would be better to expose a range of these that are considered safe (e.g. performance, technical debt) and let newgrf authors worry about how to use them
• more controversial: expose additional penalty / bonus payments for vehicles, separate to income and running cost
  • use these to penalise e.g. long distance for uncomfortable vehicles
  • use these for a bonus, e.g. pax coaches earn more if there is a casino wagon in the train

Critique: none, this is an API, do safe extensions, then let mod authors figure out what to do with it

Hide vehicle profit, possibly in the context of a more complete sandbox mode

This isn't a complete concept, but a 'true sandbox' mode could be be highly beneficial.

One aspect of this would be to simply hide per-vehicle profits.

One way to test the value of this might be a lang hack to blank out all profit strings. Additionally turn off news warnings, and cheat a lot of money or hack command cost to make building free.

A divergent but related idea would be to consider each connected cargo graph as a profit center. So that the profitability is measured across all vehicles in that graph, not per vehicle. This is a realism approach that some e.g. city networks use, where profitability of each vehicle is meaningless. These networks look at how each connection contributes to overall ridership. This would not be a sandbox mode though.

Critique:

• this isn't very developed idea
• the hacks we could test with are just hacks
• a full sandbox mode probably has many unexpected edge cases and may cause unmanageable technical debt and QA fragmentation
• full sandbox mode might work very poorly with e.g. AIs

Decouple per-vehicle 'profit' from 'success'.

• Add satisfaction rating concept
• Apply satisfaction per vehicle
  • maybe as % - details can be done later
  • basic satisfaction calculation could be a decay model, similar to cargo aging - starts high, decreases with journey time
  • satisfaction decay period would be reset by cargo unload/load
  • vehicle current satisfaction value is statistical average of n recent journeys
  • this calculation would be exploitable by forced load/unload, possibly other methods - but discovering exploits is part of a game, it's how people work
• Also calculate average satisfaction per journey leg (cdist link in the linkgraph), by averaging across the vehicles in the link
• I don't think satisfaction would be tracked in cargo packets, but maybe I'm wrong
  • I don't see it as necessary, an equivalent value could be derived for any journey by taking a weighted average of the cargo legs involved
• Add newgrf methods for vehicles to work with satisfaction
  • Adjust default decay rate
  • Replace calculation entirely by providing a specific value, based on for e.g.
    • Arbitrary value author decides, like 'comfort level'
    • Reliability
    • Time since last service
    • Number of breakdowns
    • Current speed
    • Load factor (current cargo / capacity)
      • Crowded vehicles are more satisfying, or less? :)
    • Station rating of pickup / destination station
    • Have any vehicles in this shared order group crashed recently?
    • Vehicle age
    • Vehicle colour: red trains are better
  • Read current satisfaction value
• Replace min. vehicle profit in original high score with min. vehicle satisfaction
• Expose satisfaction to GS
  • per leg?
  • per vehicles using a station?
  • per vehicle?

Further extensions

• Expose vehicle satisfaction to station rating
  • Provide option to replace current station rating calculation
    • e.g use satisfaction instead of speed or vehicle age
• Expose possibility of deliberate feedback loop between vehicle satisfaction and station rating
  • Why? Dunno, might be interesting
• Expose average satisfaction values to the town company rating

Critique:

• 'satisfaction' is most relevant to pax and similar cargos, coal probably doesn't care much.
  • but that's fine
• does the UI have space to show satisfaction? It would need displayed in e.g. vehicle lists, vehicle info windows etc