Industries in towns: consumption proportionate to town size

[jamespetts]

I am considering implementing this feature in Experimental, but thought that it would benefit Standard, too; I can write a patch for Standard if the Standard developers are interested.

There would be some advantage, I think, to having the consumption of pure consumer industries (i.e., those which consume but do not produce) in towns made proportionate to the size of the town. What I envisage is quite simple: currently, industries have their consumption/production set randomly between the base production and the base production plus the range. For pure consumers in towns, I suggest that the randomisation be replaced with a linear proportion of the size of the town compared to the size of other towns, such that pure consumer industries in the largest town on the map would all have their production at base + range, pure consumers in the smallest town base + 0 and pure consumers in the average sized town base + (range / 2) (and so on in between).

It would make more sense to players, I think, for the amount consumed by towns to be proportionate to their size, and this mechanism would not disrupt any of the existing mechanics of the game, as the existing production ranges would be maintained, as would an even distribution in those ranges. I'd be interested in people's views.

[TheMachineguy]

Interesting. But would this affect the amount of workers going into that industry depending on town size?

[Dwachs]

Nice idea. Should not be too difficult to implement

[The Hood]

Sounds good.  The only thing I would add is that some consumers, esecially the smaller ones in pak128.Britain, should not keep on growing indefinitely, otherwise you could still have one small grocers serving a huge metropolis.  Maybe there could be a maximum value, after which another similar consumer springs up in the same city to take up some of the extra demand?

[Archon]

I like the idea.
I have been thinking about following system:

   Shops have minimum city population and consume base amount at minimum population.

   Linear consumption increase until base * 5 is reached.

   When consumption more than 2 * base there is change for new shop.

Base consumption could be defined for shops or goods. It would likely need some changes for new industry algorithm or allow suppliers increase production when demand increases (fields or/and something else?) . Also it might be good idea to remove industry connections.

Bottom line I think game deserves industry system overhaul.

[jamespetts]

The original idea was a rather simpler one than Archon suggested, which did not involve the shops' consumption rate changing with time, but rather being fixed at the time of creation. In Experimental, of course, industries close down eventually, or are upgraded to later types (at which point the consumption figures would be revised; but note that, if the consumption proportion is simply set as a proportion of the size of the town in question compared to other towns, then the proportion is not likely to change drastically over time unless some towns are served and some are not).

[TheUniqueTiger]

I would like to tweak a little bit... The idea is good and associates with real world as well. This also relates to the new industry chain creation with benchmark city growth. Introduce a config setting for the pop increase for triggering increase in consumption. (This should be less than increase in industry chain pop setting.) If we don't want to introduce a new setting, we can assume this value to be say 25% of "industry_increase_every" setting.

1. While increasing consumption or creating new industry, keep a record of the last city pop and the current city pop. Thus we can track the increase during the period.
2. When pop reaches this value, increase the consumption by proportional amount as the increase in pop (as we know from step 1).
3. If the consumption is out of range for the industry, increase consumption to maximum and create another same bonus industry chain with minimum consumption (as the existing one will have maximum production).
4. The original new industry creation on pop increase should not change. Rather if an additional chain is created in step 3, it should be treated as a 'bonus'.

[wlindley]

I like this very much.   

I also wonder -- at industry creation time, when creating the Consumer part, could the algorithm decide to (continue to) create Consumers (like shops) to create based on the sum of the consumption values?  So that when creating a furniture chain, after creating the factory, then it's possible one furniture shop (say) would be created in a large city, or else three might be created in small towns?

[prissi]

How should such a chain balanced? As much as I like dynamic games, Simutrans factory production should stay constant over time, so good chains can work without constant tweaking.

There is also a higher chance for more than one consumer in larger towns. Thus a larger consumption is already (albeit very indrect) incorporated.

[Zeno]

Maybe both ideas you have could work together: production increase could be achieved by allowing industries have "fields" (would require additional gfx, like factory extensions); on the other hand, a limit of 3 or 4 "fields" could be set to this industries, so after these 3 or 4 updates, a new consumer would be created keeping the balancing thing still working...

[jamespetts]

How should such a chain balanced? As much as I like dynamic games, Simutrans factory production should stay constant over time, so good chains can work without constant tweaking.

The original idea did not involve industries changing their consumption over time, so this would not be an issue.

There is also a higher chance for more than one consumer in larger towns. Thus a larger consumption is already (albeit very indrect) incorporated.

