News:

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

Fixing city limits

Started by neroden, July 14, 2013, 04:10:47 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

neroden

 So, the current city limits code is problematic.  Cities can overlap.  This has weird results as the number of buildings divided by the area no longer represents the density of construction, causing even stranger building results.  It also makes it hard to implement any future, fancier stuff where cities have individual identities if cities can overlap.

So I changed the city limits code entirely, on the "fix-city-limits" branch.  Here cities (a) cannot overlap, and (b) do not expand nearly as much. 

On this branch, there are two major changes. 

First, a city will only expand if it tries to build within its limits and discovers that it cannot.  Due to the way the city building code is written, this *can* happen even with many vacant spaces in the city, because there is nearly always a percentage chance of refusal-to-build during construction.  But it will lead to denser cities.

Second, on this branch, a city will only expand in one direction at a time, and will not expand to overlap another city.  (There are several bugs in that last bit related to odd situations: bridge construction and construction of multi-tile buildings.  I will try to fix these properly some time.)

I consider this an improvement over the current system.  However, there are several subtle issues which make me wonder whether I should do a more aggressive rewrite. 

The first issue relates to the fact that all cities have rectangular borders.  If cities cannot overlap, then when cities get too close together, you can end up with "dead zones" into which no city can expand.
(Diagram in ASCII art:

+---+-+
|   | |
+-+-+ |
| | | |
| +-+-+
| |   |
+-+---+

Suppose the four outside boxes are cities.  The center box can end up being something none of them can expand into.)

The second significant issue relates to the forcing of greater density by this design.  I can probably correct this while still having rectangular borders (by reintroducing the "we are sufficiently built out that we should sprawl" variable).  I'm not sure this is necessary or desirable.  But finally...

The third is those rectangular borders.  They're kind of unrealistic.  For various reasons, in experimental, every tile has a pointer to the city which it is part of, anyway.  So we could create an alternative to precisely rectangular borders.  However, all the alternatives I have come up with involve storing an awful lot of data in the stadt_t structure, and having some very complicated border-change-computation routines.  And I'm not sure whether it's worth it.

So, anyway, I'm working on this project on the fix-city-limits branch.  It is certainly not ready to merge.  I welcome thoughts.

Important side note: I still haven't solved the bug with corrupted city limit values which happens if DEBUG=1 or DEBUG=0.  This is my next target...
----
Update: I have somehow managed to fix the bug with corrupted city limit values with DEBUG=1.  For reasons I do not fully understand, I have not been able to port my bugfix back to the main branch -- it appears to require my rewrite in order to work correctly.  Anyway, I'm not quite sure what's going on here, but that gives me more incentive to make this branch "ready to merge".

Cities are coming out very rectangular on my branch currently.  There are two ways I could deal with this:
(1) I could reimplement the "city should sprawl more" factor
(2) I could attempt to implement non-rectangular city limits
I think #2 is better in the long run, but it seems much more complicated...


kierongreen

Sometimes one city can be entirely enveloped by another even (this does happen in real life also). Personally I might handle this by saying that if more than half of a city overlaps the coverage of a larger city then the smaller city is subsumed into the larger one - buildings transferred and Townhall demolished or remaining as a tourist attraction of some kind.

Non rectangular city limits - I can imagine that being a real pain to implement. If you go much beyond 4 corners then the most efficient way is probably being to store city in planquadrat. On the other hand for map display you really want a polygon.

For me sprawl is good - I find a city where all the buildings have reached the highest level more than a bit unrealistic.

greenling

Hello Neroden
I think,that city they growing and they then get a contact with another growing city,that than both not in one
another grow.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

This is an interesting subject that deserves some consideration. I recall you discussing some time ago implementing a city merger code where, if one city became subsumed into another (as happens in reality), then the smaller city would become part of the larger city and the town hall turned into an attraction (or possibly just deleted). This is worth considering further, as we want to avoid a situation in which cities specifically stop expanding towards each other when they get close, which is the opposite of what happens in reality (absent some green belt planning system).

Further, consideration needs to be given to whether this will work with the proposed changes to town growth, in particular the system of having town growth dependent on local transport such that the places where buildings are built or upgraded correlate with those where the transport service is the best. The extent to which any town sprawls should depend on actual simulated economic parameters in the game rather than a potentially arbitrary numerical factor.

Thank you for your work on this, however: it is appreciated, as always.
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.