Cute boyf and anime babes naisu @emmett9001

it’s me

This post is about using Twine in the context of an Actionscript Flash game, since Nina and I did so successfully in our recent game Ladylike with Deckman Coss and Winnie Song. Twine is “an open-source tool for telling interactive, nonlinear stories”, so of course upon seeing the “open-source” aspect, I promptly decided to fork the core library (conveniently written in python) for use in our own game.

The problem we faced was this: our vision for Ladylike was a primarily dialogue-driven story that lets the player explore youth and the lack of agency sometimes experienced by tweens. We wanted the gameplay (at least in the opening section) to be entirely a text-adventure. When we wrote the first version of Ladylike for a game jam, the code we used to accomplish this didn’t lend itself to fitting large stories inside one’s head:

var zero:ConvoBranch = new ConvoBranch(0, "I don't want you two being friends...");
zero.addResponse("I know.", 2);
zero.addResponse("That's not fair mom, she's my best friend!", 1);
convoTree[0] = zero;

Though nicely object-oriented, this method of setting up a text adventure pretty clearly doesn’t scale with the size of the story being represented. The ConvoBranch constructor accepts a parameter ID, which is an integer used to uniquely identify that branch of the conversation tree. The addResponse calls point to new branches via their second argument.

As I’m sure Nina can attest, writing a story in this format was painstaking. The conversation tree in Nina’s head was huge, and drawing tree branches on paper and copy-pasting code blocks was getting old fast.

click through for fullsize image

Like a dutiful “game engine programmer” (a funny yet maybe appropriate title here), I wanted to turn Nina’s writing interface from the above code into something like this:

var myStory:Story = new StoryGenerator(storyFile).generate();

Nina and I immediately looked to Twine for help, as she’d used it successfully on some other projects in the past, and it provides a nice interface for editing interactive stories. The only issue was that the core library only supported exporting to html format (if you click the previous link, you’ll see the typical twine story format). Clearly this wasn’t great for our needs, since we wanted to use Twine as a tool in a pipeline rather than the main medium of our game.

Long story short, I found and forked the “twee” core library, which is the base on which the Twine UI is built. I added simple support for outputting to JSON, which enabled Nina to rapidly prototype and decoupled me from the writing process.

Shortly after figuring out a workflow that worked well for getting Twine stories into Actionscript, I encoded this workflow into a tool creatively called twine-as3, or “Twine for Actionscript”, which we used in the final version of Ladylike. Twine for Actionscript is a small set of classes that simplify the workflow for using a Twine story in Actionscript applets.

The workflow is explained in the README of the twine-as3 project, but I’ll go into some detail about how we used it in Ladylike here. The library exposes a TwineImporter class, which it uses to create a “pages” array representing the parts of a given Twine story. The structure it uses is highly generic - in fact it’s little more than an Actionscript object representation of JSON. The TwinePage object has an identifier, a list of tags, and some text. Together, this information is enought to uniquely represent a position in the story (as is familiar to Twine users). This generic structure, although not quite what we needed for Ladylike, seemed necessary to allow users of the library as much freedom as they have when using Twine on its own.

var pages:Array = (new org.twine.TwineImporter(twineFile)).getPages();

In Ladylike, the conversation between the player character and the mom character takes the form of “prompts” from the mom that have several possible answers the player can choose. Since Twine is generic enough to allow a much wider range of story forms, Nina and I agreed on what amounts to a “protocol” on top of the base Twine data format that would make importing simpler for our needs. As long as the Ladylike Twine file was written a certain way, it would import seamlessly into the Actionscript program. The code used to implement this protocol can be found here. Notably, the following code hacks the link fields of a typical Twine story page to work with our conversation generator:

var regex:RegExp = /[\[\[\]\]]/g;
var stripped:Array = pages[i].getLine(j).replace(regex, "").split("|");
var response:String = stripped[0];
var targ:String = stripped[1];
cur.addResponse(response, targ);

This code looks at the text of a Twine page and uses a regular expression to find the first link to another page (represented by [[ … ]] ). In Ladylike, each page has some text followed by two line breaks, then some lines of text for responses, each with a link to the appropriate next page - otherwise this method would break. This is the kind of thing that still needs to be implemented oneself when using twine-as3, since it’s quite hard to guess what ideas someone might come up with for the Twine layout of their next game.

Those are the basics of how twine-as3 is used in our game Ladylike. I wrote this because I’d like more people to know that it’s possible and actually pretty easy to use Twine for things other than pure text adventures. If you’re at all interested in learning more about how to use Twine with actionscript, you can contact me at emmett {dot} butler 321 {at} gmail {dot} com. I’m especially interested to know what kinds of features would be useful to the community of Twine users, and in seeing games that use Twine and Actionscript together (and maybe even Twine for Actionscript!).

Thanks for reading!


how do you Do it? is a game about clandestine childhood play by Emmett Butler, Nina Freeman, Jonathan Kittaka, and Deckman Coss.

Play Online

Why Try It: Cute art and dialogue; awkwardly mash two plastic bodies together.

Time: Five minutes.

How to Play: Use WASD to move your arms and J and K to rotate the dolls.

More Info: Nina Freeman and Emmett Butler have developed a number of other short games, many of which they have collaborated on. You can find them here and here.

Jonathan Kittaka’s art can be found at blogathan, and Deckman Coss’s sounds and other work can be found at cosstropolis.

This weekend, Nina and I worked with David Coss and Jonathan Kittaka at the Global Game Jam NYC site. We made a game called “how do you Do It”, about what little girls do when their moms leave the house. Click through to play! This was one of the most fun game jams I’ve done, even though in the middle it was super stressful.