Given that the suggestion is very easy to code and, in its original form, would have no significant effects on overall balance, is it not worthwhile going a little further in this direction since doing it in the way that I originally suggested would probably make sense to most players?

[moblet]

How should such a chain balanced? As much as I like dynamic games, Simutrans factory production should stay constant over time, so good chains can work without constant tweaking.

Chains don't have to be perfectly balanced. In practice there needs to be enough supply capacity to meet all the demand, but it doesn't matter if there is spare production capacity provided production stops when downstream storages are fully stocked, as occurs in JIT mode. The player will have to add transport capacity as population grows to keep the chains balanced, which is perfectly realistic.

Consistent execution of a demand-driven or "pull" market system means that the decision of what raw material suppliers and factories to open would depend on the value of the capacity shortfall for each end product. By "capacity shortfall" I mean the difference between total map demand and total map capacity, regardless of actual production levels. If the map has a capacity shortfall of, say, $10 worth of furniture and $5 worth of cars, the next shop to open would be a furniture shop. Opening a new furniture shop means the sim would have to check whether the existing furniture factories have sufficient capacity to supply all the furniture shops on the map; if not, open a new furniture factory. Work back up through the chain to ensure there is enough supply throughout. This is economic theory at its simplest and would be straightforward to code.

I don't know how it would work trying to implement only part of a pull system in conjunction with the existing supply chain logic, but I suspect it could get very messy.

[jamespetts]

Moblet,

I like your idea of a demand based ("pull") model for determining industry growth. I was in any event planning to make some changes to the industry growth model for the next major version of Experimental, and am thus interested in your thoughts in this area.

For reference, the current code (from Standard) is as follows:

Code Select Expand


