Exploiting the new overcrowding handling

[ivansanchez]

One of the new features of Simutrans-Experimental is this one:

Also, if passengers or goods (except for goods, such as coal, that do not care about how fast that they are transported) have been waiting more than a certain amount of time to board a convoy, they will leave the network entirely, never to return.

And that, my friends, can be exploited into making lots of revenue. Suppose the following scenario:

Producer ---- line 1 -----> Hub station ---- line 2 -----> Consumer

Now, assume that line 1 is very profitable (long distance, fast and big convoys), and line 2 is not (short distance, crappy convoys, bad placement of stations in urban environment).

With standard simutrans behaviour, the factory hub station would get overcrowded easily, and then the producer would stop making more goods, effectively crippling the money-making line 1.

With the experimental behaviour, line 1 earns money just by sending goods to the hub station... and letting them rot. As the station doesn't get overcrowded because goods rot, the producer keeps on producing stuff, thus not crippling line 1's ability to make loads of money.

The underlying problem, I think, is that the new "rotting" behaviour just destroys the ability of consumers to cap the amount of goods that can be transported. With standard simutrans, the maximum throughput of goods is equal to the capacity of either the producers or the consumers, whichever is lower. With experimental simutrans, the maximum throughput of goods is equal to the capacity of the producers. The consumers just don't matter anymore.

Now, I agree that rotting goods is nice and all, but when line 2 is composed of a single horse and carriage transporting 3 units of whatever every 6 months, things start to get stupid. Think of it: I can move thousands of tons of raw materials, and get paid for doing so, but the factory will see just ten tons per year or so. What factory owner in his/her mind would pay me for such a nonsense?

The aim of this feature was to avoid the overwhelming levels of overcrowding possible in Simutrans-Standard, and to provide the player with a realistic monetary incentive not to have stations overcrowded for any significant length of time.

Ha! Letting stations overcrowd lets me make more money than before!


I don't know about the best solution to this. Penalysing the player per unit of commodity rot? Making the producers make less of a commodity if some of it was left to rot the previous year? I'd like to hear ideas about this.

[jamespetts]

Ivan,

thank you for your analysis on this issue. There is, in fact, already a mechanism in Simutrans-Experimental to penalise the player for overcrowding: when packets of passengers are discarded, the number of "unhappy passengers" is incremented. The higher the ratio of unhappy to happy passengers in a station, the lower the income earned for all passenger transport from that station.

On reflection, however, that may not be adequate. It does not, for one, apply to goods. Probably the most balanced solution would be to ensure that the player does not get paid for transporting any cargo that is eventually discarded: in other words, to ensure that only goods that complete their journey earn revenue.

This would be fairly simple to implement were it not for the fact that it is possible for goods to be transported on their journey by more than one player. Suppose that player A operated the first leg of the journey in your scenario, and player B operated the second leg. There is a conceptual problem and a technical problem. The conceptual problem is this: should player A not get paid until player B transports the goods to their final destination (or not)? The technical problem is that ensuring that the player is only paid for the journey when it is complete is far harder when the cargo is transported by multiple players: at the end of the journey, how does the cargo remember how much money to give to each player? Storing that much information for every cargo packet would vastly inflate memory consumption and degrade performance.

The solution may be more subtle. For passengers, there is a journey time tolerance feature: they will not travel on any route if the overall journey time is above their individual tolerance level (which varies partly randomly and partly depending on their intended journey distance). Whenever packets are discarded at a station, the average waiting time for that route at that station is greatly increased (by twice the maximum wait tolerance of the passengers) to represent the fact that travelling through an overcrowded stop will likely involve an exceptionally long wait. That waiting time is added to the overall journey time, which, if it is greater than the passengers' individual tolerances, deters them from travelling entirely.

If perishable goods (that is, goods with a speed bonus rating of over 0%) similarly had journey time tolerances (not set randomly per unit, but a fixed level depending on their speed bonus ratings: the ratio could, perhaps, be set in simuconf.tab), then the same mechanism could work for goods, too. Non-perishable goods (with a 0% speed bonus rating) could be set not to be discarded at all.

Another way of looking at the issue is that, like passengers, who do not stand at the station for weeks on end and eventually die of starvation, but find their own way to their destination (by taxi or otherwise), goods that are discarded have not rotted or perished, but have simply been taken by some local private transport to their destination, at their supplier's cost. That would then justify the player being paid for the part of transportation completed by that player even if the subsequent leg was not successfully completed within a reasonable time.

I should be interested in others' views on this subject.

[ivansanchez]

Another way of looking at the issue is that, like passengers, who do not stand at the station for weeks on end and eventually die of starvation, but find their own way to their destination (by taxi or otherwise), goods that are discarded have not rotted or perished, but have simply been taken by some local private transport to their destination, at their supplier's cost.

