Limiting the intercontinental milk trade (and other industrial musings)

[jamespetts]

On the Bridgewater-Brunel multi-player game, one balance issue that was predominant was the prevalence of a large, highly developed and extremely profitable inter-continental milk trade: a dairy on the Eastern island would happily demand milk from a cattle farm many hundreds of kilometres away on the Western island, and great shipping companies were built on the profit that this generated. The citizens of the Simuworld in the 18th and 19th centuries clearly had more interest in butter, yoghurt and cheese than fresh milk.

I have been working on trying to address this, both in the pakset and in the code. Firstly, in the pakset, I have stipulated what I hope are more realistic prices for milk transport based on the number of milk churns that could be transported in 19th century railway wagons and the amount of milk in each churn, extrapolated then to other forms of transport automatically. On the basis of my calculations, each "crate" of milk should be treated as being equivalent to 5 17 gallon (that is, 77l) churns. They have been renamed "churns (x5)". The price for transporting a single five-set of churns has been reduced by about half to reflect the actual amount of milk involved.

I looked briefly at the amount of milk actually being produced and consumed, but, on initial inspection, this appears to have been calibrated correctly, and I note that this calibration was undertaken after the Pak128.Britain-Ex 0.9.1 was released, being the pakset used on the current online game, so I have left this for the time being.

I have, however, introduced a new distance category (it may be remembered that the fare stages system introduced in 11.0 allowed different rates for goods carried over different distances), so that any milk transported over 160km (approx. 100 miles) will not generate any revenue. It will generate revenue for the first 160km of its journey, but not thereafter.

The next step was to alter the code. Firstly, I have corrected an issue that I believe originates in Standard, whereby the maximum industry distance was only respected on creating new chains, not extending existing chains. However, a single maximum distance for every type of industry in the game is really not very adequate, so I have introduced a new feature, allowing a new parameter, max_distance_to_consumer, to be set in every producing industry. This number, set in kilometres, will be an additional limitation on the distance that an industry can be built from its consumer (using the same radius limitation system as already exists in Standard and current and previous versions of Experimental, with the exception that the radius is now a proper circle rather than a square as it was before). The minimum of the general maximum distance and this special, per industry distance is taken. By default, the special distance is unlimited (65535).

I have so far added data for this new feature only to the cattle farms, stipulating 40km for early cattle farms, rising to 160km or 200km for later  cattle farms (built after the introduction of railways). These combined measures should ensure that the game is better balanced, and that Simucitizens get nice fresh milk in the morning from their local farm.

I should be interested in feedback on these concepts, especially from those who have played the online game, and also any thoughts as to the other industries for which the new max_distance_to_consumer parameter should be set, and how it might best be calibrated.

[Leartin]

Is this "max_distance_to_customer" you introduced dependant on experimental code, or could it be proposed for standard as well?

[jamespetts]

I think that it could be implemented in Standard fairly easily, with the exception that the distance would have to be in tiles rather than km.

[Aquin]

I should be interested in feedback on these concepts, especially from those who have played the online game, and also any thoughts as to the other industries for which the new max_distance_to_consumer parameter should be set, and how it might best be calibrated.

From a realism point of view should all cooled goods have a very limited range, as mobile refrigeration is a invetion of the late 1800's for ships (~1870) and trains (1851-1878 varying degrees of usability) and even later for trucks (~1925).
Prior to these dates milk, meat and fish shouldn't be transported for more than a days lenght, or come in a more durable form, like hard cheese, dried/salted meat/fish.

[jamespetts]

Splendid, thank you; I have added constraints for meat and fish, too.

[Sarlock]

Wonderful, this should go a long way to address that issue.

Fresh milk doesn't travel very far generally, even today, simply because it's just cheaper to get it from a local dairy than import it over long distances, even with modern refrigeration.

Many products should have this distance limitation applied, at least until the mid 1900's, to encourage local transport network options rather than reward the first batch of players handsomely for capturing those few precious long-distance bulk trade routes.  In the current server game, in the 1750's, it was the milk, wood and coal trade that brought in 90% of the revenues/profits for the largest companies.  This gave those players an edge that no subsequent player could possibly compete with.

There were very few short haul barge routes that players installed simply because it was far more profitable to connect long distance cross-map industries together.  If industry A and B are next door to each other and C and D are next door to each other on the other side of the map, and they are interlinked, it made far more sense to connect A to C and B to D than connect neighbours (A to B and C to D) together.

