Thank you all for your thoughts. There are a number of quite complex issues that have been raised, and it is useful to give careful consideration to each of the issues. I will deal with some of the separate issues under different heads.
Region boundariesThere is a possible and relatively straightforward way of making this proposed feature work with region boundaries: if it is possible to use the idea of a Voronoi diagram to draw a median line between sets of points rather than individual points, then the Voronoi diagram algorithm could be used to determine region boundaries by the following process:
(1) generate square regions as at present;
(2) generate towns at random points as at present; and
(3) use a Voronoi diagram algorithm to determine which tile is in any given region by taking the set of all cities in each region as the point between which distance is measured.
This relies on a Voroni diagram being able to determine median lines between multiple sets of points rather than among a number of individual points, and I do not know whether a Voroni diagram can do this. If it can, however, it might lead to more realistic region boundaries.
Care must be taken, however, to ensure that the algorithm for this is not too resource intensive. It is unlikely to be feasible to store the region in a tile as this is likely to take excessive memory (albeit this can be tested). Likewise, any algorithm to determine to what region that any given tile belongs and that is called frequently in a large and well developed game needs to be very efficient to avoid adding excessive computational load. This will need to be tested in a profiler when developing such a feature.
Ceding and joiningRanran writes of "ceding and joining"; I had not envisaged a process of ceding, as it is difficult to imagine what mechanism in the game might lead to this, and this is not something that tends to happen in reality so far as I am aware. Can I ask what mechanism that you had in mind for this, Ranran?
New towns arisingThere is currently no mechanism for the generation of new towns automatically, but players may (at great cost) found new towns. The current system of founding new towns allows the act of founding a town to increase the global population, which does not make much sense.
I am not sure what mechanisms would be ideal for town founding in future and whether there is any need to have a system whereby towns be automatically generated during the game, but certainly any system, whether automatic or manual, for generating towns, must respect the planned realistic mechanism for calibrating population growth over time.
Town shapes/generation mechanicsThe actual mechanism for growing towns needs to be changed significantly from the present in order better to reflect reality. The fundamentals of what makes it optimum for people to build a building in one place rather than another are likely to be universal rather than specific to any one place or time, but the operative factors that bear on those fundamentals may differ. We need to have a system that simulates those fundamentals in order to make the system work.
There has been extensive discussion of the current and proposed city growth algorithms
here. I do recommend that these be read and that any further discussion of actual city growth mechanics be added there so that the discussion can be kept together.
The concept of boundaries and boundaries at different levelsI am not sure that I fully understand Phystam's description of how Japanese city borders work. We do want a system to be as universal as possible, as I know that Simutrans is popular in Japan, so it would be best to avoid a system that is specifically European; but I need to understand how the Japanese system works in order to understand what is universal and what is regionally specific.
Is it the case that there is no concept at all of a boundary of a city at all in Japan such that there is no sense in which open countryside that is nearer one city than any other city is considered not part of the city in question; or is it the case that there is an area that is understood to be the city proper, and a surrounding area, which may or may not be urban in character, that is considered to be part of a larger metropolitan administrative area of which the city is the centre?
The practicalities and implementation of city boundariesWe do need to consider what we want city boundaries to do in Simutrans-Extended. They currently have a number of specific functions:
(1) they limit where a city may attempt to grow - this will at least partly be to reduce computational overhead of trying to iterate over all map tiles (is this the function that the Voronoi diagram was intended to serve?);
(2) they determine land value, as land value inside a city will be higher than that outside a city (although the long-term plan is to replace this with a more sophisticated system that will not rely on city boundaries);
(3) they determine whether any industry needs to have an independent connexion to the electricity grid provided by the player, or whether it is sufficient that the player has provided electricity to the city generally as is the case when any industry is located inside the city;
(4) they are the primary nodes in the private car routing network; private cars inside city boundaries route using a heuristic system, whereas private cars cannot leave cities unless they are on a defined route to a destination outside the city;
(5) they determine whether player built roads are adopted by the city authorities (and given a lower speed limit); and
(6) they determine whether player built road stops must be able to be shared with other players irrespective of the choice of the player owning the stop.
Thus, we may well need multiple different types of city boundaries to serve different functions. Functions 2, (probably) 3, 4, 5 and 6 need to be served by a system that determines where in practical terms that boundaries of the built-up area really lie. Function 1, however, may be better served by a different system that draws a wider boundary. Perhaps one might call this a "district"?
However, until we have a more sophisticated system for deciding where buildings should actually be built, the problem is that a wider boundary may cause city buildings to grow randomly a long way from the centre of town for no good reason and where there is plenty of space for buildings to be constructed in a more desirable location closer to the centre of town. I do strongly recommend reading
the earlier technical discussions of the city growth system in order for such discussions as we may have about the boundaries, which is one aspect of city growth, to be fully integrated into the planned revision of city growth at a more fundamental level.
City mergers and hierarchiesThe hierarchical system suggested of states, provinces, counties, cities and towns is interesting, but I am not clear what each of those levels would entail in a practical sense, nor how those would fit into the concept of regions.
The concept of regions as we have now seems to be the approximate equivalent of states and/or provinces. I am not sure that we need to distinguish in gameplay terms between the two. We currently have no implementation of anything like counties, and the current system has no distinction between towns and cities. In the UK, the difference between towns and cities is very peculiar, as a city is defined as any town that has either a cathedral or a Royal charter. In most places in the world, the difference between a town and city is simply size; one would not generally have a town
inside a city, so I do not think that the terms "cities" and "towns" are apt to describe a hierarchical system. I generally use the terms "town" and "city" interchangeably when discussing Simutrans, as, in the UK sense, the word "town" is generally more apposite, but "city" is the word traditionally used in the UI and is also used in the code.
The city merger system that I had proposed was one in which a large city would take over smaller cities/towns when the boundaries of the two touched; the smaller town would become a borough of the larger town, and the larger town would become a metropolitan area. The original part of the town would retain its original name, but the wider area would become "Greater [X]", where [X] is the name of the original larger town/city.
This system has the technical advantage of not needing to destroy the memory structure of the smaller town (which simply becomes a borough and retains its separate identity, town hall, statistics, etc.; it would remain a "city" in game code terms, and just have a data member which indicated that it had the status as a borough), which avoids having to track down pointers to non-existent city objects scattered across large and unknown parts of the code. It also preserves continuity (so new stops placed inside the old town boundaries are named after the old town), is more realistic (as this is what happens in reality) and makes the game more interesting (as players can see the results of the gradual historical growth of towns). A Voronoi diagram algorithm might be an effective way of drawing the boundaries between boroughs in such a system.
Some thought would need to be given to how to deal with town statistics in such a case. However, all 6 of the functions listed above would probably have to be based on the larger metropolitan area's boundaries.
So, if we are to have a hierarchy, we might have something like this:
(1) regions;
(2) (possibly) districts (although I am not entirely sure how these would work in game mechanics terms - this would need to be considered);
(3) towns/cities; and
(4) boroughs.
We will need in due course to give consideration as to how best to integrate these features with the planned town growth features.