Tiny City with Huge Population

[bpm860]

Hi all; I recently created a new map under Experimental 10.0 with 28 cities at a median city size of 25,000 and this city was generated:




Notice the population; 139,000 citizens with only 68 small buildings?  Will more buildings appear quickly?  Or is this a bug?

[dc_ae]

Yes,
when you get your lines running the city will start spreading and getting really big.

[Carl]

Note also the large "homeless" figure. This indicates that only 1,800 of your citizens are housed. This can happen when the city can't find anywhere to put extra buildings to house all its citizens. Though from the picture you've uploaded, that seems rather strange. However, certain values in a pakset's cityrules.tab can lead it to stop expanding even when there's room to do so, I think.

[jamespetts]

What pakset are you using?

[bpm860]

Pak128.Britain (with the pak128 trees and ground textures).  Starting year was set to 1940.

Edit:

A tangential question about city growth:   If I build road bridges across a river like in the above screenshot, will the city expand across the river on its own? (What if I build them as the public service player?) This is one thing that always disappoints me with large cities that only seem to stay on one side of a river when created on a new map...

[prissi]

If the city build an attraction, a factory or relocates the townhall on the other side, yes. This is the only way when there is a straight river. (That requires of course an existing bridge.)

Otherwise, if the rivers bend and parts of the other side came into the city borders, then it depends very much on the availability of ways and the cityrules of the pakset in question.

[infernalmachine]

That's a very odd picture.  On the left side of the town, there appears to be 2 sections of a farm field (which would explain why the town can't expand that way), but no farm buildings.  On the right side, across the river, there seems to be part of a Tree Plantation.  It's as if the industries have been built below ground with only parts showing.

Not sure if this means there's a problem with the industry placing code, or whether it's just a problem with using the pak128 trees/ground in a different pakset.

