A huge part of the generation of random maps in AoM was in the unique way areas were built. Through a series of parameters, these could be made to be arranged as anything from a single circle, to a complex fractal-like shape. When I started development of an implementation of rmBuildArea I had no idea how I should approach such a task, and went for the nearest thing I had done before; world generation for a minecraft-like game.
This involved using a augmented noise function, whereby the values nearest the centre of an area would be artificially higher, depending on the size of the area. The amount of noise contributed to each value would be proportional to how circly or noisy the area was described to be. Tiles would then be selected if their value was larger than a constant threshold. This produced a map like the following, when loading acropolis.xs:
(note this is without support for constraints, so grass patches appear everywhere)
This looked ok, but it was very different to how Age of Mythology produces its own maps, whereby areas are very varied, with the potential to have long string-like bits coming off of them
Another interesting property of their areas was that they always tried to fill exactly the number of tiles specified for each area; this means if an area is made circular, and positioned half off of the map, its effective radius would be much larger to compensate for the tiles unable to be placed.
I began thinking of how something like this could be possible with a functional system; it soon became clear that it just wasnt, a more progressive system was needed to satisfy these requrements, so instead I re-write the area code to now use a flood-fill style algorithm, where the central point of the area is chosen as the initial tile, which then adds the 4 tiles surrounding it to a list, along with a cost and noise value, and the tiles with the lowest cost are progressively processed. This means under an extreme situation, it is possible for lines or very non-circular areas to be produced, given the right properties.
This new system, as the old one did, then goes through the required blurring and threshold stages to select which tiles should be present in the final area. This appears to be implemented very similarly to how they are in BANG!, as in both engines, burring an area intensely causes the area to become very small (as if the values were being blurred with a lot of 0’s, and eventually falling below the threshold).
The terrain now better represents how it would appear in the BANG! engine, with very irregular shaped areas.
One issue which may be apparent in this screenshot is that areas seem to favor diagonal lines. This is a bug, and will need to be further investigated at some point.