News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

City and industry densities

Started by ras52, July 13, 2011, 10:21:33 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ras52

I'm currently playing with Simutrans 110.6 Ex 9.11 with Pak128.Britain-Ex 0.8.  Can anyone comment on what settings for the new map dialogue box the pakset is optimised for?  Whilst I'm sure the aim is for the game to be enjoyable across a wide range of settings, it seems the pakset has to be targeted to some extent at a particular range of settings.

Things like the number of industry chains has a big effect: on a map with few industries, it's rarely possible to utilise a convoi for more than 50% of the time.  It goes out full and returns empty, and there's little scope for anything more sophisticated.  On an industry-dense map, it's often possible to do better, either by sending the convoi via three or more stops, or with a hub arrangement where convois can run full both ways between major transport hubs.  Likewise, the density of cities has a huge effect on the viability of passenger transportation.  If the cities are few, well-spaced and small, passenger transportation doesn't become viable until relatively late in the game.  (I rarely play up to the present day so can't comment whether it stays viable.)

Veering slightly off-topic for the pak128.Britain-Ex forum, I wonder whether it would be better if the new map dialogue talked about densities instead of numbers for things like cities, industries, attractions and initial intercity road lengths.  Instead of 16 cities on a 256x256 map, we would say 0.004 cites / km^2, assuming distance_per_tile=25.  (Or we might express it per 1000 or 10,000 km^2 so that only integers were used.)  The advantage of this is that as you change the size of the map, you don't need to think about changing these settings.  16 cities in a 256x256 map automatically becomes 64 in 512x512 map or 256 in a 1024x1024 map.  Certainly the way I play, if I change the map size, I tend to change these densities more-or-less in proportion to the map's area.

Richard Smith

jamespetts

Richard,

thank you for your post. We haven't really calculated the optimum numbers yet, but what you want to aim for is a map where the city and industry density approximates real life: use the city clusters function to help to achieve this. Higher densities tend to work better, but the use of clusters can allow you to have large open spaces as well as dense urban areas. As to industries, given that industries are everything from oil refineries to corner shops, go for a higher number of chains rather than a lower number, as, again, this will be more realistic.

If you are able to find some good numbers for your settings, do let us know of them, as this is something that needs further explanation.
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.

ras52

One problem with relying with on values from real life is that we hit problems with scale.  In the real world, in the 19th century, the median country village probably had a population of 500 and would comfortably fit within 1 km^2, but in the game, a village with that population takes up about 5 km^2.  Even a village that small probably had a pub, a church, and at least one shop, and the game requires a city hall.  Those buildings take up 1, 4, 1 or 2, and 4 tiles, respectively -- 10 or 11 in total; assume that about 50% of tiles are taken up with ity roads, and we've already used 20 tiles, and that's before any houses are included.  To look right, you probably want at least as much space taken up with houses as with non-residential buildings.  That means that a sensible representation of a village takes about 50 tiles which is roughly consistent with the 5 km^2 that the game requires for a 500-person village. 

In most of England (ignoring sparsely populated areas such as the North York Moors or The Fens), there's around one 500-person village per 10 km^2. We can get that figure in a number of ways.  I tried dividing the area of a county by the number of parishes in it, taking villagesize*area/population for the whole county, looking at a map and counting villages per unit area, and they all give similar values.  At distance_per_tile=25 (the default value), that means one village per 160 tiles.  Or 400 villages on a 256x256 map.  Using simutrans' automatic map creator, I can't fit more than about 40 villages on a 256x256 map (including rivers).  And if I manually add villages, it starts looking very crowded.   

So I'm coming to the conclusion that either we should consider realistic villages beyond the scope of simutrans, or distance_per_tile is too high and needs roughly halving.  If we're serious about supporting realistic 18th century transportation, I think it'll be difficult to avoid supporting villages as such a high proportion of the population lived in villages.  But support for the period 1750-1830 has always been much less solid than later periods, and perhaps it is better to focus on getting the post-1830 period right, with large villages and small market towns as the smallest cities accurately depicted.  Any thoughts?
Richard Smith

jamespetts

Richard,

those are very interesting calculations, and most useful: thank you. Because it is not practicable within current hardware constraints to have realistic long-distance journeys with lower distance per tile values than currently employed by default, it may well indeed be necessary to ignore for our purposes the smallest of villages and instead concentrate only on the larger connurbations (the largest villages, small towns and above). Even in the pre-1830 era, there is probably not a great deal to be added to the game by detailed modeling of transport to tiny villages.
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.

ras52

Thanks for your thoughts on this, James.

If we cannot reduce distance_per_tile then we probably have a problem with population sizes.  Today, a small town occupying 5 km^2 likely has a population of 8,000 to 10,000; in the game, a town that size has a population (in 2000) of around 1,000.  The code to calculate city population size is hard-coded in stadt_t::get_einwohner(), and I don't really understand why it's doing what it's doing; but multiplying it all by 8 or 10 gives populations that are more compatible with the area of the town.

But this does raise an interesting point.  A village that occupies 1 km^2 in the game generally only has its size under-represented by a factor of maybe 5; a town that occupies 5 km^2 is under-represented by a factor of up to 10.; a big city that covers 200 km^2 is under-represented by a factor of about 15 or even more; and a conurbation the size of London is under-represented by nearly a factor of 25.  That must be partly because the bigger towns don't have enough high-density buildings.  The graphics are there, but they're under-utilised when renovation_percentage = 38 (the default), and if I increase that, say to 60, then even the smaller towns get high-rise developments.  However, that's a somewhat separate issue.

If we can't currently fit a typical village into a 1 km^2, perhaps we should ask whether it's possible to change anything so that it can.  If the village is on a T-junction, then of the 16 tiles in the square kilometre, 6 are taken up with city roads leaving 10 for buildings.  If we had, say, a 1x2 church and a 1x1 light-weight 'city' hall, there would be room to add, say, a bakers and a pub, and still have 5 other houses.  There's no technical problems with having a smaller church.  But I've no idea whether a small 'city' hall introduces technical problems.  The only other issue is cosmetic -- that the city generator tends to add too many roads, and not enough buildings.

And if smaller city halls are not possible, how about making churches serve the role that city halls have in the game?  Virtually all villages, towns and cities have a principal church, but villages may well not have a hall; and where villages do have a suitable hall, they'll almost certainly be Victorian or more recent.  What should a 1750 village hall look like?  It's a moot question if they rarely existed.  The existing city halls wouldn't be wasted as they'd simply become attractions that would be present in towns and cities, but not in villages.  And there's certainly scope for some impressive cathedrals to serve the city hall role in big cities.  Anyway, it's just an idea.
Richard Smith

jamespetts

Interesting discussion. Two broad issues arise, I think. First of all, the population counts: I have not changed the formula for determining the population count between Standard and Experimental. The actual population counts in Simutrans as things currently stand cannot be taken as a proxy for real-life population counts, for the reasons that you point out. The important thing as far as Simutrans is concerned is whether the number of passengers generated by a conurbation of the relevant size is realistic. That, I suppose, is hard to judge in many ways, but it does not seem a long way off reality as it currently stands. If it were possible easily to alter the code to report different population sizes, such that the actual population counts were more realistic, without changing the underlying game mechanics, then this might be worthwhile.

A second part of the first issue is the effect of the "renovation_percentage", and its inability to discriminate adequately between smaller and larger towns. I have not looked into this much hitherto (and presently don't have access to the machine on which I compile the code, and may not for about a week). This code, too, is similar to the code in Standard, although does incorporate some changes (albeit not written by me) that were originally intended for Standard but later withdrawn. I do wonder whether it would be worthwhile looking into whether altering this code somewhat could produce greater density discrimination between towns of different sizes (although do bear in mind that I have a very long queue of things that need to be implemented, so this might not be looked into for some time; however, if anyone were willing to produce a patch on a Github branch, this might substantially expedite matters).

As to the second topic, I think that there are practical problems here. First of all, we can't change the base size for a city hall, as, as the town grows, it has to be upgraded to the larger sizes, and this cannot be done if the base size of the smaller version is different to the base size of the larger version. The church is treated by the game as an "attraction", and thus cannot substitute for a city hall - the same graphics could be used, I suppose, but then there would be nothing to stop the game building an additional "attraction" church in the same town. It would also be somewhat confusing to swap attraction churches and city halls - a church is not the administrative centre of a town, so it would be counter-intuitive if the game were to treat them as being so. Also, it would not be at all easy to get the city generator reliably to make a town with the requisite number of houses, and then the (separate) industry generator put suitable small industries in place - a "village" is just as likely to get a textile mill or a printworks as it is to get a 'pub or a bakery.
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.

inkelyad

#6
Quote from: jamespetts on July 14, 2011, 12:34:32 PM
This code, too, is similar to the code in Standard, although does incorporate some changes (albeit not written by me)
I believe it was me. I have wanted more noticeable downtown core.
Quote
could produce greater density discrimination between towns of different sizes
Each building have population capacity/building level. City population is less then sum of that.
Make hight-level buildings for pak and city will take less space.

But... City grow. Even at map creation. If grows rate is small it will not build hight-level buildings. If population increase is 100 code will not build new +1000 skyscraper. And it can't do 10*100 -> 1000 replacement.

EDIT:
Quote from: ras52
if I increase that, say to 60, then even the smaller towns get high-rise developments.

Yes. At map creation it is 'grow from 0 to 1000'. It is fast. Code will build one hight-level building for 1000 peoples.

Carl

Just a brief comment on one of the issues here. I've been building a large UK simulation with a distance-per-tile of 250m, and I've found that at this level the ratio of "Simutrans population" to "real population" is about 1:13.

The disadvantage to changing this would be that you'd get small houses with populations of around 80. But if these are understood to represent a residential area of 250x250m, then this would be more palatable.

inkelyad

building population = bulding level * 10. So it can be changed.

But we can't think tile == residential area and scale population accordingly. Roads throughput will not scale to that. Unless we make vehicles with unnatural capacities.

jamespetts

One question is: what is more important - the accuracy of the population per building or the accuracy of the population per conurbation? There is something to be said for the latter being the more important, especially since I am not aware of people taking particular note of the population per building statistics: that information can, in any event, be represented to the player differently so as not to give the impression that it is a population per building figure.

As to the point made by Inkelyad about towns growing when formed - might there be some benefit, I wonder, in having a different renovation percentage for creating new maps than for towns expanding in existing ones?
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.

inkelyad

Quote from: jamespetts on July 14, 2011, 04:12:17 PM
One question is: what is more important - the accuracy of the population per building or the accuracy of the population per conurbation?
Population per vehicle.

jamespetts

I'm not sure that I follow - all that is being discussed, I think, is the changing of the numerical representation of a town's population in the GUI, not anything that would affect passenger generation rates?
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.

inkelyad

Example: country population/number of seats in country railroad network should be same for simulated and real world.

Carl

Quote from: inkelyad on July 14, 2011, 04:01:27 PM
building population = bulding level * 10. So it can be changed.

Is that always true? In my experience it's building population = 6*(building level + 1). So buildings with passenger level of 0 contribute population 6; and so on.

inkelyad

level 0 is special case i think
But usually it is *10

stadt_t::baue_gebaeude:
...
h = hausbauer_t::get_wohnhaus(0, current_month, cl, new_town);
if (h != NULL) {
       // will be aligned next to a street
       won += h->get_level() * 10;
}

stadt_t::renoviere_gebaeude:
...
case gebaeude_t::wohnung:   won += h->get_level() * 10; break;
...

And building can be not used fully. Its level is potential population.

ras52

Thanks for all your comments.  Let me take the four separate sub-topics in order.

Population  It's good to see that carlbaker's estimate of the under-population of 1:13 is more-or-less consistent with what I've found.  However, I don't agree that small houses with a population of 80 or so is necessarily a problem, as it already exists.  I've just used the public service player to create a new city on a blank 1750 map.  The city fits into a 5x4 tile square (1.25 sq km) and contains three buildings: a half-timbered house, a church and the smallest sort of city hall.  It has a population of 292.  The way that's calculated is rather complicated.  As I haven't seen it documented, and I'll forget it I don't write it down, let me document it here:

The 1600s half-timbered house has Level=1 in the .dat file, but the value in the code (e.g. as returned by get_level()) is one less than the value in the .dat file.  The city hall has Passengers=10 in the .dat, and that is used in place of the level in the code.  Because the city hall occupies four squares, it is counted four times.  (That explains why the city claims to have five buildings: four are the city hall, one is the house, and the church is ignored as it is an attraction rather than a city building.)  A building tile with level N in the code contributes 6(N+1) to the population; this is governed by logic spread around simcity.h and .cc.  In total, those five building tiles contribute 4x6(10+1) + 1x6(0+1) = 270.  On top of that, each unemployed or homeless person contributes 0.5 to the population, and there are 22 of each.  270 + (22+22)*.5 = 292, which is the population.   Despite the comments, the code that Inkelyad refers to that takes the building population as 10 times its level is only used in determining the number of homeless people in the city.

James's question "what is more important - the accuracy of the population per building or the accuracy of the population per conurbation" is to my mind moot.  I don't believe we need to choose either.  The population of a city is not the sum of the population of the individual buildings, nor should it be.  A building tile clearly doesn't actually represent a single building, as, unless your name is Louis XIV, a house takes up considerably less than 250m x 250m, and a settlement with only half-a-dozen buildings would very rarely in real life be a viable place for a bus stop / railway station.  The value returned by get_einwohner() [einwohner being German for population] is only ever used in dialogue boxes and graphs, so the sole effect of altering that function would be to inflate the reported population without increasing the number of inhabitants per building, or the number of passengers attracted to a stop.

I've tested that city creation appears to work correctly and respect the median city size entry with an inflated city size.  There are probably a few issues involving saved games, and it would be worth reviewing the unemployment and homelessness figures, and power consumption, at the same time, but I think it would be a fairly self-contained change.

City centres  I've been experimenting with some modifications to the city generation (and expansion) code.  Four things I'm been trying to implement is city bridges so that cities are more likely to develop around a river, as often happened in the real world; a slightly lower road density; simulated organic growth, so at the start of the game a town has newer buildings around the suburbs and older buildings in the centre; and zoning, so that buildings are more likely to be built near existing buildings of the same type (commercial, industrial, residential).   If the latter works (and it's a bit early to comment yet), it would be logical to see if it could be extended to separate high-rise developments from lower-density areas.  I'll report back if/when I get anything working.  If anyone has any other thoughts along these lines, I'd be interested to discuss them. 

Churches as city halls  I accept this is quite a radical idea, but I'm not sure I did a very good job of explaining exactly what I had in mind, and why; let me have another go.  I tend to play the earlier years in simutrans: typically starting in 1750, and more often than not getting bored of the current game by 1850, so my perspective is probably skewed towards getting that period accurate.  During that period I think it's fair to say that except in large towns and cities, the church was the administrative centre of the village or town.  Until 1834, what we'd now call social security was the legal responsibility of the church vestry, as was any free healthcare that existed (which wasn't much); the vestry had to appoint a parish constable until police forces were introduced in 1839; churches had legal authority over probate until 1859; and responsibility over highway maintenance, refuse collection (in so far as it existed) in various steps between 1866 and 1894.  Outside of towns large enough to be constituted as boroughs (and even to some extent in them), I would say the church was very much the administrative centre of the village during the 1750-1830 period.

What I'm suggesting, at least for consideration, is as follows.  Every settlement needs to have a 2x2 building as its administrative centre.  In the code it's called a town hall; the pakset translates this as 'parish hall', 'town hall' or 'city hall'.  A big 2x2 city hall looks entirely reasonable in a larger town or city; but in a smaller village, it looks really out of place, and even if a smaller image were drawn, it wouldn't change the fact that it uses a lot of space.  But on the other hand, there's already a 2x2 building that appears in every village -- the pakset is configured so that all villages have churches.  If we translated 'town hall' (in the code) as 'church' (with possible alternatives 'chapel' and 'cathedral') and used the church image in place of the *all* the city hall images, then the game would still be logically self-consistent.  Go to your typical village or small town; what's the largest, most prominent building?  Maybe it's a school or factory, but more likely, I reckon, it's a church.  In any case, it almost certainly isn't the village/town hall.  Even in London, I doubt many people would pick out the Guildhall, Mansion House or the County Hall as the most prominent building, elegant though they are; but I wouldn't be surprised to hear St Paul's Cathedral named.  Of course, there are other places, such as Manchester, where the Town Hall is a prominent building; but my impression is that it is they that are in the minority.

So churches would no longer be attractions: they would serve the roll that city halls currently have in the game.  The current city hall images would be used as new city attractions.  That means they would be found in larger towns, but only rarely in small villages.  That sounds appropriate to me.  Maybe in the future someone might draw some more church pictures -- that might happen anyway -- and in the same way we currently have five levels of city hall, we could have various images from a small chapel up to a vast Gothic cathedral.

In any case, I'm really just throwing this out as an idea for discussion.

Industry placement  Your (James) last point about the industry generator being equally likely to put a "village" industries (e.g. pubs, bakeries) and "town" industries (e.g. textile mills, print works) in a small village isn't to my mind too problematic.  To be realistic, there should be a lot more pubs than breweries, clothes shops than textile mills, newsagents than printworks.  I'm not sure that balance is right yet in the game, but I don't see a fundamental reason why it can't be fixed.   The result will be that there are far more "village" industries than "town" industries in most industry chains, and so the majority of small villages will end up with just "village" industries.  And where that doesn't happen, is that a great problem?  I know of small villages that are home to cement works, haulage depots, oil refineries, nuclear power stations; as long as they're the exception rather than the rule, I don't see a problem with that.
Richard Smith

Carl

Quote from: inkelyad on July 14, 2011, 06:43:46 PM
level 0 is special case i think
But usually it is *10
Interesting. Does this work differently for buildings manually placed by the player? I'm certainly finding a regularity whereby when I place a 1-level building it adds 12 to the population, 2-level adds 18, 3-level 24... etc etc. Or, to pick up on your last comment, does this mean that the buildings are only 6/10 occupied when manually placed?

inkelyad

ras52, it seems you were more thorough than me.
Quote
To be realistic, there should be a lot more pubs than breweries, clothes shops than textile mills, newsagents than printworks.
Is it possible with current code? There was talks we need many small industries (pubs etc) inside big cities but a have no luck with that.

Quote from: carlbaker
does this mean that the buildings are only 6/10 occupied when manually placed?
It seems i was wrong about how code works. Ask ras52.

Carl

Ah, so I see! I failed to read that post before asking my question.

ras52

Quote from: inkelyad on July 15, 2011, 05:43:34 PM
Quote from: ras52
To be realistic, there should be a lot more pubs than breweries, clothes shops than textile mills, newsagents than printworks.
Is it possible with current code? There was talks we need many small industries (pubs etc) inside big cities but a have no luck with that.

A good question.  And, yes, I think it is possible with the current code, and in small test examples it works fine.  For example, I've created a test pakset with just a grain farm, forest sawmill, brewery and pub.  An industry chain is defined as one consumer-only factory (in my test pakset, a pub) together with the minimum number of factories needed for fully supply it and all of its suppliers.

If I tell the map generator to build a 1750 map with a single industry chain, I get a map with 1 pub, 1 brewery, 1 grain farm and 2 or 3 (on average 2.4) forest sawmills.  The large number of forest sawmills is because only 4% of their production goes to woodchips which is what the brewery needs.  (I'm guessing woodchips are for malting the barley, as if it is just for heating the beer then in later years it should be phased out in favour of electricity.)  Usually the full woodchip output of two sawmills is border-line enough to supply the peak output of a brewery; sometimes it's just insufficient and a third is needed.  A grain farm, by contrast, almost always has ample productivity to supply a couple of breweries at peak capacity.  I'm not sure these are true-to-life, but they can easily be rebalanced in the pakset.

If I now tell the map generator to create two industry chains, it just adds an extra pub to the existing chain.  My map now has 2 pubs, 1 brewery and (on average) 1.1 grain farm and 2.3 forest sawmills.  Add a third chain and I sometimes start needing a second brewery.  On average the three pubs are supplied by 1.4 breweries, 1.1 grain farm and 3.6 sawmills.  When there's more than one brewery, the supply chains are not distinct: we frequently find pubs being supplied by two breweries and sawmills supplying both breweries.  And that's not just a single pub / sawmill overlap that could be explained by mopping up the surplus demand / supply left over from the previous chain.  Add a fourth pub and we have 1.8 breweries, 1.2 grain farms and 4.2 sawmills.

However, in nine further games, the map generator failed to create a fourth chain because it cannot find a suitable city location for the pub.  I was using a 256x256 map with eight cities, two of which are big, and relatively few rivers and sea.  Examining the maps, it seems to me that there were plenty of seemingly-good locations for the fourth pub, but that the map generator code was failing to find them because the value of factory_spacing in simuconf.tab is so high.  By default this is 48, meaning that every factory effectively blocks out a 97x97 rectangle in which further factories cannot be placed.  It's unsurprising that on some maps, the map generator cannot find places to put these factories.  I tried changing factory_spacing to 12 (i.e. 3 km).  That seems a much more plausible setting to me, and generates much better games (to my mind).

So I don't see any major code issues here.  Other than factory_spacing parameter, the only criticism I have is that the pakset could perhaps do with a little tweaking.  Personally I'd be inclined to make it so that a brewery is supplied by fewer sawmills and maybe more grain farms, and that it is perhaps able to supply more pubs.  But these are easily rebalanced without touching the code.

The only one of these possible rebalancing issues that I've looked at the moment is the forest sawmill.  There are five versions of this introduced in 1750, 1850, 1920, 1950 and 1970; their productivities are 2+2n, 40+4n, 80+5n, 90+10n and 180+10n where n is the number of fields.  That looks looks plausible, although the first one might be a little low.  But the output factors are all over the place: 20%:4%, 100%:150%, 160%:160%, 240%:60% and 100%:500% for planks:woodchips.  Are these really intentional?
Richard Smith

inkelyad

So factory_spacing should depends of factory size. Or, better, replace it with 'industry level/output/production per km^2'. Was it ever suggested for Standard?

ras52

Quote from: inkelyad on July 17, 2011, 03:49:13 AM
So factory_spacing should depends of factory size. Or, better, replace it with 'industry level/output/production per km^2'. Was it ever suggested for Standard?

Not so far as I can see searching the forums.  And this would be a non-trivial change to that part of the code.  At present, the code works by maintaining a matrix the size of the map which is tested whenever the industry builder wants to build a new factory.  Every time a factory is built, it blocks out all tiles within factory_spacing tiles horizontally and vertically.  That's irrespective of industry type -- so a sheep farm can't be within 12 km of a bakery.

I cannot see any real-life justification for preventing factories from being arbitrary close.  Walk down a high street, and you may well find a pub next door to a bakery, a grocers or even another pub; go to an industrial estate, and you may find a brewery next to a textile mill; visit a rural dale somewhere and you may find sheep farm after sheep farm, all next to each other.  Perhaps there's a game-play reason for it?  I can see why it would be good to make sure there's a separation (at least twice the stop catchment area) between a factory and its suppliers; after all, the game is about transportation, and that's defeated if they're close enough that the goods do not need transporting.

But I'm not sure production (or similar) per km^2 is the right solution either.  For many industries that doesn't make sense.  Why should beer production be tied to area, for example?  And for those that do, farms for example, we have fields for that purpose.  If the proposal for underground "fields" comes to anything, then mines will similarly be limited by area.  I wonder whether the right solution is to think in terms of per capita demand.  Maybe one pub can serve a coverage of 1000 people.  If the total map population is 10,000, then there would be at most 10 pubs, and as in the current game, they would have to be cities on site with road access.  But there would be no other limitations on their placement.  (In practice, I wouldn't advocate removing the factory_spacing code; merely setting the parameter to something very small, possibly zero.)

Looking at the history of simuconf.tab in git, factory_spacing has gradually been increased: this time last year, it was 8 and increased to 24, in November it was increased again to 32, and this February to 48 where it now stands.  There must have been a reason for this, and I'd love to understand it.
Richard Smith

wlindley

Good points, ras52.  Steel mills, for example, in reality, would tend to group together in a city where natural resources and transportation are advantageous, and where workers from other mills could be lured away. Orchards and farms tend to congregate in areas of good soil. 

In the game, we should see groupings of similar industries... when building a new factory, the game should build it either (a) as close as possible to another that produces or consumes the same goods types or (b) at least factory_spacing distance away; and there should be a weighting between those two cases.  With that algorithm, factory_spacing should indeed be a fairly large number... about "three towns away".  Factories could benefit too from the dat parameter build_time -- except that would be the maximum population level per instance of that factory in a town: in Britain, build_time for a pub might be 1000 so a town of 100 could have one, a town of 1001 could have two, a town of 2001 could have up to three.

Especially considering the idea of coal, iron, and oil "fields" it might be useful to consider a fundamental revamp of industry placement. Coal and iron tend to be found near mountains. Oil fields could occur nearly anywhere including underwater.  (Coal does too, of course; but underwater coal mining is not economical in the real world.) Sawmills would occur in forested areas.  Steel mills generally locate along rivers, ports locate along coast-lines, and pubs occur more often in towns that have mills or factories.  Bookstores occur more often in cities with many churches or schools.  Vineyards are attracted to slopes, wheat fields to flat land, rice fields to land next to a river.

Each industry type would need to be able to specify what sort of natural features, resource, city sizes, or landmarks or attractions that attract the industry.

This suggests that a map generating process that first lays out the basic terrain, then adds rivers (there are other threads about river generation), then forests.  Based on the terrain, water, and vegetation, create the fields for coal, iron, oil, lumber, ports, and agriculture.  Only then would we add the first towns, population being attracted to the mines and farms and ports. Towns that are near many industries then grow larger, building landmarks and attractions; and the result is a more natural distribution of everything.


jamespetts

#23
Thank you all for your interesting comments and analysis. A few replies: firstly, I agree with Richard that it does not greatly matter if a small house is recorded as having a population of 80, as that is not directly represented in the GUI (unlike a town's overall population), and this is consistent in any event with the scale (one should imagine one house as a representation of a series of similar houses). I do think it worthwhile getting an accurate representation of town population, as it will help a great deal in balancing and make it easier for players to understand, especially if the change is relatively straightforward. One area of the code that might be affected, other than those already mentioned by Richard, however, is the formula for calculating congestion, which currently relies on a "congestion density factor", one parameter of which is the town's population. However, that should be fixed easily by applying whatever factor is applied to the town's population in reverse to this number in the appropriate formula before calculating it.

As to city centres, note that there is already a feature in Experimental whereby cities are more likely to develop near rivers or the coast. If we can get a system to make it more likely that a city will build bridges over a river, that would be better still. I am also very interested in Richard's experiments with producing a slightly lower road density and the simulated organic growth (I did have a go at trying to implement the latter, but did not get very far). There is, I think, already some measure of zoning, however: buildings of a similar type will generally tend to be built together, as one can observe with larger cities in Pak128.Britain-Ex (and possibly the Standard version, too). Larger cities often have a distinct industrial district, for example. I should be very interested to see any test code (and it would be particularly helpful if the test code was implemented on a Github repository forked from the base Experimental repository with one branch per feature (and possibly if desired with a further branch combining some or all features) to ease integration and facilitate testing).

As to the discussion of churches as city halls, the idea is an interesting one (and it would be good to see graphics for larger churches/cathedrals in any event), but I think that it would potentially be confusing for players looking for the city hall to have to find a church, not least because, although in older times for smaller towns, churches may well have been the administrative centres, that is not true in modern times, and has not been true of larger towns and cities for many centuries. If it were possible to have different town halls, not only for different sizes of town, but also for different eras (I cannot remember whether this is possible; it is not something that I have changed from Standard to Experimental), then it might be worth considering drawing an extra small version of the town hall to go below the existing size, and have that version be a church of some sort, and replace it in more modern times with a more modern type office building. Indeed, there is much to be said for producing a number of different graphics for different eras of town hall if that were possible (the current type seem to be late 18th/early 19th century in style), but the constraint is, as ever, the time that it takes pakset authors to produce these things when there are more pressing things than town halls to which to attend.

As to the industry densities, this analysis of the code (and this part is unchanged from Standard) is most interesting and useful. The industry spacing has been increased in order to allow for greater space between industries in the same chain; I was not aware that the spacing applied to industries regardless of chain. This is a somewhat problematic feature, and it would be far more desirable if the spacing factor applied only to industries that are connected to each other. In the meantime, however, there is much to be said for Richard's suggestion of reducing the spacing to 12 for the next release.

As to the output factors of the sawmill, the industries were recently rebalanced on the basis of some quite detailed research done by one of the regular users of this forum: there was a post about it some time ago. I implemented the research, the result of which is the industry output/input factors that we have now.

Thank you to all who have participated for the very useful feedback, and I shall look forward to seeing any code that Richard is able to produce!

Edit: One other thing that will have to be considered if refactoring the population size are the target and actual industry densities: currently, the game will determine whether to build new industries based on whether the actual industry density is lower than the target industry density. The industry densities are set by adding 1 / the distributionweight of each industry on the map and dividing that number by the total population. The target industry density is set when the map is first created; the actual industry density is calculated from a number ("industry density proportion") set when the map is first created, and adjusted whenever an industry is added or deleted, and the population, every month. This value will have to be modified when loading from a saved game. Also, we are dividing by a number 13 times greater than previously, we need to make sure that the type of unit in which the densities are stored can cope with the extra precision required.
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.

inkelyad

Quote from: jamespetts on July 18, 2011, 12:59:51 PM
it might be worth considering drawing an extra small version of the town hall to go below the existing size, and have that version be a church of some sort
2x2 city hall square is one object, but I think it can be used to draw two or three small buildings.

sdog

#25
+1 on wlindley's suggestion

could inkelyad's city placement code be a start for this, with different and additional parameters. defining how industries avoid certain aspects. placing powerplants and steel mills closer to water might be one first approach.
Affinity to water might be very important for pak britain, with it's focus on water transport in early years.

when thinking about a revamp of industry placement it would perhaps be worth to have a look in Dutchman on Rails' suggestions (edit: might have been AvG) and experiments regarding a mass of tiny end consumers, to simulate retail networks.

the (minimal) immediately doable change could be basing the spacing between industry on a percentage of map size. (especially since online games brought a resurgence of small maps below 1k tiles of longest side)


jamespetts

Sdog,

that's a very interesting suggestion. Inkelyad - do you think that you would be able to adapt your city placement code to work for industries?
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.

sdog

one a second thought, maybe not too many criteria are needed. Steel mills, breweries, power stations, textile mills, grain mills and sawmills should be attracted to water. Textile and steel mills should also seek cities.

all end consumers and craft shops should be in towns, that works already.
a nice addition would be if new shops would be able to replace city buildings (small percentage), else they all get built at the periphery when the town grows.

coal and ore mines should bunch.

everything else should likely just fill up empty spaces, with their terrain setting taking care of not appearing at silly places. (avoid any other industry?)

inkelyad

Quote from: jamespetts on July 18, 2011, 07:37:03 PM
Inkelyad - do you think that you would be able to adapt your city placement code to work for industries?
I don't know. I never looked at industry placement code.
Building and using probability map is trivial. But it is hard to find "right" equation for it.

Short way will look like this:
1) Build interface between simutrans and some kind of GIS program.
2) Do a lot of experiments with it.
3) Put result back into simutrans.

I do have such project in early pre-planning stages. (Read: I am too lazy to do it). But it involve loading pre-build maps, not calculating it in game.

jamespetts

Apologies for the ignorance: what is a GIS program?
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.


inkelyad

And you should walk through one of the GRASS tutorials. It is useful for self-education.