Twine Gardening

I haven’t published much in Twine on IFDB, but I actually use it a great deal: it’s become a prototyping tool of first resort for a wide range of professional projects, the format in which I deliver content to be converted into some other final presentation. A not-trivial amount of pro-level game story prototyping happens in Twine these days.

Which reminds me to mention that Chris Klimas has a Patreon for Twine maintenance and development, and it would be great to see that get some more support. Twine is usefully free to creators who might not be able to afford it, and long may it remain so — but I use it for industry purposes, so I pay for mine. (He’s also reachable via Unmapped Path, and has developed an engine to bring Twine pieces to mobile.)

One of the most characteristic things about writing in Twine is the business of curating the narrative map. Twine generates this map automatically, making a new passage for content every time you create a link that doesn’t refer to an existing passage, and placing that box somewhere near the originating passage. Which is fine, to a point, but very soon several things happen.

  1. performance drags and Twine takes its own sweet time inserting the box
  2. Twine’s idea of where to auto-place the box doesn’t correspond to my idea of how the contents should be visually arranged
  3. I can never zoom out as far as I want to, because even the smallest-box depiction of the Twine map doesn’t show me the whole monstrosity I’m working on

A really large portion of my time working in Twine consists of clicking back to the map view and dragging boxes around to better convey the story structure I have in mind. Pruning. Gardening. Rebalancing. Trying to make clusters of content stick together and make critical moments visible at a glance. Structuring so that I can recognize certain standard mini-structures.

For instance, both of these passages belong to a narrative that is, at the large scale, a standard branch-and-bottleneck, but the lower-level structure is actually very different:

The first diagram describes an “are you really sure you want to commit to this disaster” sequence: if the player heads down the left-hand path, they have several opportunities to opt out and rejoin the main storyline; but past a certain point, they’ve lost the game and are committed to a losing epilogue. And then, if the player survives that and traverses to the lower right portion of the diagram, there’s a big delayed-branching result with many different outcomes customized to what the player’s done so far: a narrative payoff for earlier choices. There’s some clustering to those delayed-branch results, which the diagram also tries to convey.

Continue reading

DINE

Screen Shot 2017-04-23 at 9.26.07 PM.png

DINE is, as I posted earlier, an unusual interactive fiction system that takes typed input but does not handle it through a parser. Instead, it uses text classification to find a response that is most coherent with the player’s input — a measure that depends heavily on linguistic similarity.

To author content for DINE, the author writes example player inputs (such as “I picked up the photograph”) followed by the response text that the author has in mind. Both the sample input and the actual output are considered when the system chooses a proper response. The system also applies a penalty to any output text the player has already seen.

There’s one final affordance: next to each paragraph of output is a “Huh?” button. Click it to reject the response you were given, and the system will search for the next best fit. It’s not guaranteed to work more with the story than whatever you read last, though.

DINE is not a particularly ideal tool for the kind of experience we associate with parser IF. If you do >INVENTORY twice in a row, you might well get a totally different response the second time — and one that is not especially coherent with the input. Indeed, there’s no way to explicitly author world state, other than as “pages” for the player to land on.

Different DINE pieces handle this in different ways. Olivia Connolly’s “A Quiet Street” offers quite long pages of story between interaction points, and sometimes sets up obvious single tasks for the player to try next, as for instance here, where the game directly tells me what to do:

Screen Shot 2017-04-23 at 10.30.21 PM.png

At its best — for instance, when the circumstances of the narrative made one particular action feel compelling, but didn’t explicitly spell out what that action was — this could achieve a pleasing level of fluidity, as here, where I know that there are strangers approaching the house but that my mother hasn’t seen them yet:

Screen Shot 2017-04-23 at 10.39.00 PM.png

Continue reading

Mailbag: High-Agency Narrative Systems

Today’s mailbag entry (at the request of the submitter, anonymized and edited a little) gets into the question of how to create salience and quality-based narratives and other similar games, given that typically one has to build one’s own.

