News: Portal
Our Simutrans site. You can find everything about Simutrans from here.

Split: Re: Potential feature discusion: economic integration

Started by Iluvalar, January 03, 2016, 07:59:57 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


This was split from another topic and it is locked. -Isaac Eiland-Hall

Here is my suggestion again since it match the need again.

You should create a new gooey ressource system. The workpower is generated by the residential building, pour a bit in the area, and tend to flow faster along the roads. It is aborbed by the shopping and industrial building. Which in turn produce other ressources like goods, entertainment and shopping.

You could then generate the passengers depending on the needs and production of each zones.

I have several reasons to suggest that generalized ressource system instead of your hardcoded solution :
You can then create new resources such as crime, pollution, education, grocery, social. In a generalized solution, the new ressources could be in the hand of the pak maker who could come up with more buildings and more crazy idea. You could calculate precisely the success of individual buildings. A player could buy a souvenir shop or build a new hotel  in front of his station and you could calculate the success of the building.

I know I sound like I want to make a full blown simcity game and we don't aim for it. But what you try to implement is not far away from it anyway and wouldn't require much less effort. The simulation wouldnt require much cpu actually and could happen slowly just once a month or so.


Quote from: jamespetts on January 03, 2016, 09:05:14 PM
However, the town growth system that I plan to add later will have some sort of concept of desirability. I have not decided quite how it will work yet, but one idea would be for buildings and other objects to have a radius of effect on different types of desirability and a level: an industrial building might have a 10 tile radius of -5 residential desirability, for example, which would (albeit indirectly) simulate pollution. (Indeed, the existing town growth system from Standard does something a little bit like this, but only for types of city buildings, not indiviually determinable by specific buildings).
Yes ! This was my first idea, but let's expand it just a little. First, we generalize the idea; Instead of creating an hardcoded "residential" need/effect/ressource (I'll stick with ressource), allow for the creation of new one that could be held in a file like goods.dat . Let's just say for now that a residential buildings create something called "workforce" which affect the success of surrounding factories and shops.

You have 2 ways to manipulate this new system now. A) recalculating once the surrounding resources on the construction of a new building (which might be faster but a bit buggy on city changes) or B) Holding the matrix of those "ressources" in cache and adding the new area of effect of the new building (or substracting on the building deletion) on top of the data. (eventually saving them a few bits per tiles) . I suggest the option B as it will be better and allow for expansion.

Now let's push a bit further. And I can't stress enough that you don't need to simulate that constantly. A few ticks per game month would be enough for our needs.  The "ressource" is spilling on the surrounding tiles. Say there is 20 "workforce" on a tile created by a residential building and the next tick, 1 workforce spill from each side and 1 workforce dissipate. At the end of the simulation, you have the same "bubble" of workforce around the same building as before. It's just a bit more calculation, but now you can keep track of the amount of workforce you have and you can make the viscosity of the ressource increase along the roads. The workforce would spread faster along the roads and hit farther distances by itself.

You'd now have a heat map of the workforce that you could "scoop" into the nearby factory with a bus and another heat map for consumers (maybe even several needs (food, entertainement, fourniture...) at a fairly low simulation cost. The fact that you could then calculate the success rate of all the city building by evaluating how well their different needs are met and therefore the city growth would just be a bonus feature...

From a coding point of view then :
You need 2 matrix, the first holding the amount of workforce on each tiles, the second holding the flow of matrix on this tick. So you don't have a top-left bias. You hit a tile, you calculate how much spill using the amount on the tile, the viscosity of the ressource and the eventual roads around, you make the displacement in the flow matrix and when you're done with every tiles you add the flow matrix to the normal matrix. No so hard...


Quote from: jamespetts on January 04, 2016, 07:32:54 PM
As to the second idea, the idea of a workforce being distributed from residential buildings by proximity: this idea seems to me inconsistent with the idea that the game is inherently about simulating transport. The idea is for commuting passengers to travel, either by walking, by private car or on player transport, to their destinations and for that transport to be an inherent part of the game mechanic. The idea that you suggest of distributing workers by radius seems to me to be a way of approximating very basically what the game sets out to (and already does) model in detail as part of its core mechanic. A fundamental principle of the desirability model that I set out above is that it is intended to apply only to things (such as pollution or visual amenity) that are not moved from place to place by transport of the kind simulated in the game (including walking and private cars).
I don't think it's reasonable to simulate every kind of local transport. It would be tedious to say the least to make the player babysit every little restaurant in the game and claim that if the player don't personnaly transport the consumers there, the business would go bankrupt. You don't want to create a sim game where every resident go to the grocery with their car once a week... You need to accept that the bulk of the transport in the town is not done by the player and that we can't really simulate it with the tools we have.

