xenotropicdev / theoracle2 Goto Github PK

see p. 380 (in 020122) for a description. basically: 2-6 oracles (generally of a similar function - peril, feature/description, etc) are gathered in an array. the d6 is then rolled with the d% to randomize which table among them is used.

with a bot instead of physical dice, it'd be possible to have more elaborate ways of randomizing these, but for the time being it's probably better to just implement this close to as-written. partly for scope control, partly because getting super fine-grained about probability may not add much for the amount of work it is. maybe later (or on a separate bot).

here's some ideas on how it could be implemented:

at its most basic a command could look like this: /array [title] [oracle1] [oracle2] [oracle3] [oracle4] [oracle5] [oracle6].

however: since arrays are generally organized around being a Peril, Feature, or Opportunity, we could cut down on the 'noise' of autocomplete options offered to the user by splitting them in to subcommands: /array [subcommand] [title] [oracle1] [oracle2] [oracle3] [oracle4] [oracle5] [oracle6], where subcommand is one of Peril, Feature, or Opportunity. we could still accept any ID in the autocomplete fields for those who really want to go "off-road", but only offer autocomplete options for the appropriate category (or include them, if the user input is within a character or two?), which in some cases may allow us to display all available options before the user even starts typing them. Dataforged already has some (mostly-complete) tags that flag oracle content as perils, features, and opportunities; down the road, users could be prompted to tag their own custom oracles in a similar way.

rather than outputting a single result, the command outputs an embed with a display analogous to the sample index card, showing which oracles are assigned to this array:

included with the embed are components for managing the oracle array. at minimum this would be just a button to generate a result from the array in a new roll.

it'd be handy to have one to manage/edit the array contents, too - perhaps by swapping out different arrays? an example of a use-case for that is suggested by the index card in the book: no single 'derelict peril' table exists, so it probably refers to the peril table of whatever derelict zone the players are exploring at present. given that derelict zones are likely to change multiple times over the course of a single derelict expedition, recreating the card every time could get old. so maybe tables that have a parallel across multiple subcategories could be offered? hmm. this sounds like a pain in the ass to determine programmatically, but it's something i could tag in dataforged, too. List<string> GroupWith, perhaps, or as another tag string? that'd make it easy to extend with user content.

not all 6 oracle parameters have to be set manually, necessarily. if the parameters are optional, we could assume that any unspecified rows are populated with the last specified oracle. then if someone provides just oracle1 and oracle3, oracle1 is assigned to 1-2 and oracle3 is assigned to 3-6.

a more involved implementation might involve storing oracle arrays in the DB... but they're generally so fleeting that i wonder if it's worth doing so. it might be better to hold off on that until we can get an MVP in people's hands to see how they like it.

iirc we discussed this possibility in discord at one point, so i'll add it before i forget again.

if it comes down to whether or not the resource files can be easily generated by ppl who aren't using VS, an alternative approach would be for me them to just suck it up and migrate to VS for OSX for working on this project.

however, it did sound like there might be value in moving to JSON beyond that. i will say that, since i have a bunch of tools already built for manipulate dataforged's JSON, it'd be fairly easy for me to write tools to create a list of every translation string in the game. it would also make it easy to piggyback off of roll20's crowdsourced translation data.

more concretely speaking: if JSON resources were implemented tomorrow, i'd happily commit to spending the next week or so migrating all the strings over.

if we wanted something beyond simple string/key values, i do have a suggestion on the format. to assist ppl doing the localization , it may be useful to include page references with some/all strings, so that localizers can quickly locate the terminology in its original context. for example: "score" (verb, as in 'score a hit') vs. "score" (noun, as in 'progress score')

though if we're including that kind of metadata with them, well, VS's designer files do have that going for them already...

off the top of my head:

• unordered (bulleted) lists to unicode bullets
• links to discord's nonstandard underlined text (double underscores)
  • same regex could be used to parse the text for move references; a list of move references could then be used to generate
• tables (probably overlaps with table displays for oracle previews)

adjacent to XenotropicDev/TheOracle#76 : it'd be cool to associate assets with specific PCs/Parties/Command Vehicles in the DB.

TBH, the current system of assets being embed-only actually works pretty well, so this probably isn't especially high priority.

i think the biggest gain here would be making it possible to show all a PC's assets with their character sheet in some fashion (probably "collapsed" behind some button or menu option).

it would probably have to come with a command like /pc asset add, at least for the time being. it could be stored in the database as an AssetId, plus values for any user-settable asset elements like the condition meter value, a companion's name, and so on.

Db
  PlayerCharacter
    Assets
      AssetStub
        Id
        Name
        ConditionMeter
      AssetStub
        Id
        Counter

