Articles
Terraforming
The following is a small article revolving around the implementation of terraforming in the Sphere map editor, using existing resources and within working limitations.
The following is largely a technical dump of information and ideas that may find their way into a coherent algorithm.
Central to the idea of terraforming is the adapter tile theory: an adapter tries to fit in with the base terrain type of the surrounding tiles. The process of adapting involves analysing the eight tiles that surround the current one. Choosing the right adapter type isn't easy. And after that, the right adapter configuration, the thing that chooses the precise type of adapter tile to lay, isn't easy either.
I'm going to go with the 'trust' principle: the currently laid tile has to best match its surroundings based only on the base terrain type of those tiles. It makes my job ten to twenty times easier than trying to doubly match up two adapters for two tiles. My script is supposed to work and be tangible, not function infallibly. Of course, this means that if I have water and snow terrains, which don't adapt directly to each other, but have a common grass adapter set, then they won't automatically choose to adapt to grass on either end. I had a tree hierarchy that would be able to do that, which I described online in the Spherical forums, but there's no practical way of representing such a structure in the current tileset file format, so I'm settling on the next best thing.
We're going to be working with binary terraforming. This means adapter tiles will assume the tiles surrounding the current tile are of either the same terrain type as the current tile, or of a single different terrain type. Also, under this principle, adapters should only be one-way. That is, snow should have an adapter tile set for grass, but not the other way around, otherwise, the end result will be graphically unpleasing.
The way this will work is inherently ingrained in the encoding of data in the formerly unused 'name' property of the typical Sphere tile. Future versions of the Sphere tileset format may incorporate terraforming data within the tiles or the tileset as a whole, but for now, we'll stick with what we have. The basic form of tile names comes in the form of '(base_terrain_type).(adapter_terrain_type).(adaption_surroundings)', where base_terrain_type and adapter_terrain_types are names of terrains like 'grass' or 'snow'. The adaption_surroundings parameter is a list of digits from 0 to 7, indicating the delta angle to which the adapter should adapt to. 0 represents zero degrees, pointing to the east. The numbers extend counter-clockwise in 45 degree increments, so 1 is north-east, 2 is north, 3 is northwest, 4 is west, and so on through to 7, which is south-east.
Having a tile surrounded by only one type of terrain is actually a relatively rare scenario. Realistically, there's going to be two, three, four or more types of terrains surrounding a single tile. So, how do we resolve which adapter to use? Additionally, which adapter configuration should we choose?
Resolving the adapter to use for a tile involves checking the surrounding terrain types, using the adapters available to the current tile. Each base terrain is tallied up, while having its adaption surrounding settings prepared. The terrain that gets the most tallies wins out, and is subsequently chosen for this current tile to adapt to, using the adaption settings that were saved for this choice. If there is a tie between two surrounding terrains, the one that occurs first wins. And if there is no suitable adapter, the tile pretends that it is surrounded by tiles of the same terrain type, i.e. its environment is effectively ignored.
I said that the adaption surrounding settings were prepared. How? Well, earlier, I mentioned the 'trust' principle, and here's where it is applied. Since an adapter can't adapt to any more than one type of surrounding tile (two, counting its own terrain type), it won't try. It leaves that task to the tiles that surround it. Thus, the chosen configuration is set by flagging a digit for each 'match' to the terrain type being checked for when the surrounding tiles are being checked. So even if the surrounding tile terrain type is different, the configuration will only adapt to the tiles it can, and assumes the other tiles will handle adapting to this particular tile as it can.
Using this method has its presentational limitations, but it's simple, it operates within the confines of the Sphere editor environment, and directly avoids complicated recursion scenarios.
And there's my idea, plotted out after midnight because I was too buzzed to sleep with it stuck in my mind.