Items and Enchantments Redux

I've been below radar lately partly because of too much work (the paid kind), but also because I'm rearranging some innards in the engine, in particular about items and enchantments. I'm not done yet, but it's progressing towards a direction where I think I can say that I'm not going to be backtracking.

Context for everything below: I'm very heavily using JSON for "database" data: anything that can be happily statically defined. One of my main issues thoughout several years is the lack of having a nice, generic and cheap way of specifying some property as either an instance or a database reference - this has led to a lot of special-purpose solutions, incurring technical debt.

Originally, my entity configuration/instantiation system had a few serious flaws. I had a special database for fully-fledged entity configurations (allowing things like location, etc), and the standard database that stored the more abstract configurations for ... other things, like equipment properties (not the items per se) or "usable item" properties, and so on. The former database ended up being very limiting, naturally. The reason I had provided that was because it was easy to mirror the entity configuration class. Long story short, I never used that entity configuration database effectively ... ever. Also, I added equipment enchantments just before the Unity fiasco, but I did so in a confusing way. So, this summer, I decided it was time for some heavy duty cleaning up.

I won't go through the long iterative process, so here are just the "fruits" of the labour (they might still contain a few worms, but that's going to show up after proper use).

• The fully-fledged entity configuration database is gone - the hassle is not worth the probably zero uses of it.
• Item instantiation is done in three stages:
  • Database prototype (e.g. "sword", or "potion")
  • Dynamic data (e.g. "iron" with 2 enchantments, or "minor healing" potion enchantment)
  • Entity-specific data (e.g. position, or owner)
• As hinted above, Equipment is handled in the same way, conveniently. I can specify a dagger in the static item database: its weight, base value, some pointer to its properties (attack skills etc). The dynamic properties can contain enchantments and the dagger's material, as the material may give extra properties: could affect weight, how well it can be enchanted, value multipliers, level ranges found in, etc.
• I rewrote some configuration classes that handle enchantments, and this is where things get a bit funky:
  • Equipment enchantments should be generated for any level. I should be able to ask for a lvl32 enchantment for a sword, to get some appropriate effects with appropriate "strength". So far so good.
  • I want potions to be visually distinct and generally stackable, because they're supposed to be consumed relatively frequently. For this reason, I want them to have fixed enchantment grades, e.g. "minor", "regular", "major". This will place fewer requirements for sprite generation (which will be procedurally augmented anyway) and allow better stackability than say potions of health lvl 1, lvl2, lvl4 etc, all being distinct unstackable items and probably looking identical on the ground.
  • Other items will fall in one of those two patterns, depending on requirements (and brain matter allocation when the time and content comes). The result should be the same: I ask for some good enchanted items for e.g. lvl 32, and I get something appropriate: either a granular enchantment in the case of equipment, or the closest-best in case of fixed enchantment grades.

Oof. On top of that, I thought I'd change this 3-tier configuration paradigm to the level objects (torch, door, table) as well, and that caused another massive refactor which has calmed down by now.

Other updates

• Journal screen. Because there will be quests, journal notes and text, I need of course a screen where you read some text from a document, plus support for creating such items. Now the interesting challenge will eventually be to add some procedural generation there too, not as much in the way of general exposition/history/lore (that should be more static), but context-sensitive stuff that relate to the current location and state of the world. I know GenAI is the thing to pursue, but I'm more interested in the likes of Tracery where I'm in complete control of the tone and text, plus I like a slight bit of funky repetition and standardisation, it makes it easier to distinguish the "flavour text" from the core info we want highlighted.
• Gold handling. To be an item, or not to be? Item suits better for roguelikes, so that's what I'm aiming for. I've prepared a few sprites, and some functionality, but to test it, I need...
• Item transfer screen. This I think is the last of super-essential screns (their lack being game-breaking), it's in the works