Twine Troubles


Photo by Daniel Schwen

The interactive fiction platform Twine has been around for many years, but recently it’s been at the centre of the DIY game creating movement. Rise of the Videogame Zinesters heralds it as an accessible development tool for those without programming experience. New voices are joining the game-making world, and the variety of Twine games is truly remarkable: personal games, satirical games, Kafkaesque games, sexual games, and many more.

Inspired by the creativity of this new wave of game makers, I decided to work on a small Twine game as a side project. I read a few tutorials, downloaded the application, and began assembling a story. Unfortunately, I started encountering minor hindrances much sooner than expected. I was digging through forums and documentation to implement functionality that I thought would be trivial. Disheartened, I frequently had to resort to kludgy workarounds.

Here are my four biggest frustrations with Twine:

No Nested Logic

Twine has built-in syntax for linking passages, displaying text conditionally and getting/setting variables. However, the syntax does not allow any of these to be nested. You can’t display a variable inside a link or a conditional statement. You also can’t embed any html inside a link, which makes image links difficult.

// Can’t print a variable in a link
[[Hello there <<print $name>>|Say Hello]]

// Can’t conditionally print a variable
<<if $name eq "Bob">>Is <<print $husband>> feeling better?<<endif>>

// Can’t embed an image in a link
[[<html><img src=”foo.jpg” /></html>|Link]]

The workaround is to write your own html in these cases, instead of using the built-in Twine syntax. You can access the Twine variables and link to passages using JavaScript, though that has its own headaches (explained in detail below.)

Verbose Macros

Twine allows you to write custom JavaScript macros, which is great! The process for doing so, however, is a tad obfuscated and verbose. To make a macro: create a new passage, add the tag “script”, then write your logic in a function with the following template:

