News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Marchettis constant on differently sized maps

Started by Mariculous, October 15, 2020, 04:26:31 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

Whilst porting pak192.comic to extended, I have noticed some issues with pax generation: Passenger streams do greatly depend on the size of the map and city clusters.

One design goal is to allow people playing the game on a medium sized map, whilst providing a realistic feeling on a switzerland-sized map, which is as small as 1100x1750 tiles, as well as providing a realistic feel on a Germany-Austria-Switzerland-sized map, which is as large as 3750 x 5025 tiles.
That huge span of size is chosen for two reasons:
1. The the pakset is currently mainly focused around that area, though it's not strictly limited to it.
2. Not everyone got a hexacore high-end server with 16 GB of ram, as well as not all clients can join such servers. We want a pakset that works well for everyone who is interessted in extended.

Currently, there is a fixed amount of average journey attempts per month, which does not seem to work well with Marchettis constant when scaling the map.
There already is a mechanism increasing the tolerable time of the next journey, if no destination in range was successfully brute-forced, which slightly improves this.
As far as I understand the mechanism, the additional time is reset as soon as a suitable destination was found, no matter how far-away (as always in terms of time, not distance) it is.

This is not optimal and especially on small maps will significiantly reduce the average journey time of passengers, as these will rather unlikely stack up much time and if they do, it is still rather likely to reset that time on a short walking trip to the neighbor.

Instead, it might be sensible to tweak the additional time budget system a little bit to stick more directly to the only constant we got, which is Marchetti's constant:
When a (group of) passenger(s) attempts to go on a journey,
- First determine the journey time budget inhabitants of the related house have generated from the previous journey attempt to now and add it to the time budget.
- Then randomise a tolerable journey time from the time budget available. (might be skipped, but I guess we need it to balance the ratio of local vs long-distance journeys properly)
- Next brute-force attempt a suitable destination within that time
- Finally, send the passengers on their journey (if a destination was found) and subtract that journey time from the budget, no matter if they took public transport, the car or even just walked.

We might need a system to prevent very badly or not at all connected areas from infinitely piling up journey time budget, so these won't rush for world tours when they get connected.
There are many ways to achieve this, depending on how much effort one wants to put into this.
A simple thing to prevent time from piling-up in unconnected locations is to substract the just added time budget when the journey brute-forcing failed with "no route" in the majority of cases.
Journey time piling-up due to very badly connected, but not entirely unconnected, areas will eventually be used by a long journey some day, which is perfectly desireable I guess.

jamespetts

I think that you misunderstand how the current system works. What happens is that the success percentage of passengers travelling from an origin building is used to modify the journey time tolerance.

For example, if the base journey time tolerance is 1 hour, if 100% of passengers have succeeded in the preceding year in making journeys, then the modified journey time tolerance is also 1 hour. However, if <100% of passengers have succeeded, the modified journey time tolerance is modified in accordance with the tolerance_modifier_percentage setting (66% in Pak128.Britain-Ex). For a 50% success rate, this would be 66% / 50% = 1.32, roughly equating to 1 hour and 20 minutes. If the previous year's journey success percentage was 0%, the journey time tolerance is simply doubled.

The idea behind this is to simulate the fact that the travel time budget idea encapsulated in Marchetti's constant is that passengers will spend a fixed amount of time each day travelling: if they make fewer journeys per day, each of those journeys can be longer. This is a very rough way of simulating this, but, within present day computational limits, it is the best that we can do whilst allowing for very large maps.

Thus, there is not a system that increases the journey time tolerance of the "next" journey which resets when a destination has been found. Because of this misunderstanding of how the system works, I do not understand what you mean when you refer to the current system not working well for maps of varying sizes. What exactly are the symptoms of the problem at each given map size? I will need to work out the cause of the problem independently from the available data. 
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

The current system is what can actually be observed ingame.
On small maps, the passenger streams are very low, whilst on larger maps they are much higher.
This does not allow to design a pakset that will work well on a Switzerland-sized map as well as on a Germany-Austria-Switzerland sized map.

jamespetts

Quote from: Freahk on October 16, 2020, 06:27:38 PM
The current system is what can actually be observed ingame.
On small maps, the passenger streams are very low, whilst on larger maps they are much higher.

Do you mean that there is a significant variation in passenger success rates between smaller and larger maps, or a significant variation in the number of passengers generated per unit of population?

Note that the number of alternative destinations scales with the map size (not in dimensions, but in the distribution weight of destination buildings) automatically, which might be more relevant to this issue than the journey time tolerance modifications.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

I'll try to analyse this in detail.
For now I observed that on small maps, the average journey time of passengers seems to be lower than on larger ones. At the same time, many of those passengers that successfully go on a journey are walking to their destinations.
This is based on the observation that medium distance trains, although rather frequent and fast, won't attract many passengers.
On long-distance it's the same, but that might be explained by simply the lower number of inhabitants within a range of - let's say - 5 hours, because the map is simply not that large.

I guess the likelyhood of gambling a local destination being much higher on a small map than it is on a large map might play an important role here.