[jamespetts]

Interesting. Do you think that early bulk and other industries should be distance limited, too?

[Vladki]

This is very interesting topic. There was indeed a very long distance trade even in early times. Remember Marco Polo? Phoenicians? But this trade was mostly limited to durable exotic goods - spices, silk, wine, tea, gems... Only goods that could be sold with huge profit to offset the risks of long journey. In those times nobody would be willing to pay premium for bulk goods from far away if they had a chance to get them from closer source. Exception was if it really had some special quality - like welsh slate.

We do not simulate risks of long journeys - bad weather, pirates... Also AFAIK exotic goods are not common in paksets.

So i think all industries should start within some limited max distance from source. And when they reach some level of production or get upgraded, they may connect to some idle source that is further away.

Sent using recycled electrons.

[killwater]

I would say that it should rather be a time limit than distance limit as it will disregard the value of high speed transport - in reality it pays off to transport perishable goods with higher speed than for example coal and you can transport it for a longer distance then. With the system you propose it does not matter if you want to transport something with fast rail convoy or slow hose drawn cart. I consider it a huge drawback.
As for maximum distance between connected industries it is quite a good idea. If it is implemented do you still have to limit a distance that goods will travel?

[jamespetts]

Killwater: the system does not limit (and never has limited) the distance that goods travel, rather the distance over which industries may link to other industries. What has been introduced, and is already in the current release system, is a system whereby certain goods, including bulk goods, do not earn any more revenue over a certain distance.

A time limit could, in principle, be introduced for goods transport (using a similar system to the travel time tolerance for passengers), but not for the linking of factories in the first place, as there would be no reliable way of telling how long that a journey may take between two industries that have yet to be built, and it would be highly problematic if two linked industries could in reality never be connected because there was no way of getting the goods fast enough from one to the other to enable them to travel.

[killwater]

Killwater: the system does not limit (and never has limited) the distance that goods travel, rather the distance over which industries may link to other industries. What has been introduced, and is already in the current release system, is a system whereby certain goods, including bulk goods, do not earn any more revenue over a certain distance.

What I meant it should not limit revenue in regard to distance but rather to time as goods do not rot because they travelled too many km but because the expiry date run off.  In fact those goods should earn nothing at all. Anyway I would consider industry spacing limit balanced by max good type transport speed as good enough simplification that would deal with the problem of to high revenue. Company not sending goods if it takes to long to transport would be a nice feature too but I think the former one is more important.
As to address a general issue of goods revenue over long distances there should be a mechanism that limits amount of long range connections between industries to some ratio let's say for every long range connection there should be three short range ones or industry should prefer to send goods short range as transport cost is lower and retail price then could be lower or profit higher.

[Vladki]

I also think that time is the important value for perishable goods. I think that using (modified) time tolerance as for passengers would be simple enough and would work well. Perhaps some connections would be our of range at the beginning of the game but later would become feasible.

Reducing profit for long distance transport of durable goods does not make too much sense to me.

For industry placement... What is the formula? Is it just equal probability for any place up to some maximum? What about changing it to some sort of gaussian curve to get higher probability for close by industries and only exceptionally few long diatance links?

Sent using recycled electrons.

[jamespetts]

The idea of the revenue system was that people are not willing to pay any more for (e.g.) coal coming from 200 miles away than they are for coal coming from 100 miles away, because such extra transport distance does not add value.

[wlindley]

How does a factory decide how much of its production to deliver to its various customers? Surely a dairy would only agree to supply a few crates of cheese to a far-away customer, while selling tankersfull of milk to the local grocer. Or does the which-customer code choose customers based on expected factory income?

[killwater]

@jamespetts
But in this situation there will simply be no order for the long distance coal. Unless it is a different type of coal. Transport company should not subsidize companies it should charge based on the cost of transport not profit viability of the industry.   

[jamespetts]

A transport company might have a choice between transporting no coal and making no profit or transporting coal 200km for the 100km price and making a small profit because the only coal consumer connected to that particular transport company's network is far from its only coal producers. The coal customer will not care whether the coal is from nearby or far away so long as it is at the right price.

W. Lindley - this is based on the demand of each consumer industry if I recall correctly.

[prissi]

Given the simutrans scale, I would rather have the farms produce cheese; since with fields and all, the next diary would so close to a farm ...

[jamespetts]

A realistic scale is workable for Experimental, I think, where Pak128.Britain-Ex has 125m/tile.

