For people who prefer the ol' text-editor-and-compiler workflow to a pretty web-based tool, there's a command-line compiler for Twine stories called Tweego[1]. It can compile a source file in the Twee v3 format[2] to a single HTML file that includes the plain-text markup and the JS "story format" engine that parses the markup, renders it to HTML, maintains state, etc.
Tweego comes with the same three default story formats that Twine comes with: Harlowe[3], the basic default; Sugarcube[4], designed to provide a smooth upgrade from Twine v1; and Snowman[5], designed to be extended with JavaScript and CSS. I've dabbled a bit with Harlowe, and while it's flexible and powerful, I found it a bit underwhelming as an actual markup language, especially after growing used to Markdown.
If I ever write another Twine story, I'm going to try Chapbook[5], which is actually based on Markdown, or maybe event try writing my own engine.
Chapbook looks nice, but even after first glance I see a lot of things potentially missing, such as possibility to redirect to "death passage" from each passage if health drops below zero. Maybe it will be developed in that direction, but for now I feel Snowman should be a default choice for any developer trying out Twine, because you basically code everything in JS.
There's some argument that the limitations of this format (compared to open-ended parser games, or the very open-ended AI Dungeon posted here last week) are a benefit. Ian Bogost's piece in the Atlantic a couple of years ago, "Video Games are Better Without Stories" [1] argued that narrative in games can't deliver on its promise--you can't craft a story while also letting the player explore. To my taste, games like Inkle's 80 Days and Heaven's Vault, and Nicky Case's games like the Coming Out Simulator [2], make effective use of the constraints of the medium. They do feel more like literature than games, which might feel overly conservative to folks primarily interested in the phenomenological possibilities of games.
My project, Unfold Studio [3], makes use of the affordances of Inkle's Ink language for teaching CS in the context of students' existing identities and concerns. Here, the limitations of the format are again useful. Students can create small playable worlds in a way that's still manageable and which makes CS concepts rhetorically powerful--they are immediately useful for creating particular experiences for the user. Here's an accessible piece [4] on how this approach could support marginalized youth in developing criticality: understanding and challenging unfair techno-social conditions.
> narrative in games can't deliver on its promise--you can't craft a story while also letting the player explore.
Roger Ebert made a similar argument[1] a while back.
While I agree that interactivity and narrative are in tension, I don't agree that they are incompatible. There was plenty of exploration in Planetfall, but also a very emotional scene. While many have argued that that scene should be discounted because it's in a non-interactive portion of the game (e.g. [2]), the impact of the scene exists because of the relationship that was built-up with Floyd mostly through interactive moments and exploration.
In the realm of non-computer games, there are all sorts of highly interactive story-telling games and RPGs, and while I think Ebert would claim that those don't count because the narrative is accidental rather than intentional, I find that to be a somewhat arbitrary distinction.
My friend and I used the Twine and then Inkle formats for our interactive fiction game. But these formats produce unreadable JSONs and require custom editors to edit them. Also, their libs for Java/Objective-C had a lot of bugs :( And learning a new DSL to write a book takes too much time...
As a result we created a new interactive fiction format:
I kind of wish we had a format that was more readable than JSON, with whitespace instead of brackets, but then I start wishing for references and things like that, and realize I've arrived at YAML, which is nobody's notion of a good idea.
My wife has played some of those! She's a huge fan of the point and click adventures, I should see if her Steam library is sharing. Thank you for the reminder :)
this looks really interesting as a format; I agree that Twine is hard to engage with, the editor code is a mess and the generated format isn't clean. But it is quite fun and quick to use as a visual story "map" editor.
For your file format, I can't see the runtime inside the github repos, is that also available?
Haha! We did the same with our interactive-fiction game. At first we started with Twine but quickly switched to Inky format. But their libs for Java/Objective-C are not very good so I had to create my own ports to it. In the end we ended up with creating are own interactive fiction JSON format. All editors can do JSON, you do not require a special software to do it (ASAIR Inky required .NET SDK to be installed...)
If you're interested in writing stories in a language like this, I've been working on a project called Yarn Spinner (https://github.com/YarnSpinnerTool/YarnSpinner) that basically implements a Twine-like system for dialogue in Unity. A few indie games are using it - most notably, Night in the Woods (https://nightinthewoods.com). We're pretty pleased with the results that people are getting from it.
Heh, I looked this up back in the day and thought how confusing it was that it had the same name as the yarn package manager since I was using it in my build process.
Does it have a way to export to JSON or another structured format? My game's built by building a website from Twine exported to JSON with Twison and it's not ideal.
We can’t do that yet but we’d be interested in knowing what kind of structured format you need? E.g., do you need the nodes? the lines? The structure of the interconnecting nodes? something exotic like the parse tree? Let us know! We'd love to help out.
Yarn Spinner predates the Yarn package manager by about 1 year!
My game is basically an interactive story told in chat format, so what I use with Twison is a list of nodes and I use the node text content, the nodes it points to, and a set of tags to organize which node correspond to which conversation. I'm currently working on a way to set variables when entering a node but that's all done 'client side'.
I want to like Twine games and stories, I really do.
I always find them underwhelming, though.
I can see how these might be of interest to a very young audience, in analogy to the CYOA books of yore. But the appeal to a more mature audience, like the appeal of parser games or really video games generally, escapes me. It's always struck me as odd that these games are compared with traditional IF parser games, because parser games (which have their own problems) seem to me to be in another galaxy in terms of gameplay, scope, and complexity.
This is an example of how it's hard for me to even see the potential of the platform. Does this ever get beyond clicking on words, with branching storylines? Are there any examples of Twine games that get beyond simple hypertext storytelling?
Twine's creator, Chris Klimas, acknowledged one of its key limitations in a blog post several years ago [1]:
> I also think that if you stick with Twine long enough, you’ll eventually bump up against its limitations. Maybe someday, you’ll want to have the player put an apple inside a knapsack and then place that in a refrigerator the player can push around. Games have been created from stranger mechanics.
> Twine doesn’t have a world model. It has variables and flags, but those are tough tools to work with if you are trying to build a simulated world that can be toyed with in any real way.
> So eventually, after futzing helplessly around with $appleInKnapsack, $knapsackInFridge and not $knapsackOnTopOfFridge, and $fridgeDoorClosed, you might think to look for something better to realize your dream of objects containing objects containing objects. You might try Inform or TADS (or maybe even ADRIFT or Hugo, if you are well-read). You hopefully have heard of them in your short interactive fiction career. Ideally, you regard them as neighbors three doors down; you haven’t had a chance, or a really a reason to visit, but you wave to each other on the way to work. They’ve always seemed like friendly, good-natured people. Talking with them is a natural next step.
I have seen a lot of Twine games, from the simple to the complex, and I have found that for every single one of them there is a point where I stop really reading the pages and just kind of start quickly skimming the pages and clicking whatever I think is most likely to get me through the story the fastest.
Soon after, I usually come to the point where I close the tab and never come back. For all but the shortest Twines, this is well before I've come to an ending.
I want to like them too. But they just resist me getting into them. I've pretty much given up.
Open Sourcery is a very good Twine game with significant player agency.
> BEL/S is an Elemental Firewall: a fire elemental bound with C++ code to protect a network of people and places. She can learn things, develop relationships, and even gain sapience. Or she can burn everything with fire. It's up to you.
The essential gameplay centers around a loop where you choose places to scan. You have a variety of choices to make for each threat, from annihilating them to passing off the issue to your creators to making friends with the viruses that attack the systems you were tasked with defending. (You do make choices by clicking)
The choices you make affect your options in the final fight, which even triggers actions based on a real-time countdown clock and not just clicks (by default, you can toggle in settings).
It gave me a hilarious and enjoyable few hours of gameplay. You can play the initial bit online, and the preview is representative of the whole game's appeal.
Agreed that these aren't as good as something like Blue Lacuna, but the intended audience is probably different.
Kids like simple CYOA type books and are a natural fit, where games like Blue Lacuna are a bit much. Likewise, some adults just want a simple a fun game with no backtracking and complex puzzles. I played one of these for a few hours on my phone once and it was indeed entertaining.
I agree that these are pretty limited. I taught a class on interactive narrative last year and I really wanted to have my students make something like Zork but there just isn't anything user friendly enough (The class had no per-requisites so I didn't want to assume the students had any technical knowledge and many didn't) so I chose twine.
I was pretty happy with what they did because there was a really wide range of topics that aren't usually seen in gaming (one was making dinner, another was going to the mall, another was a text based football game. There were a number of games about more-traditional topics too).
Inform7 with the natural language rules is pretty user friendly, but it's not web based and requires some technical background. But with a tutorial it students can get a long way, it also has publish to html built-in http://inform7.com/
I'm driving a story through a faux SMS interface using a Twine like engine (Ink). Many games that are very rich use Ink/Twine/etc to drive dialog or narrative elements.
I've been wondering why we don't apply modern NLP techniques to the traditional parser-based interactive fiction format. In particular, part-of-speech tagging ought to be very robust by now, so we should be able to handle sentences with complex relative clauses and homonyms pretty well now, making the whole experience less frustrating.
Various levels of NLP do get applied in IF, but it doesn't necessarily help much. Being able to parse input is an important step, but the game/story needs to be able to do something with those verbs and nouns. For a good player experience the author needs to communicate clearly what range of input will be acceptable, making sure all nouns mentioned in text can be interacted, any actions implied in the text or by the nouns themselves are recognised, etc. If you do that well then you can have a good player experience with a purely handcoded parser.
You either hand some of this over to a ML model to handle, and lose some control / deterministic-ness, or you write a ton of code to handle the combinatorial explosion of potential parses of the sentence.
I guess AI Dungeon 2 sort of does this, though it's more like an advanced chatbot in the guise of a text-based adventure game, rather than an actual text-based adventure game.
usually a good-sounding idea like this, if it hasn't been tried, must have some hidden pitfalls. but the number of people writing parser-based interactive fiction is ludicrously small, so probably just nobody thought to do it.
Interactive Fiction isn't a genre I'm well versed in, but Seedship by John Ayliff stood out to me as particularly effective, and I know that was made with Twine.
I created a related set of tooling called Ficdown (ficdown.com) that lets you write simple choice-based interactive stories using Markdown syntax (headings to represent scenes, anchors to represent choices and variables, and so on). My focus was on supporting the creation of stories that could be compiled into static ebooks to be read on e-readers that wouldn't support systems requiring a custom engine to run.
The maintainer has a patreon that I support. https://www.patreon.com/klembot I'm impressed by how diligent he is with sending updates out to backers. He's currently updating twine and I'm sure he would like some support.
To the best of my knowledge, Twine the game system predates Twine the Python package publisher by several years. (The first release of the game system was 2009; the first release of the packager appears to have been 2013.)
Looks cool reminds me of that tool might have been called bigboard or something. Had a yellow logo got bout by a company starts with an 'm'. Anyone recall? Just a giant whiteboard to pin things, create mind maps etc
I wrote my thesis on something similar [1, 2]. My thesis asked all kinds of questions [4].
It was about XIMPEL which had a lot in common with SMIL (a former W3C standard), mostly because they were developed by people who were a bit rivals of each other. Here is a showcase of XIMPEL [3].
What happens when you introduce applications in non-linear storytelling? Answer: you can recreate CodeCademy.com.
What happens when you allow for media to be played in parallel: you're opening a can of worms that has a lot of implications on user experience and architecture of non-linear stories. You'll see some of the implications later on.
Is ReactJS suitable as a framework for non-linear storytelling compared to vanillaJS? Answer: yes, because ReactJS is component-based, so the components will be based on media items for which you can tell a story. I also think it's possible to make story/content components.
How do you measure frustration in a non-linear story framework? Answer: you could do it via the webcam if the user consents. Since mouse clicks and watch time is not enough. Non-linear stories are not applications, but they can be (in XIMPEL at least), when media is passively consumed, you need facial expressions (and user consent).
Now that we have parallel media playing how to do time scrubbing? Answer: in my thesis I outlined multiple options. The biggest question is: do you want to have a time line or a time graph?
Now that we have parallel media playing does that mean that a subject point in the story should be able to survive subject point in the story that comes after it? If it makes sense, content-wise, then yes. If you wouldn't have parallel media playback, this would not make sense. (ok, I'm butchering this answer, can't summarize it well, you can always read my thesis ;-) [1])
Is XIMPEL Turing Complete? Answer: almost! If we allow for the user to disambiguate certain issues, then yes. What helps a lot with this is that XIMPEL allows the use of integer variables. And you can get very far with 2 integer variables, since you can represent 2 integer variables as 2 stacks, and 2 stacks makes a tape. Where it fails with XIMPEL though is knowing which story/subject point to jump to.
Twine is also a package publishing tool[1] in Python. With growing number of projects and tools it is inevitable that we are going to have more and more of these name clashes. I wonder if we can arrive at a naming system for projects to avoid such name clashes to improve the brand identity of these projects.
One could look to the rules around trademark. If two things share the same name, but not the same market, they both keep the name. Humans can be relied on to literally coordinate an offering using a mark and market.
Tweego comes with the same three default story formats that Twine comes with: Harlowe[3], the basic default; Sugarcube[4], designed to provide a smooth upgrade from Twine v1; and Snowman[5], designed to be extended with JavaScript and CSS. I've dabbled a bit with Harlowe, and while it's flexible and powerful, I found it a bit underwhelming as an actual markup language, especially after growing used to Markdown.
If I ever write another Twine story, I'm going to try Chapbook[5], which is actually based on Markdown, or maybe event try writing my own engine.
[1]: https://www.motoslave.net/tweego/
[2]: https://github.com/iftechfoundation/twine-specs/blob/master/...
[3]: https://twine2.neocities.org/
[4]: https://www.motoslave.net/sugarcube/2/docs/
[5]: https://klembot.github.io/chapbook/guide/