Refinements to passenger generation

[jamespetts]

Over the years since the current passenger generation system has been developed, various considerations have been given to refining it to deal with the tendency that passengers have to take very long trips to get to very minor destinations (e.g. travelling 10 hours to get to a fish and chip shop). Another issue is that visiting passenger success rates are not affected by whether local consumer industries are well stocked, since passengers can simply visit other local amenities instead.
The solutions that I have devised to this are as follows.
Maximum journey time tolerance rating for buildings
Passengers which generate with a high journey time tolerance can be inferred to be making the sort of journey that they would be prepared to travel a long time to take. Certain building types (e.g. fish and chip shops) do not in general warrant that sort of journey. Therefore, it would be sensible for building types optionally to be able to specify a maximum journey time tolerance. If passengers pick such a building and have a higher journey time tolerance than the rating, then they will not attempt to travel to this building and will instead search for another destination.

One complexity is whether to reset the alternative destination counter so as not to count these attempts. Not doing so may well result in passengers making significantly fewer attempts to travel, thereby affecting the carefully calibrated passenger generation figures. However, doing so might result in infinite loops were insufficient buildings are available. I am provisionally minded to opt for the former on the basis that, providing that there are enough buildings without a maximum journey time tolerance and enough with reasonably high escape chances, the longer distance passenger should travel often enough (and passengers with longer journey time tolerances have inherently more options in any event).

This should simulate the fact that only places with important buildings will attract passengers from far away, and alter the nature of traffic going to certain places as compared with others in a way that more accurately simulates reality than now.

To simulate the fact that, very occasionally, there is some exceptional reason for passengers to travel a long way to apparently unimportant buildings (perhaps somebody is meeting an old friend at the fish and chip shop who lives nearby, or is negotiating with the owner a contract for the supply of fish), one might have for each building an escape probability, that is, a probability that the journey time tolerance maximum will not apply.

Some visiting passengers require consumer industries
At present, all visiting passengers choose at random from a list of all buildings with visitor demand. This does not simulate passengers' need to journey to shops to buy things. Therefore, a proportion of passengers will need to be generated bound only for consumer industries. A separate list of consumer industry destinations will need to be created for the purpose. The proportion will need to be able to be set in simuconf.tab.

This should ensure that it is necessary for players to supply local industry chains for passenger success rates - which will in the future determine town growth - to be high.

[Vladki]

Maximum journey time tolerance rating for buildings

I recall that something similar was already discussed. I proposed that this could be somewhat dynamic, based on how many instances of the same building are present in the current game. If there is only one fish & chips shop in the world, then it would warrant a long journey, but if they spawn in every town, then they would not. Perhaps this should apply only to factories and attractions, but not to city buildings (res/com/ind).

Some visiting passengers require consumer industries

I remember proposing to split visitor trips further to "shopping" and "lesiure". Shopping trip destination would be only COM/IND and factories, and would count as visitors/customers. The rest (RES, attractions) would be leisure trips. The difference would be that shopping should have frequency and time tolerance closer to commuting, while true leisure trips have lower frequency and higher time tolerance.

[freddyhayward]

I remember proposing to split visitor trips further to "shopping" and "lesiure". Shopping trip destination would be only COM/IND and factories, and would count as visitors/customers. The rest (RES, attractions) would be leisure trips. The difference would be that shopping should have frequency and time tolerance closer to commuting, while true leisure trips have lower frequency and higher time tolerance.

I agree. Excluding commercial city buildings from shopping/consumer trips would be fatal to balance.

[jamespetts]

I recall that something similar was already discussed. I proposed that this could be somewhat dynamic, based on how many instances of the same building are present in the current game. If there is only one fish & chips shop in the world, then it would warrant a long journey, but if they spawn in every town, then they would not.

I do not think that having this based on the number of a type of building in the world is workable, for the reasons given at the time.

Perhaps this should apply only to factories and attractions, but not to city buildings (res/com/ind).

The idea is that it apply to all types of building with a visitor demand.

I remember proposing to split visitor trips further to "shopping" and "leisure". Shopping trip destination would be only COM/IND and factories, and would count as visitors/customers. The rest (RES, attractions) would be leisure trips. The difference would be that shopping should have frequency and time tolerance closer to commuting, while true leisure trips have lower frequency and higher time tolerance.

