Yes, Technical Debt is still rearing its ugly head.  One of the things that any procedurally-generated Roguelike has is a ton of different files that hold profiles that define how to generate cities, landscapes and enemy encounters.  And tables, so many randomized tables!
During the 7DRL I found an expedient solution that worked for the challenge and a fair amount of time afterwards.  I baked data right into each Unity scene that I saved out, imagining that I could just make a scene for each type of scenario or terrain profile I wanted.  I could bake in components that had all the predefined information I needed and just load them as needed.  I could even drag-n-drop the appropriate prefabs for everything I wanted to spawn.  How simple.  Sure, it nagged at me that it wasn’t super extensible, but scenes were cheap to make and I was interested in how far it could get me.
Wellll, it turned out it was pretty far, but eventually it started to haunt me.  The more scenes there were, the harder they all were to maintain, even if all the common information was kept in Unity prefabs.  Oh god, the prefabs…  they are great sometimes, but they also can puke all over themselves if I moved files around or a metafile got invalidated somehow.  Also, any time I wanted to choose something randomly, it felt like I was writing new code to deal with it each time.
I also used the serializer for a number of structures, but there was always a desire to have more flexibility when reading data.
Anyway, I knew I needed to up my datafile game.  My friend Jim’s amazing RL Dungeonmans has something like 500+ datafiles holding anything from name generation to encounters to tile definitions, with weighted randomization tables and tables that reference other tables.  How slick!  He spent many years refining his data methods and he encouraged us to reuse his approach in our own games.
So last weekend I finally bit the bullet and built a datafile system around some of the same concepts and in the end my format is virtually the same as Dmans.  This way I can build a sector with a pretty flexible format:
defThing sector_basic
{
class adSectorData
scene Overworld
biome Desert
nametable sector_name_chart
treasuretable sector_treasure_table
music mus_desperado
basic_city_table 1d2
sector_outpost_chart 2d4
sector_town_chart 2+1d3
}
And these tables have some handy reference capabilities (recursing through each table referenced) and weighting for randomized results:
defTable "sector_name_chart"
{
#t1 "sector_place_types"
#t2 "place_nouns"
#t3 "sector_adjectives"
"The [t1] of [t2]" 10
"The [t3] [t1]" 10
"The [t1] of [t3] [t2]" 10
}
defTable "sector_adjectives"
{
"New" 10
"Old" 10
"Dry" 10
"Frosty" 10
"Winding" 10
"Hewn" 10
"Locked" 10
"Winding" 10
"Ancient" 10
...
…and bingo, my world generation becomes 10x more flexible and powerful.  I’m dyin’ to get back to the drive-shoot stuff, but this was so worth it.
The patch system has a lot of additional features yet to do.  For example, allowing the definition of patches in a nine-slice style where I can scale them to an arbitrary size with consistent edges.  This would allow me to create arbitrary-sized plazas, but more importantly, I can create a road patch that has signs, lights and various elements on it, that scales according to the length (and width if desired) of the road.
I didn’t expect to get dragged into city decor so early in AutoFire’s development.  It’s certainly a topic of interest to me, but the push in that direction really came from trying to find props for the game.  My 7DRL city was fine, it was basically a dungeon.  A dungeon can be a twisty maze of passages and hallways don’t necessarily need a specific direction of travel defined.  However, it felt like 90% of modern-day props required placement with some thought…  You can’t just sprinkle in mailboxes, street lights and stop signs via Random.Range(0, size)…  There needs to be established clusters and strips of materials.  I can construct hand-built areas anyway, but to extend everything into procedural town I’m pushing the limit of my limited home-grown tools.
I’m quite aware that I’m running the risk of entering a bottomless pit of effort… Â Making a city look like a city is hard, and many games make that their only thing, whereas I have