And nothing would then stop you to do both... I gave a solution to detect the flow of workforce going from the apartments to the factories down the street. And assess that yes, indeed, those residents do have a local job. But nothing would stop you to still generate the passenger for the player to move from one point to another locally, if they do want to run a local bus. You would just have a better understanding of where those come from, where they want to go and why. And likely in the futur, generate the traffic with more precision.

But also on an intercity scale, you would have a general idea of the needs of the passenger at the stops and where those needs could be met. At first very basicaly dealing with "consumers" but, while staying very reasonnable about the amount of those things tracked, you could eventualy distnguish consumers seeking fournitures and electrics from consumers seeking for entertainement from "consumers" seeking for a job.


I think that you underestimate what the existing systems relating to passengers walking and taking private cars already achieve with great simplicity and reasonable realism: what you suggest would do no more than duplicate what is already simulated by these means, with the great disadvantage that what you envisage does not appear to integrate fully with the recently overhauled passenger generation system or the workings of industry as suggested here.

In brief: passengers walk to their destination when walking is the fastest or only available mode of transport to their destinations. Passengers take private cars to their destination when they have access to a private car and it is the fastest or only viable mode of transport to their destinations. These passengers are the same passengers as are generated for players to transport. The proportion of them that are transported successfully, whether by the player or otherwise, is important, and will be even more important once the town growth system is fully implemented. Walking has no pathfinding, and private cars use a very approximate extrapolation of a pathfinding system that finds routes only between city centres (to check that the origin and destination are connected by road: all buildings within a city are presumed to be connected to one another).

I am afraid that it is really not clear how you imagine that what you propose would improve upon that (and, worse, it would require considerable additional resources for pathfinding: consider that a large game may have over 500 towns, many of which will be large, and that a reasonable walking radius is quite a few kilometres (at 125 meters per tile) in the absence of alternative transport, and private cars can of course go any distance).
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.


