News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Proposed refinement to passenger generation - uniqueness

Started by jamespetts, August 14, 2018, 11:20:55 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

I have noticed some anomalies in the emergent effects of the passenger generation algorithm as applied to the Bridgewater-Brunel server game as it is currently running. I think that I have devised a possible solution to this issue, but I should be grateful if anyone could review the outline plan for the solution to check for possible unintended consequences.
The observed anomaly is that the success rate for visiting passengers is more or less the same in well connected towns as in completely isolated towns. Take, for example, Bugleigh, a town served by two major railway termini, two airports, a dock an underground railway network and a 'bus line. In the previous game year, 1922, a total of 180,745 passengers were generated. Of those, 87,850 got to their destination on foot, 14,263 reached their destination by the increasingly popular means of private car, and 19,171 reached their destination by public transport. Thus, out of a total of 180,745 possible passenger journeys, 121,284 or 67% were completed successfully.
As a counter-example, take the town of Darkesmouth, a completely isolated town in the Eastern highlands. It has no connexion by public transport of any sort and no connexion by road to allow external private car transport. It is a long way from any neighbouring towns, making it difficult even to walk long distances. That town generated 99,523 passenger trips in 1922. Of those, 84,669 got to their destination successfully on foot; 6,432 reached their destination by private car and 0 used public transport. Thus, out of 99,523, a total of 91,101 passengers successfully reached their destination - that is 91.5%.

Those statistics do not differentiate between visiting and commuting passengers, but individual buildings do. Commuting success rates are nearly 100% throughout the whole map because of an imbalance of residential and other buildings which is a separate issue more related to town growth than passenger generation. However, visiting passengers also have a very high success rate in the isolated towns - the building at 6355,2505, for example, in the town of Darkesmouth, reports a 91% visiting passenger success rate for 1922; the building at 6355,2496 reports a 100% visiting success rate; the building at 6362,2503 reports an 85% success rate. These are all buildings picked at random from Darkesmouth. In Bugleigh, the building at 1367,2543 shows a visiting success rate 0f 78% in 1922; the building at 1357,2538 shows a success rate of 67% in 1922 and the building at 1376,2538 also shows a success rate of 67% for 1922.

The high success rates might partly be accounted for by the previously described imbalance of buildings, meaning that there are not enough residential buildings in proportion to other buildings (I had pushed a fix for this in June, but this would only affect future town growth, so much of the previous imbalance may well remain), but it is troubling that the success rates are not materially different in an isolated town than a well connected town.

The immediate reason for this is almost certainly the alternative destinations feature. The maximum number of alternative destinations for visiting passengers is currently 11,196 and the minimum 4,198. This means that each visiting passenger will attempt to travel to up to 11,196 (and, on average, 7,967) different destinations before giving up and failing to travel. There is a total of 760 towns on the map, all of similar size. Taking Crowbere as an average town, it has 932 buildings, suggesting a total building number on the map of approximately 708,320, meaning that, on average, each visiting passenger will consider visiting 1.1% of the total number of buildings on the map before giving up. That means that, in a town like Darkesmouth, there is a high chance that a passenger, unable to visit any building outside the town, will nonetheless find a building in the town to visit and will successfully complete her/his journey.

In one respect, this system is working as intended, as the intention is to simulate the days of stagecoaches where very few people could ever travel other than on by foot. In the towns of the 18th century, it is still important that local people be able to visit shops to use up the goods that they supply. The idea is that, once towns become more connected, passengers will go more often to their preferred destinations and less to local destinations. In many ways, this works well, with millions of passengers being transported on public transport every year (extrapolating from there being >100 well connected towns, and each well connected town having > 10,000 passenger trips per year).

However, in another respect it does not work as intended: the intention is in due course to have a town growth model based on the local passenger success rates in individual buildings nearby, forming a sort of heatmap so that the town growth algorithm can pick the most desirable spots on the whole map in which to put new buildings or upgrade existing ones. This system should automatically balance residential and non-residential buildings if designed correctly, but it cannot work in the desired way of creating settlements that follow closely the availability of transport (as in real life) without there being a real distinction between transport success in connected and unconnected towns.

One possible approach is simply to reduce the visiting passenger alternative destination numbers, but doing this more than slightly risks making 18th century towns untenable as few passengers would be able to get to the shops.

