I've noticed a subtle but significant change in the way I've been doing things in regards to random level generation since I first started the Golem project. With the original Golem, I placed the burden of translation work on the engine code and left it up to the script to simply place the small building blocks of a level. The script would determine which tiles were rock, which were grass, which were dirt, etc... and the engine would handle the appropriate translation of base type and neighbor patterns into the correct transition tile needed to seamslessly blend adjacent tiles. Similarly with walls; I would simply signify each tile as being of this or that type of wall, and the engine would do the translations, selecting specific pieces of wall and placing them so that the whole would blend seamlessly and look plausible.

This approach required the construction of special file formats and complicated juggling of data. Each tile or wall type for a certain pattern of neighbors could possibly have a given number of randomly selectable alternatives, in order to reduce the appearance of repetition. This required a file format to organize multiple options per configuration, and to include meta-data for the probability of selecting any given alternative. Things got kind of weird, and this was a small part of the ever-escalating house-of-cards complexity that caused the demise of the original Golem. It was getting too hard to systemize the construction of tile and wall sets, the formats were sparsely documented, confusing to work with, and lacked a comprehensive set of tools to make their creation and manipulation easier. Maintenance of the format specs and the tools required to manipulate them got harder as features were added. The architecture itself lacked flexibility; if a particular wall piece or tile was not in the given tile or wall set, then it could not be used. So I either had to bloat tile sets with tiles that might be used in only one level, or I had to construct special tilesets for that one level that duplicated large amounts of tiles that were included in other sets. All in all, the whole approach lacked flexibility, which is why the project ended up dying. (Well, one reason, anyway).

With the Golem3D generation back-end, I am doing things quite differently. Instead of forcing the engine to handle matters of translation, I perform those tasks in script instead. The engine provides a few commonly-used helper functions, such as functions to analyze the neighbor pattern of a given tile and encode that analysis in a value that can be used as a table index. However, I am not limited to packing tiles and walls into sets as I was before, allowing me to do away with custom file formats for everything and to better pick and choose. I can more easily do 'non-standard' or level specific stuff, such as placement of special tiles or walls for special levels and so forth. Randomization of alternatives is far simpler, as I can tweak the probability tables for a particular set of options simply by modifying the script, rather than editing a custom file and re-packing the data as an additional pre-processing step.

Like I said, it's a subtle difference, but the impact on the cleanness of the backend has been profound. There is a bit more processing overhead this way, as the script can not translate as rapidly as the engine can, but the tradeoff in regards to the flexibility gained makes it more than worthwhile. I've pretty much done away with custom file formats altogether, except for the various meshdata and animation data files. No more tileset files, no more wallset files, no more propset files, etc... I can just dump various objects into organized folders in a directory tree, and use them from anywhere and from within any script at will. The code of the generation script provides the proper format of the data, customized for the level being generated.

Sorry, just some random thoughts. Back to work.