certain assets can have other assets attached to them - specifically Command Vehicles (e.g. starship - but i think keeping it generic is more future proof for shattered isles), plus the Rover support vehicle. in both cases these are restricted to Module assets. support vehicles aren't attached to command vehicles per se in the mechanics, but conceptually they kinda are, so i reckon they be organized similarly.

if parties can include a command vehicle/rover, we could still associate the Module asset with a player character to keep it tidy and better track xp spent. the vehicle could then check all members of the party for module assets to see what modules are attached to it.

Db
  Party
    Players
       Player1
         Assets
           ModuleAsset1
           PathAsset1
       Player2
         Assets
           ModuleAsset2
           CompanionAsset1
    Vehicles
      Starship
        Assets
          <ref: ~/Players/Player1/Assets/ModuleAsset1>
          <ref: ~/Players/Player2/Assets/ModuleAsset2>

if a Rover is available to attach a module to when adding a module asset to a PC, there might be some prompt to attach it to specific vehicle. otherwise they should default to the starship.

If we keep track of the last interaction each discord user did within a server we could default things like the player character look-ups to that character. It could be it's own database table, and/or be data point for each character in the database.

this would probably require a rewrite of significant portions of the PlayerCharacter class, its related enums, and any commands that touch PCs.

it might be worth following the game's parlance here:

• edge, heart, iron, shadow, and wits are "stats"
• momentum, health, spirit, and supply are all "meters"
• health, spirit, and supply are "condition meters", but momentum is not
• PCs may or may not have additional condition meters from their assets
• only "stats" and "condition meters" are rollable

introduced in #7 a245e4e 🤦

resolved by #29 d18b903 , but it's pretty self-contained and could easily be applied ahead of that.

Discussion about how to store, create, and update game data.

Main options are:

• None (Current Oracle approach)
  • Relies on discord
  • Has a lot of extra code for parsing things
• Database
  • Requires some additional data storage
  • Has recreation advantages
  • Probably custom object advantages

The action-pc-roll is relying on the player message Id not being 0 for something, and that's causing the interaction to fail.

i'm thinking a multi-select dropdown to reroll (and maybe set?) some or all of the dice.

additional user input could be obtained via an emphemeral to keep the roll embed post uncluttered.

questions to answer:

• how should roll "history" be conveyed?
• what's the most sensible limit on the number of rerolls allowed?

atm this would mainly be to have a referenceable, standardized embed template to keep things consistent. but once text inputs/modals are live, it could be used to standardize components that can be used to, say, edit descriptions/titles without creating a new embed.

this will make it easier to:

• maintain consistency when using emoji as ux icons
• reference emoji by strings instead of digging in to the character map
• save time searching for an appropriate emoji
• easily make sweeping changes to emoji across the board
• enable reverse lookup of emoji from component interactions, as a fallback in case we need to lower the character count on a custom ids
  • example: 📖 is associated with "reference" in the dictionary. if this emoji is parsed from the originating component of an interaction, it is understood as as attempting to reference content specified elsewhere in the component
  • ngl, parsing emojis for anything seems pretty cursed. on the other hand, once localization is in place, it might be more reliable than parsing a components's Label or Description...

• i'm imagining a Dictionary<string, IEmote> handling most of the Ux actions
• emoji representations of oracles, moves, etc might be better handled by some system of fallbacks. example: if there's no association with a specific oracle table, it falls back to oracle category. if there's nothing for the oracle category, it falls back to a generic oracle emoji.
• some specialized groups of emoji (progress marks, etc) might be better handled with a Dictionary<int, IEmote>

Player characters cannot be deleted from the database, and might start to get in the way if they issue test commands, then move to a long term player card.

• See rsek's branch on TheOracle's github

we have a number of situations where the group/params of a slash command or the values of a selection menu are important, but the log output doesn't include them, which makes them a little harder to debug. would it be feasible to include them when they're available?

Select Menu Components

Slash Commands

in starforged there's now several properties associated with each challenge rank (ticks marked on progress tracks, legacy ticks from expedition/bond/quest of a given rank, recommended resource hit, etc). i could centralize this in a dictionary, which could then live in the service providing other rules data.

Oracle results should show a thumbnail if one is available.

my intent is to cover campaign clocks, tension clocks, and scene challenges. see #7 for details.

• Buttons over reactions (See Discord.Net Labs examples)

Currently if things change within a components ID all the bot users will need to remake their character to solve the issue.

My initial thought is that any breaking component ID changes should keep the old ID signature around for a while and convert the message to the new format if possible, or alert the user if not.

I'm not sure if there's some kind of framework that can be developed to help with this issue, but I wanted to post this as an issue so that others can discuss it, and I can have a place for any ideas I have regarding this topic.

For the time being this isn't a huge issue as the bot is still in an alpha phase, but as we get closer, and up to a release it will become a big issue as the bot user base grows.

This is caused by the subcategories in the Dataforged data. More detailed entries and a better db search query should fix this.