Level generation work as usual for this week, it's slowly getting a bit more ... refined.

Spawned object variations

Areas can define "algorithms" to generate content for them, like jugs, statues, carpets, etc. But for example, we have 10 statues, which one to specify or to pick? Another example could be jug color variations: yellow, blue, etc. Requirement no1: be able to resolve a generic name like "statue" to instantiate one from a multitude of variations.

But there's more. Some variations only make sense in particular environments. E.g. a desert dungeon is yellow-ish and a forest dungeon might be green-ish. So, when I'm asking for a "jug" in a forest dungeon, I should instantiate the green ones rather than the yellow ones. I already have a super-helpful class for "spawn requirements" that allows specification of such things. Requirement no2: pick a variation subject to current context and variation spawn requirements.

So, satisfying both requirements is not that complicated after everything is set up correctly (in JSON), the only annoyance is that I need a separate mapping between "spawn class name" (the "generic") and explicit names that can be directly generated. On the other hand, this allows to have lots of heterogeneous stuff in this mapping, like objects, decals and more. What is needed is to provide some information for how we want to instantiate an object. E.g. for a jug that would be "InteractiveLevelObject" so my code looks up a delegate stored in a dictionary whose key is "InteractiveLevelObject", and it will spawn the object.

Since this is complete, from now on the levels can look a bit busier than usual.

Procedural spiderwebs!
Procedural spiderwebs!

Webs and autotiles

I already had a few sprites for webs (corners or standalone), but now I need to procedurally generate them as part of the dungeon and having them look nice. Option 1 is to use a single sprite for everything, but that does not look as nice. Option 2 is to convert the web sprites to a tilesheet that I can use autotiling to select an appropriate sprite based on context. Thankfully that was not painful since I have a bunch of tools to assist me with such conversions, so I edited a few sprites and made the autotiles. Now the harder part was to allow a generic object to use a tileset instead of an explicit sprite, which was functionality typically reserved for non-entities such as decals, walls or overlap tiles. After some fiddling, all is done and the webs are now dynamic. Web sprites change if the environment around them changes dynamically (neighbouring wall gets added/destroyed or neighbouring webs are added/destroyed).

More procedural spiderwebs!
More procedural spiderwebs!

Misc

  • I've added a new algorithm option for procedurally populating areas, tweaked for clusters. For example, when you want to have a corner of a room filled with jugs/crates
  • Added a breaking animation when you use a tombstone (was actually one line of json - yay for overengineering config files). When you "use" a tombstone, it breaks and you might get treasure or undead. Now, instead of just switching sprites, you can see the tombstone breaking. Groundbreaking stuff.
  • Some misc bug fixes as usual
Dynamic spiderwebs!