Explore splitting Delve content/functionality into its own module

[rsek]

One concern raised by @ben in the past is that this would make delve content much less discoverable... and we'd probably end up fielding a lot of questions about it, haha.

however! v11 is making several improvements to dependency management. among them are a "recommended packages" field in the system manifest. to my knowledge this is telegraphed in the setup screen, too.

Potential benefits

• follow the broader FVTT ecosystem by having core content living in the system package while supplements live in modules. a sensible convention, IMO
• less clutter for people who don't give a gosh darn about Delve stuff
• a module could be system agnostic, so people using the Delve framework for running dungeon crawls in other systems can get in on the fun!
• a tight, focused package may make it easier for other folks (particular first-timers) to build their own modules on top of it

Challenges

• how would migration work for foundry-ironsworn worlds with existing delve content?
  • migrateData is a reasonable start
  • i'm thinking an alert dialog with something like: "Delve functionality is now handled by XXX. Your Delve content is preserved, but you'll need to install the module to use them."
  • could an overlap period make this a bit gentler?
  • does v11 introduce any new package features that could help us out? for example, being able to flag a package update as having breaking changes, so people have a bit of warning?
• there's a bunch of other delve-specific optional rules and such. which package do those go in?
  • or... do i split the package even further? for example:
    • delve: basic, system-agnostic "engine"
      • actor: delve site
      • item: delve site theme
      • item: delve site domain
      • denizen matrix functionality -- cleanest way to do this is to allow it to handle any sort of actor. i can probably lean on document rolltable links for this
      • oracles? hard to avoid including at least some of them.
      • oracle presets/helpers/generators (monstrosities, delve site names, etc)
      • progress tracks? is that a thing people do when using it for other systems? 🤔
        • should... should progress tracks be their own module? oh god, what have i done
    • ironsworn-delve: depends on foundry-ironsworn, delve.
      • delve moves
      • delve encounters
      • optional delve rules: threats, failure track?
      • uses existing vue sheet since foundry-ironsworn is in the picture

With a system-agnostic module

• i'll have to write some non-vue sheet templates; i'd probably keep those simple, and let foundry-ironsworn simply override them with its fancier vue sheets
• how deep do i want to go with the rules implementation? like, what's the "cutoff point" where i say, "nah, i'll leave this to foundry-ironsworn"?
  • i should prob research this by talking to ppl who've used delve with other system

[rsek]

Huh, so as it turns out: items/actors are still system-specific, just not in a way that creates a module dependency:

fair enough. so, a system-agnostic delve module could still be reasonably expected to provide ironsworn-specific content; it wouldn't create clutter for non-ironsworn systems.

does raise some questions about what document to use as a base for themes, domains, and delve sites. 🤔

• journal entries are the only option with subtype support
• but rolltables actually model most of the behavior we care about
  • could be generated on the fly using prepareData(), similar to how we do them with getters in foundry-ironsworn
• a denizen matrix could be modeled with minimal changes to the base rolltable. it's really just a collection of actor results, and they already have support for that

a delve site, meanwhile, is basically a container for:

• a theme
• a domain
• (possibly) an additional theme/domain, if the optional rule for extras is used
• a denizen matrix
• a progress track to a site

which might be doable with a journal entry holding various subtypes of JEP? JEs also work as a map pin, which is nice.