I have been using Twine 1.4.2 almost exclusively since it was released, and have not had time to properly explore Twine 2. As such, this article is concerned with using 1.4.2.
When Nadia, Leif, and I sat down in November to work on the very beginnings of our GAMERella game, the first thing we decided was to delegate specific roles. Leif was the programmer and set creator, Nadia was the 3D asset artist, I was the story and sound designer. We decided to work on a 3D game in Unity3d because we all felt up to the (rather immense) challenge.
As we settled into our roles, before I opened up my text editor, I opened up Twine. One of our goals was that we wanted dialogue, and before I could give Leif any mechanics to program, I knew I would have to design the mechanics first. I had just read this article by Carolyn VanEseltine which proposed that Twine is not only a great game engine, but also an extremely useful tool for prototyping because of it's GUI:
Twine, for the uninitiated, is a tool for making hypertext games in the form of webpages. This has been done before, but what makes Twine special is the visual interface.
The visual interface of Outsider's prototype - a "blooper" version is available for play on itch.io for free.
As Carolyn VanEseltine demonstrates in her article, Twine is particularly useful when you need to breakdown the following game mechanisms:
- User flows
- Code architecture
- Branching narratives
- Branching game structures
VanEseltine is a veteran programmer whose blog is a treasure trove of quotable paragraphs - go take a careful look as soon as you can.
Prototyping in Twine is a little bit like writing pseudocode before beginning a program. At first it often feels like a waste of time, like one is spending too much time working around a problem rather than tackling it head-on.
Pseudocode looks a lot like regular computer code, but is human-readable. The advantage of writing pseudocode before programming in a programming language is so that key details of algorithms can be worked out before any code is actually written. Pseudocode statements can usually be easily translated into real programming statements.
while not at end of list
compare adjacent elements
if second is greater than first
get next two elements
if elements were switched
repeat for entire list
The advantages of pseudocode are very similar to the advantages of using Twine for prototyping - pseudocode gives the programmer room to concentrate on the finer details of the algorithm without having to worry about the specifics of programming languages and environments. Twine, similarily, gives the designer room to concentrate on the finer details of the game's design without having to worry about the specifics of programming languages, assets and game engines. The programmer experimenting with pseudocode doesn't even have to decide which programming language to use before writing the pseudocode, just as a game designer using Twine doesn't need to worry about game engines or programming skill.
In the Outsider prototype, I kept the verbosity to a minimum unless I was describing something that I thought was significant about the game's environment.
I used the "environment" tag to describe the game environment, and the "mechanic" tag to describe specific actions the actor or player can take. Twine 1.4.2. is extremely simple, using only the "title" and "tag" to control the "passages" (what Twine calls those little boxes floating in the GUI).
Because this was the very beginning of our game making process, anything tagged "environments" (and later, "characters") was shared immediately with Nadia, the artist, who was concentrating on the visual feel of the game's assets. I shared "mechanics" with Leif so that he knew what to program into Unity - since the mechanics were mostly "walking" and "looking around" it gave Leif clear indications of what we needed to get working in Unity, and what kind of scenes we needed.
Moving from Twine to Unity3d
Much of what was prototyped in Twine, we were not able to incorporate into the final prototype in Unity. Because it was GAMERella, a two-day game-jam, we only had 48hrs to go from extremely vague concept to "unfinished product" - which you are welcome to play here. In particular, we had a lot of problems implementing a dialogue system that worked properly. It was Leif's first time programming in Unity and he was learning how to use the game engine as he was building the mechanics of the game - as he wrote in his blog post recap, "it was a fantastic experience".
As I return to working on Outsider with the team, I've decided to return to Twine not only to re-work the mechanics of the story, but especially the dialogue and how I want the game to resolve - the "story" of Outsider will be short but compelling, so timing and resolution is important. When I sit in front of my notebook I often find I don't know where to begin re-iterating Outsider's narrative design. But working the narrative through Twine was a very useful drafting tool the first time around during the game jam, and I ended up doing some of my most productive writing on it during the jam.
I hope my notes on prototyping with Twine is useful and helps your game-making efforts! If you are interested in learning more about Outsider or following its development you should check out this Patreon post.