A game that Nina and I worked on recently, Ladylike, has received an honorable mention in the IGF Student Showcase. I want to say thanks to David and Winnie, who helped make the game as pretty as it is, and to Nina, without whom the whole story of the game would not exist or be as well written.

You can find the official announcement of the Honorable Mention here, and you can play Ladylike here.

Ladylike is also free and open source, so check out the code if you’re interested.


I should really queue these posts, shouldn’t I?



Lately I’ve been feeling like my life is sorta out of control, like I can’t shape or affect any of the stuff going on around me. This might have influenced my decision to highlight Ladylike, a game by Nina Freeman, Emmett Butler,…

Ladylike on Indie Advent Calendar

I wrote this a while ago when I was trying to understand how arguments and scopes work in python. Here it is in case anyone wants my explainer.

Disclaimer: I use the terms “value” and “reference” here a bunch. These terms are used only to illustrate the point. I don’t mean to imply that python’s calling model has any concept of a “reference” or a “value”. In particular, look at the last two paragraphs.

When an object of a mutable type is passed to a function, what is actually passed is sort of a “fake pointer”. That means that, while it can be used to access parameters of the object it points to, the address to which it points cannot be modified.

This is “pass by value” in the C++ sense, where the value is a reference (maybe an integer representation of some location in memory). An important point is that the value is of an *immutable* type. That means that we cannot play with it like a pointer: we can’t, as in C, pass a pointer into a function, change the address it points to, and have that change visible outside the function. We can, however, use the reference to play with members of the object it points to.

More clearly: when a name is assigned to at function scope, the outer-scoped value of that name is discarded (mutable or immutable, it doesn’t matter). When a name is used to reference a mutable parameter without reassigning to it, the named object is modified.

If a name is assigned to in a function, the corresponding parameter appears to be passed by value (ie the outer object of the same name is not modifiable).
If a name is not assigned to in a function, the corresponding parameter appears to be passed by reference (ie the outer object of the same name is modifiable).


If you’re married to the value/reference paradigm, this can be thought of as “pass by value where sometimes the value is a reference”.
By that I mean that a name can be used to *reference* the same mutable object that exists outside of the current scope, but the identity of the object referenced by the outer name cannot be changed - any attempt to do this will actually result in the function-scope name being reassigned to a new object, but will have no effect on the outer-scope name.

This model is also called “pass by object” since the terms “value” and “reference” cease to be meaningful when used in this context.


Ladylike is a game about parental control and manipulation by Emmett Butler, Nina Freeman, and Deckman Coss.

Play Online

Why Try It: A short, dialogue-focused piece that expresses childhood experiences of powerlessness and neglect.

Time: Two minutes, though worth replaying to see alternate dialogue.

How to Play: Use the arrow keys to select options/move around and the enter key to make dialogue decisions.

More Info: Ladylike was made for the was created in 48 hours for the 27th Ludum Dare competition in which participants were asked to create a game that fit the theme of “10 seconds.”

Nina Freeman and Emmett Butler have developed a number of other short games, many of which they have collaborated on. You can find them here and hereMy House, My Rules and Fist of the North Carp are the most similar to Ladylike in that they also deal with parent-child relationships

This is a very nice write-up thank you!

Nina and I made another game about her childhood this weekend for Ludum Dare 27. Warning: this one is pretty sad, you guys.

Nina and I made the second of n games about her childhood this weekend for the What Would Molydeux game Jam (last time around, Diego and I made this ). Our game this time is called My House My Rules, and it’s a stealth game about hiding snacks from your (Nina’s) mom. Play it please!

A few weeks ago, we made our first game about Nina’s childhood

Nina and I made this game about getting slapped in the face with fishes for the Fishing Game Jam. Check out the dev log here and play it on Nina’s site.

My attempt at animating a dad for our #fishingjam game

My attempt at animating a dad for our #fishingjam game

Background I made for a game about gettin slapped with some fishes for #fishingjam with Nina


Emmett Butler is a web and video game developer and an NYU senior studying computer science and music technology. In this post, he reflects on his time as an intern at Parse.ly

Today, I leave Parse.ly after 20 months of work that took me from writing web scrapers to diving deep into semantic…

I wrote this post for the next wave of Parse.ly interns.


This is an exploration I did last night into pseudorandom noise generation. I was working on a project that involved the use of Perlin noise to make a target move erratically, and I couldn’t resist the temptation of making vapor trails (a pretty common use case for noise).

Nina and I found a Perlin noise implementation and adapted it into a simple class. Later in the evening, listening to the new Anamanaguchi album, I was inspired to make something cool looking, which led to this smoky rainbowy excellence.

The code that draws the smoke lines is based on code that simply draws a horizontal line. From the horizontal line, noise is applied to the vertical position of each pixel in an amount proportional to the distance of the pixel from the right side of the window. This is why the right side of the image appears less erratic than the far left side. The noise function is also passed the frame count as a parameter, to make the smoke lines progress from one side of the screen to the other and off then side. Without this addition, the lines would compress onto themselves over time, never leaving the screen.

The colors are generated by three sine waves, each representing one of red, green, and blue. The phases of these sine waves are disturbed by Perlin noise, and these disturbances are what cause the changing color palette.

This animation is created by writing pixel color values into a texture, then applying the texture to a sprite. The sprite is also scaled up by a factor of six in this image, since calculating the noise function at each pixel on a retina display makes the app run at <1 FPS.

Check out the code for this demo here.