Replies: 1 comment 1 reply
-
It reminds me a lot of the old system, which essentially constructs items and saves them into the world itself. I don't like that system because it limits the type of relics, and prevents any kind of updating later on to the base item type since it only copies from it but creates an entirely different item. If this is specific defined items with copy-from then relic data appended, a system that just calls a "relic" itemgroup could work, and would be easily extensible. One of the major downsides to normal relicgen is that usually the combinations are trash, so this could help us make more balanced artifacts, though I imagine you'll quickly run into duplicates and there are less highs and lows. I'm of two minds on that. |
Beta Was this translation helpful? Give feedback.
-
So I had an idea recently while continuing to fumble with #4171, that it might be possible to implement the intended end result of generated artifacts purely via JSON. While I got past the initial compile failures that started giving me second thoughts, it's still going to be a lot more work before I can port everything we need for even a basic relic generation setup, test it all, sort out any remaining code divergences, and only THEN can I even get to actually writing up what kinda artifacts I want it to generate.
Implementation this in JSON would entail defining a number of base objects, ideally inheriting from specific templates to streamline things. Then these objects would get a pool of potential variations that inherit from them and each define specific
relic_data
. These would essentially be a collection of premade artifacts.Player-wise, the main advantage here is we could construct items with specific themes and fine-tune the balance of any given premade artifact. Much like how Arcana mod, Magiclysm, and Magical Nights tend to implement magical items, they could all have specific themes and utility, so you'd never get an artifact that does nothing but tank your stats and irradiate you with no upside. The drawback, obviously, is the amount of variations on an individual base item will be limited, there won't be the kind of true randomness that DDA's relicgen is hypothetically capable of. If the player picks up a flesh cube or whatever and there's a dozen potential relics it could be, they can still learn to expect what that item will do. Whether this is a good thing or not, say if the pool of effects for said base item were themed (so for example, all effects tied to flesh cubes pertain to themes of healing and stamina but also potential mutagenic effects) is definitely subjective.
Development-wise, the big one is simplicity. I'm still not great at wrangling C++, plus been juggling a lot both offline and online these days, so getting time and energy to port over and polish relicgen code is difficulty. Unless I can find someone to foist all that work onto who knows the code better, I don't know how long it'd take until the relicgen PR is finally usable. There's a lot of PRs from DDA we'd need to port because I don't want to just merge a bare skeleton of the system and then risk it staying like that due to further port work stalling, I'd want to get it to a basic level of playability before it even leaves the draft stage. Whereas going straight to the JSON solution means I'm immediately writing the actual artifacts and their effects, basically we get to shortcut straight to actually using the relic data we already have the existing foundation for.
The downside is tedium. Not for the player, but for the person writing it. JSON writing and cooking up a bunch of ideas for premade artifacts and what themes they could have will be a lot of mind-numbing copy-paste work. It's still potentially going to be slow going. I should note however, that these methods don't have to be mutually exclusive. We need to write up the basics of the base items and plan what effects they could potentially have anyway. And even if we switch to the JSON method then complete relic generation later, we can use those pools of thematic effects as a baseline for
relic_procgen_data
pools, and use the base items themselves. The only thing we'd need to obsolete in the process would be the premade artifacts inheriting from the base items, and then restructure any itemgroups that spawn them to instead use the ability to spawn relics once CleverRaven/Cataclysm-DDA#42345 is ported over as well.In addition, I would still have the option of keeping my portover PR on the backburner and working on it when time and energy permit, so the question is basically whether I keep fumbling with it before actually implementing random relic spawns, or do I essentially shift focus to a way that lets me create and place the relics first using JSON methods initially, then implement a way to randomize their properties via C++ methods later on.
21 votes ·
Beta Was this translation helpful? Give feedback.
All reactions