I know! I loved those games. We would load them onto our neighbor's TRS-80 from a cassette tape. It would take a while, so you really had to want to play. I managed to finish Haunted House, but I struggled to finish the other one she had - I forget what it was called. Then I wrote my own in BASIC. I wish I still had those cute things :)

Indeed, they do! Helen's first choice is whether to follow her heart and marry Jed, or to go along with her family's plans, and wait for Saunders. Likewise, Jed can decide to, but does not have to marry Helen. In this sense, depending on the reader's choices, the stories of the various characters may become inconsistent (and I guess this is hardly avoidable).

Thanks, Andrew! Where can one find your interactive fiction?

There are some scripting languages for writing gamebooks precisely to capture the kind of dependency that you illustrated: - Ink is Inkle's in-house language. (Listing it first because I find Inkle's games stunningly beautiful and fun.) - Twine is another scripting language with lots of open-source digital gamebooks (the website claims 'thousands'). - Choicescript is a third option (this one I haven't tried at all; some of their games are quite successful on Steam). From my cursory research: Ink and Choicescript do not natively allow for generating gamegraphs. Twine already uses graphs in its design, though [I'm merely guessing here] a graph in Twine is not identical to what I would mean by a gamegraph, where picking up a key or not would result in branching. So one could try building an Ink/Twine/Choicescript -> gamegraph functionality.

For your work, twenty thousand nodes should be quite managable for WL. Care to do some tests?

I wish I'd invested more time early on during development of my own work in progress (2001 to present) to harnessing WL Graph functionality to track game state dependency. My interactive fiction's also in a discrete choice-based system, so somewhere between a "game book" and a modern text-parser game on the scale of how quickly the game state can branch.

Instead of Wolfram tools, I just used flowcharting software to build up a dependency graph, where each node wasn't a complete state of the game, as with a CYOA-style book, but a permanent advancement in some aspect of the game state, with one (or more) nodes pointing to another if the former were (all of the) prerequisites for the latter. Example with three linked nodes:

[Find Key] ---> [Take Key] ---> [Unlock Door]

A serious drawback was just how inflexible and cramped a flowchart can become with no automatic functionality for spacing out nodes logically. The attached image shows an overview of how large the chart became (in 2004) by the time I maxed out the number of allowed links by the software and gave up on charting things this way. (The game's start point is in the top-left corner, and roughly speaking, the further down/right one moves, the deeper into the game is being represented.)

This post's got me interested once against in trying to build up my current inforrmation in a graphable structure, if I can be confident it can handle on the order of twenty thousand nodes!