Have you written an IF game in a language like Inform or TADS?

Any object can potentially interact with any other object in the same scene (or in your inventory). These languages support standard language abstractions (classes, types, whatever) - but that will end up with very boring responses when you try to make two things interact with each other, and players don't enjoy the game if it has too much of this - it kills the suspension of disbelief. As such, game designers put in a lot of effort to put in custom responses and behavior just so that the player remains immersed in the game.

It's an O(N^2) problem.

They usually invent game dynamics to prevent this from happening (e.g. making sure you lose/consume objects to get from one part of the game to the next - so that N is drastically reduced).

I hate to say it, but your comment comes off a bit condescending. While Ink and Inform hide away some abstractions to make it easy for newcomers, plenty of games are written in TADS (easily the 2nd most popular language for IF), and you very much have to have a programmer mindset to write games in it. Telling a TADS programmer they need to think in terms of variables and functions is like telling a physicist he needs to understand calculus to model the world.

> I hate to say it, but your comment comes off a bit condescending.

Upon re-reading, I think it may come off this way. I'm sorry - I didn't mean it.

My comment was mostly colored by experience with various IF examples I browsed over the years, including most recently poking around some RenPy-powered visual novels. In all those cases, the stories were vastly under-utilizing its markup language. By that I mean, you could cut the source down to 1/10th or less of its original size by introducing some loops and variable grouping; further still with procedures. Reading them felt like reading assembly output of heavily inlined code.

What I failed to communicate is that my complaint comes from a good place in my heart! The stories I just criticized were all good stories, packaged into great experiences. But then I see the mess inside and realize just how hard it was for the author to evolve it, how much time and pain and effort they've burned maintaining an script whose complexity grows like O(2^N), not O(N^2)! How much easier it would be for them, how much richer story they could deliver, if they used higher-level tools for the job.

> It's an O(N^2) problem.

In raw form, it's 2^N problem - it's all the little "visited-church_1?", "visited-church_2_night?", "ate-biscuit?" flags that are exploding. This is the part I see frequently mismanaged, where higher-level tooling would be helpful. You can build neat interactive stories with just some flags and conditionals, but what you write is limited by how much of the resulting state space you can keep in your head over time (the problems really start when you want to change something you written a while earlier).

> They usually invent game dynamics to prevent this from happening

That's a good, time-honed, high-level strategy :).

> that will end up with very boring responses when you try to make two things interact with each other, and players don't enjoy the game if it has too much of this - it kills the suspension of disbelief

That's true, and the same is also a problem with videogames with procedurally generated content (this and IF being essentially facets of the same thing). But there are ways around it, if the tooling helps you with this, and you know how to use it. That's why I'm wishing for some wider knowledge sharing of tools and techniques from the programming world, because we deal with structurally isomorphic problems every day, and have plenty of tricks up our sleeve, that could be useful for IF writers, or even managers and legislators (bureaucracy is a computing environment too - where rules are code, forms are messages, humans are the runtime).

> While Ink and Inform hide away some abstractions to make it easy for newcomers, plenty of games are written in TADS (easily the 2nd most popular language for IF), and you very much have to have a programmer mindset to write games in it. Telling a TADS programmer they need to think in terms of variables and functions is like telling a physicist he needs to understand calculus to model the world.

You're right, and I apologize here. I haven't seen TADS before. Skimming some sources downloaded from the project page, it definitely exposes you to some software development experience (including the less nice, and perhaps less relevant, parts too).

Relatedly a lot of other similar complexity management tools from "writing code" have direct or indirect equivalents in writing complex branching narratives. Things like "integration testing" ("if I run this script of choices, do I get a world state that I expect?") and "fuzz testing" ("can the user find weird input combinations that break the world state?").

You can graph dependency graphs and state machine graphs to try to look for bad patterns or unwinnable cases visually.

In one interesting extreme example Andrew Plotkin put a ton of work into building python tools to build the puzzle dependency graph of Hadean Lands to hard prove them (in the style of mathematical proofs) and make sure they didn't contain unaccounted for unwinnable states. Plotkin blogged a lot about that during the development of Hadean Lands.

If I was Plotkin I'd use prolog for that :), that's just a graph node-dependency check.

I assume it was a combo of familiarity and also related to whichever mechanisms Zarf was extracting world states graphs from Inform 7 and/or Z-Machines. (I haven't read the blog posts in a while, and obviously Zarf's blog is blocked on this work laptop because technical discussions about games can't possibly~ have technical insight into work.)

Although you're right, if you phrase OP's question as "how do you manage complexity with Ink", you could talk about specific named constructs in Ink (knots, stitches, weaves, tunnels, etc.) These are specific ways to organize a story graph and transitions, and might look like or be direct equivalents to concepts in other programming languages, but have specific names and usages in Ink. As always it's probably best to RTFM if you want to know more about how these concepts work rather than a random HN comment :) https://github.com/inkle/ink/blob/master/Documentation/Writi...