AlphaCentauriBear wrote: 22 Jan 2024 13:56
In my mind "making shorter routes" is a better (more interesting) game than "making longer routes".
I would prefer if the game didn't focus solely on short or long connections. Neither of them reflects reality well. Moreover, in the case of short connections, as _dp_ writes, you would have to do more than just eliminate the effect of distance. Otherwise, the game, especially multiplayer, would be incredibly boring - everyone would only build short connections. An important change needed would be a significant reduction in the number of processing enterprises. Without this change, where there is almost always a processing company next to the mine, players would have no real incentive to made any longer and more complex lines. Another change that would be useful with this approach would be to limit the acceptance of goods by cities, so that the player does not use the simplest method to deliver an entire large production to one small city just because it is closest.
Personally, I see three other possibilities for how the game's economy could be made more sensible.
1. Make the player a producer (newGRF)
Nothing new, the previously mentioned Buy, Process, Sell and Caribbean Industries newGRF have such economy, but I think it's quite interesting. Since many players feel like industry owners in this game, let them pay for raw materials and make money on products. Here, just like in the case of the reverse distance effect, to make it more interesting and not for the player to deliver everything to one city, these could have a limited acceptance of deliveries proportional to the size of the city and the more products were delivered, the lower the prices would be.
2. Increase the importance of subsidies/contracts so that they become the main or most attractive form of earning money. (new features in game)
Then, as is the case in reality, the player will look for and want to pursue the most attractive offers that suit him. Currently, there are several problems with subsidies which make them unattractive:
A. They are very rare, usually 1-3 a year for the entire map - for it to make sense, there would have to be at least a dozen or several dozen offers; this should depend on the size of the map and the number of players.
B. They only apply to very short, unattractive connections - to avoid it being boring, the offers should also apply to much longer connections
C. There are no offers if cargodist is enabled.
D. Their default duration is very short. For subsidies/contracts to make sense as a basis for economics, their duration should be long or even unlimited.
E. For subsidies to make sense, basic transportation rates should be much lower to the point of being barely profitable.
F. Browsing through one long list of offers would be tedious - offers could appear directly in the city or enterprise window, which would make it easier for the player to observe offers in the area he is interested in. Additionally, a bell icon could be added, thanks to which the player could be informed about offers he may be interested in. It would also make sense to have a map icon that, like in the case of the cargo flow legend, would show subsidized connections on the gameplay or/and mini map.
3. Make that passengers, mail and other industrial cargo have a predetermined transport direction (upgrade for cargodist).
Currently, cargodist only distributes cargoes in different directions when there is a choice. A player who plays using this feature will always earn less than one who avoids it and builds isolated A-B connections. A player who knows the consequences of expanding the network usually doesn't do it or loses more or less motivation to build bigger things.
The change would mean that each city and each enterprise would designate the directions in which it expects transport, with the city or enterprise being the first to designate the direction, and only then a station from those that are available or "any" if there is none. Due to slow changes, the calculation of directions could take place quite rarely, every 2-3 months (4-6 minutes), which should not constitute a significant CPU load, especially if the calculations could be transferred to another thread.