What I keep getting drawn toward on a personal level is your work–and other people’s work too–on procedural narrative generation. I have enough knowledge of coding to understand states and modeling systems and when to move from one to another on a conceptual level, but at this point I could not make one in any language or engine. I think this is something I would like to learn to do more of...

Obviously I’ll need to learn a language from the ground up. That’s fine. I suppose I’m asking what would be most helpful to focus on–not just in terms of C# or Ruby or Python–but other skills as well… most of my questions/interests are about event generation, procedural chains of causality, etc.

Further discussion with the asker indicated they are talking about the kind of quality-based and salience-based narrative systems I wrote about in the article Beyond Branching; this RockPaperShotgun column about Alcyone also gets into some detail about the state of play in this space.

Systems like this can achieve a combination of player freedom and agency that is hard to reach in CYOA or any other node-based system (I would include ChoiceScript here): there are often dozens of viable choices available.

Meanwhile, because you’re not tied to a specific simulation concept (like the standard parser IF world model), you can adjust the qualities of your QBN to the particular needs of this work. Track your protagonist’s health, her interest in opera, her sense of humor, her tolerance for pain; track her relationships with each of a dozen friends, or a dozen aspects of her relationship with one friend.

On the other hand, the tooling and the design abstractions in this space are not nearly as advanced as they are for parser IF or CYOA/hypertext/stats-based IF, so if you want to work with it, you probably have to build your own.

That’s a topic that could take a number of articles, and there isn’t as much writing in this space to point to as in the parser space.

Continue reading

Mailbag: Writing for Versu

g_ending_2@craigtimpany writesYou’ve covered Versu’s architecture, but I’m curious what that was like to write for… In particular I’ve been wondering how very non linear tools affect a writer’s flow.

For those just joining, Craig is asking about Versu, a system focused on agent-driven narrative. Versu and the games made with it are no longer available, but there’s information available about the system, including several papers at the Versu website, and past posts of mine here about the conversation system and about what it was like to convert Galatea to the Versu format.

During the first portion of its development, Versu content was driven through Praxis, the language that specified social practices and truths about the world state. Praxis is very powerful and allows the user extremely detailed control over what is true about the world, and what all the agents want; and the baseline implementation of conversational practices, among others, were written in Praxis. However, writing extensive dialogue in Praxis was essentially wrapping conversational elements in code — a high-friction way to compose, and one that discouraged revision. To address that, we developed a DSL called Prompter. I am not going to re-describe here everything about how that worked, since the attached papers go into detail.

But the core point to know is that, within Prompter, one wrote scenes. Each scene could have some opening text; some parameters about what was allowed to happen in that scene (e.g., “no one dies in this scene, but Veronius is allowed to have sex”); a body of dialogue that can be spoken only in that scene and nowhere else; and then one or more ways that the scene can end.

Using that information, the system would follow its own rules about how conversation and social actions could chain into one another, improvising a particular performance around the scene parameters the writer had set on the page.

Continue reading

JavaScript front ends for Inform Games

I initially titled this post “Glulx-compatible Vorple,” but felt that possibly that headline wouldn’t convey much to authors who aren’t already familiar with the esoteric edges of IF tooling history. The good news is that it is now much easier to make your Inform game look good in the browser, and to take advantage of CSS and JavaScript in sophisticated ways.

Juhana Leinonen has announced a public beta of the Vorple extension set for Inform that works with Glulx, consisting of not one but several connected extensions for achieving various JavaScript effects.

Vorple’s functionality goes beyond the (still quite cool) work that furkle did to support the front end of WorldsmithA version of Vorple has been around for some time, and the prototypes for it existed as far back as the IF Demo Fair, but what’s been available so far has been compatible only with the Z-machine, a format so small that it’s increasingly hard to generate any viable Z-machine games with Inform 7 at all. Meanwhile, Hugo Labrande has maintained a Vorple version suitable for use with Inform 6.