/* this function is called, whenever it is time for industry growth
* If there is still a pending consumer, it will first complete another chain for it
* If not, it will decide to either built a power station (if power is needed)
* or built a new consumer near the indicated position
* @return: number of factories built
*/
int fabrikbauer_t::increase_industry_density( karte_t *welt, bool tell_me )
{
int nr = 0;
fabrik_t *last_built_consumer = NULL;
int last_built_consumer_ware = 0;

// find last consumer
if(!welt->get_fab_list().empty()) {
slist_iterator_tpl<fabrik_t*> iter (welt->get_fab_list());
while(iter.next()) {
fabrik_t *fab = iter.get_current();
if(fab->get_besch()->get_produkte()==0) {
last_built_consumer = fab;
break;
}
}
// ok, found consumer
if(  last_built_consumer  ) {
for(  int i=0;  i < last_built_consumer->get_besch()->get_lieferanten();  i++  ) {
ware_besch_t const* const w = last_built_consumer->get_besch()->get_lieferant(i)->get_ware();
for(  uint32 j=0;  j<last_built_consumer->get_suppliers().get_count();  j++  ) {
fabrik_t *sup = fabrik_t::get_fab( welt, last_built_consumer->get_suppliers()[j] );
const fabrik_besch_t* const fb = sup->get_besch();
for (uint32 k = 0; k < fb->get_produkte(); k++) {
if (fb->get_produkt(k)->get_ware() == w) {
last_built_consumer_ware = i+1;
goto next_ware_check;
}
}
}
next_ware_check:
// ok, found something, text next
;
}
}
}

// first: do we have to continue unfinished buissness?
if(last_built_consumer  &&  last_built_consumer_ware < last_built_consumer->get_besch()->get_lieferanten()) {
int org_rotation = -1;
// rotate until we can save it, if one of the factory is non-rotateable ...
if(welt->cannot_save()  &&  !can_factory_tree_rotate(last_built_consumer->get_besch()) ) {
org_rotation = welt->get_einstellungen()->get_rotation();
for(  int i=0;  i<3  &&  welt->cannot_save();  i++  ) {
welt->rotate90();
}
assert( !welt->cannot_save() );
}

uint32 last_suppliers = last_built_consumer->get_suppliers().get_count();
do {
nr += baue_link_hierarchie( last_built_consumer, last_built_consumer->get_besch(), last_built_consumer_ware, welt->get_spieler(1) );
last_built_consumer_ware ++;
} while(  last_built_consumer_ware < last_built_consumer->get_besch()->get_lieferanten()  &&  last_built_consumer->get_suppliers().get_count()==last_suppliers  );

// must rotate back?
if(org_rotation>=0) {
for(  int i=0;  i<4  &&  welt->get_einstellungen()->get_rotation()!=org_rotation;  i++  ) {
welt->rotate90();
}
welt->update_map();
}

// only return, if successfull
if(  last_built_consumer->get_suppliers().get_count() > last_suppliers  ) {
DBG_MESSAGE( "fabrikbauer_t::increase_industry_density()", "added ware %i to factory %s", last_built_consumer_ware, last_built_consumer->get_name() );
// tell the player
if(tell_me) {
stadt_t *s = welt->suche_naechste_stadt( last_built_consumer->get_pos().get_2d() );
const char *stadt_name = s ? s->get_name() : "simcity";
char buf[256];
sprintf(buf, translator::translate("Factory chain extended\nfor %s near\n%s built with\n%i factories."), translator::translate(last_built_consumer->get_name()), stadt_name, nr );
welt->get_message()->add_message(buf, last_built_consumer->get_pos().get_2d(), message_t::industry, CITY_KI, last_built_consumer->get_besch()->get_haus()->get_tile(0)->get_hintergrund(0, 0, 0));
}
reliefkarte_t::get_karte()->calc_map();
return nr;
}
}

// ok, nothing to built, thus we must start new
last_built_consumer = NULL;
last_built_consumer_ware = 0;

// first decide, whether a new powerplant is needed or not
uint32 total_produktivity = 1;
uint32 electric_productivity = 0;

slist_iterator_tpl<fabrik_t*> iter (welt->get_fab_list());
while(iter.next()) {
fabrik_t * fab = iter.get_current();
if(fab->get_besch()->is_electricity_producer()) {
electric_productivity += fab->get_base_production();
}
else {
total_produktivity += fab->get_base_production();
}
}

// now decide producer of electricity or normal ...
sint32 promille = (electric_productivity*4000l)/total_produktivity;
int no_electric = promille > welt->get_einstellungen()->get_electric_promille();
DBG_MESSAGE( "fabrikbauer_t::increase_industry_density()", "production of electricity/total production is %i/%i (%i o/oo)", electric_productivity, total_produktivity, promille );

bool not_yet_too_desperate_to_ignore_climates = false;
while(  no_electric<2  ) {
for(int retrys=20;  retrys>0;  retrys--  ) {
const fabrik_besch_t *fab=get_random_consumer( no_electric==0, ALL_CLIMATES, welt->get_timeline_year_month() );
if(fab) {
const bool in_city = fab->get_platzierung() == fabrik_besch_t::Stadt;
if(in_city  &&  welt->get_staedte().get_count()==0) {
// we cannot built this factory here
continue;
}
koord   testpos = in_city ? welt->get_staedte().at_weight( simrand( welt->get_staedte().get_sum_weight() ) )->get_pos() : koord::koord_random(welt->get_groesse_x(),welt->get_groesse_y());
koord3d pos =  welt->lookup_kartenboden( testpos )->get_pos();
int     rotation=simrand(fab->get_haus()->get_all_layouts()-1);
if(!in_city) {
pos = finde_zufallsbauplatz(welt, pos, 20, fab->get_haus()->get_groesse(rotation),fab->get_platzierung()==fabrik_besch_t::Wasser,fab->get_haus(),not_yet_too_desperate_to_ignore_climates);
}
if(welt->lookup(pos)) {
// Platz gefunden ...
nr += baue_hierarchie(NULL, fab, rotation, &pos, welt->get_spieler(1), 1 );
if(nr>0) {
fabrik_t *our_fab = fabrik_t::get_fab( welt, pos.get_2d() );
if(in_city) {
last_built_consumer = our_fab;
last_built_consumer_ware = 1;
}
reliefkarte_t::get_karte()->calc_map_groesse();
// tell the player
if(tell_me) {
stadt_t *s = welt->suche_naechste_stadt( pos.get_2d() );
const char *stadt_name = s ? s->get_name() : "simcity";
char buf[256];
sprintf(buf, translator::translate("New factory chain\nfor %s near\n%s built with\n%i factories."), translator::translate(our_fab->get_name()), stadt_name, nr );
welt->get_message()->add_message(buf, pos.get_2d(), message_t::industry, CITY_KI, our_fab->get_besch()->get_haus()->get_tile(0)->get_hintergrund(0, 0, 0));
}
return nr;
}
}
else if(  retrys==1  &&  not_yet_too_desperate_to_ignore_climates  ) {
// from now one, we will ignore climates to avoid broken chains
not_yet_too_desperate_to_ignore_climates = true;
retrys = 20;
}
}
}
// if electricity not sucess => try next
no_electric ++;
}

// we should not reach here, because that means neither land nor city industries exist ...
dbg->warning( "fabrikbauer_t::increase_industry_density()", "No suitable city industry found => pak missing something?" );
return 0;
}