[isidoro]

In my modest point of view, you are missing the point here.

I see two distinct problems:
1) That related to perishable goods with no adequate conservation transportation (e.g. milk with no refrigerated lorries).
2) That related to connections with far away industries when nearer ones exist.

Regarding 1), it's only a matter of transport time, not distance.  Some goods (perishable) can have a life time and a time counter.  If the storage and travel time is greater than the limit, no revenue for the transportation company.  Additionally, one can have two types of milk (normal milk and refrigerated milk) with different vehicles to transport it and different life times, to deal with the different use cases of this and perhaps other perishable goods and history.

Regarding 2), I see it as a demand-supply law problem.  If I am an industry that needs coal, in order to be viable, I have to pass my transportation costs to the customer.  If I'm alone, maybe I can do it by rising prices.  But if there is a neighbour company selling the same product but bringing the coal from a nearer source, that company will have lower costs, lower prices and I will sell no products.  But in both cases, it is not a problem of the transportation company.  The transportation company has to get paid for the costs it has (distance) as it is now.  Whatever other solution like the ones proposed in this thread seems artificial to me.

You can avoid long-range contracts because they are deemed economically unfeasible, but you have to pay the transportation company for what it does: transportation of certain goods certain distances.

[DrSuperGood]

Industries should not be able to make impossible links. If a link is offered it should always be viable and connecting all links should always be an option.

Further more spoilable goods should refuse to send (similar to how passengers refuse to make a journey) if the time is not reasonable for the distance needed to travel. Additionally perishable goods should "spoil" so require refunds similar to how passengers leave with a refund if they are left in a stop too long. If you keep to the expected journey time with a bit of room for error from source to destination then goods will not spoil on the way. Spoilage should only be a penalty for an inefficient or backlogged network similar to how passengers leaving with refunds does for passenger networks.

The range of connections between industries as well as expected transport times should change as time progresses. For example fresh fish might start with an expected landing time of less than 6 hours from the fishing site from the 1700. However when modern fishing ships are introduced the range is removed as the refrigeration means that they can be several hundred hours or more on a return journey.

This raises an interesting idea of "transport quality". Currently only passengers have this in the form of "Comfort" which is used to govern if they leave on a journey or not as well as the pay you receive. However this could also be applied to all goods with a similar purpose. An early fishing ship could offer low quality transport of fresh fish to a port which will suffice for all routes at the time of introduction. However when refrigeration fishing ships come in they offer a higher transport quality than old ships did and also fishing ports start to link with far away schools. Trying to use an old fishing ship on these new routes will not work as the goods will refuse to send due to insufficient quality of transport to make the journey. New fishing ships on the other hand can take advantage of these extended range routes thanks to the improved quality of transport they offer.

[Sarlock]

Industries should not be able to make impossible links. If a link is offered it should always be viable and connecting all links should always be an option.

Agreed.  This is best resolved at the industry level -- they shouldn't link to out of range industries.  If a link exists, it should be profitable -- otherwise it can lead to player confusion when routes fail to make a profit.

[Vladki]

I like drSuperGoods suggestions. That way you could distinguish between trasporting fish / meat /milk as fresh (hours), refrigerated (days), and deep frozen (months). As perishable goods should be considered also vegetables and fruit. And maybe newpapers. Who in the simuworld is interested in old news...? But there the quality of refrigeration does nor help

Sent using recycled electrons.

[zook2]

1) As for spoilt milk and similar effects, I'd really think first about how to communicate the effects to the player without a million popup windows or burying the information so deep that it gets missed. If you can't find a simple and clear way to do it, then don't bother.

2) Someone mentioned Marco Polo: off-map luxury good production would be an interesting feature. Didn't we discuss "map-edge cargo tranfer spots" or something similar at some point?

3) As for long-distance transport: I think nobody mentioned economies of scale yet, at least not in this thread. If a coal mine (or farm or factory...) has sufficient production levels and therefore low unit costs, it might be economic to ship the product halfway around the (game) world, while the cost advantage of your friendly mom-and-pop neighborhood mine lies only in low transport costs, i.e. the higher the relative production, the longer the distance an industry can link to a consumer.

[el_slapper]

2) Someone mentioned Marco Polo: off-map luxury good production would be an interesting feature. Didn't we discuss "map-edge cargo tranfer spots" or something similar at some point?

The problem is : Simutrans allows map extension. What happens to your off-map point, that suddenly moves? Or stays in the middle of the map? Makes no sense in both cases.

