Does anyone know of an examples of stories/games made with this? Not like a full on game like 80 Days, but something like what you could end up with after following the tutorial?
I want to show this to a friend and I think an example would help give them an idea of what's possible.
I'm happy to report that this Ink-based portfolio is accessible with a screen reader. I wonder if Inkle ever plans to switch to web technologies for their full-blown games, instead of embedding Ink in a game engine.
(A few of those are false positives because someone made a personal scripting language called Ink, but most of them appear to be the interactive fiction from this article)
I've had similar thoughts in the past with blogs. Make more controversial opinion pieces require readers to indicate their concern and feedback, and then address inline. This way, I can understand the percentage of readers that bounce after reading the headline or don't engage too deep.
I have in the back of my mind to do the same. I think there's a ton of potential there, because you can pack a lot of nuance into an experience where only the nuance the reader actually cares about is surfaced. Additionally, doing the research to support objections both enhances your own understanding of the situation and shows the reader that this is an avenue you've considered.
There's one UX wrinkle I haven't sorted out yet, which is that I would ideally like to let readers propose new branches to support rebuttals/perspectives I didn't consider in the initial draft. Probably the cleanest way (particularly in my case, because the source is open) is to request PRs on the Ink script with new branches. But non-technical readers are unlikely to be comfortable working with PRs, even in a language as approachable as Ink.
Well, and a second, which is that in my ideal UX for something like this, I'd like support for explorable models (like in Jupyter). You could probably merge Ink and Jupyter because Ink's Javascript integration is open (I added support for "choices" that behaved as hyperlinks in my portfolio site linked above).
To that end, these days I'm exploring hacking the Godot editor into a browser of "model-driven documents", but life is busy so progress is slow.
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.
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...
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.
Another great tool for interactive fiction is the Inform7 language[0]. It's very close to natural language, there are many good examples[1] online and I found the documentation[2] easy to read.
Personally if I would want to write something I'd probably just write it in C++. But a friend of mine who's an English teacher had to create an interactive story with Inform7 during his education. I was really impressed how simple it seemed for someone with no programming experience.
Although the core library is not updated anymore, I find TADS 3 to be the superior language for offline interactive fiction. It's the most technical language by far, but that's why it's also the most feature rich (and for someone with a programming background, probably also the most intuitive). I'm still regularly amazed at what's baked into the standard library, that would be an absolute pain, or even outright impossible to do with other authoring systems.
C++ would suck for that (and any other language) as Inform6 gives you an object table and a parser for free with lots of object types such as rooms, containers, verbs, cardinal directions... already defined in the standard English library.
And the Z machine games can be run everywhere.
Declaring some room with i6 it's literally four lines of code:
The object name and the internal one, the description upon entering it, a light attribute, and a semicolon.
I recently wrote a text-based adventure game in C, which I then ported to Z80 assembly language. My goal was to write a simple game that could run on a CP/M system.
Using C wasn't too painful, but I agree that using something else would have been more straightforward. I've ended up in a situation where the user can type "USE TORCH", but really they want to type "LIGHT TORCH". So I added that as a synonym, but once you do that in a few different places you end up accidentally supporting commands such as:
LIGHT THE BOOK
READ THE TORCH
They work, but they're utterly bogus from a logical point of view.
That said I'm pleased I managed to get it working at all, and my next step will be writing a third version using an infocom compiler & interpreter.
Object -> "flashlight"
with name 'flashlight' 'torch',
description "It's a battery-powered flashlight, of the sort that switches on and off.",
after [;
SwitchOn: give self light;
SwitchOff: give self ~light;
],
has switchable ~on ~light;
I absolutely agree that the Inform languages are great for creating interactive fiction, hence why I originally linked it.
But I have created text based adventures (usually with some RPG-style combat) in C++ a few times for fun and it can be done in a fairly clean and simple way.
As far as I'm aware, the only modern compiler that supports Z-machine output is Inform 6. Maybe Inform 7 does as well, but that segment of the IF community has basically moved on to the Glulx virtual machine, which Andrew Plotkin created as a 32-bit spiritual successor to the Z-machine.
If you're using Godot, there's Ink integration, but if you want VN- or character interaction-focused features you can also consider Dialogic[1] if you want a tool with a UI integrated into the Godot Editor.
Ink in particular (as opposed to, say, Inform7) is strong here because it already supports Unity integration. Heaven's Vault was developed with Ink, and that's a 3D adventure game that happens to have its story branches managed by Ink but the user experience is far from typical IF fare.
But you can even make commercial parser games. Anchorhead and Hadean Lands are two relatively recent examples.
Commercial parser? Hadean Lands and Anchorhead (the commercial edition) are just gblorb/glulx, a rehash of the Z-Machine with 32 bit capabilities.
Said this, I'd like people knew Inform6 more, among IBG.pdf (Inform's Beginner Guide) and DM4.pdf (Inform6's manual).
The language is dumb easy. It's object oriented (almost literally, you declare in-game objects as... objects with properties), and the games can be run on legacy machines fastly, such as Amiga/Atari/68k Macs.
Also, I forgot: There's Puny Inform, a reduced subset from Inform6 with few changes here and there in order to create games targetting the 3th version of the Z-machine. Thus, the games will run anywhere, even on the C64, Spectrum, MSX, BBC, Linux, OSX, Windows... everywhere.
Inform 7 progress has been "slowed" the last few years because a lot of work has been put into refactoring it to be more re-useful. Possibly not to the exact same extent as Ink has been to embedding in C#/Unity, though something resembling that has been part of the motivation.
The refactoring isn't necessarily making it "simpler" (especially compared to something like Puny Inform or even the people that have resurrected ZIL for the challenge of writing games with it), as it is defining a higher level object (world) model than just raw VM characteristics like Inform 6 or otherwise writing directly for a Z-Machine. But if it does reduce the coupling between stages of Inform 7 compilation it does offer some interesting tools for world building that Ink or Inform 6 can't quite offer.
This is a skill that should be very valuable to pretty much any product design team, even outside games. Tech products are mostly UI, and UI is mostly interactive text. For some reason UI/UX design teams tend to be run by people who think visually or technically, with writing as an afterthought. I think the very specific skills required to write good IF would improve almost any UI, and there’s probably more money in that career than in a career writing IF.
There are a couple of publishers looking for writers (if you don't want to self-publish). The biggest general publisher I'm aware of is Choice of Games. [0] Unfortunately, they have the least interesting (to a programmer) scripting language. There are also many publishers of romance IF.
You're severely underestimating the complexity of choice-based games. Ink, for example, is Turing-complete (it features variables, looping and branching. (As is your description of "fancy CYOA books," for that matter--take the PDF as the rule system and the "little notebook" as the tape.)
I recently wrote an Ink-based game that, among other things, allows you to swap out one of the main characters based on an early choice, necessitating swapping out names, pronouns, behavior and dialogue throughout. You could manage this as a PDF, but you're looking at an exponential explosion in length. Much easier to handle it with variables, subroutines and text substitution.
"Interface" is exactly the right word. You're never going to capture the feel of a parser-based game with a choice-based engine because the input is so limited. But don't mistake the limitations of the UI for the potential complexity of the underlying game.
That said, if you remember games like The Secret of Monkey Island, they attempted to capture the feel of a traditional text adventure, but they swapped out the parser for a visual interface with a limited vocabulary. I've seen at least one attempt to do something similar with Twine (a traditionally choice-based engine).
Some of the qualities of parser-based IF that make it most distinct from choice-based IF are also the most controversial ones: "freedom to explore and discover" can also be rephrased as "requirement to repeatedly play guess-the-verb". More accessible parser-based IF tends to provide affordances that make it feel closer to choice-based. A really well done, detailed, thoughtful parser-based IF can have a wonderful fluency and immediacy that choice-based IF has trouble replicating, but well done, detailed, thoughtful choice-based IF can provide a degree of narrative focus and clarity that would feel weird and railroad-y with a parser.
Not so much since mid-90's. That happened with GAC/PAWS/DAAD games for the ZX Spectrum, yes, but since Inform (specially inform6) targetting the ZMachine with the English library for i6 it made dumb easy to generate basic actions and synonyms to avoid that from the roots.
No thank you. Their interface is nearly garbage when it comes to smooth writing and even worse, that they obligate users to create an account only through the options of their Google account or their Facebook account is simply unforgivable. It's bad enough that Ink itself almost certainly scans all compositions by users for data mining purposes, but to have to then also know that the whole process needs to be done through logins via these two giant personal information parasites is a whole second level of shitting on customers.
Where does it say anything about creating an account via Google or FB? Or creating an account at all? (Except for on itch.io, which is a suggestion for hosting rather than Ink itself, and also doesn't seem to require Google or FB).
I was obliged to open an Ink account for some text compositions a few weeks ago, and yes, the only way by which I was able to do so was through a Facebook or Google login. There was no other option.
I want to show this to a friend and I think an example would help give them an idea of what's possible.
Edit: Someone wrote a "portfolio" for their personal website which is pretty cool https://news.ycombinator.com/item?id=26765367
If anyone has any narrative examples that would be ideal.