Do you have any thoughts for dealing with, for example, how to keep things in balance (within reason: not necessarily, as you point out, exact equilibrium between supply and demand) in the light of factories closing down or being upgraded?

[moblet]

Do you have any thoughts for dealing with, for example, how to keep things in balance (within reason: not necessarily, as you point out, exact equilibrium between supply and demand) in the light of factories closing down or being upgraded?

For starters these are complexities that only apply to timeline play, and could be switched off otherwise.
Closing down
Under the pull model the only reason an industry would shrink is the same as the only reason it would grow - change in consumer demand. Extending the pull model to cater for declining industries could look something like this:
1. Have demand for the end-product cease or decline after some specified date
2. Once, say, map-wide supply exceeded demand by more than one shop's throughput, close a shop. Then run the same test back up through the supply chain - test whether a supplier can be closed down and still leave enough capacity to meet demand. Obviously if demand fell from 100% to zero overnight all links in the supply chain producing only that product would disappear overnight, while some proportion of the diversified producers might also go. The remaining diversified producers might need to have their production parameters changed at the moment that demand for one of their products evaporates. If demand is going to disappear from diversified producers it may be really messy to sort out.
Even the simplest implementation of this looks to be more computationally expensive than the growth algorithm. The simplest implementation would include having demand-per-consumer suddenly commence at a particular time and then suddenly cease at some later time, which is two parameters per end product. Tapering demand at the death is an option if one wants to get mired in complexity and increase player micromanagement load.
Upgrading
If a particular link in the chain suddenly becomes more productive, I see two options:
1. Ignore it and wait for population growth to absorb the excess capacity, or
2. Test to see if factories can be shut down, and shut them down. Of course replacement factories may well spring back up in future.
Of course if the closing down algorithm is running unfettered it will automatically implement option 2.
Option 1 would have a problem under the simple pull algorithm - if, say, sawmills doubled in productivity but product demand remained constant, the simple pull algorithm would observe the doubling of sawmill capacity and respond by doubling the number of plantations. Two possible solutions I can see are to use a more complex consumer demand calculation instead of the simple comparison against customer capacity (i.e. calculate the required number of plantantions from the consumer demand for wood products, which could become very messy if productivities were changing and products were coming and going over the timeline), or to increase the productivity of every link in the chain in proportion so the relative capacities remain unchanged.
Summary
Both of these features have the potential to introduce unworkable complexities so I suggest some serious thinking about how essential they are and, if they are essential, how to minimise the complexity of implementation. E.g. compromises might need to be made in the area of diversified producers. A mere pull model on its own, like and especially in conjunction with JIT, can introduce enough dynamical complexity to keep a player very busy, and I'd be inclined to first implement and test pull without these features and seeing if extra complexity is warranted in gameplay.

For realism and to avoid driving the player insane new factories should be founded near either suppliers with excess capacity, or customers with unmet demand. If closures are not to occur on a "whole chain disappears overnight" basis they will require careful thought on this aspect, and probably a lot more complexity.

[jamespetts]

Hmm, interesting.

My original thought was to implement something rather simpler (and note that there is no system in Simutrans, either Standard or Experimental, for simulating demand for the end-products of consumer-only industries: they simply consume what their .dat files tell them that they should consume, and this is static once they are built), and along these lines: at the end of every month, there would be a check to see which consumers had unmet demands. There would then be an attempt to match unmet demands with unmet supplies by linking consumers with inadequate supplies to producers with outputs not fully consumed. In the case of consumers with unmet demands with no existing industry able to fulfil them, the idea was that, whenever the industry density increased, the next industry/ies to be built would seek to match those unmet demands (and not just, as now, for consumers that have no supply at all of a particular product, but also for consumers that have some supply of a product, but less than demanded).

[Fabio]

I'm a PAX guy, so I would relate the consumer-only industries' consumption to the number of PAX travelling to its building.

[colonyan]

If this have made into either experimental or vanilla simutrans, it is one dream come true.
For person like me without coding abilities can only wait for this kind of bliss to arrive.

[moblet]

