Making an immersive experience with Twine
Twine is a powerful tool for making or prototyping immersive playful experiences.
Digital history isn’t just about computational analysis or mapwork or computer vision or AI (though of course, it can encompass those things.) It can also create compelling stories and experiences. Sometimes, these can involve very complex websites with underlying js code and so on.
But sometimes, it can be achieved much more simply.
Before video games went all-in on powerful graphics, games (and playful engagements) could create deep simulations and immersive worlds simply through text. Ever get lost in a book? These were like that - but the book read you back, changing depending on what you did (or did not do). In recent years, there has been a renaissance in these kinds of experiences. For convenience, we call these ‘interactive fiction’ but they don’t need to have fantastical settings. One of the key tools in this renaissance has been the tool Twine by Chris Klimas. Meant for generating choose-your-own-adventure type stories, the tool is sufficiently subtle that quite complex experiences can be created. There is a lesson at the Programming Historian currently in development, by @gkirilloff that I am very excited to see come out, because I think scripting out, mocking up, and building compelling experiences around our scholarship is a necessary part of the digital historian’s toolkit.
In Kirilloff’s tutorial, they point to a few of the reasons why we might want to build these kinds of experiences - for one, it widens accessibility to our scholarship; for another, it allows us to deal with contingency and the idea that the past was not fore-ordained; and that the world is a complex system (goverened by non-linear interactions and feedback loops).
For this tutorial, I want you to play some twine-powered games, but CW: the first deals unflinchingly with a very realistic depiction of depression.
So, please play at least one of the following:
Now, following Kirilloff, for one of these experiences, can you identify:
- the game’s argument?
- the way the design of the experience contributes to that argument?
- who is the intended audience?
If you’ve played more conventional video games, have you ever seen these kinds of themes explored in a simulation or game environment? Probably not. So Twine gives us the possibility of exploring all sorts of experiences, to represent all sorts of people, in ways that can be designed to make an argument about the past: that what you are able to do in a game (its mechanics, or procedural rhetorics) are as important as the actual story your experience tells.
Twine can also be used to prototype the desired interaction or storytelling that would be delivered with far more complex technologies (if you’ve seen Bandersnatch on Netflix, that was designed with Twine). And of course, you’ve already encountered Twine in this course when I designed that interactive syllabus exploration for you.
Design your game
You’re going to use Twine to make a sketch of what a potential history game might look like. There are a variety of frameworks for analyzing games about history (eg this for instance) but not so many about writing historical games.
- Select your favourite academic paper you’ve written (or read).
- What is the argument? Condense it down so that you understand the argument’s ‘verbs’ or main actions
- how might you tell the story of that paper by focussing on things the player/reader can do that intersect with that argument/those verbs?
- what does that imply about your intended audience?
Start Sketching it out
- Aim for five to ten minutes worth of play
- I’m not going to reproduce here the ins-and-outs of the Twine interface, as there are many excellent tutorials in the world to show you that. You could go over to Krilloff’s work-in-progress at the Programming Historian; link to the lesson will be in the first comment at this thread. Alternatively, there’s this tutorial. And there’s this one, which has a lot of videos too.
When I work in Twine, I always use the online version; it saves your work automatically into your browser’s cache. If you clear the cache you lose your work. So as a habit, I export a version to html every time I’m done a session. You can always re-import the html if you need to. At the bottom left of the interfact is an ‘up’ arrow button; click on that and hit ‘publish to file’. This will let you save your work as .html.
You can put the html file (and any other supporting files you might create) into a github repo.
Going Further
See what you can cook up using this online collaborative storytelling game generator, Story Synth. This is a framework for building deckbuilder type games, drawing on prompts kept in a google spreadsheet, and meant to be played collaboratively online. Give it a whirl, share what you’ve built in our Discord space, let’s play!
Alternatively, if you’ve played 80 Days or Heaven’s Vault from Inkle Studios, you’ll have encountered their powerful story engine Ink; you can download it and give their tutorial a whirl. Robin Sloan (one of my favourite authors) talks about crafting with Ink
Finally, if you’re into Minecraft, I just saw a new article come out that details how to import a cultural heritage landscape into Minecraft to create simulations therein:
Edwards, B., et al. “The Bryn Celli Ddu Minecraft Experience: A Workflow and Problem-Solving Case Study in the Creation of an Archaeological Reconstruction in Minecraft for Cultural Heritage Education.” Journal on Computing and Cultural Heritage (JOCCH) 14.2 (2021): 1-16.
If you’re logged into Google, the Google Scholar Page for this article has a download link for the pdf.
It might be challenging, given the amount of time you have, but I’d be open to someone seeing if they can replicate Edwards et al.’s workflow. (Indeed, several iterations of Minecraft ago I used to teach a class on historical simulation where the major piece of work was to create a historical minecraft world. But the workflow then was much simpler, before microsoft got their hands on the game).