You're right, in a sens that what I suggest here doesn't directly solve your concern. It also aim to improve other areas of the game. (like for exemple, the desirability radius you're talking about). I'm suggesting it here, because it could be used at the base of your motivational problem.

Tell me how you generate the passengers right now. How you will distinguish the need of them ? Who want to work ? Who need new electronics at the shop ? You randomly select them ? You assume that they will always start from the residential area ?


As noted above, the idea of the desirability radius (for the town growth algorithm) is intended to be quite distinct from dealing with the sorts of things that can be transported: those sorts of things are simulated directly.

The new passenger generation system already implemented in the devel-new branch works as follows: packets of passengers are generated at residential buildings using a weighted random system based on the population size of the building. The random check is performed periodically, and calibrated so that an approximately realistic number of passengers is generated in any given period of time. Each packet of passengers consists of one or more passengers, up to a maximum number that can be set in (the default being 7, which is a hard-coded number in Standard). The number of passengers in the packet is partly random, but the maximum is fixed by the population size of the building as well as the global maximum.

Each packet of passengers, on being generated, is assigned a function as either commuting or visiting passengers. This is weighted random based on the proportions of each set in

Commuting passengers pick a destination from the list of commuting targets. That list comprises all buildings in the game world that have jobs. Picking a destination is weighted random based on the number of jobs in the building (that is, total number of jobs, not number of jobs available). Visiting passengers similarly pick a destination from the list of visitor targets, which are all buildings with a visitor demand above zero.

On creation, each packet of passengers is assigned a maximum journey time tolerance, a maximum number of alternative destinations,  whether they have access to a car and whether they always prefer to use a private car where possible. The number of alternative destinations is a simple random between 0 and a fixed maximum set in; the journey time tolerance is a normalised weighted random based on numbers set in; whether passengers have access to a car is a simple random function based on the proportion of people with access to a car at the given point in the time-line at which they are generated; and the preference for using a private car wherever possible is a simple random based on a probability set in

The packet of passengers then checks whether it can reach its first allocated destination within its maximum journey time tolerance by any means of transport available, including walking (although in that case the maximum journey time tolerance is halved to simulate the fact that walking is more arduous than riding as a passenger). If the packet can reach the destination within its journey time tolerance and the destination is currently accepting passengers (currently, this is relevant only to whether there are any available job slots), the journey is allowed to begin. Passengers will always choose the quickest route to their destination, except for those who always prefer to use a private car, who will always use a private car if they have access to one and the destination is within their journey time tolerance using a private car. For walking passengers or those who take their private car, the journey is regarded as being made straight away and the passengers delivered to their destinations instantly. There might well be scope for having a list of in-transit passengers somewhere to make the arrival times more realistic, which will be more significant when this suggested feature is implemented. For passengers taking public transport, they are added straight away to their origin stop to await the convoy that will take them on the first leg of their journey. (Again, there might be some benefit in having a delay between being generated and arriving at the origin stop to reflect the time that it takes to walk from their ultimate origin to their origin stop). Once passengers complete their journey (instantly and automatically by walking or by private car, or on actual arrival at the destination stop when transported by the player), the journey is logged as a success at the origin building and as an arrival at the destination building (and if the passengers are commuting passengers, the requisite number of job slots are filled at the destination building).

If, however, the passengers cannot reach their first selected destination within their journey time tolerance, they pick another destination at random from the list until the number of alternative destinations allocated when they were generated is exhausted. If no reachable destination can be found before the number of alternative destinations runs out, then the packet is recorded as a failure in the statistics of the origin building. The reason for the failure is recorded on the colour coded "passenger destinations" overlay in the minimap. The colours are:

(1) dark yellow: walked to destination;
(2) light yellow: transported to destination by public transport;
(3) teal: transported to destination by private car;
(4) orange: cannot use a private car, too far to walk, and no public transport route available to the destination;
(5) pink: there is a public transport route available to the destination, which is the quickest way of getting there, but it exceeds the journey time tolerance;
(6) bright red: there is a public transport route available to the destination within the journey time tolerance, but the origin stop is so crowded that the journey cannot begin; and
(7) dark red: the destination stop is not accepting passengers, but would be accessible if it were (and no alternative destinations that can be reached are accepting passengers).

Furthermore, all journeys generate a reciprocal return journey (which works in the same way as described above, the passengers being generated at the destination building), and some generate an additional onward journey from the first destination, which are again calculated as above (and each onward journey also has its own return journey; there are thus no triangular journey patterns). Whether an onward journey is generated is randomised based on a probability set in

The aim of this system is to create realistic journey patterns and realistic success rates and visiting rates at buildings based on actual simulated transport factors without consuming too much memory bandwidth so as to allow huge maps with many hundreds of towns to run in an online game.
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.


Wow, this is much more precise that what I was expecting. Thank you for this long answer. I wasn't asking that much detail. But the things I was expecting are in your post.

1- No distinction between the needs : One of your "visitor" could first try to go to the zoo and then chose to buy a car instead. (logical)
2- Always starting from residence : No chance a worker would go eat something, that a visitor in the hotel go at work or that the owner of a shop need to go buy hardware ? And there is no movement between the small industrial buildings to the small commercial buildings ? Not a single box ever ?
3- Simulation limit : "packets of passengers are generated at residential buildings using a weighted random system based on the population size of the building". You do a good job at simulating 1 hour of traffic this way and pretending it's a month. It's perfect for a traffic simulation. But how do you intend to extrapolate the real amount of consumer in a shop if it barely receive 3 passengers per months, with holes of successive 3 months where it receive none ? Even the big official factories, they'll receive between 2 and 3 bus of passengers the simulation will be wonky. But for the small shops, it will be the chaos. Even with all statistical analysis of the world, you wont get any usable data before 10 years of simulation. By this time the building can be obsolete... And probably changed 3 time already. Think about it this way, the weakest possible statistical relevancy need 10x the sample to be any good and if you make more then one analysis using this small sample, you're still far from doing any sience... This mean that to be able to calculate the revenue of a building with an accuracy of +-10% (which is sad considering you will want to simulate taxes and operation cost and all...) you need at least 100 passengers. otherwise, the simulation would be meaningless.

What I suggest is not very more heavy than one A* algorithm for each "ressource" that could at least approximate the remaining of the needed data. Also, I suspect you to want to increase the size of the map because you're aware that what is going on in individual cities is actually kinda boring. But if you works on complexity of individual cities, every single of them will become much more interesting to explore and you wont need as much to make the size of the map explode to keep the interest of all players high. Remember we are getting closer to the "simcity" level where 1 single city could hold the interest of a player during the whole game. Even In huge map, my suggestion is actualy not as ressource expensive as you insinuate. It needs 10 operation per tile per ticks per ressource and it can slowly run during the course of the game and just make 1-2 tick per game month if we can't afford more... wouldn't cost 1% of the cpu on any map.


May I ask whether you have had a go at compiling the devel-new branch of Experimental to see how the system works in practice? The issues that you mention have already been considered and dealt with.

As to (1), tracking the needs of each specific passenger would require a system that actually remembers, for each of tens of millions of simulated people, how much food that each has in their larders, and keeps track of that in real time. This is not possible with current computer hardware or any that is likely to be invented for decades. Statistical averaging will have to suffice.

In respect of (2), read again what I wrote about onward journeys, the system relating to which was intended to deal precisely with this issue.

As to (3), this is dealt with using the time scaling system in Experimental: each month is constituted as a fixed number of hours (6.2 hours by default; the number is not rounded because the relationship between speed and distance in tiles from Standard is maintained), and the simulation of micro-level times (journey times, production and consumption of goods and so forth) is all based on this scale. Thus a small shop, for example, which has 3 job slots needs to receive on average 3 commuting passengers every game month (6.2 game hours at default settings in Pak128.Britain-Ex) to have its slots filled. If you actually run a game in Experimental, you will see that, where there is a realistic balance of houses and commercial buildings, a realistic number of job slots are consistently filled if everything is in walking distance of everything else (or otherwise transport connected).

As to using A* algorithms, consider that an attempt to use an A* pathfinding algorithm for every private car in the game had to be abandoned because it took so much computational effort that the game became completely unresponsive for an indefinite period even on a modestly sized map. The pathfinding for goods and passengers uses the Floyd-Warshall algorithm (that is, a single run of an algorithm exploring all start and end points and the routes between them simultaneously), stores the results and only updates them periodically (and spaced over time to avoid overloading the computer by doing it all at once). This was written by a very skilled coder now sadly retired from Simutrans development. Edit As to 10 operations per ticks per tile, consider that some Experimental online games run something in the region of 2,000 x 4,000 tiles, which would equate to a total of 80,000,000 operations per tick, most requiring heap access. That is clearly infeasible.

In relation to the size of the maps, the reason to have a large map (I am not "increasing" the size, as for years the Experimental online games have been played with very large maps) is to simulate a range of both short and long-distance transport and the interaction between the two. If I wanted to play a game involving just a single city, I should play Cities: Skylines. The point of Simutrans is to simulate an entire (small) country's transport network, not a single town's. The relationship between short, medium and long distance transport is inherently interesting and obviously cannot be simulated in small maps.
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.


You're aware that 1ghz stand for 1,000,000,000 operations per seconds ? That's 1/100 of a seconds for the simulation tick and i need 2 of those per  6.2 hours apparently. How is that infeasible ?

Ok so 3 jobs per month. Let's suppose that the player "fail" and he miss 1 job every 11 trips. That's 3% of the transport that are missed. How much month you think you'll need to simulate to picture correctly this kind of failure ? What if that failure happen randomly on the first month ? I mean... there is 1 shop out of 11 in that town that WILL... Your simulation will assume that those shop had to close 30% of the month because there is no employee at all ? When, In reality, they'd have to close early just 1-2 afternoon. The situation for those shops would be extremely exagerated and some of those shops might prematurely close. and the situation repeat itself the next month. Statistically, their would be 1% of the building in the city that would experience this 2 months in a row... And on the other side, there is 50% chances that all employee reach the destination the first year. 25% 2 year... 1 out 20 buildings in your city would run 5 years at full capacity without experiencing at all that 3% of employee missing.

You'll lack of data and your simulation will be extremely chaotic.

Isaac Eiland-Hall

I'm not comfortable with where this thread is heading. I'm issuing a mild caution against escalating it.


For the most part, most macro-economic components can be simulated with high-level approximations which will arrive very close to that achieved with detailed simulation with a far lower computational cost.  The goal is a transport simulation, not a city simulator, with more realistic city growth desirable only insofar that the end result is a more accurate transportation simulation.

James is also very cognizant of the fact that every small deviation made from the core Standard Simutrans code causes one more potential issue where future patches will conflict with Experimental and require lengthy conversions to make work, or, worse, not being able to incorporate the patch at all.  Keeping the two at least mostly aligned is certainly beneficial, especially given that James is mostly running solo with development work, with the occasional (and very welcome) assistance from others.  Supplementing the existing code with small changes that enhance the simulation is ideal, rather than daring to change the core simulation.  I'd hate to see the project paint itself in to a corner and fizzle out!

The proposed jobs simulation should work well to address some of the issues that occur presently.  One thing I would like to add to this, which has been discussed many times previously, is a more realistic distribution of industries that are closer to cities (excluding primary resource extraction industries which can remain more widely distributed) to allow for more workers to be able to walk to work, which until modern times was the primary mode of commuting.  Most cities grew in conjunction with local industries, as workers needed jobs and jobs needed workers.  The service and support industries and commercial districts that grow up around these areas can be easily and cheaply (computationally) simulated as a by-product of the residential-industrial jobs relationship.
Current projects: Pak128 Trees, blender graphics


Quote from: Sarlock on January 06, 2016, 07:51:23 AM
For the most part, most macro-economic components can be simulated with high-level approximations which will arrive very close to that achieved with detailed simulation with a far lower computational cost.
I'm curious, to say the least. I'm quite litteraly talking about hitting the data of the building once per month. To do an approximation with " far lower computational cost" you'd need to manage it without even knowing the type of building your approximating. It sounds like a huge hack ^^. Tell me more !

It doesn't have to happen for every building... just once. The tile iteration take care of the tile and the building underneath it. We said it already, for the ram we need 2 bit per ressources calculated per tile. It would be the bottleneck indeed, but we can afford 12-20 ressources like that easily which is more then enough for our needs. I also made a much more complex evaluation of my algorithm. I REALLY need 15 operations per tile (reading the tile, the building beneath it and the data linked to both. I highly doubt you could avoid them anyway if you want so simulate anything)+ 15 per ressources treated per tile. It will be dealt with in split seconds.

I gonna try to explain the statistical problem again. slowly. Let's assume a player run 10 bus in a small 100 building town. He's fullfilling 97% of the job requirements in town. Once per month, one of your 3 job per shop get lost. It's a reasonnably good network. Of course the player doens't really know if it's 97% , 90% or 100% at this point so he's not sure he want to add the 11th bus in the town. This kind of situation will probably be the norm right ?

But here is your problem : The failure (the job not fullfilled) wont wait the 5th month that you get statistical data to appear. 10% of the building in the town will suffer from the lack of job as soon as the first month. You'll have no tools for those 10 buildings to know if they are receiving more then 66% of their job requirement. Actualy, all you know with some confidence at this point from those data is that they receive over 33% of their job per month.  As far as I can tell, if you want a somewhat realistic economy, losing 33% of their sales would be quite catastrophic for those shops. They might bankrupt on the first month of simulation. Worst, one of those 10 buildings will experience a second failure the next month. Please, note that because of the amount of building simulated, we are not talking about a rare event, we are talking about statistical certitude.

it will take about 151 months (, Before every of the 100 buildings have a 50% chance of experiencing their failure. Before that point you wont have the statistical data to know what is going on with those building in a 3% order of magnitude. But we know that every months there will be that unlucky building in the town that experience that double failure event. So by that time you have that data to really compute that everyone is just missing 1 employee per year, 151 buildings out of a town of 100 buildings will go bankrupt. Your simulation will be too chaotic, unless you come up with something else to approximate the job level in the area.


I think that you have made two misunderstandings of the simulation of passenger transport. First of all, you appear (although this is not clear because your description is rather vague) to think that, in any given month, a job slot is either filled for the whole month or not at all. This is not how it works. A building with 3 job slots will accept commuting passengers until such time as it has zero job slots remaining. Job slots will become available again one by one as the effect of the existing commuting passengers elapses with time. The actual way of modelling the fulfilment of job slots does so using a single 64-bit integer representing the time (in internal units) when all job slots will be unfilled. The number of open job slots is thus calculated as a proportion from this as and when necessary (for example, to show in the GUI, or when passengers attempt to travel to the building). Every commuting passenger arriving at the building increases that number by a set amount. Industries also have a separate way of tracking passenger arrivals, which latter system is also present in Standard (which does not have job slots, but has a "boost" system in which industry production is increased when the industry gets more than a certain number of passengers in a month; this will probably have to be removed as duplicating the system that I describe here). Consequently, the system of jobs is rather less binary and rather more smooth than you seem to imagine: the question is not whether one, two or three job slots are filled in any given month, but rather what proportion of the month there are on average how many open job slots. There is a great difference between an industry with 3 job slots having only 2 filled for 95% of the month and having only two filled 5% of the month, with all three filled the rest of the time.

May I suggest - again - that you try playing this version (I assume that you can compile from the sources?) to see how it actually works rather than spending what must be a considerable amount of your time attempting to extrapolate from what I have written, sometimes incorrectly? You seem to write in very emphatic terms for somebody who does not appear to have tested the system (and it is the effect of the passenger generation system, which already exists and has already been tested, rather than the additional features that I propose on which you are mainly commenting).

The second misunderstanding concerns the nature of the consequences of any given industry having unfilled job slots. Currently, there are no particular consequences; the proposed consequences I do set out in quite some detail above. They do not include an industry closing down if it has one unfilled job slot at some point during a month. If a consumer industry has too few employees, visiting passengers would not be able to start their journey to that industry until the number of employees reached the relevant threshold. This is not calculated once a month, but rather in real time, so an inudstry that falls below its employee threshold for 5% of the month will not accept visiting passengers only during that 5% of the month in which that threshold is not met.

I do very much appreciate feedback (and have already noted that your suggestion of a customisable desirability effect is a potentially worthwhile one), but please do try to moderate your tone somewhat: you are coming accross as unnecessarily confrontational, which is really not the way that we like to do things on the Simutrans forum. I understand that people do get passionate about computer games, including Simutrans (which is why, after all, we are here), and it is splendid to see somebody with so much enthusiasm, but people are more likely to look favourably on your feedback if you present it in a more moderate style.

Finally, I note that what you write appears to be in aid of your earlier suggestion of workers counting as a resource and radiating from buildings, but I am afraid that I still do not understand - because you have not explained - how you imagine that that sort of system could work together with the passenger generation system as already implemented and as I have described above. The basic idea - of treating workers as a resource that spreads along roads - seems to me to be incompatible at a quite fundamental level with the core idea of Simutrans, being to simulate the transport of passengers and goods directly, although it might work for certain other kinds of economic simulations. Even if there are problems with the passenger generation system, therefore, there would still not be a reason to implement a system that treats passengers as resources that radiate along roads.
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.


Ok first, yes I promise I'll take a good look so experimental. As soon as I have the machine and the time to give it a good try.

Ok I did the math for 3 travels. You can tell me the real numbers if you want, i'll make another calculation. But I'm pretty sure you don't simulate all the traffic of the month right ? So even if it's not 151 game month, even if it's 24, you're simulation would still either react in sawtooth with extreme event inevitably happening all the time OR you could smooth the teeth by using the means of the data over several months. But then your simulation would be unresponsive. One could delete the road that lead to the shop and the shop would react as if it have the consumers for several months before your simulation catch up...

I'll try to explain the whole system again step by step and trying to avoid the traps of the last time. A certain amount of workforce sprout from the building say 100 units. That gooey substance have a viscosity and it spill slowly on the adjacent tiles. Like tar or wax. Say for simplicity that we made the dissipation speed to 1 and that for every tile covered by our workforce, there is 1 workforce that dissipate. If we let run the simulation run enough we end with a radial area shaped like a cone or a dome that end up covering the 100 tiles around that building. This is actually what we'll draw first when you build the structure as a approximation.

We end with an area where it is possible for the citizen to work. It's literally an heat map of the possible workers with a bit less people willing to go in long distance. One of the advantage of doing this this way, is that we can add the workforce of all buildings and it wont affect the simulation. We get an heat map of the possible workers of all the city at once. For now, we would have got the same exact results by adding the cones of all the building at once. So you can imagine that easily.

Next we could distort the area to account for the road speed. The workers won't walk in a perfectly circular area anymore. Most of them will spill on the road because it offer less resistance to the spilling effect. Since you're fan of realism, you can also reduce the resistance with comfort if you want.

Now if we add a factory that absorb some of the workforce, we'll have a very interesting result. The hole that it will do in our gooey workforce will cause the flow of the workforce on that tick to fall inside the hole to fill it. From uphill down the road up to the apartment building up to the factory that need the worker. You won't obtain the path of any individual worker but you will have a metric of the sum of all the worker who went across that tile. Just like the freight heat map we have. The system, by nature well be a bit elastic.  But once it find the equilibrium it shouldn't create, nor forgive about any workers in the town. They will all find the path to their job, we'll just won't have the path took in memory. We just have the amount of workers who traveled a given tile in a matrix and in the other matrix we'll have how many started from one location or how many landed on it.

Using this data to generate the actual passengers shouldn't be hard and you could of course boost the success of the factories when the player smake the transport themself if you want. From there, you can do much better then just the random "job" or "non-job" passengers that you seem to randomly create; You'll be abe to distinguish the consumers of food from consumers of entertainment as I suggested. I also realized that the commercial desirabilty you wanted would also require the "products" generated from the small factories. As far as I'm concerned, you could also keep track of them and generate the boxes just like we generate passengers. The only limit is the 12-20 "resources" we can keep track of in RAM without really affecting it.


James, I'm trying to explain it in a way you'll understand. If you have an odd of around 90% chance that a job is fulfilled, you'll still have around 10% standard deviation after the first 100 jobs. Your simulation doesn't quite know yet if it's 80% or 100%. Could be anything in that range. This is kinda the minimum acceptable. For 1 isolated shop I guess it would be a decent precision but your simulating hundreds of them, so you're bound to have several of them which will still be quite off. Under those 100 jobs it just become worst and worst. You will have to make a simulation that deal with the fact that it doesnt know if it's 50% or 100% of the employees that are in the shop. After 10 jobs (a months ?) 1% of the buildings will still have no job at all fullfilled.  The amount of uncertainty wont be manageable.

What I'm mean "sawtooth" is that some buisness will be unimaginably successful or unsuccessful for months in a row. An exagerated amount of buisness will go bankrupt if you apply such data as is. And if you wait, for those 100 jobs to be fullfilled, then your simulation will lag for what seem like years (right?). Wont be satisfactory either way...

What I'd suggest exactly is that you'd use the flowing system to satisfy roughly the minimum amount of passenger and job for the buisness to not bankrupt and stay afloat if they have everything they need in a reasonable distance. Every city will have some buildings in difficulty and some buildings on the right spot that are successful. All in all, a city without player assistance shouldn't have any growth rate this way... You will have first to set the taxes and operation cost of the building as you want (the closest to reality in your case) and then tune the flow system to give a % of the total workers and consumers that match the city wide 0 profit goal.

Then you'd create the passenger with different goals using the heat map of the different ressources, the same way you use the heat map of the population to do it right now. The player transport would boost the city grow in the way you expect it.


I really don't think that there's much communication happening here: you write again about businesses becoming bankrupt, but I have noted that there is not proposed to be any mechanism for businesses to become bankrupt as a result of having unfilled job slots. You do not really seem to have engaged with the point about the way in which slots are filled, but it is very difficult to tell because what you write is still exceedingly vague. You still seem to rely on what you wrote earlier concerning uncertainty and imprecision, which, as I explained there, appeared to be predicated on a misunderstanding about how job slots work, yet you do not appear to have corrected that misunderstanding, and have simply repeated in summary form what you wrote before without explaining how it relates to what I explained about how job slots actually work.

As to the flowing system, we still do not have an explanation as to how this is intended to interact with the system of simulating transport directly. As I have written before, it seems fundamentally incompatible with the basic idea of Simutrans. I do not think that you have addressed that.

You also write about taxes on buildings and profit goals; neither of these things exist as features or are planned as part of the city growth or economic integration system. It is very unclear, therefore, how you see this relating to everything else in the game.

I do not know what you mean by creating a passenger with "different goals" (do you mean this to be the same or different to the system of alternative destinations described above?) "using the heatmap". The current system does not use a heat map of population: it chooses origin buildings using a weighted random system based on the number of residents in those buildings. An important part of the system is that it measures the journey time from the ultimate start point to the ultimate end point, including all walking time.

You really need to describe the process with the same degree of precision as I used to describe the current process for it to make any sense, I am afraid.
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.


I'll answer from the last chapter to the first this time.

By different "goals" I meant "motivations". finding a job, a shop, entertainement, etc... I don't think you need alternative destination anyway with this system. If the player don't "scoop" the simulant out to his destination of choice on that iteration. His needs will still be unsatisfied and he will still be there on the next iteration. If there is no player based solution available for him, he will slightly increase his area of research in his neighborhood to find a solution by himself. He will eventually dissipated but I think you can safely leave him there until the next passenger generation.

The amount of population on every tile that's quite close to a heat map doesn't it ? You could use the same system at the start and the destination to identify the exact building affected.

I tough you were quite an adept of realism ? Of course all this have for main goal to help calculate the success of the different buildings in the town. It helps simulate the "desirability" of the buildings in the area, their success (and therefore the total city growth) AND helps generating a better passenger simulation (as you will have a better grasp of their overall motivations without having to generate them randomly).

For how you will simulate the bankrupt etc... from there it will be easy. Every building will have a default for their type and eventualy particular "motivation" needed or affecting them described in their .dat. As part of the flow system, you will hit the data of that building when one need is fullfilled. Summing them to know the % of needs fulfilled would be extremely easy. You will know that this building have 81% of his needs fullfilled this month. Since your not interested into simulating it more then needed, you could go with a general formula that would make the building making profits in a % of it cost when it needs exceed a certain base point and lose money when it doesn't. You could send the taxes to the public service and the profit to it owner if he is simulated and use those as solid metrics for the city growth.

I'm being vague because at this point, we are not really answering the actual problem : generating passengers for the different buildings. I'm just trying to show you that this system i'm trying to describe here would be highly expandable and solve several simulation problems you have about the economic simulation.

The core of the system is a loop that check for every tiles and make a real basic fluid simulation with it neighboring tiles and would help generating better your passengers. That's why I suggest it here.


Hi guys, this conversation is getting to be too long to be read. And neither of you seem to understand the other, and repeating the same arguments over and over.

Ilualvar, your suggestions really sound like reimplementing simcity, where transport (of anything) is only approximated by distance and existing roads. But we simulate transport directly - every individual passenger is simulated. There's no need to simulate some abstract workforce as a resource. And so is for jobs (factories, ind, com), shopping (com, factories at end of chain) and entertainment (com, attractions).

Your idea of some abstract flowing resource may be appropriate for simulating other things that are not simulated directly - especially air and noise pollution. But then it can be very simplified - it spreads evenly in all directions (wind and elevation ignored), and can be calculated once when a building is built, upgraded or destroyed. Then it can be used for city growth mechanism.

I could imagine a growth mechanism as a ongoing compromise between commuting time and pollution. People want to live close to their job (and shops), so that they do not spend too much time commuting (and shopping), but they want to be as far as possible from any source of pollution. The problem is that the source of pollution is at the same place as jobs (factories and transport hubs)... The equilibrium will change during time, as the transport becomes faster, and people could commute from greater distance (cleaner air) within the same time. I hope that this will result in separate clusters of residental and industrial buildings, yet close to each other. Commercial buildings not making much pollution could then appear anywhere. Perhaps this could even enable creation of new towns around newly discovered mineral resources (mines). I think that other "resources" like education, health care, fire/police protection, etc, which are important in simcity, could be omitted and considered as entertainment/shopping opportunities - simulated by "visiting" passengers and appropriate succes/failure rate.

Also you seem to be worried that if a factory with only a few jobs is not fully staffed it will close down or reduce production for whole month. But workers are generated much more often, not only at the turn of month, so any vacant job opportunity has a chance to be filled quickly, as long as there are enough residents around. AFAIK simulated people will take any job as long as it is within their commuting distance. And empty job opportunities should boost the city growth.

However it would be interesting change of simulation to close factory which has no (or too little) workers for long time, as well as if it is not producing.


Iluavar, I am afraid that you really do not seem to be understanding me nor making yourself clear. You appear to be envisaging a radical redesign of more or less the entire game (your last post makes it clear that what you suggest goes very far indeed beyond merely using a fluid system to simulate walking passengers, including a completely new simulation of the financial success of every business and the abolition of the alternative destinations system, which is fundamental to the present model) without any clear explanation as to why that should be necessary, and without a clear idea of how that would fit into the fundamental idea of Simutrans, being a game about the simulation of transport. I do not think it worthwhile taking the discussion further in those circumstances.

Vladki - you summarise the balance between commuting time and pollution well, although I think that things other than air pollution (such as noise pollution and population density) are also relevant in city growth models: people tend to want to live in quiet places where they have plenty of space, and in houses rather than in flats, all other things being equal. Also, the amount of pollution that industry produces changes over time, altering the dynamic of where people want to live.
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.


Quote from: Vladki on January 09, 2016, 10:58:23 AM
But we simulate transport directly - every individual passenger is simulated.
No you're not... You're simulating 6 hours instead of a month. This is 120x less traffic. This will cause the improbable events to happens 120x more often then it should and even worst near impossible situation to happen quite frequently. Like having no employee hitting a specific shop for months in row despite the fact that the network is covered at 90% efficiency.

It would still be viable, if you were simulating 1 shop somewhere. You could live with odd events... But you guys are simulating hundreds of town and impossible events will happen all the time in your simulation.

I feel just like Malcom in Jurassic park trying to explain chaos theory, statistical certainty and butterfly effects to people who don't understand such things. lol.

Quote from: jamespetts on January 09, 2016, 02:53:00 PM
It would be very difficult to simulate noise pollution from traffic without simulating private car traffic on a per tile basis, which is not feasible within the limits of the computational power of any current computer or any likely to be produced in the foreseeable future for the sort of map sizes interesting in Experimental. One could add negative desirability from large public transport hubs (and especially airports), however.

This is rather straying into discussion of town growth rather than the economic integration system set out initially, however.
You'd have an viable approximation count of the amount of traffic on road with the system I suggest. And we already made the maths, I need 1 second calculation on a 1ghz computer to simulate the traffics in a 100km radius of every building in 1 month. The key here is that i'm running the SAME A* algorithm for ALL the passengers.

Don't say it's not feasible....


I'm being vague for the simple reason that you guys refuse to tell me how much trips per month generate a typical building in your simulation. I first made the math with 3 jobs x 2 trips per month. But you told me that I'm wrong and a single job could generate more. But you never said how much more. I highly doubt you generate 2 shifts with 2 trips per shift for every of the 30 day of the month during that 6 hour simulation. In real life, people tend to make more then 1 trip per day and come back home.

I gonna ask the question directly so I get the information. Don't tell me again i "don't understand" if you plan to hide the answer. How much trips per game month do every population in the town do ? I expect 90 for a valid real life homologous.

Isaac Eiland-Hall

I have split these posts from the original thread and locked it. -Isaac Eiland-Hall