macros['randomnumber'] = {
    handler: function(place, macroName, params, parser) {
	insertText(place, Math.random());

That’s the bare minimum script for inserting a random number. Here’s a fancy version with all the bells and whistles:

try {
  version.extensions['randomnumber'] = { major:1, minor:0, revision:0 };
  macros['randomnumber'] = {
    handler: function(place, macroName, params, parser) {
	if (params[0] === undefined) params[0] = 0;
	if (params[1] === undefined) params[1] = 1;
	var n = Math.round(Math.random()*params[1] + params[0]);
	insertText(place, n);
} catch(e) {
  throwError(place,"randomnumber error: "+e.message); 

None of it is egregiously verbose, but boilerplate phrases like “handler function place macroName params parser” are daunting. Twine is a great tool for first-time game makers, it would be nice if writing macros was equally approachable.

I also wish it were possible to import script functions from external files. That would allow authors to share and reuse modular components. A library of common functions would be a boon to those without the technical knowledge to write their own JavaScript. Dan Cox has a clever macro for loading external JavaScript libraries, which I’d love to see integrated natively.

File Format

Twine is a graphical interface wrapper for a simple plaintext format (called twee). However, the application saves stories in a .tws file, which is just a Python pickle serialization. Since this format is not human readable, it discourages the use of source control. Why bother tracking your changes when you can’t understand the incremental differences?

Thankfully, there’s an easy built-in way to get around this. In the Twine menu, call File > Export Source Code to export your story to a plaintext twee file. You can even modify that file in a text editor and reimport it back into Twine (though you’ll lose some of your previous passage arrangement).

Weak Documentation

There is some documentation for both Twine and twee. The former covers the basics and the latter alphabetically lists available functions (assuming robust JavaScript knowledge); neither is terribly useful for learning to write macros. I found the answers to my questions scattered across the TweeCode google group, Porpentine’s resource compilation and Dan Cox’s macro tutorials. Here are a few useful tricks I had to figure out the hard way:

Firstly, if you want to link to a passage (named “foo”) from embedded html (e.g. for an image map) use <html><a href="#" onclick="javascript:state.display('foo', this); return false;"> foo </a></html>. (If you neglect to return false, it’ll work on Chrome but not Firefox.)

Secondly, if you set a variable in Twine syntax using <<set $foo = true>>, you can access it from within JavaScript macros with state.history[0].variables["foo"]. You can use this to get around some of the nested logic issues I mentioned earlier.

Finally, a minor idiosyncrasy: Twine does not allow links back to the “Start” passage. Many authors get around this limitation by making a new first passage and displaying it in “Start” with <<display ActualStart>>.

Despite my criticisms, I still think Twine is a valuable and important platform. Fixing certain small issues would simply improve what the tool already does well: provide a accessible way for everyone to make personally meaningful games. Twine is free and open source with a passionate community, so I’m certain it’ll continue to improve and grow.

→ 5 CommentsTags:  ·  · 

Mark of the Dishonored

Video Games

Mark of the Ninja + Dishonored

I’ve been feeling rather stealthy lately, playing through Dishonored and Mark of the Ninja over the last few weeks. Playing them back-to-back has contrasted them rather sharply in my mind, though neither title suffers for the comparison. Rather, I’d like to highlight how certain elements of Mark of the Ninja’s design align perfectly with how I like to play stealth games.

Since most stealth games allow for a great deal of player agency, there are many perfectly valid ways of playing them. Some move through the levels like a ghost, others prefer to murder everyone from the shadows. Some are willing to go loud if their stealth is broken, others hide and try again. My preferred approach is to play each scenario as flawlessly as I can. I like to ascertain a situation, determine a strategy, execute it, then figure out how I could have done better. Can I avoid alerting the guards? Use fewer resources? Turn the environment to my advantage? I treat it like a puzzle, playing it over and over to find the optimal path.

In theory, there are “try again” mechanics built into the stealth genre. Your character is weak, so the guards can kill you quickly. Alternately, you escape and wait for the alert to die down. Either way you get a chance to reevaluate your strategy. However, both of those options are time-consuming, and the delay makes it difficult to iterate on a plan. Once you sit through a death animation and loading screen you’ve already forgotten the specifics of your recent failure. I made a point to pick up Dishonored on PC, allowing me to use quicksave and quickload to narrow down my perfect approach.

I didn’t have to micromanage my saves in Mark of the Ninja. The checkpoints are generous and there’s no score penalty for death. When my plan went badly awry, the window for recovery was small; I either died or escaped within a few seconds. There’s no minute-long ambiguous alert state, just clear immediate success/fail feedback. You could say Mark of the Ninja is the Super Meat Boy of stealth games: you die a lot, but you’re already back in game before that has a chance be bothersome. Iterating on a plan isn’t a tedious process when you can immediately begin executing your next idea.

Mark of the Ninja

Another element that supports the “puzzle” approach to stealth is predictability. As Anthony pointed out, Mark of the Ninja’s clean 2D presentation and excellent UI make it an exceptionally deterministic game. You have the unlimited ability to freeze time and line up exactly where your ninja distractions are going to land. Vision cones and noise radii sharply visualize the limits of a guard’s awareness. Everything is a known quantity, making failure a fault of planning rather than execution. The ability to know the outcome of individual actions with certainty gives players the confidence to create complex plans.

When I feel comfortable with a stealth game’s mechanics, I often like to invent impromptu challenges for myself. Can I fit all the knocked-out guards into one closet? Can I reach that far ledge with a pile of physics objects? I’m always impressed when the game recognizes and encourages these actions. For instance, I grinned when Dishonored popped up an achievement for reaching the top of Kaldwin’s Bridge.

Mark of the Ninja takes this idea one step further by taunting you with challenges. A prompt appears when you enter a new area, with instructions like: “kill 3 gasmask guards while they are walking in poison gas”. It’s entirely optional and rather difficult to pull off, but who can resist the temptation to try! The fact that this challenge exists is also a hint to new players: here’s something fun you didn’t know you could do. Completing challenges helps reinforce the player’s knowledge of how certain game mechanics interact. Reifying the made-up challenges that experienced stealth gamers give themselves helps encourage an improvisational mindset in every player.

Mark of the Ninja is a spectacular game, one that makes stealth mechanics accessible and readable without reducing their complexity. Furthermore, it support the puzzle-like stealth experience that I love: figuring out a plan then executing it flawlessly. I can’t wait to see what Nels and the team at Klei come up with next.

Oh, and I completely agree with RPS: the ninja protagonist should be named Mark.

→ 1 CommentTags:  ·  · 

The Perpetual Testing Initiative

Video Games

Portal 2 Level Editor

This week saw the release of Valve’s new beginner-friendly level editor for Portal 2, dubbed the “Perpetual Testing Initiative”. Many have praised this new software for its accessibility, and have advocated it as an entry-point for first-time level designers. I had a chance to experiment with it a little myself, and I’d like to explore some of the specific principles Valve employed to create this remarkably approachable editor.

Booting up the editor for the first time gives you a simple rectangular testing chamber. The walls and floors can be dragged in any direction to expand the space or create connected chambers and corridors. Puzzle devices are dragged and dropped into the world from a tidy panel on the left side of the screen (very much like The Incredible Machine.) Right clicking these elements in the world exposes a small selection of options, and allows you to connect them to other devices. Simply moving the camera around the 3D space will likely be the most challenging interaction for a fledgling designer.

The editor is stylized like a blueprint: elements appear simpler than they do in-game, some devices (like the Aerial Faith Plate) project dashed path lines, and ceilings / backward-facing walls are automatically hidden from view. A working knowledge of Portal mechanics is assumed, as there are curiously no tool-tips to explain how the various devices function. Even I had to use trial-and-error to figure out how the Track Platform works, as the official Valve wiki is unfortunately sparse at the time of writing.

A great deal of editor’s simplicity derives from the fact that it’s not a generic tool designed to make levels, but rather a very specific tool to make test chambers. Test chambers in the Portal universe have a well-defined format. They are white, sterile, closed and grid-aligned rooms. They contain some permutation of the 32 devices. They necessarily have exactly one entrance, one exit and one observation room (which functions as the level’s main light source.) These fiction-appropriate constraints keep the editor simple by limiting the number of possible ingredients.

The devices themselves demonstrate a similar simplicity; both input devices (buttons, laser catchers) and output devices (laser emitters, piston platforms, etc.) maintain only binary states. Attaching several inputs to the same device will require them all to be active (logical AND), but there is no sanctioned way to achieve OR, NAND or XOR. Connections between devices are always visible to the player, as the editor automatically generates an in-game dotted line between them. Keeping the interaction between devices simple allows the editor to abstract away from any sort of complex scripting logic.

Fundamentally, the Portal 2 editor works so well because of the judicious use of physical constraints. In The Design of Everyday Things, Donald Norman describes how these types of limitations “constrain possible operations” such that “desired actions can be made obvious.” Since it’s almost impossible to do the wrong thing in this editor, the only possible actions are correct ones. Designers are thus free to experiment without fear of breaking the level in an esoteric way. The only clearly incorrect operation I’ve found is placing two devices in the same spot; the feedback for this error is clear and immediate.

In my few hours of experimentation I made a simple test chamber called “Ducks & Drakes”, which you can download and play by hitting subscribe in the Steam Workshop. You should also check out the Perpetual Testing Challenge over at the MapCore Forums.

Tags:  · 

Moving Pixels Podcast

Video Games

League of Legends - Sona & Jax

A few weeks ago, the gents from the Moving Pixels podcast invited me to join them in conversation about League of Legends. League is an extremely popular free-to-play game in the style of Defense of the Ancients, and I’ve been rather hooked on it for the last few months. Jorge Albor, G. Christopher Williams and I discuss what we love (and hate) about the game, Riot’s clever business model, and the type of community that competitive games attract. You can download the podcast or subscribe on iTunes at the link below:

Moving Pixels – League of Legends

Since it’s been seven months since my last post, here’s a quick list of what I’ve been up to lately: I gave a talk at Juegos Rancheros (Austin’s indie game collective) back in November. Pax Britannica was ported to Montreal’s Arcade Royale and demoed at the Prince of Arcade showcase. Mostly, though, I’ve just been working hard on Starhawk (look for it on shelves May 8th!) However, all this does not excuse my writing hiatus; I’ll endeavour to resume regular blog cromulence over the next few months.

[Sona & Jax Lunar Revel fan artwork by RUshN]

Tags:  · 

Mechanical Drama in Jamestown

Video Games

Jamestown Screenshot

While I’m not typically a shmup player, lately I’ve been enjoying a great indie shooter called Jamestown. It piqued my interest with its colonial Martian setting and beautiful pixel art. However, the game’s lasting appeal rests in the strength of its peculiar Vaunt mechanic.

When activated, Vaunt grants the player a seemingly arbitrary list of benefits: a brief bullet shield, followed by increased damage and a score multiplier for as long as the energy meter is kept filled. In practice, this mechanic gives Jamestown its own particular systematic rhythm of tension and respite. I’d like to use Vaunt to explore the idea that a game mechanic can have an inherent dramatic arc similar to those created by traditionally authored stories.

When I speak of a dramatic arc, I mean something along the lines of the three-act structure commonly used in storytelling. Strongly authored media (films, books, plays, etc.) map very nicely to this kind of structure, as does the authored content in video games. For instance, a level in Jamestown is composed of a series of increasingly intense enemy waves followed by a climactic boss fight. The pacing and intensity of this level design is determined entirely by the game’s creators.

Three Act Structure

When examining a game’s effective dramatic arc, we must of also take into account the player’s agency. The abilities that the player has control over can increase or decrease dramatic tension. For instance, a bomb move that kills all the enemies on screen gives the player a breather, thus creating a moment of dramatic respite. A slow powerful attack creates high tension (as the move charges) followed by low tension (as the hit connects.) These types of mechanics create a parallel dramatic arc authored by the player. The two arcs superimpose each other, interacting in a sort of wave interference that heightens some moments and dampens others.

What would the dramatic arc for the Vaunt mechanic look like? It begins with normal moment-to-moment gameplay, with its mild variations in intensity. Some high-tension impetus for activating Vaunt would then occur: a mid-wave difficulty spike or simply the filling of the energy meter. In response to this event, the player hits the ‘B’ button to activate the bullet shield and begin Vaunt mode. The momentary safety of this shield creates a brief nadir in dramatic tension.

Jamestown - Begin Vaunt Mode

After the shield has expired, Vaunt mode remains active as long as the player continues to replenish the energy meter by killing enemies. As I mentioned previously, remaining in this mode grants a score and damage multiplier. These multipliers increase the benefit of skilful play, which in turn increases the innate tension of moment-to-moment gameplay. Furthermore, surviving the duration of Vaunt mode grants an additional score bonus. The dramatic tension increases parabolically as the potential benefit of the survival bonus accumulates over time.

Vaunt mode can terminate in three different ways. The most desirable outcome, illustrated in the graph below, is when the player runs out of enemies to kill and the energy meter expires gracefully, granting the full survival bonus. In terms of dramatic tension, this would be a plateau followed by a resumption of normal gameplay. If the player instead becomes overwhelmed during Vaunt mode, she has the option to press ‘B’ again to activate a second bullet shield. This choice ends the mode prematurely, only granting half the survival bonus. This outcome would be represented graphically by a second brief peak in tension. Finally, the player could die during Vaunt mode and lose out on their survival bonus entirely.

Jamestown - End Vaunt Mode

These graphs reveal some general ways that a game mechanic can increase or decrease dramatic tension. When they provide momentary safety, increase performance pressure or ransom potential reward, they have a strong dramatic effect over time. We can also see how the mechanical tension interacts with the authored dramatic arc. The encounter design provides the high-tension impetus for activating Vaunt, and the level’s difficulty strongly influences which way the mode will end. The nature of Jamestown’s Vaunt mechanic works in concert with its strong level design to create an exciting gameplay experience.

The MDA framework asserts that game mechanics create an aesthetic response in the player. When we observe this response over time, we see patterns of dramatic tension and reprieve that match those found in storytelling. We often praise the narrative power of heavily-authored games, but the best video game tales often emerge from system-centric games like Dwarf Fortress, Civilization and EVE Online. If we acknowledge that game mechanics have inherent dramatic arcs that superimpose the authored content, then we can begin to analyze mechanics in terms of their storytelling potential.

→ 2 CommentsTags:  · 

© 2007-2014 Matthew Gallant, hosted by A Small Orange, powered by Wordpress.