Skip to main content

Using Twine for Games Research (Part I)

Recently, someone sent a request over the DiGRA list for experiences and information related to academics learning to make games. I replied with a bit of handwavy proselytizing for Twine, copied (and slightly edited) below:
For a surprisingly diverse range of game design logics, Twine makes an excellent prototyping tool for research. Carolyn Vaneseltine writes about using Twine for prototyping here: 
I'd really like to see Twine in use especially for games *research*, for a few reasons:
  • Deployability. It's absolutely the "most time-effective path" from game idea to "an arbitrary person with the internet can play it."
  • Resilience to bitrot. As long as people care about creating backwards-compatible web standards and supporting JavaScript, Twine games will be playable. If we consider our research to be describing "permanent ideas," then people need to be able to play with those ideas decades later!
  • Most people find it quite easy to learn, and it supports quite a range of mechanics, as long as you can conceptualize them in some turn-based way. It's really one of the better settings for thinking about the *systems* in games first without having to muck about with event handling and graphics rendering.
  • Reusability/reproducibility. If the point is to communicate some system of mechanics, then I think Twine works pretty well because the source code is usually readable, easy for the author to release, and easy for outsiders to manipulate. 
Of course, I realize a lot of research goals in games involve aesthetic experiences that Twine won't help at all with creating. But I think it's overlooked as something that would often suffice for the "proof of concept" work we do in research, where instead people sink lots of time into clunky 3D simulations that distract more from the research than they contribute to it.
Afterwards, though, I began to question my own recommendation. I've tried using Twine for research-like ideas (see: numerous attempts at replicating the behavior of Prom Week as a text game) with very limited success, and certainly nothing leading to publication. Nonetheless, it has still been my favorite tool for dabbling in digital game design due to the lack of assumptions it imposes about what kind of game you are making, and I still feel in my soul that it should be possible to communicate this generality in a compelling way to the research community.

So, since the contributors to Twine recently released a new, web-based editor along with a tantalizing new macro and expression language, I decided to launch a period of focused study using Twine to implement some "classic" prototypes and document my roadblocks. I'll use my blog as a "lab notebook" for these experiments, which will incidentally also contain a review/critique of Twine 2.

Before I get into that, though, I want to be more explicit about what I mean by "games research." To be quite honest, the range of research activities discussed on the DiGRA list is quite mystifying to me, and I would love it if someone could write an overview of "things people at universities are doing that they call games research." I have a sense that there are at least the following categories:

  1. Humanities-based scholarship on the cultural context and contents of games, patterned off of "media studies." They ask questions such as how gender and race are represented in the assets and stories of games, as well as how game mechanics reflect cultural values.
  2. Human-Computer Interaction-based study of how humans play digital games, asking questions about what happens to them psychologically under different conditions and whether games can be designed to induce specific experiences (such as education).
  3. AI-based study of how games can simulate more realistic or engaging experiences. A lot of the questions seem to surround programming the behavior of non-player characters, including everything from pathfinding in geometric space to dialogue and storytelling.

My personal studies align most closely with the third category, although because my background is programming languages and not AI, I think of the interesting questions as less about characters and more about representation of game states and behaviors, i.e. "how do we model arbitrary fictional worlds that react to input?" and "how do we reason about the semantics of how these worlds evolve?"

Note that I would also count something like, say, an operating system as a "fictional world," but on the other hand, I'm not as interested in games where the primary and necessary challenges are things like "very quickly calculate the outcome of lots of geometric and physical constraints changing and render them at a certain frames-per-second requirement." So in that sense, what I'm calling "games research" is really a particular intersection of formal system modeling and games, and that's the focus of my current hypothesis under examination (that Twine is a useful tool for stating and answering questions about these systems.)

This post has already exploded in length, so I'm going to save the actual results of experiments so far for the next post. Meanwhile, I'll describe some examples I intend to describe as case studies:

  • Hack-and-slash: player character has a record of attributes like health and inventory and can strategically alternate rest, adventuring, and spending coins (won through adventuring) on more powerful adventuring tools.
  • Dining philosophers: classic problem in synchronizing concurrent systems made interactive by allowing a player to control (all, one, or several?) philosophers: they can pick up a fork on the table, set down a fork they are holding, or eat if they are holding two forks.
  • Social simulation a la Prom Week: multiple characters with sentiments toward one another that can change via player-selected pairwise interactions.
The central questions I'll be asking about these examples are (a) is it easy to encode in Twine, and if so, how is it done? and (b) what do we learn from the encoding? I'll try to pose some example-specific questions before diving into the implementation, as well.


  1. A fascinating blog post! I'm eager to see the case studies.

    I was a bit surprised to see your own work placed under the AI umbrella (although I certainly see how it could be applied as part of AI work). In terms of game design (I don't know about the labeling of research activities), I would rather have related it to "procedural content generation", from question of how to describe good narratives (also quest generations, etc.), to how to procedurally generate good environments for the players (maps in rogue-likes, etc.), until questions such as "how to generate trees that look good" that actually seem closer to "geometric and physical constraints" than "AI".


Post a Comment

Popular posts from this blog

Using Twine for Games Research (Part II)

This preliminary discussion introduced my thoughts on using Twine as a tool for creating prototypes for games research. I'll start with documenting my first case study: a hack-and-slash RPG-like setting where the player character has a record of attributes ("stats") that evolve through actions that turn certain resources (money, health, items) into others. I've selected this hack-and-slash example because it falls outside the canonical "branching story" domain thought to be Twine's primary use case, but it is not too much trickier to implement. It relies crucially on the management of state in ways that simple branching stories would not, but it does so in a fairly straightforward way.

If all goes well, this post may also serve as a tutorial on the "basics" of Twine (links + variables + expressions). In particular, I'll be using Twine 2/Harlowe, and I haven't seen many tutorials for this new version published yet.

To me, the main "…

Using Twine for Games Research (Part III)

Where we last left off, I described Twine's basic capabilities and illustrated how to use them in Twine 2 by way of a tiny hack-and-slash RPG mechanic. You can play the result, and you should also be able to download that HTML file and use Twine 2's "import file" mechanism to load the editable source code/passage layout.

Notice that, in terms of game design, it's not much more sophisticated than a slot machine: the only interesting decision we've incorporated is for the player to determine when to stop pushing her luck with repeated adventures and go home with the current spoils.

What makes this type of RPG strategy more interesting to me is the sorts of decisions that can have longer-term effects, the ones where you spend an accumulation of resources on one of several things that might have a substantial payoff down the road. In a more character-based setting, this could be something like increasing skill levels or adding personality traits.

Often, the game-…

Why I don't like the term "AI"

Content note: I replicate some ableist language in this post for the sake of calling it out as ableist.

In games research, some people take pains to distinguish artificial intelligence from computational intelligence (Wikipedia summary), with the primary issue being that AI cares more about replicating human behavior, while CI is "human-behavior-inspired" approaches to solving concrete problems. I don't strongly identify with one of these sub-areas more than the other; the extent to which I hold an opinion is mainly that I find the distinction a bit silly, given that the practical effects seem mainly to be that there are two conferences (CIG and AIIDE) that attract the same people, and a journal (TCIAIG - Transactions on Computational Intelligence and Artificial Intelligence in Games) that seems to resolve the problem by replacing instances of "AI" with "CI/AI."

I have a vague, un-citeable memory of hearing another argument from people who dislike the…