My original thought was to implement something rather simpler...along these lines: at the end of every month, there would be a check to see which consumers had unmet demands. There would then be an attempt to match unmet demands with unmet supplies by linking consumers with inadequate supplies to producers with outputs not fully consumed. In the case of consumers with unmet demands with no existing industry able to fulfil them, the idea was that, whenever the industry density increased, the next industry/ies to be built would seek to match those unmet demands (and not just, as now, for consumers that have no supply at all of a particular product, but also for consumers that have some supply of a product, but less than demanded).

This didn't sound simple at all. Can you explain it again, and define what you mean by "unmet demands"? I'm not sure if you're referring to "actual supply vs demand" or "capacity to supply vs demand". If it's the former one has to be careful about having the sim compensate for the player's failure to achieve 100% delivery, as short-term imbalances will always exist and the player should be working to address them. It would not be nice to have the sim change its behaviour because it detected an imbalance in the previous month; the most likely outcome of that approach is to complicate and undermine the player's efforts to restore balance.

I'm a PAX guy, so I would relate the consumer-only industries' consumption to the number of PAX travelling to its building.

I haven't played all the transport sims, but Railroad Tycoon 3 has a pull model with new industries appearing over time (no old ones disappear, although individual factories not owned by the player can vanish if unprofitable). Every individual house has a (tiny) demand for a range of products, according to its size, which is just like what fabio's suggesting. The demand for goods for a residential building ought to be directly proportional to the number of pax it generates. The question in my mind here is not whether this is an elegant arrangement, there's no doubt about that, but whether it would be too computationally expensive in practice. RRT3 has only a small fraction of the number of buildings that Simutrans has. If it was too computationally expensive then town population would be the obvious fallback, and given how computationally cheap this would be, and that it would probably serve just as well in practice since goods are delivered to shops rather than individual homes, I'd be inclined to first try designing around calculating demand at town level rather than drilling down to building level.

There's another pull approach I just thought of too - shops only open if there is a catchment area containing sufficient demand. I don't know if this would add anything in exchange for its complexity, though.

[sdog]

Railroad Tycoon had static population, and limited number of buildings to reflect cities and towns. Both also had arbitrarily different demands for different products.

City population would be a much more direct approach, also much more sensible. Just define how much greens or print is required per 1000 population. Spawn outlets as the demand in a city is larger than that.

Uncertain of  understanding Fabio correctly, i think he wants to base the consumption of end user goods in a factory on the passengers transported too (or from) it. This is i think not a good idea, first it does seem a bit far fetched, the outlet is already in the town, and in walk range. ST doesn't cover the small scale distribution, to any corner shop.

Second it seems to be quite complicated to couple pax transport percentage to consumption. Pax are handled quite differently. Bridging those two concepts doesn't seem trivial.

[jamespetts]

Colonyan,

which one of the various ideas suggested here do you consider bliss?

Moblet,

apologies for being unclear. What I meant by "unmet demands" was industries which demanded goods at a higher level than the capacity of the industry/ies connected to supply it. So, for example, if consumer C1 has a demand for goods G1 and G2 of 50 and 100, and C1 was linked to producer P1 which produces 25 G1, P2 which produces 25 G1 and P3 which produces 50 G2, then C1 has an unmet demand of G2. C1 would then search for any other producer that produces G2 that has spare production capacity in the sense that it is not linked to (in the sense of having contracts with, not necessarily having transport links to) enough industries to consume all of its capacity. So, for example, P4 might produce 500 G2, and be linked to C2, C3, C4 and C5 which each consume 100 G2. P4 would then have a spare production capacity of G1 of the value of 100, so it would be a candidate to be linked with C1.

[colonyan]

jamespetts,

its that you've showed interest in doing this extension is the bliss, not other extension request is.
I've been waiting this. I don't mind waiting more. This will be some fundamental change.

[moblet]

So, for example, if consumer C1 has a demand for goods G1 and G2 of 50 and 100, and C1 was linked to producer P1 which produces 25 G1, P2 which produces 25 G1 and P3 which produces 50 G2, then C1 has an unmet demand of G2. C1 would then search for any other producer that produces G2 that has spare production capacity in the sense that it is not linked to (in the sense of having contracts with, not necessarily having transport links to) enough industries to consume all of its capacity. So, for example, P4 might produce 500 G2, and be linked to C2, C3, C4 and C5 which each consume 100 G2. P4 would then have a spare production capacity of G1 of the value of 100, so it would be a candidate to be linked with C1.