The difference between this and previous suggestions is that this version makes the consumer industries a subset of the total visiting destinations pool rather than having them entirely separate: in other words, a visiting passenger which is not a consumer industry only passenger might still go to a consumer industry, but a consumer industry only passenger will not go to anything else.

I agree. Excluding commercial city buildings from shopping/consumer trips would be fatal to balance.

This is not, I believe, what Vladki meant, and in any event, is not the aim of the system of requiring a certain proportion of passengers to visit consumer industries, viz. that those passengers need to be visiting buildings that they can only successfully visit if kept supplied with a stock of goods by players. There is otherwise no need to separate trip types at all.

[[C] Ranran]

There is otherwise no need to separate trip types at all.

The current city growth system is obsessed with industry, placing a great deal of emphasis on the balance between work and residents, and prioritizing the construction of IND buildings.
I hope future growth system changes will improve this, but the new distinction may contribute to improving this.
Separating leisure and shopping could separate the growth factors of COM / IND and could enable the new urban growth system to simulate more realistic growth. For example, simulate the creation of a commercial district and the development of a commercial district. And if there is a distinction, it can be displayed in the GUI to promote the player's understanding.
Also, in the real world, those trips tend to differ greatly in usage class and travel time.
By distinguishing between travel and destination, we can reduce the number of destination search attempts.

[Matthew]

To begin with, I would like to make a point of order/procedure.

These are two separate features. I cannot see that they stand or fall together. Would it not be better to split the discussion into two separate threads?

On the substantive proposals, my main concern is the implications for memory bandwidth, which is the game's principal bottleneck. I know that it is good practice to design the feature before thinking about data structures, but the OP already discusses data structures:

A separate list of consumer industry destinations will need to be created for the purpose.

I oppose this if this is a single list that is too large to be cached. If so, won't it just replicate the memory bandwidth problems with the current passenger generation algorithm, which is the most CPU-intensive part of the game? It would be sensible to estimate the effects on memory bandwidth before commencing coding. Maybe I am ignorant and it's not a problem at all; I would be happy to be proved wrong!

I have long wondered whether the current passenger generation algorithm could be made more cache-friendly by generating packets with similar characteristics together (same thread/same step/sequential time). The most obvious characteristic to use is city and region, so I think of this as 'regionalization', but other characteristics could be used. Rewriting the algorithm to generate passengers from particular localities together might improve the chance of data structures (buildings, stops, and journey times) being in each thread's cache. If that was implemented, then it would coincidentally offer alternative (and possibly better) ways to solve the problem of passengers who "take very long trips to get to very minor destinations". I have not made a detailed proposal to implement 'regionalization,' partly so I can learn more C++ beforehand, and partly because players have been asked many times not to distract coders from the top priorities, which are critical bugs and convoy re-ordering. But the potential performance benefits are very large, so I would be sad to see a new feature replicate the current passenger generation algorithm.

[jamespetts]

The suggested refinements are intended to be implemented with fairly minor changes to the existing algorithm so as to allow this to be done in a minimal time. Since the implementation of the impossible journey heuristics, the performance impact of passenger generation is a very small fraction of what it was previously. There is thus no compelling reason at present to spend a large amount of time rewriting an algorithm that generally works well in order to improve its efficiency when its performance impact is now low.

Particular care must be taken with any alterations to this algorithm, as such alterations are capable of having complex and far-reaching implications for gameplay and upsetting the current delicate balance of passenger generation and demand, which is why I am posting about these relatively modest proposals for change here: to see whether anyone can spot any specific anomalies that the proposed systems would cause that I have not spotted.

As to the separate lists, this will not affect memory bandwidth: the new consumer industries only list will be a subset of the existing all visitor destinations list.

[Vladki]

Just a brainstorming idea. What about making the shopping trips based on what is being purchased. Let's give weights to various goods offered by shops. Generate a shopping demand randomly based on these weights and look for nearest shop with those goods?

[[C] Ranran]

Recall that the building has a visitor demand and a class percentage.
The likelihood of getting there on a visitor trip should depend on this parameter. Such a parameter already exists.
Parameters for their speed of consumption (purchase) already exist too.