Complex game worlds, simple text interfaces (2015)
egamebook.com
egamebook.com
I have a sense that this space is somewhat unexplored. Text-based game world simulation is a relatively underdocumented (to my eyes) form of the 'game UI overtop a database manipulated with game logic rules' type of games, of which Simulation games are at the complex end of.
There are things like Twine and Inky that offer variables and conditionals to prewritten bodies of text, but doing composable texts worlds that change their state based on the accumulated choices of players over the course of their time seems to be a complex feature to build and extend, whether in Twine or another tool. Dialog simulation systems that remember what options you've done and give you additional options or changes over the course of the game are sold as products online. Heck, someone recently patented a 'grudge' system that a popular game (League of Legends?) used.
Or maybe I've just been looking too closely at it. I've been working slowly for about the past 2 years on an automation system for a tabletop RPG (non D-20 system) to speed up battle generation & resolution, trying to incorporate all of the various rules that say 'in X scenario, if Y conditions are met, gather this information from the user, then apply its Z effect like so, but also let the DM / user change any of the above or ignore the entire thing before you do so', so while I've ordered Designing Data Intensive Applications in hopes of gaining more insights, this problem certainly seems like a big thing to chew on from my self-taught programmer's POV right now.
The game has several levels (explored more in my 2017 "fractal stories article"[1]) - from top to bottom it can be something like
> you're in a room > you're talking to this person > you're in this branch of the conversation
OR
> you're in another location > you're in a fight with these two monsters > monster A is swinging at you with an axe > you've deflected that swing and have an opportunity to counter-attack
It's basically a stack of situations.
To answer your question, the design patterns differ according to the situation. The roaming between the locations is relatively simple node-navigation (except we need to track from which node we come to each location, for example, and we can skip through visited nodes that haven't changed). The dialogue can be something very similar to ink [2]. The combat is similar to roguelikes, where it's turnbased, but as a player, you only "see" your own moves, and the other moves happen in between. I do track of time on the level of milliseconds, and I have moves that take more or less time, also depending on who makes them (an agile goblin readies a sword much quicker than an old man stands up from the ground).
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].)
[1]: https://filiph.medium.com/skyrim-rendered-in-text-1899548ab2...
[2]: https://www.inklestudios.com/ink/
[3]: http://ironthronepub.com/
(Edit: format)
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.
A concentration is a kind of value. 200.9ppm specifies concentration. 200.9 ppm specifies concentration.
A room has a concentration called current concentration. A room has a concentration called former concentration.
To decide what number is the probability inverse between (space - a room) and (second space - a room):
let guess be 20;
let way be the best route from space to second space;
if way is up, let guess be 50;
if way is down, let guess be 10;
if the guess is less than 10, decide on 10;
decide on guess.
Every turn:
follow the diffusion rules.
The diffusion rules are a rulebook.
A diffusion rule (this is the gas movement rule):
repeat with space running through rooms:
let sum be 0.0 ppm;
repeat with way running through directions:
let second space be the room way from the space;
if second space is a room:
let incoming be the former concentration of the second space divided by the probability inverse between second space and space;
let outgoing be the former concentration of the space divided by the probability inverse between space and second space;
let difference be incoming minus outgoing;
increase sum by the difference;
now current concentration of the space is the former concentration of the space plus the sum.
A diffusion rule (this is the resetting concentration rule):
repeat with space running through rooms:
now the former concentration of the space is the current concentration of the space.
The last diffusion rule (this is the lethal dosage rule):
if the current concentration of the location is greater than LC50:
say "The concentration in the air overpowers you...";
end the story;
otherwise:
if the current concentration of the location is greater than TLV-STEL:
say "You feel extremely uncomfortable in this environment."
Instead of doing something when the current concentration of the location is greater than TLV-STEL:
if going, continue the action;
say "You can't work in this environment: your eyes and nose sting and it hurts to breathe."https://play.google.com/store/apps/details?id=egamebook.com....
The main menu art and music is cool, though.
The lack of focus on graphics meant that complexity of description and systems didn't need to have visual work to go along with it, which allowed for much more complex systems than I'd seen in any game at the time.
Maybe that extra effort makes it more enjoyable and valuable?
Part of the immersion was how strict the RP was. You weren't even allowed to break character in the public chat. From the newbie guide:
In Achaea, you are playing the role of your character, not yourself. Your character is of the realm of Achaea and knows nothing about concepts like computers, the internet, the Boston Red Sox, or anything that does not exist in the world of Achaea. You must remain "in-character" (IC) just about everywhere. There are a few exceptions, such as in private conversation with someone else who does not mind if you go "out-of-character" (OOC). There can be administrative consequences for going OOC publicly, so be careful! If another adventurer warns you that you are exhibiting "insanity" or acting "insane", be aware that the word "insanity" in Achaea usually refers to OOC behaviour.
For me, it's a winning combination of a) quick to start, b) easy to "pause" (it's not realtime), c) lightweight and d) high-level strategy. Unfortunately, it was lacking depth at the time I played it (a few years back). I didn't mind, though. It was a casual fix, like playing Tetris.
Anyway, definitely recommend picking it up. And it's by a solo dev, so there's an authorial quality to it, too.
If you've never done it, find a TV and movie or show that has audio descriptions of visuals for visually impaired audiences. It's kind of an interesting experience to hear a voice over describing the scene.
One of my favorites was the description of the opening Paramount logo animation. Something like, "Stars flying from a dark sky skim across the surface of a calm lake towards a distant mountain, then circle the mountain as the name 'Paramount' appears"
Back in the day he gave a couple of talks about using logic systems & logic programming to control NPC behaviour. The end result of that work went into Little Text People.
An interesting idea would be to have 3 good options shuffled up with 2 bad ones.
Ok, well. We'll define text something being able to be printed on a teletype.
Modern Z Machine games have complex-ish worlds, but roguelikes' objects have a far more emergent gameplay.
Then, MUDs. A lot of them have pretty complex worlds simulations.