Integrating the Level Generator in Unity
It's been a while since the last post, as there was some serious under-the-hood refactoring work to connect the C# game side and the C++ level generator.
Updates lately have been varying in nature, as I'm plugging whatever holes have been left open by the new updates in level generation. And there can be holes at three fronts: C++ level generation, C# game, json configuration, so it has been a bit wild (==draining). Here's a short list of things that I needed to take care of:
Sometimes doors appeared outside caverns, in "zone connections" (single points connecting an area to another one). Solution: have fixed logic on the C# side on if we should spawn a door from a zone connection: if any of the adjacent areas is door-supporting (e.g. a dungeon), spawn a door, otherwise don't.
Overlap tiles that allow smooth transitions between e.g. square dungeon floor and noisy biome floor have been fixed, as some other changes had made this feature stop working
Adding a wilderness "padding" area for first levels of adventure locations has now become a dynamic (runtime) option. I'd like to specify some multi-level dungeon configurations in JSON, but I'd like to be able to run them with or without wilderness. So now we can say in runtime if we want to spawn a dungeon and start directly in the dungeon or outside in the wilderness. It's going to be typically wilderness, but I can foresee various missions where that will not be the case.
Support for different-order stairs. Some multi-level dungeons should go upwards. Now that's an option in the specification, and the effect is that we proceed to further levels by taking stairs that go up. Prime example: wizard's tower or lighthouse.
Fixed a bug introduced by recent changes where I wasn't able to get correct stairs sprites
Changed the way of expressing floors, blocked tiles, liquids and doors. Made them a bit more heterogeneous than they were before. This change caused a few of the issues above
Better support for escape missions. We can specify easily e.g. a multi-level dungeon where we start at a particular level (or last level) and particular zone (e.g. some prison area in last level) and we need to make our way to the exit.
Step towards robustness in config file changes and savegames. So far, I could do the following: play game, save game, change the .json files, load the game, BUG! Because of the way I'm referencing configuration entries via indices rather than names. I've not made the code more robust really, but when I'm saving the game now I'm also dumping the entire configuration, and when I load that game I compare the current configuration and the saved configuration and I can detect if I'm going to get issues or not and where. It's not much, but better than silent bugs.
A bug got introduced where some floor from one area would be next to blocked tiles of another area. A bad example is dungeon floor corridor ending at a tree which is at the border between dungeon and wilderness. Bad. Fixed now.
I have a structure which contains "spawn information" for things, and contains things like tags, biome, zone architecture (e.g. spawn spiders if we have "abandoned" tag, spawn trees if we have a "biome" zone architecture, etc). I've added "difficulty" to that class, as it's useful for spawning monsters, leveled items, etc.
I had a bug where the walls of rooms in a dungeon were using different tileset compared to non-room blocked tiles. Bad. Fixed.
I've tested destruction in settlements. Now if we specify a "ruined" tag in a settlement zone, we get destroyed buildings. Now what's the catch? Rooms were always classified as indoors and past me thought I should stop fog /rain from entering/dropping in such rooms in settlements. But now, if a room is ruined, we actually want things to creep in. So I've added such a detection and hopefully it wasn't much of a headache. Yay! But sheesh, things one has to work on with graphics.
