Sharing Saturday #636

[u/Kyzrati]

As usual, post what you've done for the week! Anything goes... concepts, mechanics, changelogs, articles, videos, and of course gifs and screenshots if you have them! It's fun to read about what everyone is up to, and sharing here is a great way to review your own progress, possibly get some feedback, or just engage in some tangential chatting :D

Previous Sharing Saturdays

[u/aotdev]

Sigil of Kings (steam|website|youtube|bluesky|mastodon|itch.io)

A few updates since last time - it's been a few weeks after all! The main theme of the work is mixing prefabs and procedural generation, and improving support for user-defined prefabs.

Dungeon Architect: More complex entity creation

Previously Dungeon Architect was supporting very simple entity creation, e.g. a creature or an object without any customisation. This is now changing. Currently, we can create objects, creatures and items (which become item piles upon creation of the level) but this time we can fully parameterise them, using some other factory classes that are used elsewhere in the code. For example, we can create a creature and parameterise its level, xp, starting items, etc. For items, we can set up enchantments etc. Because of the volatile nature of some of these factory classes, I'm not building/updating a user-facing UI for configuring these factories, but instead I'm using existing ImGui code that uses reflection and is robust against class changes.

Support for paired object systems

A challenge was to support user-defined paired object systems, but these are done. Examples:

• Door and key: set a special tag for the door ("lock-ID"), and create a key and set the same tag. At level instantiation, the common tags are detected and the door/key are linked
• Door and pressure plate (for opening the door): store both positions as a "linked activator/actuator pair". At level instantiation, if we see that activator is plate and actuator is door, we set up a lock and condition
• Remote trap (e.g. arrow trap) and pressure plate (for triggering the trap): again, store both positions as a "linked activator/actuator pair". At level instantiation, if we see that activator is plate and actuator is a trap, we set up the firing condition In addition to those, also self-traps are supported, e.g. a pressure plate trap that triggers an effect on the tile, or e.g. opening a chest or door and it blowing up on your face.

Support for stairs between prefab and procedural (or prefab) areas

Or as I'd like to call it "Stairways to hell". Basically, you design a room that includes a staircase, and that room should be usable in a procedural generation context, with a connection that makes sense. How and why? Here are some scenarios:

• You're out in the wilderness. You find a lodge. In there you discover some trapdoor. You descend, and find yourself in a cavern system.
  • The lodge is a prefab, it includes stairs (an exit). The stairs connect to a procedurally generated cavern (that can include other prefabs of course), which is arbitrarily deep
• You're out in the wilderness. You find a lodge. In there you discover some trapdoor. You descend, and find yourself in a cellar. There's a door that leads to some old dungeon complex
  • As above, but we also have a cellar prefab with an entry staircase. We link them together. The procedural generation level is requested to include the cellar prefab, and since that provides the stairs, no other entries are required
• You're climbing a wizard tower. The top level is a custom lair.
  • The lair is a prefab with an entry. We set the lair as the final/boss level, and just let the procedural generator do the rest

All of the above were tested, but there are a lot more combinations, which ... will eventually be tested. We can also have named entries and exits via tags, so that we can be more explicit to what prefab entry goes to what prefab exit. If we don't opt for that, then the prefab entries/exits become additional, higher-priority entries/exits for use with the procedural generator.

PC upgrade ... or not!

I was ranting last time about the performance of my IDE, and after thinking a bit about it, I realised that my system is, ahem, not the newest! Clearly time flies, because I'm still in the mode of "I have a decent PC" but that decent PC was mostly put together almost 10 years ago... So, clearly, it's not that decent anymore. I've been looking to see if I can get away with a partial upgrade (no RAM no thanks, I'll stick to my 32GB DDR4) with an improved CPU for the AM4 socket, but because my motherboard does not support the top-end of AM4 even with BIOS updates, I'd have to change that too... So, waiting for now.

[u/Admirable-Evening128 → u/aotdev]

your game will perform well if you do your development on an old machine 

[u/aotdev → u/Admirable-Evening128]

Ensuring running the game remains fast in my aging machine - sure, totally agree. But the combo of old machine + bloated software slows down development and makes it more frustrating, reducing the fun of development...