For that reason, I have been considering an alternative approach: adding a uniqueness rating to buildings. This figure would be a percentage. At 0%, there would be no difference to how things operate now, and that would be the default for all buildings without this parameter explicitly designed. However, at above 0%, the uniqueness rating would be a measure of the percentage chance of any passenger who had selected this as her/his destination in the search for a reachable destination to terminate the search early, and refuse to go to any alternative other than that building. At 100%, passengers would refuse to consider any alternatives once they hit that particular building in their destination search. At 50%, passengers would be equally likely to continue their search to the end of the list as to terminate it at that building. (From a techincal perspective, I was planning to do this by using the number of alternative destinations that the passenger has already attempted to reach in that passenger's list as the random element, avoiding additional calls to simrand() and also, if it is made so that, the fewer alternative destinations that the passenger has so far attempted to find, the more likely that it is that the search will terminate prematurely with a unique building, this will reduce computational demand by maximising the number of alternative destination searches averted).
The idea is that larger, more important buildings (and especially those appearing later in the game) will have higher uniqueness ratings than earlier, smaller, more ordinary buildings. A fish and chip shop or a grocer, for example, would be likely to have a 0% uniqueness rating, whereas a large sports stadium would be likely to have a 10-25% uniqueness rating (a small sports stadium of earlier times perhaps 5-10%). A major office building or a department store would also have a non-zero uniqueness rating, as would the largest town halls.

The emergent effect of this should be that, once there are a significant number of buildings with a non-zero uniqueness rating, towns connected to other towns that have significant numbers of unique buildings should have significantly better connectivity statistics than towns not so connected, without jeopardising passengers' willingness to travel to local shops. It will also reward players who connect towns with significant numbers of buildings with a high uniqueness rating.

I should be very grateful for any constructive feedback on this analysis of the issue and of the suggested solution before I make a start on implementing it.
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.

ACarlotti

I don't think your proposed refinement is the right way to fix this. I'm still thinking about what could be done instead, but for now I'll point out a couple of issues I see.

Firstly, the formulae you propose do not take into account the overall size of the map (in terms of area or population or whatever). This means sticking two copies of a map side by side (with no links betwen them) would significantly reduce the number of passengers travelling in each half.

Secondly, I think this only affects the level of passenger demand to different places (by reducing the number of alternate destination considered), without actually taking into account the variety of destinations reachable. So (for example) with your suggested scheme, if (say) theatres and electronic goods stores had similar statistics, and a village currently had transport to a theatre but not to an electronics good score, then the additional passengers transported on a new link to a second theatre would be the same as the additional passengers transported instead on a new link to an electronic goods store. This isn't what we want - we would expect the electronic goods store to attract more new passengers, while the second theatre would attract fewer new passengers and might even reduce the number travelling to the first theatre.

So I think a good scheme will require that passengers seek out similar destinations to their first choice destination. This would probably require some extra information in the pakset to make it work well (e.g. to indicate in some way that different food stores are similar). I'll think about this more later.

jamespetts

Thank you for your thoughts - this is most useful. I should be interested in your possible alternative. Adding information to the pakset for building categories is not a big problem so long as there are not too many of them; however, as passenger generation is one of the most, if not the most, computationally intensive part of the whole game, it is important not to do anything that significantly increases memory bandwidth requirements in this method by doing things like keeping track of where individual people work, what they have visited in the past, etc..
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.

ACarlotti

So I can think of three different kinds of journey, which need handling in different ways:
Commuting - Residential->Workplace->Residential. This should be balanced on both sides - i.e. number of journeys should be tracked and capped at both the homes and the workplaces. I don't know exactly what the current system is; perhaps it already works well. The success rate (i.e. number of jobs filled at an industry, and number of people in employment in a residential location) should influence the future development of the cities and industries.

Residential->Residential - This could represent people visiting friends/family, or people going on holiday elsewhere. For these, the existing generation system ought to work reasonably well - families and friends will typically be located so as to be reasonably reachable from each other, and so the efficiency of the transport network shouldn't affect numbers too much. This success rate probably doesn't need tracking to be used elsewhere.

Residential->Other - This represents people seeking out a particular type of place, whether it be a supermarket, a butchers, a theme park, a theatre, or whatever else they want to seek out. I think the overall level of demand will probably need to be coordinated by dividing this into categories, with an estimated (maximum) frequency with which people to travel to buildings of each category (and also a typical journey time tolerance). Within each category it will be necessary to devise a way of distributing passenger among the different types of buildings, including their willingness to consider alternative destinations. I think one parameter should be the (typical) proportion of buildings of some type that a passenger attempting to visit that type will consider. Another parameter might be a list of other types of buildings for them to consider as alternatives (with a probability of considering it). To prevent having lengthy lists of buildings in every object this could be recursive, so that if someone is looking for a butchers, that might indicate a 50% chance of considering a supermarket instead, which may in turn indicate a 25% chance of considering a bakery (so 12.5% chance of considering the bakery if the are no other chains that might lead to it).
EDIT: These 'Other' destinations should also have a capacity (perhaps both an ideal capacity and a maximum capacity). This then avoids excessive numbers of passenger travelling to a single location, and could also act as a driver for new locations opening or closing. Places that have few visitors might close down, while visitors that don't manage to visit a location of the desired type (or similar) have a small probability of triggering the creation of such a place near to their home, or near to another building of that type that is overcapacity (which could help similar building types to cluster).

Another thing to consider is whether passengers should travel to the first place they find within range, or whether they should continue searching, with a probability that they will switch to a closer destination if one is subsequently found.

jamespetts

Thank you for your thoughts. It might help to explain a little how the current system works first.

Each packet of passengers generated can have between 1 and n passengers in it, the default value for n being 8. This number is semi-randomised and depends in part on the size of the generating building.

When each packet of passengers is generated, it is assigned (using a weighted random allocation) either to be visiting or commuting. All buildings on the map can have visitor demand. All non-residential buildings on the map can have jobs. All buildings that have visitor demand are added to a global weighted vector of visitor targets. All buildings on the map that have jobs are added to a global weighted vector of commuting targets. Buildings can be and frequently are in both lists. All residential buildings are additionally in a global passenger origins list. Residential buildings may also be visiting targets (giving rise to residential to residential journeys).

Packets of passengers pick a destination at random from the appropriate list: commuting passengers the commuting targets list and visiting passengers the visiting targets list. The lists are weighted random, meaning that the higher the number of jobs that a commuter target building has, and the higher a visitor demand that a visiting target building has, the higher the chance that that building will be picked. Unlike in Standard, a multi-tile building is a single entry on the appropriate list(s).

On generation, passengers are also assigned a maximum journey time tolerance. This is a weighted random number intended to concentrate the times at the lower end of the scale. Passengers are also assigned a maximum number of alternative destinations. This is a random number between the minimum and maximum journey time tolerance values set in simuconf.tab for visiting and commuting passengers: visiting passengers are assigned a random number between the minimum and maximum number of alternative destinations for visiting passengers, and commuting passengers are assigned a random number between the minimum and maximum number of destinations for commuting passengers.

Depending on the settings in simuconf.tab, the minimum and maximum number of alternative destinations for both visiting and commuting passengers can be scaled with the number of buildings (or, more specifically, the total for all visitor demand/jobs on the whole map). This is enabled by default in Pak128.Britian-Ex. This is done with the following simuconf.tab settings:

max_alternative_destinations_per_visitor_demand_millionths = 2750
max_alternative_destinations_per_job_millionths = 5000

min_alternative_destinations_per_visitor_demand_millionths = 750
min_alternative_destinations_per_job_millionths = 2500


The idea of this is that different sizes of map should result in the same passenger success rates for any given quality of transport.
If the destination picked first by the packet of passengers is reachable within that packet's journey time tolerance, the passengers make that journey. If not, they pick another destination using the same method, and repeat this process until either they find a journey within their journey time tolerance, or they run out of alternative destinations, whichever is first.

The process of checking player networks to see whether a journey time is within passengers' tolerance is quite computationally intensive (especially as to memory bandwidth), and, because this part of the code is very frequently accessed given the large numbers of passengers generated and the very large number of alternative destinations each on a large map, this can be the single greatest consumer of CPU resources on a larger map, so great care must be taken not to increase this more than necessary.

There is a possible refinement to the uniqueness system that I think would avert the problem that you initially identified, although it might make it harder to calibrate and understand.

The way that I imagined uniqueness as working is that it would stop the search if a unique building was found and the packet of passengers that had found it was not more than X way through the alternative destination search, X representing the uniqueness rating and also the percentage of the search.

For example, for a packet of passengers with 100 alternative destinations and a building with a uniqueness rating of 10, the search would be stopped if the passengers hit that building in one of their first 10 attempts at finding a destination. If the packet was at attempt 11 or later, the alternative destination search would continue if the passengers could not reach that destination within their journey time tolerance.

If, instead of using a percentage of the actual number of alternative destinations, the figure were a fixed number, scaled by reference to the max_alternative_destinations_per... figure, then, as the number of buildings increase, and the number of alternative destinations likewise increase, the passengers would be proportionately less likely to be in that early part of their destination search when hitting a given unique building and thus this would compensate for the larger number of unique buildings on the map.




In relation to your more specific suggestions, I am not sure that there is a need to have separate specific code to handle residential to residential traffic, as this is already handled by the system for visiting passengers. In any event, it does not solve this underlying issue. What you describe as "other" is, together with the residential to residential traffic, what is coded as visiting passenger traffic.

I am not sure that I fully understand your reference to not having lengthy lists of buildings in objects and recursive lists - can you elaborate a little on what you imagine in light of the passenger generation system described above? I fear that you may be imagining a system in which individual citizens are tracked in some way rather than the parameters being randomised on trip generation, which I cannot see being feasible in terms of memory bandwidth (attempting to do something like this was what caused all the trouble with the 2013 version of SimCity and is probably the reason that the maps were restricted to 1km square).

As to visitor destinations having a capacity and closing: closing/opening is part of town growth rather than passenger generation; something like this is eventually planned, but an overhaul of town growth will be a very major piece of work, and will have to wait until vehicle maintenance is complete; fine tuning of passenger generation along the lines suggested in my original post is much more minor and can be done as a priority. As to capacity, there is some provision for this: commuter targets have a capacity represented by the number of jobs filled, and shops selling goods have a capacity in the sense that, when they run out of goods (as shipped by players), people can no longer reach the destination (and it is treated in the same way in the passenger generation code as a destination not reachable within the journey time tolerance). Non-goods based visiting destinations do not have a capacity limit, but I have not seen evidence so far of any buildings being over-visited to an unrealistic extent as a result of this.

As to passengers not travelling to the first place that they find within range, this would increase the computational load on the passenger generation algorithm by requiring more journey attempts per passenger, so this is best avoided. In any event, in reality, people do not always travel to the closest possible place, but have a particular preference as to where to go and a travel time budget to go there (there is some research on this topic), so will travel to preferred destinations if reachable.

In any event, thank you again for your thoughts on this topic: they are much appreciated.
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.

prissi

Just out of curiosity: Standard had introdduced an non-linear distance function "locality_factor_per_year", that makes it much less likely to travel far in earlier years. The time tolerance sounds like this. But why not giving up, if the first traget is not within distance? Getting the passengers too high in early years will lead to troubles anyway.

jamespetts

The idea is that passengers in the early years will predominantly walk to their destinations, as most of them will not be able to afford player provided transport, and even those who can will often find it to take too long, so only higher wealth passengers with a higher journey time tolerance will travel in the early years, generating low passenger volumes for players' stagecoach networks approximately commensurate with the numbers of people actually using stagecoaches at the time.

The idea of alternative destinations is that, if people's destination is a grocery shop on the other side of the map, it makes no sense for passengers not to travel unless this specific grocery shop is reachable within the journey time tolerance: in reality, people would go to a local grocery shop, local being defined by journey time, not distance (although the two being related, of course; but the relationship is precisely one defined by the actual transport networks created by players in the game, so should not be a fixed constant).
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.

prissi

Well, this comes very close the the current implementation of destination in OpenTTD, i.e. choosing from a list of available destinations, with the number of travels set by the generator (here the buildings surrounding the stop). To me it would take the fun out of Simutrans, if the passengers go only where they can go and not become unhappy. Provide happyness is a great motivator.

jamespetts

What do you mean by the number of travels here, may I ask?

As to the passengers being happy or not - the trouble with the Standard implementation is that there is an unrealistic exponential increase in the number of passengers willing to travel anywhere at all as more towns are connected to each other. In reality, people would not refuse to travel if they could not get to one specific destination in many cases: they would instead just travel to reachable places, but would prefer other places which are not currently unreachable, but might become reachable later.

I wonder whether a proper way of dealing with this issue may be more sophisticated than originally outlined, and calculate passenger success rates based not just on whether the passengers travel at all, but on how close to the top of their list of alternative destinations that their actual destination turned out to be - perhaps uniqueness as a concept could then be used to calibrate how significant for the passenger success rate that being near the top of that list is - much less, for example, for grocery shops than sports stadia (although even for the latter, people may often prefer to support local teams). This would reflect the concept of passengers being unhappy at not reaching their higher priority destinations without producing the exponential network effect.

I also wonder whether there are actually two separate issues here: one as to the correct calibration of passenger success rates, where uniqueness and destination priority are relevant, and one as to the total number of passengers who are travelling: I notice that, in the server game, even in well connected towns, most passengers complete their entire journey on foot. In many towns, even in 1923 (when I last checked), almost as many passengers were travelling by private car as were by public transport. This suggests a calibration issue distinct from the uniqueness/passenger success rate issue, and which needs to be solved before considering the latter. My initial guess is that the minimum and average journey time tolerance for visiting passengers may be too low and the number of alternative destinations too high, producing large numbers of passengers making very short journeys to very local destinations.

I will need to carry out some experiments to see whether this can be improved just by altering configuration settings before looking at modifying the code.
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.

ACarlotti

Quote from: jamespetts on August 24, 2018, 03:34:55 PMan unrealistic exponential increase
I think you mean a 'quadratic' increase (i.e. the number of journeys is the square of the number of places connected). 'Exponential' would be rather more extreme.

Quote from: jamespetts on August 16, 2018, 12:56:45 AMIn relation to your more specific suggestions, I am not sure that there is a need to have separate specific code to handle residential to residential traffic, as this is already handled by the system for visiting passengers. In any event, it does not solve this underlying issue. What you describe as "other" is, together with the residential to residential traffic, what is coded as visiting passenger traffic.
I realise now that residential to residential traffic can be treated in the same way as other visiting traffic.

QuoteI am not sure that I fully understand your reference to not having lengthy lists of buildings in objects and recursive lists - can you elaborate a little on what you imagine in light of the passenger generation system described above? I fear that you may be imagining a system in which individual citizens are tracked in some way rather than the parameters being randomised on trip generation, which I cannot see being feasible in terms of memory bandwidth (attempting to do something like this was what caused all the trouble with the 2013 version of SimCity and is probably the reason that the maps were restricted to 1km square).

I am not imagining tracking individual citizens at all. For an example of what I meant, suppose that our pakset contains a bakery, a market, a supermarket and a butchers. The pak files specify that:


Intended destination[Possible alternatives (and probability of considering)
BakeryMarket (30%), Supermarket (50%)
MarketButchers (20%), Bakery (20%)
SupermarketButchers (15%), Bakery (15%)
ButchersMarket (30%), Supermarket (30%)

A (packet of) passenger(s) wants to visit a bakery, but there are no bakeries in range. So with 30% probability they'll then consider a market instead, and with 50% probability (independently) they'll consider a supermarket instead. If they are willing to consider both then they test them in a random order. Suppose there were no markets or supermarkets in range either. Then the only thing left to look for is a butchers. Having tried the supermarket, there's a 15% probability that they'll try the butchers as well. Having also tried the market, then there's instead a 20% probability that they'll try the butchers as well. (These last two tests are not done independently, to prevent the probabilities getting really big if there are lots of different paths of alternatives to reach this point. Instead, we might pick a random number between 0 and 1 for each building type, and then if we compare this first to 0.15, and then also to 0.20.)

I don't think this is a perfect system, but it reflects the ideas I have had so far; I think there this can be refined further.

QuoteAs to visitor destinations having a capacity and closing: closing/opening is part of town growth rather than passenger generation; something like this is eventually planned, but an overhaul of town growth will be a very major piece of work, and will have to wait until vehicle maintenance is complete; fine tuning of passenger generation along the lines suggested in my original post is much more minor and can be done as a priority. As to capacity, there is some provision for this: commuter targets have a capacity represented by the number of jobs filled, and shops selling goods have a capacity in the sense that, when they run out of goods (as shipped by players), people can no longer reach the destination (and it is treated in the same way in the passenger generation code as a destination not reachable within the journey time tolerance).
My ideas do support changes to the town growth system, and should perhaps be viewed as a long term proposal rather than a short term fix. However, in creating any short term fix (perhaps along ther lines you suggest, if that can be easily tested) it would be sensible to consider any proposed long term changes.

QuoteNon-goods based visiting destinations do not have a capacity limit, but I have not seen evidence so far of any buildings being over-visited to an unrealistic extent as a result of this.
With a global system for allocating passengers (i.e. all buildings are possible destinations for each passenger) I expect things will average out well. However, with the sort of system I propose, there is the potential for new buildings to be flooded with visitors - e.g. if an entire cities' population tries to visit a single cinema at the same rate as they would once several more cinemas are open.

QuoteAs to passengers not travelling to the first place that they find within range, this would increase the computational load on the passenger generation algorithm by requiring more journey attempts per passenger, so this is best avoided. In any event, in reality, people do not always travel to the closest possible place, but have a particular preference as to where to go and a travel time budget to go there (there is some research on this topic), so will travel to preferred destinations if reachable.
I agree that this probably is unnecessary and undesirable.

jamespetts

I have been spending some time testing the passenger generation issues to-day, with a focus for the time being on the calibration of the existing settings. The results are so far inconclusive.

I have tested a reduction to a very low number of the minimum number of alternative destinations for visiting passengers - but this makes no measurable difference to any metric that I can find other than the global percentage of passengers reaching their destination, which reduced from 77% to 73%. The number of walking passengers in any given town did not seem to decrease significantly.

I have tested forcing all of the passengers to be at least class 1 ("low") (as many trains do not by default allow for accommodation of class 0 ("very low") passengers), but again this makes no measurable difference to any metric (there might be a slight increase in the numbers of passengers travelling, but there is not enough of a difference to be obviously greater than the regular monthly variations in the travel statistics for well connected towns.

Testing with a debugger (with the normal class logic), I could not discern any strong patterns (which would be difficult given the volume of data), but I do notice that the public transport journey times on the server map are often very high - sometimes many tens of hours, while the journey time tolerances are usually fairly low - normally either a few minutes or an hour or two. (These are all door to door journey times, for reference). I also noticed quite a high number where there was no public transport route available at all: I can only imagine that these are class 0 passengers and/or unconnected towns.

I then wondered how these journey times compared to reality, so I calculated a figure for average door to door journey speed. In the Bridgewater-Brunel saved game, the door to door journey time average speed was usually in the teens or twenties of km/h. I then compared this average door to door journey speeds with two real life examples (albeit present day real life examples, as it is difficult to find sufficient historical information). I took as an example a ~300km journey on the server game which had an average journey speed of 23km/h (in the year 1925). I then compared it to two present day journeys - one from where I live to Harrogate and one from where I live to Aberystwyth, both approximately 300km. I assumed a 15 minute journey from the station at the destination to my ultimate destination in both cases. Harrogate is well connected, and gave an average door to door journey speed of ~76km/h (including waiting times at all stations). Aberystwyth is less well connected (although surprisingly has a direct train from a London terminus now), and gave a door to door average journey speed of ~45km/h, including a ~40 minute wait at the London terminus. These journeys both included a mile walk from my house to the local Underground station, which I timed at 20 minutes.

Comparing 2018 with 1925 is not entirely accurate, so these results are for the time being somewhat inconclusive. However, it is notable that even the Aberystwyth journey with the long wait and the slow journey has an average journey speed of nearly twice the average journey speed for the 300km journey in the server game. It is not entirely unreasonable to imagine that a well connected town in 1925 would not have a lower average door to door journey speed than a poorly connected town in 2018 (in each case from the outer part of a well connected town).

I have not got to the bottom of why the player networks on the server game are inferior to real networks in their average door to door speeds for the most part. One possible theory is that players do not have an incentive to make them better because of the very high number of alternative destinations for visiting passengers. I have not yet tried adjusting the maximum number of alternative destinations for visiting passengers, so this is something that may be worth investigating. Some further investigations as to the nature of networks on the server game may well also be worth looking into. I do notice that the urban networks are often less well developed than in reality, although the larger towns have many well developed urban networks, including some substantial underground railways and tram and 'bus networks. Another feature of many networks on the server game that is different to reality is that there seem to be very few limited stop trains: most trains seem to stop at least once in most towns through which they pass. In the days of steam trains, whose acceleration is slow, this could make a big difference to average speeds, and in reality, railways used a combination of short distance stopping trains and long distance limited stop trains for this reason. Players on the server game do not seem to have created the long distance limited stop trains very much for some reason, having only local urban services stopping in several places in one or two neighbouring towns and longer distance trains that stop once in each town.

I should be interested to hear from players on why their networks are constructed thus so that I can understand whether there are any unrealistic incentives at work encouraging this behaviour.




As to A. Carlotti's suggestion - this is an interesting idea in general terms. As I understand it, what is imagined is a system in which the current generic pool of visiting destinations is subdivided into an arbitrary number of subtypes defined in the pakset, each building being able to be assigned to one of those subtypes, and passengers first selecting a subtype (perhaps in accordance with simuconf,tab settings on the probability of each) and then looking for alternatives only within that subtype (or, if none are found within that subtype, having a confirguably weighted random chance of picking another subtype).

Some very careful thought would be needed as how best to calibrate this, and what impact on performance that having an arbitrary number of lists of destinations for visiting passengers rather than having a single list might have. (Indeed, it is no longer a single list: there is now one list for each class of passenger, so we are potentially looking at a two dimensional array of lists to implement this feature).

I should note that the description of the feature above is a slight adaptation of A. Carlotti's suggestion, intended to fit better with the current algorithms and data structures, and in particular, with the system of choosing passenger destinations from a global weighted random list of possible destinations.

A capacity limit, if necessary, would not be too hard to add, as the current code for jobs could be recycled: it is a very efficient system, so this should not add much computational load, but would require an extra 64-bit integer per building on the map, so might make a non-trivial impact on memory footprint and possibly memory bandwidth. (There would also be additional data required per building type, but this would be relatively trivial).

I should be interested in A. Carlotti's thoughts on my interpretation of his proposed system, and anyone's thoughts about how best to think about calibrating such a system if it were to be implemented.
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.

jamespetts

I have been carrying out some more experimentation, the results of which are still somewhat inconclusive. I have slightly increased the minimum and maximum journey time tolerance for visiting passengers in the pakset simuconf.tab (this will not affect games already started), so the maximum journey time tolerance is now 100 hours, up from 90 hours, and the minimum is now 12 minutes, up from 8 minutes (remember, the journey time tolerance values are very heavily skewed to the lower end).

I have also modified the code slightly so that the minimum journey time tolerance for any given trip is multiplied by the number of onward trips, on the basis that passengers who need to make complex, multi-stage journeys do so anticipating that these will take a longer time and thus have a higher journey time tolerance. This latter measure seems to have had a small but noticeable effect using the game from the Stephenson-Seimens server, although that may not be the ideal candidate because of its relatively low degree of connectivity, most towns being served by ship, and only two relatively short railway lines connecting 3-4 towns each. I have not tested on the Bridgewater-Brunel saved game owing to the amount of time that it takes to load a saved game with a debug version, but it will be interesting to see how this affects things when the nightly build is deployed.

Official statistics suggest that, in modern times, passengers walk to their destination just over 3 times as often as they take public transport to their destination (car journeys being by far the most common means of reaching any destination). In the Stephenson-Seimens server, passengers seem to be walking more like 20 times as often as using public transport, albeit in well connected towns on the Bridgewater-Brunel server, that is closer to 4-5 times, which seems is closer to reality. It will be interesting to see how the onward journey times alteration changes this.

Also, if anyone can find and post any statistics on average door to door passenger journey times, especially for non-commuting trips, I should be very grateful.
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.

DrSuperGood

Will these changes allow industries to finally get enough workers commuting to them in bigger cities? On the bridgewater brunel server it is impossible to get markets and such staffed even with 300 units of product waiting to be sold with regular bus services, trains and underground railways to move people around the city and from nearby cities. Once a city grows too large industries cannot get the workers they need.

jamespetts

As written previously, the issue with commuting passengers appears to be that towns produce too many commercial/industrial buildings compared to the number of residential buildings when they grow. I had attempted a short term fix to this in June - it is not clear whether this has had any effect, as it will take a large scale renewal of buildings in towns for this to be effective.

This thread, in contrast, relates to passenger generation. Getting this right will ultimately help with the eventual full reworking of town growth code, but that is the major project after next.
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.