You've just described, in a roundabout way for a specific case, exactly the pull algorithm I proposed. The definition of spare or excess capacity is the amount by which actual demand on the producer is lower than its production capacity.

At risk of going off-topic, the current contract system seems to me to be in no-man's land, and I feel like it needs to be either enhanced or (perhaps preferably) abandoned. The bases of my discomfort are:
1. As a player I can't see what the contracted quantities are (or if I can, I haven't figured out how to see them)
2. It's not unrealistic to have this kind of contracting, but the only reason why it's necessary in the real world is because the products from different suppliers are not the same. In the real world a steel mill sources coal and iron ore from a range of suppliers, because each supplier's product has particular physical and chemical properties and of course price, and blends them according to production requirements. (The desired blend may not be constant, but let's not go there.) The contract system simulates this, but the reason behind it is invisible to the player, because every supplier of the same type appears to the player to be producing exactly the same thing, i.e. bog standard "oil", "coal", "iron", "logs", etc. As a player I feel like I'm dragging the same product across the map from A to B and from B to A for no valid reason. I don't see that the contracting system is necessary to produce a rich game, and would review it as a potentially unnecessary complexity, but if it has to be there then for realism the differentiation of products should be made visible to the player. This of course only makes it more complex, adding more weight to the case for its removal.

Railroad Tycoon had static population, and limited number of buildings to reflect cities and towns.

I haven't seen the earlier versions, but RRT3 has growth in town density and hence population size and demand. Growth is not on the scale of Simutrans though, so comparatively speaking it is insignificant.

[jamespetts]

You've just described, in a roundabout way for a specific case, exactly the pull algorithm I proposed. The definition of spare or excess capacity is the amount by which actual demand on the producer is lower than its production capacity.

Ahh - I thought that what you had proposed was different (declining demands after particular dates, etc.). The system that I proposed would not change the current system in which the demand and production of industries is static throughout their lives, with the exception of the production/consumption boost brought about by supplying them with electricity.

At risk of going off-topic, the current contract system seems to me to be in no-man's land, and I feel like it needs to be either enhanced or (perhaps preferably) abandoned. The bases of my discomfort are:
1. As a player I can't see what the contracted quantities are (or if I can, I haven't figured out how to see them)
2. It's not unrealistic to have this kind of contracting, but the only reason why it's necessary in the real world is because the products from different suppliers are not the same. In the real world a steel mill sources coal and iron ore from a range of suppliers, because each supplier's product has particular physical and chemical properties and of course price, and blends them according to production requirements. (The desired blend may not be constant, but let's not go there.) The contract system simulates this, but the reason behind it is invisible to the player, because every supplier of the same type appears to the player to be producing exactly the same thing, i.e. bog standard "oil", "coal", "iron", "logs", etc. As a player I feel like I'm dragging the same product across the map from A to B and from B to A for no valid reason. I don't see that the contracting system is necessary to produce a rich game, and would review it as a potentially unnecessary complexity, but if it has to be there then for realism the differentiation of products should be made visible to the player. This of course only makes it more complex, adding more weight to the case for its removal.

Removing the contracting model would be a significantly regressive step for Simutrans: as I understand it, the reason for the contracting model in the first place is to simulate the reality that it is the people who run the industries, not the people who run the transport companies, who decides from which source that raw  materials are purchased. In reality, the owner of a textile mill doesn't say "I'll pay for any and all cotton that a transport company dumps in a station within a 100 meter radius of the factory, unless we have too much this month already". The owner of a textile mill makes an arrangement with a particular supplier. This was intended, from what I understand, to be an enhancement on Railroad Tycoon in which people could transport anything anywhere (both passengers and goods).

As to the differences being transparent to a player: that is not necessary. The differences in passengers are not, after all, transparent to a player (the dialogue box says "3 passengers waiting" not "Mrs. Jones going shopping into town, Mr. Smith going to work at the factory and little Emily going to school"), but they are transported to different destinations. Simutrans simulates the transport, after all, not the inner workings of industry. There might be all manner of reasons why a steel mill would choose to buy its coal from collieries A and B but not C, D, E and F (price, quality, the steel mill's owner is pals with the colliery's owner, etc.), and it seems to me quite plausible to assume that there would in reality be such good reasons without having to simulate those reasons specifically, just like it makes sense to assume that there are good reasons why passengers want to go to different destinations without specifically simulating those reasons.