Hacker News Reader

Comment by endisneigh | Hacker News Reader

How do you handle the exponential growth of things you have to manage with these sort of things?

I hear Bandersnatch had a huge issue editing and filming due to the same issue.

I would hope the answer is, through more advanced building blocks - like variables, procedures, functions; through more advanced abstractions - like sequences, associative containers, maybe even state machines; through means of enforcing and verifying correctness - like a type system, or unit tests.

Interactive fiction markup language is a programming language - just with a weird syntax that's tuned for content-rich, control-poor programs. Kind of like SGML/XML is a format good for storing text-heavy, markup-lean data.

The same is the case with an interactive movie script. In both cases, your story forms a directed graph[0], and the reader/viewer traverses it. But you don't have to, and shouldn't, write out the whole graph![1]

Personally, when I see "managing complexity", I read "writing code". Because, once you look past all the minutiae of programming languages, build systems and computers, this is what programming is - managing complexity.

I don't think everyone should be a programmer, but I do hope the concepts used in software development will eventually become common knowledge.

[0] - Possibly infinite.

[1] - For the same reason you don't put your whole program into main() and don't write out conditional jumps as your only control structure.

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...

The usual approach for managing complexity is to chop it up into storylets. Emily Short has written a lot about it on her blog [1]

[1] https://emshort.blog

The simple answer is very carefully.

Deus Ex (2000) had similar issues. The game's story was originally intended to branch much harder than what actually shipped. Still, it's widely considered to be one of the best games ever made, owing in no small part to its emergent gameplay.

I think we're going to be entering the era of emergent story soon. After all, AI Dungeon exists today.

While emergent story sounds nice, like Nell's primer in Stephenson's novel "The Diamond Age", suspect we won't see it in the same way we won't see a perpetual motion machine. I was inspired to this conclusion by diydsp's chastisement [0] of pursuing algorithmic music. For me, it's the hope of infinite variety. Infinity, though, is only the purview of Horror and the Holy [1]. More likely, though, my computer would only be as creative as a forty person writers room. It's not to say that couldn't be good enough. They can be derivative, so long as it's of something I've not experienced. For example, I've heard the advice to new roleplaying game leaders to crib notes from tv shows and so on, rather than set themselves the task of refereeing and writing a novel story framework.

[0] https://news.ycombinator.com/item?id=26874918

[1] https://www.goodreads.com/book/show/1722845.Horror_and_the_H...

Reply on news.ycombinator.com