Texture development time

Some time ago I and Jim Munroe released an authoring system called Texture. The system was under development for several years as we spent a couple of hours here and there whenever we had the time.

I use a time tracking tool called Toggl to keep track of how long I've been doing various things, so I have relatively accurate statistics for how much time I've really spent working on Texture. The system has three major parts: the Writer that authors can use to create Texture games, the Reader which is the "engine" that plays those games, and the Public Library which is the repository of public works made with the system.

In total I've spent about 326 hours on the project. The summary is below:

Time (hours) % of total
Writer 141 43%
Public Library 73 22%
Prototyping 50 15%
Reader 42 13%
Project management 20 6%

Pie chart of time spent making different parts of Texture

Some notes about those figures:

  • Prototyping is time spent on planning and making mockups and initial throwaway versions before deciding on the final design. We did a lot of trial-and-error iterations and test versions before starting to work on what became the final product.
  • Project management is mainly emails and Skypeing with Jim to discuss and plan the project.
  • Because of reusable code there's some overlap in many areas. Working on something that was needed for multiple areas is marked down somewhat arbitrarily in the statistics.
  • I didn't start tracking time right at the beginning, so the prototyping figure is the most uncertain one. A total of 300-350 hours for the entire project should be about right.

Additionally, while I did all the programming work, these figures don't include Jim's contributions that total to about 250 hours. He did most of the system design and spent a lot of time on the community outreach, managing beta testers and writing demo games.

For me the main takeaway from these figures is that it takes a relatively short time to make a new system, but a lot of time to make a user-friendly tool for authoring games in that system. For example, two of my custom-engine games (Ex Nihilo and Ex Materia) were both practically one weekend projects from scratch, but building an editor for others to make similar games would take at least a month or two of full-time work.

Finally here's some statistics about the lines of code in each part of the system, excluding third party libraries. "Other" includes mostly helper scripts and server setup.

JavaScript HTML CSS Other Total
Writer 4051 1298 536 36 5921
Public Library 1924 1268 208 47 3447
Reader 964 135 499 0 1598
Other 385 0 0 36 421
Total 7324 2701 1243 119 11387

Bar chart of the amount of code written for Texture

Texture released

Texture Public Library

A couple of years back I and Jim Munroe released an alpha version of Texture, a touchscreen optimized interactive fiction authoring system in which you drag and drop words on top of story text. We've worked on the release version ever since and earlier this week it was published at texturewriter.com.

There are too many new features to list them all, but here are the highlights:

  • New layout, user interface and typography. Page text adapts to available screen space automatically.
  • State tracking through flags and behaviors: actions can toggle flags on and off, which in turn lets the author trigger alternative behavior based on which flags have been set.
  • 'Sit' command hovering over 'tree' where it changes to 'sit under tree'The action's name (which is displayed when the command is dragged over its target) doesn't have to be strictly verb-noun anymore. The most common use case is adding prepositions ("sit under tree" instead of "sit tree") but it can be changed to anything at all ("sit" + "tree" → "rest under the redwood").
  • Command targets can consist of more than one word by using underscores which are shown as spaces in the final story (e.g. "oak_tree" would be printed as "oak tree" but both words would be targeted at the same time.)
  • A command target can be reused after an action has replaced it with new text by enclosing a word in the new text in [brackets].
  • Basic text formatting options (bold and italic text).
  • Texture story cover page with a draggable 'play' button and a speech bubble pointing to it saying 'Drag play and drop it on top of story to start'. A ghost image of the play button and a dragging finger icon has been placed on top of the word 'story'.Cover page and cover art; the cover page also acts as a tutorial for people who are playing a Texture game for the first time. Clicking or tapping the play button shows a "ghost" of the button being dragged to demonstrate how interaction works, and clicking again pops up explicit instructions.
  • Preview right in the editor, with a debugging console for manually toggling flags and following internal behaviors and flag changes.
  • Exporting and importing project backups.
  • An interactive tutorial that guides you through the basic features.

In addition to new editor features, stories can be published online at texturewriter.com without needing to download the project and host it on your own web site.

Logging in to the web site will automatically save your projects to the server, so they'll be safe even if you clear the browser's cache and you can access them on any device by logging in. You can still use the system as a guest, in which case the projects will be saved locally to the browser (and nothing is sent to the server), but then you'll have to back up the projects manually.

The flag system makes Texture a "real" system with state tracking instead of just simple tree-like branching. In terms of story logic we're unlikely to add features to the online IDE because it's starting to approach the limit where the visual interface can't represent more complexity in a way that wouldn't make writing stories cumbersome and error-prone. We're planning to release the Texture Reader (analogous to parser game interpreters) as a JavaScript library which would allow writing story logic of any complexity using JavaScript.

Other new features are possible though, and the next major feature under development is story-specific layout options (color and font choice.)

You can read more from Jim Munroe's blog post and from Emily Short's blog where Jim talks about writing Pretty Sure.

Introducing Texture

I've been working with Jim Munroe (Everybody Dies, Guilded Youth) on developing a new kind of text game authoring system. It's called Texture, and it debuted yesterday at the WordPlay Festival in Toronto.

Stories authored with Texture are structured like books. Each scene or node is one page that has about one screenful of text. On each page under the text are some verb boxes. Dragging and dropping the verbs on the text changes the story, resulting in a sort of e-book that mutates and evolves based on the reader's interaction.

The interface is designed for touchscreen devices. It's possible to play with a mouse but dragging the verbs with a finger is the more natural way of interaction.

The writing tool looks almost the same as the resulting story, with added authoring controls.

Texture writer

There's very little modal difference between the reader and the writer. You write the text on the page directly and create commands by first adding some verbs and then dragging them on nouns, just like you do when you're reading the story.

A prompt that lets the author choose how the command alters the story text

The writer's user interface steals borrows heavily from Twine 2 which I think does a lot of things right and having similar elements hopefully makes the interface easy to learn. The system itself is Jim's vision, my role is mostly on the implementation side.

When's it out, you ask? Right now! You can try the alpha version at texturewriter.com. (Disclaimer: early alpha. Not tested in IE, use Chrome or Firefox if possible. In Safari you need to save the page manually after clicking the "download" button. You may also need to try dragging the verbs twice before it responds to dropping the verb on words.)

The one major feature that's still missing is setting and reacting to flags, which would let you change the output based on earlier interaction. At the moment the system is basically stateless although not linear – you can branch the story by having different actions open different pages.