Rewriting city growth -- for standard and experimental

[neroden]

So I found that cities were growing way too fast for timeline games.

I found the root source of the problem: cities grow on a tick-based basis, not on a month-based basis, so changing ticks_per_month causes cities to grow faster.   

This, I have fixed on a branch.  However, I don't like the existing city growth model anyway, because i

   
• It's linear, not exponential
• It doesn't allow for city shrinkage

Accordingly I have been planning a new city growth system for experimental.  Overall, cities will grow at a certain percent per year.

Under this system, there will be some new parameters in simuconf.tab.  I was thinking about how to best specify them.  The idea is that the "supplied percentage" (made up of 40% passenger trip success, 25% goods trip success, etc.) will remain the same.  (The congestion level will continue to reduce this number in experimental, as before.)  However, this "supplied percentage" will now map into a city growth rate (a percent), using a linear interpolation table.  Very low supplied percentages will give negative growth, while a 100% supplied percentage will give the maximum possible growth rate.  These would be specified in simuconf tab.

The growth rate will then be applied at every city growth interval, with the fractions being saved and accumulated (because the growth rate will often be less than one resident per city growth interval).  This would eliminate the use of the "villages/cities/capitals" distinction for city growth; because larger cities would automatically grow faster due to exponential growth, it would not be necessary.  (A small boost in growth rates will probably need to be programmed for extremely small villages so that they reach size 100 fairly quickly.)