There are some extra details available at the announcement post here.

The new edition of Vorple opens the following possibilities for games that are being played online or in a browser (which, these days, is more and more of them):

  • Large (not the tiny and currently rare z-machine format) Inform games that can issue JavaScript instructions
  • Authorial control over fonts and typography on a level that has generally been difficult or impossible
  • Hypertext games programmed and driven through Inform, something that was previously possible but tended to come out looking rather clunky
  • Parser IF that makes attractive, dynamic use of illustrations, maps, and even videos
  • Inform games that use JavaScript to access information that has usually been sandboxed off, from checking the date to using information widely available on the internet. The Vorple extension set includes an example that pulls data from Wikipedia, for instance
  • Games that remove text after it has already been printed to the screen (something that was just about impossible with former non-Vorple Inform interpreters); this means that one can, among other things, remove error messages from the scrollback, or change the game’s printed history to reflect changes in the protagonist’s mentality
  • Tooltips and modal dialogue boxes to do things like offer definitions or confirm player choices outside the main narrative
  • Help menus other than the horrid nested, keypress-driven things we’ve been suffering with since 1994
  • Probably many other things I have not thought of yet.

I’ve had the chance to play with the extension set as Juhana tested it for release, and it is really cool.

In addition, those in range of London are welcome to join us for the IF Tools meetup May 31, where Juhana will Skype in to talk to us about the Vorple project, so those interested can get a first-hand introduction.

September Mail

Hello Emily,

You don’t know me. I read your blog and I actively use Adrift to experiment with make IF games and have tinkered with Twine also.  I know you are super busy so i will get right down to the point, least i start rambling about IF.  

In a brief summary this is about an idea (that may have already been once given to the IF community) of setting up a crowd funding for a prize pool for a IF Creator/Engine competition.

Some might say the best IF creator out there is Inform, i did try it in the past but couldn’t get into it, i tried Quest and that was confusing to use after getting used to using Adrift. I have been tinkering with Adrift on and off for about six years and it has come along way, but falls short in some areas due to only one Dev who adds new features and fixes bugs in his spare time. Adrift does have the ability to use expressions that are close to programming and it is over the last year or so i have learned quite a bit with expressions. I think Adrift is often overlooked (the ability it has with being able to create custom properties for locations, objects and characters. And the ability to create modules to add to your library or share. It still needs lots of polishing).  

I was thinking to myself today, why hasn’t there been a kickstarter (add in other crowd funding options here) on creating the ultimate IF Creator/Engine (that could handle CYOA style games, point and click, IF or all of the above in one game). But then there would be many opinions of what that might be or look like and how it would be internally structured, visually look etc no one would never agree on things. And of course the parser. So what about the next best option;  crowd fund a prize pool for 1st, 2nd and 3rd place for an Interactive Fiction Creator/Engine competition with defined criteria for judging, such as UI, Parser, multimedia support etc you get the idea. I do not know how big the funding would get to make a decent  prize pool worthy to garner attention from programmers around the world. Obviously the bigger the prize pool the more attention and interest in it. I am not a programmer so i do not know what would be a realistic deadline 12 months? 15 Months? for at least a working prototype. Programmers outside the IF world would be at a disadvantage, but could catch up quick reading a number of articles written about IF its weaknesses and strengths with what is currently available to us as tools as well as free content that can be played to see the best of the current crop of IF games in the last ten years. Maybe fresh eyes (programmers outside of the IF community) on the scene might help?

This approach could see some really ingenious ideas that may not win the prize but spark some new ideas to improve on or the winner might have something few didn’t think of that he/she goes on to finish and releases either for free or profit. People tend to be more interested in being in control of their own project and are motivated to be ambitious or think outside the box more this way. I am sure there would be many failed or unfinished entries, but hopefully there might be a small number of really well implemented ideas… 

Continue reading