A lot of refactoring work this week, all related to the native plugin dungeon generation. All the zone generators currently implemented are supported with GUI controls: dungeon, cavern, coastal and prefab. This allows for very quick evaluation of different generators under different configurations. Also integrated an inspection mode in which when hovering over a tile, we get full info on the underlying data (is it floor, read only, connection, liquid depth, etc), which is of course pretty simple to add but very useful for debugging.

Zone embedding example: Dungeon (zone3) in a cavern (zone2) just off the coast (zone1)
Zone embedding example: Dungeon (zone3) in a cavern (zone2) just off the coast (zone1)

The next stage was to allow GUI manipulation of embedded zones: be able to modify via GUI zone embeddings, so that for example I can dynamically add a zone inside another zone, and that inner zone could support another zone and so on. This works but I still don't like the current specification of the zones, as it's by name reference: I have a flat array of zone specifications, the first is the outer zone and any inner zones are specified by name (name of zones 1...N). This weak referencing approach is not ideal, as it expects existing zone presets rather than on-the-fly specification, and both approaches have their merits.

All passes in order to create the previous figure's map, in order
All passes in order to create the previous figure's map, in order

Next part was some "infotainment" stuff. Whereas I did use previously image export to get images of all different stages, the image sizes and displayed maps would be at the zone level, so inner zones would result in small images, and outer zones would result in bigger images that would contain the inner zones. So, I added some code to optionally maintain the same frame of reference across all exported images, and maintain some caches here and there, so that the resulting captured stage-by-stage images can be viewed in order, at the same scale, showcasing how exactly the dungeon is being built.

The other boring but important part of this week's work was refactoring of some JSON code (using nlohmann json) as previously was just importing json (to save myself writing some export code) but now I've changed it all to both import/export. That of course was the easy part. The slightly harder part was to fix up the framework for loading/saving class hierarchies to json, writing for example json like:

{
	"$type" : "FooDerived",
	"someBaseVar" : "asd",
	"someOtherBaseVar" : 32,
	"someDerivedVar" : 33.2,
	...
}

So, this can be serialised in a std::shared_ptr<FooBase> but will contain a FooDerived pointer, and the derived class will be initialized with the derived variables and the base class with the base variables. Nlohmann json is a very nice library, but the compile errors when you get things wrong can be annoying, or sometimes the template magic falls apart if you declare things in the wrong order and it compiles just fine but the ADL stuff fails, and so on. But now it works, so, phew.

So, while the native version gets improved, because of changes here and there it's now absolute certainty that the C# counterpart glue code will fail, but that's a headache for later to fix. Now that the JSON and Dear ImGui stuff is done, back to the main problems of:

  • Easy-to-specify complex zones with prefab subzones etc (possibly a problem for C# land, that makes the magic json fed to the generator)
  • Integration of procedural prefabs seamlessly with other prefabs
  • Integrate feature placement and prefab placement in the GUI supported pipeline