As to getting the city to "cross" the river, I usually build at least 2 bridges and place a route which has stops on the bridges.  Make sure to place the bridge stop so that it covers both sides of the river. As soon as the stop has passengers (from the near side of the river), it increases the likelihood that houses will be built near the stop on the far side. (If the stops are only touching tiles on the far side, the city won't normally spread to them across an obstacle, except in the fashion prissi mentions.)  This technique also works for expanding a city over rail lines.

(I've only thoroughly tested this technique in Standard.  Not sure it works the same in Experimental.)

[prissi]

Passengers are generated by houses. The presnece of a stop is not used in current cityrules, as far as I know. Thus the probability for houses should not depend on bridge stops.

[infernalmachine]

I generally use pak128.open.  The current cityrules.tab has 5 of its 16 house rules relating to stops (symbol 't' -- 's' is street and 'n' bare land). Example rule:

Code Select Expand

##
# . . . . . . .
# . . . . . . .
# . . . . . . .
# . . . n . . .
# s t s . . . .
# . . . . . . .
# . . . . . . .
#
house_15 = ....... ....... ....... ...n... sts.... ....... .......
house_15.chance = -2

But other paks may differ.

[jamespetts]

Pak128.Britain-Ex (and the Standard version, too - both, I suspect, copied from Pak128) has something similar:

Code Select Expand


## House near a stop
##
# . . . . . . .
# . . . . . . .
# . . . . . . .
# . . . n . . .
# . . s t s . .
# . . . . . . .
# . . . . . . .
#
house_12 = ....... ....... ....... ...n... ..sts.. ....... .......
house_12.chance = -2
##
# . . . . . . .
# . . . . . . .
# . . . . . . .
# . . . n . . .
# . s t s . . .
# . . . . . . .
# . . . . . . .
#
house_13 = ....... ....... ....... ...n... .sts... ....... .......
house_13.chance = -2
house_14 = ....... ....... ....... ...n... ...sts. ....... .......
house_14.chance = -2
##
# . . . . . . .
# . . . . . . .
# . . . . . . .
# . . . n . . .
# s t s . . . .
# . . . . . . .
# . . . . . . .
#
house_15 = ....... ....... ....... ...n... sts.... ....... .......
house_15.chance = -2
house_16 = ....... ....... ....... ...n... ....sts ....... .......
house_16.chance = -2


[bpm860]

That's a very odd picture.  On the left side of the town, there appears to be 2 sections of a farm field (which would explain why the town can't expand that way), but no farm buildings.  On the right side, across the river, there seems to be part of a Tree Plantation.  It's as if the industries have been built below ground with only parts showing.

Here's the city from another angle.  There are only two farms - one small orchard across the river and a farm to the south in this screenshot:



I guess I will keep playing with this map; so I should expect a huge building growth boom once I start connecting the industries in this town?  What other things can I do to get the homeless population into houses?  Thanks for all your help!

[infernalmachine]

Pak64 doesn't have stops in any of its house rules.  That must be where the misunderstanding comes in.

@ bpm860

Sorry.  I got confused by the ground textures into referring to pak128 farms and tree plantations, and forgot that pak128.Britain industries are smaller (and different) from pak128.

The "fields" I was referring to (which aren't fields) are the two rectangles at the right of the city in your second picture.  What are those?  They appear to me to be the main reason (after the rivers) that your city stayed so small.

Houses like streets (and in the pakset you're using stops too so the bridges over the river with stops will help) and also other houses. In the pakset's config directory, the file, cityrules.tab, has the rules for how cities grow.

First there is a renovation percentage which is the likelihood a city will grow up rather than out (it defaults to 12%). Now assuming that renovation is more than just cosmetic, then the population density of your current houses should increase (is that what actually happens, anyone?) and some of your homeless will be housed downtown.

Then there's the minimum building density (default 33%) which means that houses (and probably streets too) will not build themselves until the density reaches the minimum.  But that begs the question of how that density is calculated, which I can't answer.  Is it a local population density, or citywide population density, or local house density? I'm guessing the last of these -- count the number of houses within an n x n square centred at the potential building spot.

Anyway, it means that city spread is gradual. And also that streets and houses never build themselves away from towns. (Presumably, if you set this value to 5 or less, you'd get rapid spread with low density -- I'm not suggesting this as a solution though.)

Then there are weights that discourage houses and industry being built next to each other.

The rest of the file is rules for when and how houses and streets are built. On their own, they're a bit misleading unless you remember the minimum density requirement.  These rules never fire out in the country.

The house rules all include streets (and some include stops as well), so that indicates what you can do to encourage building of houses.  Extend streets a couple of squares out of town, build bridges over the river and stops around the edges of the town which cover at least one existing house.

If those rectangles I mentioned earlier are lowered land, then flatten those because they are obstructing streets from being built which in turn leaves nowhere for new houses at that end of the town.

Let us know how your city develops if you keep playing that game.

[bpm860]

Thanks for your reply!  Those two rectangles are actually tourist attractions - football and rugby stadiums.

Regarding the renovation percentage; this may have been a bad idea, but for this map I set it to 85%.  It had previously been at 43% (or whatever the 128.Britain default is..) but I found that all of the cities being generated at that lower setting lacked downtown cores.  They just looked like sprawling suburban messes with endless low-density residential buildings stretching for miles.  In an effort to get some high-density skyscrapers downtown, I thought I would try changing it to 85%.  Although, now that think about it, maybe I shouldn't have expected any large downtown buildings since the starting year I've chosen is only 1940?

[jamespetts]

Ahh - this might be the issue. There is an era in Pak128.Britain when higher density buildings are currently missing entirely, and I think that 1940 might well be in that era.

[bpm860]

Ahh - this might be the issue. There is an era in Pak128.Britain when higher density buildings are currently missing entirely, and I think that 1940 might well be in that era.

Ahh, that would make sense.  I'll try creating a new game with the same settings in the year 1990.

edit: This seems to be the case.  Here's a city in the year 1990 with 85% reovation_percentage:

[jamespetts]

That looks better! We do need more 1920s - 1950s high density buildings...

[Milko]

Hello

Ahh - this might be the issue. There is an era in Pak128.Britain when higher density buildings are currently missing entirely, and I think that 1940 might well be in that era.

Yes, about 1930, look at this discussion

http://forum.simutrans.com/index.php?topic=7721.0

Giuseppe

[infernalmachine]

Interesting, although it's a bit too stark a contrast with the surroundings for my taste.  That said, it really does look right for the city centre.

At first I was going to suggest trying 70 or 75 as a value to get a bit of a suburbs, but then I had a different idea.

What if the cityrules.tab contained 3 values for renovation -- an initial value, a second value, and a transition time in months between the two?  This would allow (with code changes of course) the values to oscillate between the 2 values (using linear interpolation) as the game progressed.  There would be times of spread alternating with times of consolidation, which might duplicate a similar phenomenon in the growth of actual cities.

This might also improve gameplay.  It does get a little tedious, I find, to constantly add outer limits stops to very large cities and change routes to serve them (it's particularly annoying when the city starts spreading again as soon as you've added the stops and updated the routes -- especially if you're extending tram lines to do this). Actually, it would be even better if the oscillation only started when the town reached a certain population.  This way, different cities would be spreading or renovating at different times. (but the coding would be trickier because you'd need to keep track of each city's oscillation state, and that's also one more value in cityrules.tab).  At the other extreme, I imagine that being stuck at a very high value for a whole game might be a little boring if you enjoy the challenges of designing good city transportation networks, because the city's area would increase extremely slowly.

One question though.  Is the high-density of housing in the above picture matched by an equivalent high level of passengers and mail? I guess it is because the buildings chosen by the game here will all have higher passenger level. But then there's the question of how to transport passengers/mail within the city. I'd guess that if the whole town doesn't fit in one stop/station's catchment area then trams wouldn't have the required capacity within the space provided, so you'd be using subway or rail with only 2 or 3 stops.

[jamespetts]

Yes, to answer the question, the larger buildings are indeed matched by a (considerably) larger level of passengers/mail. There is something to be said for a  more sophisticated balance between renovation and sprawl, but I think that it needs to be less arbitrary and have a more specific, realistic economic basis if it is to be implemented. I am not sure what that basis might be at this juncture, however.

[infernalmachine]

Glad you brought that up.  I did also think of an economic basis for changing the value, but I guess I was more suggesting this for Standard, with the expectation it would be superceded in Experimental with reference to your economic model.  And even then, you could still use the upper and lower values for renovation as user-settable limits or parameters to whatever your model implemented, letting them specify the kinds of cities they want, just as bpm860 did.

EDIT:  Also, I do think that flight to the suburbs versus flight from the suburbs is driven by more than "only" economic factors. I do actually believe these oscillate according almost to fashion (ie generationally), as well as simply because things do tend to oscillate when they reach a level of saturation.  Also, I live in North America (Toronto, Canada, in fact), and the nature of growth here may be quite different from Europe or Asia, because people tend to move around a lot compared to other places.

[jamespetts]

May I ask - what is the economic basis of which you thought? As to fashion, could this not be dictated by altering the "chance" value of low versus high level residential buildings in certain eras?

[infernalmachine]

Honestly, I hadn't really thought about it beyond the phrase "economic factors".

But, if pushed, I'd guess there is first the idea of people moving to where the jobs are.  But I'm not sure if the randomness of factory placement is what we'd want to hitch our wagon to. Perhaps it would be simpler to have people move to where the most people live. This assumes, of course, that it's possible to model population movement. (I may be ignorant of how Experimental is currently or intends to make factory placement less arbitrary.)  Then there's of course the issues of birth rate and immigration from outside the map) which would be influenced by economic factors, although it would be difficult to do much with those without introducing "class" or income levels into the sim.)

Then, I guess, there's the whole issue of property values. Presumably suburban living is generally more expensive (with exceptions) than downtown living (also with exceptions), so the homeless and unemployed as less able to move out of the inner city (ie those rates in a city being high should reduce spread, but not too much since a homeless employed person wants and can/will pay for a home).  Anyway, homelessness and unemployment (and possibly population movement/birth rate/immigration) would be useful forces to influence the supply and demand for various types of property, along with transit availability, attractions, factories, etc.)

I suppose one approach would be to create an actual property market in game using the value of real estate, which I believe is already minimally in the game, and expand upon it.  Build (or renovate) only according to the supply and demand for various types and location of property, influenced by the larger forces mentioned above.

The nice thing about creating an actual economy in real estate (as opposed to merely modelling/generalizing it) is that this might open the possibility of later introducing economic "classes" into the game, both in terms of people living at particular tiles or working at factories or visiting various attractions, and in terms of different levels of transportation classes in the actual vehicles (and prices paid).

When generating a new passenger, their location would probabilistically determine their class and destination, which in turn would directly (according to rule, not probability) determine their possible class of conveyance.  I've been musing recently about having 3 classes of passenger transport and 5 or 7 classes of people.  With 5 people classes you might say that Class1 people only take ClassA transport, Class2: A or B, Class 3: A,B or C, etc.  Basically a more sophisticated version of what was tried in pak128.japan with the taxis/busses with some small success (imho). This would also somewhat mitigate the downside to the shortest path issue in trip planning which prevents variety in connecting two cities. (For example, if 2 distant cities are connected via rail, you can't also connect them by air unless the airports are attached to the stations -- again, not sure if Experimental already "fixes" this.)

I got thinking about this from several sources. First pak128.japan's use of 2 passenger types of cargo.  Then there's recent games (either CitiesXL2011 or more likely Cities In Motion) that have used these passenger/vehicle classes in an interesting fashion.  Also, here at the forum there's been some discussion of fixing the speedbonus problem for high speed trains (HST) and air travel in pak128 Standard.  But mostly, it was reading a recent BBC article asking if HST was just "a rich man's toy" in Britain these days. Also, perhaps of particular interest to pak128.Britain rail travel, where are the 3 classes of carriage which defined European early passenger rail (along with the cool steam locomotives of course)?

This got me thinking that it's fine in 128 to pay exorbitant rates for HST and the fastest planes, provided that only a small percentage of passengers being moved game-wide are actually travelling that way.  Similarly, it would be okay to have steam locomotives and old liners (ships) well past 2000 (assuming they become much more costly to run as time goes by) provided they become luxury means of travel only used by the same small percentage of travellers.

(I suppose I'm implicitly suggesting that, in Experimental at least, it might be possible to ignore fixed obsolescence dates, and generate them instead within the "economics" of the game. The trick here would be to move the increasing maintenance curves (yes, curves, not just linear) from obsolescence date to introduction date. Also, maintenance might start higher (breakdowns etc, then decrease, then later increase. A vehicle would become obsolete only when its expected ROI became impossible to meet within the game.  I'm also still intrigued by sdog's idea to bring in labour costs into the picture wrt maintenance, although I quibble with it being all fixed cost monthly. In fact, bringing in class of person into the economy and game might actually help to generate the cost curve internally?)

To sum up, I think that creating a real estate market might be the best way to go in connecting the economy to city growth behaviour.

'Nuff said, for now.... 

[jamespetts]

A market for real property is certainly an interesting idea, although modelling it in Simutrans is, to say the least, a non-trivial task. If there is a land value model - on what would it be based? We need to be careful not to diverge entirely into a Simutrans version of Sim City (Simucity? Micropolis-trans?), as this would be overdiversification and make the game unfocussed, difficult to learn and hard to maintain. So, a simplified version of a market in real property would be necessary, relating only to factors that are really relevant in the game. The proximity to well-served stops (rather than proximity to served stops simpliciter) would be one way to go (although coding even that would likely be very complicated), and proximity to similar buildings, the town hall or attractions might also be relevant (although the latter is already largely set by city rules). If land value were simulated, then it should affect the costs to the player of building on that land, of course.

As to different classes of passenger, this is more problematic than it first seems. Firstly, it would be necessary to simulate from the ground up the economy of wealth levels (I suspect that having fixed classes would introduce arbitrariness; there is no reason not to have an income level figure if one is going this far). There would have to be a really rather complicated set of factors governing this, none of which directly relate to transport. Next, the classes/income levels of passengers would have to be mapped to transport. Using an exclusive type model (above income level X, only consider travelling first class, below income level X, only consider travelling second class, etc.) is much simpler to implement (as the Pak128.Japan people demonstrated with replacing mail with first class passengers), but is seriously unrealistic. Buses and urban metro trains do not have different classes, and many suburban trains also do not. A three class system would work well enough for 19th century rail, but three classes had collapsed into two in the UK by the early 20th century (starting with the Midland's efforts in the 1870s to improve the conditions of third class so much as to be equivalent to second class, and abolishing second class entirely), and there were some places in the 19th century that had four classes, the fourth class being poorer accommodation than third class, intended to compete with very slow but very cheap canal traffic (which also had no separate classes). A simple method would fail here, even if one simplified to two classes.

In theory, a solution in which a cost/benefit analysis is performed by each passenger packet for each route taking into account comfort, journey time, cost and income would work well and be highly realistic, but this approach has two - probably irremediable - problems. The first is computational load: the path-finding system (that is, the system that determines which route that passengers/goods take from their origin to their destination) is a highly complex and computationally intensive process. It accounts for a considerable proportion of all CPU resources consumed by Simutrans. As such, it is highly optimised (in Experimental, by some very sophisticated code written by Knightly; in Standard, the path-finding is simpler even than the fastest journey time method used in Experimental for exactly this reason, and Standard is less computationally intensive than Experimental partly for this reason). Adding in other factors to route finding (such as cost and/or comfort) would greatly increase the computational load and possibly also memory consumption, and probably reduce the performance to unacceptable levels, especially on large, well-developed maps on servers (which have to run with limited and often shared computational resources). Furthermore, once cost is brought into the equation, an incentive to micromanage to an unacceptable level is introduced. If people are choosing to take the 'bus between towns A and B more than my train because my train is more expensive, I should be able to make my train cheaper, or else there is a real element of arbitrariness in the game (why should my train be unused and therefore unprofitable just because my imaginary chief ticket clerk can't be commanded to lower the fares?) But if we do allow players to control price, then playing Simutrans will end up becoming an exercise in precise accounting and revenue prediction, and will cease to be fun. If the only reason that people use player X's bus rather than my train is because my train is slower than player X's 'bus, then there is no arbitrariness, and I have no reason to be aggrieved that I cannot change the price (because doing so would be irrelevant). If, however, price is left out entirely, then one can no longer have different classes of passenger, as all passengers would simply use the more comfortable carriages (etc.) wherever possible.

So, I'm afraid, classes are probably not a practical idea in Simutrans, appealing as they might appear be; a more sophisticated urban planning system might work to a very limited extent, but I am doubtful about the return on investment in coding it. Probably the most worthwhile idea is to increase the chance of buildings being built in locales well served with transport (which would help to simulate the situation in the 1920s/1930s in London, where the town expanded rapidly along the equally rapidly expanding outer-suburban Underground network - Google "Metroland" for an historical overview). However, even this would be complicated: defining exactly what counts as being well served by transport would not be easy, and would probably require each tile to keep detailed records of what possible destinations can be served, and at what overall travelling time (and roads would have to be taken into account, too, as private car transport is likely to be considered worthwhile by many Simucitizens). This, in turn, might well also vastly increase memory consumption and considerably increase computational intensiveness. This might be worthwhile at some point, and there might be a simpler way of doing it that does not lead to an unacceptable reduction in performance, but it is not currently a priority for the Experimental project; if somebody else were to code it, and demonstrate that it did not unacceptably reduce performance, of course, that would be a different matter.

As to a more sophisticated approach to maintenance costs, however, this is a priority for Experimental, and I have been planning to do something like this for a while. I don't think that it is a good idea to model individual breakdowns, but certainly a higher running cost (based on what I am told is called a "sigmoid curve" function; if anyone can find my the formulae for it, preferably in C++ form, I should be most grateful) for vehicles that have clocked up more kilometres is something that I am very keen to implement (but, even for that, time is sadly limited; again, if anyone would like to help to code it, I should be most grateful). I am also very much hoping to introduce a new type of way maintenance cost, on top of the existing per month cost: a per tonne cost.

Thank you again for your interesting thoughts on the matter - these things are always appreciated even if I am not able to implement all of what is suggested.

[MattGosford]

How do I post pics on this site? I have a city with a population of 1.8 million and a greater urban area of 2.1 million

[Matthew]

How do I post pics on this site? I have a city with a population of 1.8 million and a greater urban area of 2.1 million

Put the link to the picture between

Code Select Expand

[img] tags like this:

Code Select Expand

[img]http://www.a.web.address/your-picture.jpg[/img]

The Insert image icon (picture of the Mona Lisa) will type the tags for you.

That requires you to already have a link to the picture on the Internet, though. There are several ways to do that:

• Post it in the Simutrans Discord server's #extended-general channel.
• Upload it to files.simutrans-germany.com (the picture will be deleted after the number of days you set); no registration required.
• Upload it to Imgur; you don't need to register but you need to reload the picture to get a high-quality link.
• If you use Linux, then you can use Flameshot to screenshot, upload to Imgur, and copy the link almost instantly.

[RealAmerican1776]

I have noticed that if you play using 24 bits per month, the population is smaller and closer to real life then say playing at 30 bits per month.