I was thinking, based on historical numbers, that the growth rate should average out to be about 1-2% (the world historical average), with well-supplied cities growing at 4% and really poorly supplied cities shrinking at 1% per year, as Detroit has been doing.  (Worth noting: in simutrans-experimental, walking is so successful that even totally unsupplied cities have a passenger success percentage of 25%, so I'd calibrate that to match with shrinkage.)  But of course paksets could set whatever they liked, depending on how long a timeline they were planning to run with and how fast they wanted growth to happen.

It may be worthwhile to specify the overall growth rate from a timeline, as with electricity, but I'm not sure this is worth the complexity.

I wasn't actually planning to implement city shrinkage just yet, though I want to eventually.  To do it well, it requires the concept of a *vacant building*.  For now I was simply planning to have the population drop as appropriate while leaving the buildings in place, meaning that more growth is required to get back to building new buildings.

I hope this meets with James's approval as it seems like another step in the direction of realism.

I'm not sure whether the standard developers would be interested in such a complex growth system.  It would be nice if they were interested in it; otherwise I will provide a different patch for standard which retains most of the existing system, but corrects the growth rate so that it doesn't accelerate whenever bits_per_month is made larger.

---
This requires a savegame version increment in order to save the "less than one passenger" growth.  I currently have it written to trigger off a change in the standard savegame version.

[kierongreen]

Personally I'd be interested in the concept of vacant buildings. For one it would be a whole load new graphics to draw and we could have derelict neighbourhoods as you see in SimCity (that is, that when cities are shrinking buildings next to a vacant building are the first to become derelict). Regarding exponential vs linear growth, would have to see how this actually worked in practice, and correcting for bits per month for growth should be option in simuconf maybe.

[prissi]

City growth is somewhat exponential in simutrans; but then it is rather too fast and hence the multipliers for 100, 1000 and 1000 inhabitants are lowered to avoid fast growing megacities (which an exponential increasing growth would lead to). Imho most cities settled finally at a certain size after a phase of exponential growth.

One could make this ceiling dependent on the initial size and any further growth would be much much slower. But there is certainly a lot of possibilities here.

[jamespetts]

Thank you for sharing your thoughts on this - this is an important topic that needs careful consideration. As some people may know, my particular interest in city growth is getting local growth right so that cities grow specifically in the areas well served by transportation, and more densely in better served areas, and not at all in areas that are insufficiently served with transportation to be sustainable, on the basis of success rates for transport (mainly passenger, but non-residential buildings might well take into account the success of neighbouring industries in receiving goods, too). The relevance of transport on how cities develop is very great, and so this is important to model.

However, as Nathaneal also points out, we also need to consider not just where growth happens, but we need to calibrate how much growth to have overall, and doing so on the basis of historically known growth rate ranges (customisable in simuconf.tab) seems in principle a very sensible way of doing this. One problem with the existing system in longer games is that, after long enough of growing, towns will all eventually get to the "capital" size and grow at the faster rate.

I wonder, however, whether we need to zoom out one step even further: would we not do better to abandon entirely the notion of a growth rate being attached to a particular city, and have instead a global growth rate, with local transport deciding where new buildings are built or old ones upgraded? If there is, as we need to have, any element of deciding how much to grow based on what city that a building is in, an unnecessary and economically distorting layer of abstraction is added to the simulation that need not be there. What we really need to do is ask two questions: (1) how many people/businesses are entering our global region (whether by birth or migration); and (2) where those people/businesses are going to live/be established. Real world economic decisions about these things do not respect town boundaries. We need a model in which the West of town A and the East of town B can grow, whilst the East of town A and the West of town B can shrink simultaneously, based on how well connected with transport that individual tiles in that city are (or are deemed to be based on how well connected that neighbouring tiles are). A model that bases growth of a city on an average level of connectedness (transport success) of a city as a whole is too inaccurate where coverage in that city is uneven. (Also, it is common for the boundary of one city to be closer to the boundary of another city than to the other side or even the centre of itself).

Devising a system to distribute growth based on transport success rates is in principle relatively straightforward. Conceptually more complicated is working out what regional growth should be: growth is not, of course, always positive - consider Ireland, where, traditionally, there has been a trend for negative net migration (i.e., more emigration than immigration). Growth in population is based in part on the birth rate, but also in part on emigration/immigration, the latter of which is strongly influenced by the strength of the economy, which, in turn, is influenced by the quality of transport infrastructure.

Thoughts as to where to start on such an endeavour would be most welcomed.

[ӔO]

global growth rate is somewhat predictable.

I would suggest there be a comparison between predicted target rate and actual growth rate.
Predicted target global growth rate should be between 0.5% and 2.0% per year, possibly randomly.

If predicted < actual, then the game should subtract population off of the poorly connected cities in the following month.
This would be like people residing in two cities finally selling off their old property and taking permanent residence at their new home. Historically, this used to be the case, when farmers immigrated to cities.

If predicted > actual, then the game should add population to cities with high demand for workers.
This would be the immigrant workers looking for a new life in places with readily available jobs.


I would suggest freight be weighed in as well. Cities grow very rapidly when there are a lot of jobs available, but dwindle and stagnate when those companies close shop. The most recent example would be Detroit that closed down its factories. Previously, it used to be coal mining towns.

[jamespetts]

The concept of "cities with high demand for workers" is a little troubling, I think, because a city can be very large, and different parts can have different levels of demand: the boundary of one city with high demand can be closer to the centre of another city with low demand than to the actual industry within its own boundaries. Averaging demand accross an entire city loses vast amounts of important information. What is really needed is to use per tile passenger success rates to find the best connected places (success rates taking into account that only a certain number of passengers per month can get to any given commuter target before all the jobs have expired).

This also leaves open the question of how actual growth is calculated if not on the same percentage as the fixed growth which seems to be the basis of "predicted" rather than "actual" growth in the proposed model.

[kierongreen]

One thing to keep in mind is that we need to also model the historical growth of towns resulting from migration from the countryside. Hence we aren't just looking at population growth overall but urban population growth - or rather rural population vs village population vs town population vs city population...

[jamespetts]

An interesting point - and further complicating this, we need to consider what counts as a village: do we actually simulate all the villages in Simutrans (at least, in Experimental with a low meters per tile setting) by having lots of "cities" with small populations? According to Wikipedia, a village can have anything from a few hundred people to over 10,000 - well within the range of town sizes that we see in Simutrans.

[kierongreen]

Ah but there are (and were in the past many more) hamlets of only a few houses which aren't simulated in either standard or experimental - not to mention isolated houses.

[Jando]

Interesting topic, please forgive a newbie like me to chime in. 

I agree that growth has two aspects: global growth and local or regional growth or shrinkage. I believe global growth is rather easily solved by just using real world numbers like for example in: http://en.wikipedia.org/wiki/Demography_of_England. Just apply the percentages listed in that article as global growth.

Now, the more interesting question remains: where does growth happen? Without doing any research on the topic I tend to believe that historically it's largely jobs, factories, businesses and supply of goods that determined what regions grew or not. Apart from commuting - and commuting is a rather recent trend that started a few decennia ago - good passenger services played a very small role in migration, if any at all. Personally I'd like migration in Simutrans to be modelled the same way. Otherwise we'd get the rather strange effect that a slum of hovels grows into a thriving neighbourhood because the player runs a dozen buslines there that nobody uses anyway.

Of course with making industries the driving factor behind local or regional growth we run into another problem: the distribution of industries on the map, both new industries and the ones generated during map generation. This seems to be largely random, with some towns getting no industries at all, others getting a few - and smaller towns and villages getting proportionally too many industries compared to larger cities. Not to speak about the industries that are in no town but are placed somewhere in the middle of nowhere along an intercity road. And of course we have to consider that Simutrans (or rather the Pakset?) doesn't really have any inner-city businesses, though the town hall could probably fill-in for that.

Sometimes I wish the game would not place any industry at all but rather pick a region of, say 30x30 tiles and let the player place the industry anywhere within that space.

[kierongreen]

Also some players just like to focus on passenger transport so they should be considered (i.e. some growth at least should be achieved just transporting passengers)...

[jamespetts]

As to hamlets - that is interesting. Does anyone have historical figures on how many people lived in them or on farms as opposed to in villages?

On the subject of using real historical growth figures, the problem is this: much of that growth might itself have been related to the strength of the economy, which in turn was sustainable only because of the quality of the transport network. If a player does not in fact have such a good transport network as England had, why should the population grow by the same amount? Population growth is strongly linked to economic growth because of immigration/emigration (and partly because of a link between the economy and the availability of healthcare).

[waerth]

Also some players just like to focus on passenger transport so they should be considered (i.e. some growth at least should be achieved just transporting passengers)...

Yes that would be me. I really hope that experimental stays playable for people whom only transport pax.

I do not like transporting goods really as it leads to messy networks. I might consider it if we could get industrial zones so all industry is placed in one area of a city instead of spread all over the place. Same goes for shops I hope we get to a point where thet will be places in centers of towns and cities

[Jando]

Also some players just like to focus on passenger transport so they should be considered (i.e. some growth at least should be achieved just transporting passengers)...

That's a good point there. Agreed. Some very fine balance might be needed.

I play in the early years, mostly starting in 1800 and, especially with version 11.x, there are few passengers to transport during the early years (and, just for the record, I believe that's designed very well). Basing growth on passenger transport during these years would probably mean little growth at all, while historically these years show a large increase in population.

[isidoro]

To make a village grow just because the player happens to place a high-speed train station and two airports seems rather artificial to me.  There has to be something else.

And that something is already in the game: touristic attractions and well served industries.  Even if you don't transport goods you have touristic attractions.  If the player wants a place to develop, he can just place a new industry or attraction there.

In history, places became important because they had natural resources (it would be very nice if coal mines were founded in mountain regions only), industry, strategic places, etc. or in crossroads between those.

The final question is: since the game founds new industries/attractions based on population, we have a loop here...  but that's good, isn't it?

[jamespetts]

One issue in the original post, incidentally, on which I have omitted to comment is that of town shrinkage. I think that this is a very good idea, as there are towns which were once industrial centres that have dwindled once the industry has left. As to how to deal with building abandonment, one could borrow an idea from Sim City 4 - alter the graphics to make the abandoned buildings darker (strictly, SC4 used alpha blended textures, as they used a rendered system rather than sprites - I am not sure how well that this would work in Simutrans, actually, but the alternative, having to draw an "abandoned" graphic for every building, does not bear thinking about).

[prissi]

You can darken buildings easily, just display_blend with and image and a light grey color; it will impact the drawing speed, but then experimental users seem to have stronger machines anyway.

[jamespetts]

Would that extra work in the drawing code be multi-threaded such that it would not be done by the same thread as the main simulation?

[kierongreen]

No - but on the other hand you could make a copy of all images then darken those. Although that might look quite strange for snow images (as well as some others).

[jamespetts]

Hmm - hadn't thought of snow images. That makes things harder. Sim City 2000/3000 used a limited set of "abandoned" graphics for different building sizes - that approach was far from ideal, but I wonder whether it could work here?

[kierongreen]

Could look a bit odd. Where did that new now immediately derelict building spring from...

[jamespetts]

It was reasonably clear in Sim City 2000/3000 if I recall correctly, but looked lacking graphically.

[wlindley]

makeobj could take the existing regular and snow images; take any pixels which differ in the snow image and keep those changed pixels aside as "Just the snow, please" -- and then darken the remaining pixels for the abandoned versions.  Possibly with the exception of green tones, for where tiles include trees or grass.  But we do get rather an explosion of images that way...

[kierongreen]

But we do get rather an explosion of images that way...

Yes... Sooner or later that's going to cause a problem. It's worth noting that there are "only" 130 odd city buildings in pak128.Britain. Almost all have 4 rotations, and snow images though so that becomes over 1000. Add derelict images for both and that's another 1000. Though 1000 concerns me less than the potential number with the various suggestions for ways/bridges (which could easily add another few 1000 images).

[ӔO]

How about a grey scale filter?

The building wouldn't look terribly out of place in both summer and winter, but would look different enough from other buildings.

Even concrete buildings have some yellowish colours to them, so it should adequately satisfy looking different from active buildings.


Sepia might work too.

[Sarlock]

Been away on vacation the past few days but I have been wanting to chime in on this discussion.

re: Abandoned Buildings

There would need to be some experimentation... the optimal solution might be an image mask that is pakset dependant so that each pakset can draw its own abandoned building image mask based on the style and colours used in its artwork.  You'd probably need two masks: one for regular and one for winter/snow images.  The winter image will want to retain its bright white colours and darken/subdue the other colours.  Muting the brighter colours of the artwork (reds, blues, etc) would probably do a nice job of making an area look economically depressed/abandoned.

It's not ideal (SC4 had a much better model, but that requires an entirely different graphical system) but it would work.  Seeing an industrial area half greyed out because of poor economic conditions would be pretty neat.

There could be a Settings option to turn this graphical effect off for computer performance reasons.


re: City Growth

We have to be careful to balance an improved system against keeping it simple enough to understand.  The game is about transportation networks, not city management, so the city growth has to be intuitive and uncomplicated.  The growth has to be a secondary result to good transportation construction: build a good network and the city grows, don't and the city doesn't.  Not only does the city growth seem more organic and logical but it also gives an improved visual reward to the player for a job well done.  Decentralizing city growth from the city hall to around well served transportation hubs would be a good first step.  That said, it has to be a bit more complicated than this to get the desired effect, otherwise city density will just "clump" around the transportation hubs.

I like the idea of a global growth rate limiter.  This should be more aggressive in the earlier stages of the game when the player is rapidly expanding their network and then slows down as the network becomes more mature.  Then within the map this growth is distributed based on the numerous factors discussed above.  Done correctly, this would naturally give rise to a few key "central" cities that grab a lot of this growth and then other areas that hardly grow at all or even decline because they aren't getting much, or any, of the share of the global growth.

[jamespetts]

Hmm - I am not sure whether a mask would be practical, or a greyscale filter for that matter, but I have no experience in graphics programming, and do not know what would be entailed. Another possibility, I suppose, would be a Sim City style "zot" (an icon above the building indicating abandonment), but that might work poorly with tall buildings. A further, perhaps more practical possibility, is some sort of "for sale" sign graphic appended to the road-side facing part of the building, which might actually be quite effective, but I do not know whether this would be feasible. It would, I think, look better than making buildings greyscale, which would detract from the realism of the visual environment.

As to growth generally, my view is that the easiest things to understand in a simulation game are those that most accurately simulate reality: it is much easier for players to apply their knowledge of real life to a game than it is for them to try to work out how the game, which purports to be a simulation of reality but in some material respects is not, works. Players should be able to abide by the rule of thumb that, if it works in real life, it will work in the game. The system that I am planning for growth distribution (which is different to the overall calibration of growth) is for growth to occur in residential buildings that have a high success rate (that is, a high rate of passengers who want to make trips that succeed in doing so), for industrial buildings, have a high proportion of their worker demand fulfilled and are near suppliable industries that are well supplied, and for commercial buildings (and end consumer buildings) have their visitor demand level met or exceeded. Geographical proximity will count for nothing: only transport based statistics (in other words, functional proximity) will count, with the possible exception of not citing residential buildings near industrial buildings for environmental reasons.

There is much to be said that, once the global growth is calibrated, decisions as to how to distribute that growth should be based on a map-wide assessment of transport success rates (with some element of randomisation, perhaps), without having growth rates set at the city level at all (as the abstraction of a "city" has no actual economic consequences for where development occurs: it is functional proximity (i.e., travel time) to resources, including human resources, that counts).

[kierongreen]

Creating copies of images that are grey scale or even just reducing saturation is certainly possible. Sepia tones should be doable too. However there's only so far you can take the programming side before you start enforcing a standard look on all paksets. That was one reason I made lightmaps and transition textures when first adding textures. It would have been possible to just generate these in code but then all paksets would have exactly the same look, which might not be great for the comic paksets for example.

[Sarlock]

Adding a zot or sign is certainly possible, although I wonder again about whether this would look right.  Perhaps we just have to accept that abandoned buildings do not have a graphical representation.  It doesn't have a direct impact on gameplay, it is only a graphical cue to the player that an area is poorly served... which is indicated by lack of growth.  I do like the idea of negative growth impacting an area that was once prosperous, however.

once the global growth is calibrated, decisions as to how to distribute that growth should be based on a map-wide assessment of transport success rates (with some element of randomisation, perhaps), without having growth rates set at the city level at all (as the abstraction of a "city" has no actual economic consequences for where development occurs: it is functional proximity (i.e., travel time) to resources, including human resources, that counts).

Well said.  A well constructed growth system would have cities develop in areas with good economics.  With a global growth rate there becomes competition between various areas for the limited amount of growth available: areas that are well served will grow faster, areas that aren't do not.  It could also bring an element of competition between players for growth factors, wanting the cities that they serve to capture most of the available growth.  Climate/location should be a factor: the reason why most mining towns never turned into thriving cities after the mine closed was because of their poor geographical location-they had little other economic reason to exist in that spot.  You can provide all the transportation you want but it still won't help.

[jamespetts]

The climate/location thing is an interesting point: that would have to be a separate addition that would affect (and restrict) how industries are placed: the system that I am planning should be capable of making the placement of industries then have a cascade effect on the rest of the economy, at least until a substantial number of commercial buildings have come about.

What do people think of the "for sale" sign idea?

[waerth]

For sale sign is a good idea

[ӔO]

the only problem with a "for sale" sign would be that it would require a different image for each language or region, since they tend to differ from place to place.


How about incorporating it into the hide buildings filter?
City centers, public property, industries and unowned buildings are given their own colour, so how about adding another one for abandoned or occupied buildings?
I would suggest a brighter grey for occupied, while keeping dark grey for abandoned.


one caveat would be if the player unchecks "hidden items appear transparent", but it's already impossible to distinguish all buildings when everything is hidden in that setting.

[jamespetts]

Ahh, but the graphics are so small, one wouldn't be able to read the text: just see that there was some text, so there wouldn't be a language issue here. Showing them in a different colour when hidden is also a good idea (as well as, rather than instead of, the for sale sign - if that can be made to work).

Edit: One further consideration, not about the graphics but more generally, is this: the interaction between the global and local growth. The best thing, I think, is to have a global growth rate set in simuconf.tab, which becomes a potential or maximum growth rate. However, new buildings can only be built (and existing buildings upgraded) if the local transport success rates are high enough. If the local transport success rates are too low, the building will become abandoned irrespective of any global growth potential (one matter for consideration: should a large building be downgraded to a smaller building or merely underoccupied if the success rates are poor, but not poor enough for abandonment?). The demand for new buildings should be set monthly (or perhaps dynamically) based on the current population, so that if there is insufficient transport network to allow the relevant potential growth, it is lost forever, rather than building up only to burst out all at once when the transport improves. This way, it will be possible for global growth to be dependant on transport quality, and allow even negative global growth (emigration) if the transport network is sufficiently poor.

[prissi]

For sale signs are not something common to all countries. In germany you see those only rarely.

[jamespetts]

For sale signs are not something common to all countries. In germany you see those only rarely.

Ahh, interesting. Is there any other sort of overlay graphic that might be used for regions such as Germany, do you think, so that the same graphical system could be used, with different actual graphics depending on the pakset?