discussion: data model roadmap

[rsek]

as the data model is changed incrementally, particularly for a post-v10 world, i think it'd be good to do some thinking on the "big picture" of how all the types fit together. here's some ideas on what a target for that might look like:

Actor

PcActor

• "PC" is probably a better term to use than "character", because "character" technically includes NPCs, which need to be their own type
• it'd be cool to have a model that relies on stat/resource definitions in the PcActor object itself, rather than hard-coding them. that'd make it more flexible for customization/hacking. an example of what i mean:

/**
* Use to determine whether a roll button should be displayed when rendering
* a representation of the IronswornResource in question.
* 'roll' means it can be added as a stat to an action roll
* 'burn' means it can be burnt like momentum
*/
type ResourceAction = 'burn' | 'roll'

/**
* Describes an Ironsworn-style resource like momentum or health.
*/
interface IronswornResource {
  max: number
  min: number
  current: number
  /**
  * @default ['roll']
  */
  actions: ResourceAction[]
}
/**
* Describes a Starforged-style legacy track
*/
interface StarforgedLegacy {
  ticks: number
  xpSpent: number
}

/**
* A valid localization key, so that the keys of a Record succinctly indicate
* which localization to use for labelling. A smarter version of this would probably
* just import the relevant json files and type things with `keyof localizationData`
*/
type i18nKey = string

interface IronswornPcActorDataSourceData {
  stats: Record<i18nKey, number>
  resources: Record<i18nKey, IronswornResource>
}

interface StarforgedPcActorDataSourceData extends IronswornPcActorDataSourceData {
  legacies: Record<i18nKey, StarforgedLegacy>
}

interface ClassicPcActorDataSourceData extends IronswornPcActorDataSourceData {
  xp: {
    earned: number
    spent: number
  }
}

SharedActor

• main difference from the current format: has its own assets. for use with e.g. Starship, SF modules, Fortune Hunter (per Delve wealth rule)...
• obviates StarshipActor

NpcActor

• handles functionality currently covered by FoeActor
• may be linked with an NpcJournalEntry

PlaceActor

• may not be necessary, TBH, if progress tracks aren't Items
• "Place" may be a better choice than "Location" because "Location" is used throughout Starforged as an attribute describing whether something is planetside/orbital/deep space

Item

AssetItem

• add a toggle, "shared". if it's true, the asset is considered to be shared by all players; this might entail actually moving it to the Shared sheet, or some other means of presenting this info to other PCs?
• PC sheet could include a collapsible display of all shared assets (or just include some shortcut to the shared)

DelveRarityItem

• i think there's a logic to this being a discrete Item (one object = one, well, object) but the simplest implementation would just be a toggle on AssetItem...
• one benefit of making these an Item is: they could then have an icon, a text input for notes, and so on. i think this would be cool, actually - makes rarities feel like special objects of power as a player
• maybe DelveRarityItem comes with an ActiveEffect, and has fields for setting the asset affected by said effect?

StarforgedIncidentalVehicleItem

• haha, that name's a mouthful. but personally i don't mind long names for the sake of clarity/consistency/easy searching. and hey, that's why we have tab completion, right?
• haven't thought too hard about this yet. but if the more-mechanically-dense Companion and Support Vehicle assets are adequately handled by Items, i think it's a reasonable place to start

JournalEntryPage

post-v10, JournalEntryPage is the "atomic unit" of FVTT's Journal system. it can be displayed in aggregate within its parent JournalEntry, or as a list of separate items. i think it'd make sense if the the game's "atomic units" of tracking (progress tracks and clocks) have a 1:1 correspondance, e.g.:

JournalEntry
  ProgressTrackJournalEntryPage
  ClockJournalEntryPage

rather than the clock being embedded as a property of the progress track object:

JournalEntry
  ProgressJournalEntryPage
    [Clock]

this lets us leverage FVTT's native indexing/searching, for instance. keeping them inside a single object made more sense with ProgressItem since it was the only way to keep them grouped together, but we have more flexibility now (especially since the parent JournalEntry can be organized into folders, too).

ProgressTrackJournalEntryPage

• use multiple ProgressTrackJournalEntryPageSheet to provide type-specific functions?

ClockJournalEntryPage

• could have different sheets for tension clock, campaign clock
• handle IS-style countdown/threat with sheets also? or embed in progress track?

JournalEntry

post v10, JournalEntry is a container for multiple JournalEntryPage rather than having text itself. its extenrnal organization (e.g. can be placed in sidebars, folders, etc) remains roughly the same, though.

JournalEntry could then be used as a container for anything that might contain a any combination of progress tracks, clocks, or pages of FVTT's standard types. i think this approach fits fairly naturally with IS: 1 NPC/Place = 1 Journal Entry is fairly intuitive (or at least i think it is, because that's what i do in my own games, haha)

NpcJournalEntry

• may be linked with an NpcActor
• different sheets to offer dice shortcuts for different types: SF creature, delve monstrosity, NPCs from either game, etc

PlaceJournalEntry

• may be linked with a PlaceActor (if it turns out to be necessary)
• functionality currently managed by separate canvas tools that generate actors (e.g. World) could instead be handled via several PlaceJournalEntrySheet types, making it easy to switch between different types "midstream"

ActiveEffect

worth investigating as a way to handle debilities/impacts, at the very least. certain ongoing asset effects might be managed here too

ImpactActiveEffect

• would also cover IS Debilities, since they're functionally the same
• the momentum adjustment could live here rather than being a static property of the PC
• there's a couple like "Wounded", "Shaken", "Unprepared", etc that add additional effects (can't restore health/spirit/supply). having reminders for these would be helpful
• them being their own effects makes it more convenient to include descriptions + rules info for them, too

AssetActiveEffect

• e.g. Ritual effects that last until you roll a 1 on your action die
• they usually define an effect and an end condition. we could have a field for each
• rather than automating the addition of a bonus or removal of an effect, we might instead provide reminders to the player
  • e.g. the roll dialog includes a message like "You have the following active effects"

DelveRarityActiveEffect

• companion to DelveRarityItem, above
• user-facing configuration is manipulated user interface of DelveRarityItem
• when present, the roll dialog or output might include additional options/reminders?