Well, I see a problem with that: I set up a line which would let goods 4 tiles away from a consumer. And then I'd like to bang the consumer's manager office and shout: Hey, stupids! I'm able to ship goods 4 tiles away, just take care of 2 tiles of transportation for yourselves!

I don't like the idea of the consumer being able to ship private trucks to handle overcrowding goods. It'd be a patch to the problem, but the underlying issue of faulty economics would still be there.

I played railroad tycoon 3 some time ago, and I really liked how it managed supply and demand. You didn't ship goods from suppliers to consumers; there was an ether of supply and demand, and you shipped goods from where the ether was high in supply (near suppliers) to where the ether was high in demand (near consumers). It's really just a per-tile field of prices per commodity.

Now, if you plan to implement private goods handling, I say you do it well. Every supplier would be able to supply further than 3 tiles away, with a higher price. Every household should create a demand of food. Every industrial building should create a small demand of steel.

It's such a big change that I guess it won't be implemented anytime soon.

--

Anyway, there is the compromise option of "the consumer will assume private shipping of x% of its demand from the nearest station which has the needed commodity. Same goes for suppliers: they'd send a x% station which has a route to a consumer.

Now, this percentage should be weighted by distance (and other factors). And industries could ship automatically to other industries instead of to stations. So, nearby industries should be able to function automatically with no player transport network, far-away industries should be able to fulfill 1% of demand or so.

--

So, I've been thinking about the issue of overcrowded cargo warehouses. What happens in real life when cargo is left to wait for weeks and the transport networks just cannot move it?

First, warehouse management gets muddier. Finding the container in the warehouse takes longer. Herding the cattle in the pens takes more drovers. Just keeping the foodstuffs cooled wastes electricity. Overcrowded warehouses should impose a money penalty on the player who built the warehouse.

Then, they rot, perish, and (in the case of cattle) die of starvation. Now, drum roll, please. And then you have to clean it up. Perishing goods should impose a money penalty on the player who built the warehouse in which the goods have perished.

[jamespetts]

Ivan,

interesting thoughts. In terms of mechanics, how precisely do you envisage these monetary penalties working?

(The supply and demand ether in Railroad Tycoon is interesting, but so different from the way in which Simutrans works that it is unlikely ever to be implemented. Simutrans requires that goods and passengers have a specific destination in mind from their point of departure).

Edit: One further thought that might be the simplest way of addressing this is to have the player pay compensation for every discarded packet based on the distance (technically, only the as the crow flies distance is feasible) that the packet has travelled from its origin to its present location, based on a zero speed bonus rating, and multiplied by a certain amount specified in simuconf.tab. What I shall have to check in the code, as I now do not recall, is whether the ultimate origin is stored for goods packets, or only the last transfer.

[ivansanchez]

In terms of mechanics, how precisely do you envisage these monetary penalties working?

Well, I don't intend to do anything precisely. I'm just brainstorming possible solutions here :-)

Actually, I do think that a cost per commodity stored in any warehouse at the end of the month makes sense, and doesn't sound too difficult to implement. And you could do all things of wacky stuff like different costs per different warehouse buildings. Increased loading/unloading time also doesn't sound bad.

About the cost of letting stuff rot/perish, I do think it should be fixed per unit of commodity. You just pay the price of the stuff. I fail to see why this way shouldn't work.

However, if a commodity perishes near a consumer, you can assume some of it will reach the consumer by private means. This percentage should be based in the distance between the station and the consumer, the fact that the station and consumer are reachable by road, and if either of them are in a city, the city congestion. I can think of this as a very crude demand ether.

I know nothing about the internals of simutrans, so I cannot provide any exact formulas.

[neroden]

The solution may be more subtle. For passengers, there is a journey time tolerance feature: they will not travel on any route if the overall journey time is above their individual tolerance level (which varies partly randomly and partly depending on their intended journey distance). Whenever packets are discarded at a station, the average waiting time for that route at that station is greatly increased (by twice the maximum wait tolerance of the passengers) to represent the fact that travelling through an overcrowded stop will likely involve an exceptionally long wait. That waiting time is added to the overall journey time, which, if it is greater than the passengers' individual tolerances, deters them from travelling entirely.

If perishable goods (that is, goods with a speed bonus rating of over 0%) similarly had journey time tolerances (not set randomly per unit, but a fixed level depending on their speed bonus ratings: the ratio could, perhaps, be set in simuconf.tab), then the same mechanism could work for goods, too. Non-perishable goods (with a 0% speed bonus rating) could be set not to be discarded at all.

I like this -- it's elegant and makes everything work the 'same way'.  It's worth trying to see if it's sufficient to solve the problem.

But I think in a typical pak all goods should be considered perishable -- minimum speed bonus rating of, oh, 0.01%.  (Can speed bonus percentages be set in smaller increments than 1%?)  Even coal power plants offer a bonus for prompt shipping, and coal can get wet, suffer chemical alterations, or otherwise 'go bad' if you leave it for a really, really long time.