> I like your idea of a TRPG helper. I was thinking of something similar. Like, have an app for combat only, where you set up the combatants, and then let the DM simulate effects of different actions done to those combatants. As you say, in TTRPG it's important for the DM to be able to bypass the system, make an exception, etc. But I'd say that 80% of the time, the DM can just report the effect back to the players. And it takes them much less time and mental effort. (Especially if we're talking about one of the more simulationist TRPGs like Blade of the Iron Throne [3].)
TL;DR: This is exactly what I'm working on, and exactly for the reason you say (input what the player wants, input the dynamically generated questions about what rules to apply here, then just report what happens), and seeing things like your Knights of SF game app give me hope that it is possible to build something like this after all!
The goal is to give the GM time to imagine narrative flair, all within a ~10 second cycle time between player input and game output so the players don't lose interest. If you as the DM have gone through all the rules, gathered further player input (you can crit! Do you?), figured out what happened, and report it to the players only to look up and see them all on their phones because it's been 12 minutes and by the way you forgot some rules that the players bought for their characters but neglected to mention, something has gone wrong. As ignoring rules that affect the battle is not a solution (why would they write them in the book if they didn't matter), a battle sim helper would greatly speed up the process of adjudicating character turns in a battle without slowing the action down to an entire session of just battle dice rolling.
Right now battles are the slowest thing that happens in our campaigns because while the battle is a closed finite state machine, it has a combinatorial explosion of state that affects subsequent options, actions, and outcomes, which is all manually tracked in the head or on paper of the GM and/or players. So much for the advertised 'narrative first, fast paced' combat system!
The particular game system I am modelling is called Genesys[1] and has a fully developed game logic model [2] (in-game characters have fields which themselves have validation rules and invariants which all effect the core mechanic of assembling a dice pool from the saved state, reading the dice results, applying the outcomes to the saved state, which then affects subsequent character turns etc.).
I am currently only modelling what happens in a fight AKA a turn-based battle system. Each battle rule will have simple text, but that then has to be parsed in order to determine where and how to apply it.
The example rule below is one of the most simple rules in the game. This is before one enables the user to edit this instance of the rule, or ignore it for this particular occurrence, or delete it from existence entirely, etc. etc.
Adversary (rule name) 1 (rule rank) [passive] (activation condition) - when targeted by a combat check (trigger condition), upgrade the difficulty of all incoming combat checks (outcome).
So we have a name, a rank (or not!), an activation condition, a trigger condition (or multiple), and an outcome. And in theory we want the user to be able to modify any of these fields at runtime for just this once (because of some narrative reason), or on a permanent basis until further notice.
Other rules have an active activation condition, so you need to check if the character would be able to trigger the rule at this time (or has some past transaction precluded it), a composite trigger condition (you are attacked, and you are hit, and the attack skill is melee, and you have not yet moved in this turn), and multiple outcomes, each with their own side effects & conditions (you take damage, the attacker gains a boost dice on their next transaction, but only if they don't already have a boost dice from a previous transaction).
Algebraic data types can help wrangle some of the game logic, via tools like aggregates of tagged unions, but while I currently have the skill to reason about modelling and writing the vertical code slices for writing and retrieving the data, my still-evolving understanding of the overall game logic system and my relatively clunky choice of tech stack (UI is Giraffe HTML forms, JSON-RPC for API, sqlite for storage) all combine to mean that I make slow progress actually getting all of the rules modelled, written to and from the DB, evaluated to affect the overall state, and updating the UI or returned API responses.
In short, I've bitten off way more than I realized at the beginning and while I've not given up yet, I definitely hope that a read through of Designing Data Intensive Applications will help me fix my data structure choices and/or re-architect my entire system to something more manageable, yet still gives me the ability to enable end users to modify the rules at runtime. Right now, because I don't know what architecture would be best in this scenario, I spend time wondering if I should re-architect to cool sounding things I found on the internet like Discrete Event Simulation, Functional Event Sourcing, Akka.Net actors, Rules Based Engine, Expert Systems, Workflow Engine, or instead try to keep it simple with something like a Finite State Machine and (application code level, database is only a data store) Online Transaction Processing would work, but my inexperience in building this system likely results in suboptimal choices like my current FSM top-level aggregate with sub-entities themselves having inconsistently built-out FSMs of their own.
Not exactly the same, but I wrote StoryHarp (FOSS) which involved defining rules to create text adventures. It includes some different ways of looking at rules as a table, a browser, and a map. Maybe there might be some way for you to come up with a way to use it to much of what you want to do in terms of defining simple rules that a GM could click on to get options. There is no randomness in the system though, so a GM would have to introduce that somehow, like maybe by rolling some dice to pick from some options. You can use it in a web browser.
https://storyharp.com/
This looks neat! The license is unclear from a quick glance of the Github so I won't be reading any of the source available, but I will be sure to try it out as a user.
TL;DR: This is exactly what I'm working on, and exactly for the reason you say (input what the player wants, input the dynamically generated questions about what rules to apply here, then just report what happens), and seeing things like your Knights of SF game app give me hope that it is possible to build something like this after all!
The goal is to give the GM time to imagine narrative flair, all within a ~10 second cycle time between player input and game output so the players don't lose interest. If you as the DM have gone through all the rules, gathered further player input (you can crit! Do you?), figured out what happened, and report it to the players only to look up and see them all on their phones because it's been 12 minutes and by the way you forgot some rules that the players bought for their characters but neglected to mention, something has gone wrong. As ignoring rules that affect the battle is not a solution (why would they write them in the book if they didn't matter), a battle sim helper would greatly speed up the process of adjudicating character turns in a battle without slowing the action down to an entire session of just battle dice rolling.
Right now battles are the slowest thing that happens in our campaigns because while the battle is a closed finite state machine, it has a combinatorial explosion of state that affects subsequent options, actions, and outcomes, which is all manually tracked in the head or on paper of the GM and/or players. So much for the advertised 'narrative first, fast paced' combat system!
The particular game system I am modelling is called Genesys[1] and has a fully developed game logic model [2] (in-game characters have fields which themselves have validation rules and invariants which all effect the core mechanic of assembling a dice pool from the saved state, reading the dice results, applying the outcomes to the saved state, which then affects subsequent character turns etc.).
I am currently only modelling what happens in a fight AKA a turn-based battle system. Each battle rule will have simple text, but that then has to be parsed in order to determine where and how to apply it.
The example rule below is one of the most simple rules in the game. This is before one enables the user to edit this instance of the rule, or ignore it for this particular occurrence, or delete it from existence entirely, etc. etc.
Adversary (rule name) 1 (rule rank) [passive] (activation condition) - when targeted by a combat check (trigger condition), upgrade the difficulty of all incoming combat checks (outcome).
So we have a name, a rank (or not!), an activation condition, a trigger condition (or multiple), and an outcome. And in theory we want the user to be able to modify any of these fields at runtime for just this once (because of some narrative reason), or on a permanent basis until further notice.
Other rules have an active activation condition, so you need to check if the character would be able to trigger the rule at this time (or has some past transaction precluded it), a composite trigger condition (you are attacked, and you are hit, and the attack skill is melee, and you have not yet moved in this turn), and multiple outcomes, each with their own side effects & conditions (you take damage, the attacker gains a boost dice on their next transaction, but only if they don't already have a boost dice from a previous transaction).
Algebraic data types can help wrangle some of the game logic, via tools like aggregates of tagged unions, but while I currently have the skill to reason about modelling and writing the vertical code slices for writing and retrieving the data, my still-evolving understanding of the overall game logic system and my relatively clunky choice of tech stack (UI is Giraffe HTML forms, JSON-RPC for API, sqlite for storage) all combine to mean that I make slow progress actually getting all of the rules modelled, written to and from the DB, evaluated to affect the overall state, and updating the UI or returned API responses.
In short, I've bitten off way more than I realized at the beginning and while I've not given up yet, I definitely hope that a read through of Designing Data Intensive Applications will help me fix my data structure choices and/or re-architect my entire system to something more manageable, yet still gives me the ability to enable end users to modify the rules at runtime. Right now, because I don't know what architecture would be best in this scenario, I spend time wondering if I should re-architect to cool sounding things I found on the internet like Discrete Event Simulation, Functional Event Sourcing, Akka.Net actors, Rules Based Engine, Expert Systems, Workflow Engine, or instead try to keep it simple with something like a Finite State Machine and (application code level, database is only a data store) Online Transaction Processing would work, but my inexperience in building this system likely results in suboptimal choices like my current FSM top-level aggregate with sub-entities themselves having inconsistently built-out FSMs of their own.
[1] https://www.fantasyflightgames.com/en/products/genesys/
[2] https://genesysemporium.com/