[wlindley]

Off-map Ports would have to be ocean or air connections. Extending a map with a seaport: the code would extend the connected body of water to new side of the map. Extending a map with an "off map" airport connection requires nothing additional.

[jamespetts]

Off map connexions ("portals" as I call them) are planned for the future (as, without them, long distance forms of transport are very limited in their use, especially aircraft and ships), but are some way down the list of priorities. We need the game to balance properly first.

[isidoro]

1) As for spoilt milk and similar effects, I'd really think first about how to communicate the effects to the player without a million popup windows or burying the information so deep that it gets missed. If you can't find a simple and clear way to do it, then don't bother.
[...]

Maybe a new colours for the money he gets each time a convoy arrives at a station: green (the player gets money), red (the player loses money), yellow/orange (the player gets less money than he should because of refunds/rotten goods).

[Sarlock]

I've thought about making a port "factory" that simulates the receipt of off-map goods that the player can then transport to secondary industries.  The player wouldn't have to worry about transporting these goods from off-map, they would just "appear" at the port.  They can then redistribute these goods via ship, rail or other methods.  Another port could operate the opposite direction -- providing demand for factory end products that are then "consumed" as they are shipped off map.

In this way, many of the "trade goods" can be simulated with using existing game mechanics.

[el_slapper]

I've thought about making a port "factory" that simulates the receipt of off-map goods that the player can then transport to secondary industries.  The player wouldn't have to worry about transporting these goods from off-map, they would just "appear" at the port.  They can then redistribute these goods via ship, rail or other methods.  Another port could operate the opposite direction -- providing demand for factory end products that are then "consumed" as they are shipped off map.

In this way, many of the "trade goods" can be simulated with using existing game mechanics.

Capitalism did work like that. it's very efficient, easy to do, etc... With one single drawback, pointed out before : you don't use long range vehicles to their full capacity.

[zook2]

Would a "portal" function simply as a port/airport, or would the vehicle actually disappear for a given time, and return loaded with exotic goods?

[jamespetts]

Would a "portal" function simply as a port/airport, or would the vehicle actually disappear for a given time, and return loaded with exotic goods?

Given that disappearing for a "given time" could, in terms of long distance sea voyages, mean being gone for many years (over 35 game years for a four month round trip voyage as might be the case for sailing ships on voyages to Australia), the disappearing option will not work. Instead, what will have to happen is that the vehicle disappears into a portal and waits for its loading time, loads and unloads, generates revenue, and exits the portal. There would have to be some adjustment to the figures, however, to compensate for it not having travelled the full distance: the revenue would be based on a notional distance to the destination in the portal, and the running costs would be debited to match. The revenue would be reduced to compensate for the fact that it can be earned much more quickly and with fewer vehicles, and the recorded journey time would be based on the time that it would have taken the journey to complete for the purposes of journey time tolerances.

[Matthew]

I've thought about making a port "factory" that simulates the receipt of off-map goods that the player can then transport to secondary industries.  The player wouldn't have to worry about transporting these goods from off-map, they would just "appear" at the port.  They can then redistribute these goods via ship, rail or other methods.  Another port could operate the opposite direction -- providing demand for factory end products that are then "consumed" as they are shipped off map.

In this way, many of the "trade goods" can be simulated with using existing game mechanics.

This is the same mechanic as the RT ports and the RT3 warehouses.

[jamespetts]

I should note that I have now implemented the range limit on a large number of other industries in the development (half-heights) branch on Github.

[killwater]

That is great. Do you have any even approximate idea when next version could be released? Or should I rather try again to compile myself which looks very complicated to be honest.

[jamespetts]

That is great. Do you have any even approximate idea when next version could be released? Or should I rather try again to compile myself which looks very complicated to be honest.

My current plan is to deal with a large number of the major projects before the next release of the code (and therefore the pakset that depends on the new code) so that the next release is balancable. This might take quite some time, and my powers of prediction unfortunately do not extend to calculating how long that it will take. As to compiling it yourself, it is somewhat complicated, albeit not insurmountably so; but beware that the town growth (and town generation) in the current development code is broken (and I have not fixed it because one of the large projects is to rebuild the system very substantially), so there may be difficulties in getting a good game with it at present.

[killwater]

What is the flaw of the grow code?

[jamespetts]

I haven't found it yet - there is currently no point in fixing the current growth code when the long-term plan is to replace it with something completely different and much better.