Phrontisterion, and some more thoughts about tools and the art

A couple of weekends ago I went to Phrontisterion 7, a living-room-sized conference on interactive storytelling run by Chris Crawford at his home in Oregon. Participant comments from that are now available.

For context for people who weren’t there: it was a really wide-ranging discussion about what projects currently exist in interactive storytelling and how/how well they work (Saturday) followed by forward-looking stuff about what to do next (Sunday). On Saturday, we talked about (among other things) Prom Week and Storybricks, Storyteller, LA Noire, Chris’ plans for Storytron 2.0, StoryNexus, ChoiceScript, and the project that I’m working on for Linden Lab. Though there weren’t formal presentations on these items, people also talked a bit about conventional interactive fiction, and about Varytale and StoryDeck.

Sunday was directed more at the question of “well, what next?” — and that was a more challenging discussion, one that I think frequently frustrated Chris. We generally agreed that we’re not trying to reproduce the Holodeck as such, at least not in its full technicolor, surround-sound, smell-o-vision glory, and quite possibly not in most of its other aspects either. I may possibly have gone on a short rant on the value of text, darn it, you know, with words, and how text is not inherently a second-class citizen and a cheap substitute for the greater expressivity of visuals. (Visuals are cool, and if there were to be a Holodeck that could conjure up a 3D immersive sensory experience, you bet I would want to try that thing out for sure. But. The art I personally want to create is made of language.)

Sunday afternoon involved a fair amount of argument, and I think, if Chris will forgive me, this is because he was looking for an agreement that all existing forms of interactive storytelling are failures and that we should be jointly pursuing a particular grail, a particular type of engine and storytelling experience. But this is much too extreme a position for me to sign on with. A lot of really interesting interactive storytelling has already been done, though the media are all still in their infancy; there are many valuable directions to pursue in the future. Eventually that conversation turned, more mundanely but perhaps with greater clarity, to the question of how interactive storytelling can work as a commercial enterprise.

But all this arguing did help refine my thinking about something else.

Chris more or less explicitly invited me to argue for a bold future of wealth and success for traditional IF, and I declined to do so: I don’t see parsed IF ceasing to be a niche product with a small dedicated audience. That audience is larger than most of the IF community tends to realize, and we’ve made some excellent progress on accessibility and outreach in the last few years. But it’s still on the scale of these things small. The parser is just too much of an accessibility challenge, and we haven’t found a way to obliterate that; and I think we’re not going to change it completely any time in the near future.

Several people have asked me recently whether I’ve “switched to” writing CYOA, in the wake of Bee, and in light of my previous comments about the parser; to which the answer is no, I really haven’t. I still have parsed IF works in progress. I’m also doing things that are neither parsed IF nor CYOA. I have another project that’s interactive epistolary story, for instance.

What has changed is simply this: I have more access to more different tools now. There are a lot of projects done in traditional IF languages that are a poor fit for the traditional world model or the traditional parser or both — but IF tools are out there and they have cross-platform support and they’re supported by a community and a history, and maybe the tools that are really suited to some of the things people want to write just don’t exist yet.

I say that despite the proliferation of CYOA-plus-world-state tools we’ve seen in the past year or three: Undum, Varytale, ChoiceScript, StoryNexus, inklewriter, Bloomengine, and the gamebook mode for Quest, as well as the proprietary software underlying Coliloquy and the Take Control books, going alongside older platforms like Adventure Book and Twine and probably dozens of smaller, more fiddly CYOA tools that have passed by over the years. Some of those tools do pretty lightweight variable tracking, some allow for richer math, some have randomization, some explicitly track inventory or have a room-based world model instead of being narrative-node-based. So we’ve got a lot of options if we want to write that general kind of thing.

But that’s not all there could be in the text-plus-some-underlying-model space.

For instance: what about an engine suited to text-based resource management games like Olivia’s Orphanorium? The text output was essential to the flavor and intent of that game, but the text input was often cumbersome and repetitive. A CYOA-ish ability to click actions might have worked better, but there was a lot more back-end simulation going on than CYOA engines typically handle. I constantly see people on the intfiction forums asking questions about how to write games with stats tracking and character creation and heavy simulationist features of this kind, and yet very few such games ever make it to release. Could that mean there’s an authorial desire here but not adequate tool support? Maybe the ideal tool looks like Inform/TADS/whatever + a clickable, lightly graphical Vorple front end, but maybe it looks like something totally new and custom-rolled.

There are multiple other directions I can imagine the text story/game toolset going, but as I am working on some of them myself, I’m not going to tout those before they’re ready. And obviously there are directions I haven’t thought of either.

But someone is going to think of them, and soon. To come back to the commercial question, there’s money here. There’s also artistic potential. I have my doubts about the salability of the parser, but none about the rest of the IF package. Text-based interactive stories using some sort of state tracking or world model? There’s a huge future for those, the forms that exist are already making money, we’ve only barely scratched the surface of the possibilities, and there are vast tracts of unexplored terrain in this vicinity.

I’m not trying to bury old-school IF, and I’m not abandoning Inform. (Believe it or not, work on the next release is ongoing; just slowly, slowly, behind the walls.)

I just think there are so many things people have been trying to accomplish by arm-wrestling the parser or world model in a traditional IF engine, that could be done better by other means.

*

(ETA: Immediately after posting this initially, I ran across this new interview by Zarf, in which he argues — as he has at more length in the IF Theory Reader — that the parser and the ambiguity it creates is the core, the fundamental mechanic, of IF. And that’s a fair way of looking at it, if not exactly mine. But if one accepts Zarf’s definition of what IF is, I would say that I am interested in a lot of things that are not IF but taxonomically adjacent to it.)

*

A small postscript, speaking of ideas about interactive story: here’s a cool article from Robert Yang comparing Varytale and specifically the structure of Bee to the rule-based dialogue work presented by Elan Ruskin at GDC 2012: both are looking for the most specific event they can trigger. I hadn’t thought of that line of comparison myself before.

29 thoughts on “Phrontisterion, and some more thoughts about tools and the art”

    1. Ah, yeah, I dimly remember discussing this game with you a few years back, but hadn’t thought about it again since then. (I see there’s a longplay video of it, too, which gives more of a sense of what it looked like.)

      To the best of my knowledge none of the existing CYOA-like engines do use a least-squares-fit method to determine which narrative node/storylet should be shown next, but it seems like it would be a fairly plausible option/add-on for someone to build.

      It’s not immediately obvious how this system would guarantee rising action and a strong conclusion, unless some of the fit variables expressed things about dramatic state rather than world model internals. But that’s doable.

  1. “But if one accepts Zarf’s definition of what IF is, I would say that I am interested in a lot of things that are not IF but taxonomically adjacent to it.”

    To be sure, I am too!

    The dichotomy between “parser” and “CYOA” is something of a hobgoblin for me right now, and I acknowledge that it’s a *false* dichotomy even as I cling to it. I have “get over it” on my schedule for next year sometime. :)

    1. I guess what I’m arguing here is that, in the set of parser-based IF, there is a significant subset for which it would have been possible to do a non-parser-based interface that would have served the mechanics and content equally well or better.

      For instance, I’m now thinking about what my conversation games would look like if I had designed a UI for them from scratch rather than assuming they needed to be parser-based, and I can envision something that I think would be suitable for several of them, as well as more novice-accessible and clearer for the player about what was going on. What if there was a topic cloud that grew during the course of conversation, where any topic may be clicked, but the topics especially relevant to the current conversation spot are highlighted? Click a topic you want to discuss next, and if there are multiple quips associated you can pick one; and if there aren’t, you fire that quip and move on immediately.

      That would expose more of the underlying model more clearly than Alabaster currently does, while involving a lot less typing and losing the performance issues that arise from disambiguating the names of hundreds of similarly-named quips. It would still be turn-based and textual, but would take much less time to learn to control than the Alabaster command line. And it would presumably feel (I’m guessing) if anything less CYOA-like than Alabaster currently does, because we’d be taking away the prompts (“You could ask her about why the Queen likes to eat puppies or you could complain about the route…”) in favor of a more compact visual way of signaling conversational hotspots within the larger domain of conversational potential.

      Now, Alabaster itself clearly wouldn’t work that way, because it still does involve some actions from the traditional IF verb set, involving the physicality of the character.

      But I think there could be some interesting things written with the UI I just suggested. Maybe all it would need is a Vorple or Glimmr hat on an Inform backend, so I wouldn’t have to rewrite the Threaded Conversation engine. I’m not sure.

      1. What if there was a topic cloud that grew during the course of conversation, where any topic may be clicked, but the topics especially relevant to the current conversation spot are highlighted?

        Have you played Gamer Mom? It’s short and does something kind of like this. Instead of a binary highlight, the conversation options are visually weighted by their position in the pane. I think it works very well with the highly emotive character illustrations that accompany the text.

      2. I have played Gamer Mom, yeah. I was thinking of something a bit more procedural than that, and a bit less emotive; though, now you mention it, I could imagine the topic cloud using size/color/placement to give some hints about the emotional tonality of the different subjects.

  2. I constantly see people on the intfiction forums asking questions about how to write games with stats tracking and character creation and heavy simulationist features of this kind, and yet very few such games ever make it to release. Could that mean there’s an authorial desire here but not adequate tool support?

    Yes and no. The smallest adequate size for a CRPG is a lot larger than the smallest adequate IF, which I think is as responsible for the dropoff rate as anything. Strategy sims have the same problem: I’ve been trying to make things in that vein in IF languages for probably as long as I’ve been in IF, and my failure to get anything done except Orphanorium has largely been about overambitious design (precisely because it’s the sort of thing that’s only cool at a fairly large scale) and overly high standards for sentence generation (which is going to be bloody hard regardless of system). Orphanorium‘s the first time I’d even really got as far as a reasonably testable UI.

    This isn’t to say that a different system wouldn’t have helped — something with less standard-IF-specific clutter, kinder to dynamic object creation, and that wasn’t slowed down quite so much by very frequent manipulation of large lists — but the best tools in the world aren’t going to make it easy to make things that are large and unusual. (Still, it seems that most of the people who want to make CRPG-like IF don’t want anything very unusual — quite the reverse — so a standardised, moderately-flexible system could have value there.)

    And I’m still really conflicted about parserless. I like that in Orphanorium you can still try to sing and pray and cuss, even if they’re not really important to the core functions of the game and most players won’t spend much time on them. I don’t see any way of replicating that behaviour with clickable buttons. Perhaps this is an expensive luxury that games that don’t resemble conventional, medium-size-dry-goods IF can ill-afford, but it’s one I’m loath to give up; it’s kind of crucial to the distinction between inhabiting a world and steering a story from the outside. (Now that I’m thinking of it, though, I like the idea of buttons somewhat more if they’re presented as strategy-game-like interfaces, with multiple panels and lots of knobs and sliders, than if we think about them as mobile-device-friendly, CYOA-like simple button sets. But a generalised version of that would be no small matter, and I’ve no idea how it’d mesh with IF-like text output.)

    For a few years, my pie-in-the-sky hope has been that we can work out parser command / world-model sets that *don’t* assume the standard IF medium-size-dry-goods world (containment, lighting, primacy of inanimate objects, actions taking about one minute) but that are still reasonably learnable and smooth-playing. Given how bloody difficult it is to learn one parser command set, this may not be reasonable.

    (I realise that a lot of these concerns are pretty parochial, and that I am rambling somewhat. Apologies.)

    1. Now that I’m thinking of it, though, I like the idea of buttons somewhat more if they’re presented as strategy-game-like interfaces, with multiple panels and lots of knobs and sliders, than if we think about them as mobile-device-friendly, CYOA-like simple button sets. But a generalised version of that would be no small matter, and I’ve no idea how it’d mesh with IF-like text output

      I was thinking of something more strategy-game-like for this purpose, too. Though it’s possible there are other sweet spots. At Phrontisterion, Dan Fabulich suggested that parsed IF might go in the direction of A Colder Light plus the ability to enter one-off words if so desired; and brought up the way in (I think?) the Leisure Suit Larry games you could pick a verb from a menu or fill in a blank to make up your own verb.

      I have mixed feelings about that idea, because it seems like it doesn’t get cleanly away from a lot of the challenges of parser IF — as the author you still have to spend a lot of time making up intelligent responses to things you don’t ever want the player to do, and there’s still the possibility that some games sometimes will present the player with a guess-the-verb experience.

      For a few years, my pie-in-the-sky hope has been that we can work out parser command / world-model sets that *don’t* assume the standard IF medium-size-dry-goods world (containment, lighting, primacy of inanimate objects, actions taking about one minute) but that are still reasonably learnable and smooth-playing. Given how bloody difficult it is to learn one parser command set, this may not be reasonable.

      Well. Hm. Yeah. I mean, obviously I’m interested in that too: conversation modeling is one direction for that, and then I’ve got all these not very conclusive experiments with trying higher level verbs for different types of social situation. (Something where the primary commands are things like BLACKMAIL, SEDUCE, BETRAY, and where the minimum time unit was a half day, for instance.)

      Possibly I’ve just never stuck to this hard enough to get it finished, but most of the time I’ve tried this kind of project, I got to disliking the parser but didn’t have a better idea. For a while, my BLACKMAIL/etc. sample game was going to be a thing where you’re trying to negotiate a political situation of conflicting loyalties reminiscent of late first/early second-century AD Imperial Rome. But I started to think that what I wanted there was an idea that all the other characters in the drama were a source of constantly escalating threat, shown in a sidebar as an image of that character with them looking more and more glowering depending on a) how much they suspected/disliked you and b) how much power they had to harm you. And then the player had to engage in a kind of spinning plates act, dedicating attention to undermining, blackmailing, and seducing these characters to keep any of them from doing anything too severe. The combination of a small, pre-defined verb set and this desire for a substantial graphical display is what moved me away from the parser idea, but I didn’t really have a better idea either (other than doing it natively in Flash or something) so I gave up for the time being.

      I wonder whether possibly this is because the tight connection between text out and text in gets looser and more jiggly when you move away from the realm of medium-sized dry goods.

      F’rinstance: If I type BLACKMAIL MARCUS, what comes *out* of the machine, ideally, is still a detailed, dialogue-rich exchange in which my character performs that activity, not “Marcus: blackmailed” or Marcus’ fear-of-me bar inching slightly to the right.

      But that means that the kind of thing I’m typing in and the kind of thing the computer is printing out are no longer in the same vocabulary, and I’m no longer scanning the output text looking for verbs and nouns that are appropriate for me to use. Instead I’m interpreting Marcus’ social behavior, recognizing it as a certain type of social move in the large scale, and trying to replicate that and/or pick a good counter to it.

      In addition, the amount of effort going into each individual verb is enormous, because I need to do a lot of situational interpretation to determine how Marcus can best be blackmailed at this point in the game; there aren’t really any small short moves the way there are with moving around a map or manipulating inventory.

      That being the case, implementation gets harder for the author, guess-the-verb gets harder for the player, and the pleasure of the parser as a conversation partner decreases, so it starts to seem on balance better to do a game with a small fixed verb set, and if you’re going to do that, why not make the list available to the player, and… yeah.

      However. This is only a theory off the top of my head. It could be totally wrong. But I think it does fairly accurately describe, at least, why my stabs in that direction haven’t gone anywhere much.

      1. At Phrontisterion, Dan Fabulich suggested that parsed IF might go in the direction of A Colder Light plus the ability to enter one-off words if so desired; and brought up the way in (I think?) the Leisure Suit Larry games you could pick a verb from a menu or fill in a blank to make up your own verb.

        I generally think that this is a horrible idea; choosing buttons is an entirely different mindset from entering parsed text, and if players can get by on the former, they’re unlikely ever to use the latter, and so authors don’t bother implementing things for the parser to deal with, and so you pretty quickly get a race-to-the-bottom that leaves you with CYOA buttons plus an ugly, pointless parser input box.

        I’ve sort of hazarded at the idea where, instead of typing a noun or selecting from a menu, you get a pop-up mindmap / Wordle-like verb-list, that neatly shows you every one of a hundred-odd verbs that might do something useful, while still emphasizing the core set that you’re going to need most of the time. Implementing that… mmmmmrf.

        In addition, the amount of effort going into each individual verb is enormous, because I need to do a lot of situational interpretation to determine how Marcus can best be blackmailed at this point in the game; there aren’t really any small short moves the way there are with moving around a map or manipulating inventory.

        I think you’re going with a sort-of-extreme case — sure, this is going to be an issue for a pure-social-manipulation game, but not necessarily more so than it would be for a finer-grained game that’s entirely about social interaction. If you were, I dunno, implementing Sim City in an IF format, or a game about managing NPCs rather than socialising with them, you could have a fairly broad, standardised, predictable, ready-to-hand suite of manipulation verbs for business-as-usual interaction. The bigger issues (which may still be impossible to overcome) are more about refining that sort of system to a point where it works as neatly as the standard IF verb-set, and then whether you can teach people to use it.

      2. I think you’re going with a sort-of-extreme case — sure, this is going to be an issue for a pure-social-manipulation game, but not necessarily more so than it would be for a finer-grained game that’s entirely about social interaction. If you were, I dunno, implementing Sim City in an IF format, or a game about managing NPCs rather than socialising with them, you could have a fairly broad, standardised, predictable, ready-to-hand suite of manipulation verbs for business-as-usual interaction

        Okay, possibly it’s true I’m being defeated by my desire to take gameplay in the most Machiavellian direction possible. (Or, to put it another way, I am most interested in exploring systems about how people interact, with lots of fiddly detail.)

        I still think the text in vs text out decoupling would be an issue for a hypothetical text Sim City-alike, though. If we envision that this game

        — is still about constructing roads, utilities, and various types of building
        — but moves somewhat away from the specifics of spatiality (text doesn’t represent that well)
        — and does feature more lyrical descriptions, to make it worthwhile doing prose (“The new cathedral casts a shade across the park. Its gargoyles scowl down at the playground. Sometimes a child disappears. Children disappeared before, of course, but no one is sure whether it is happening more often now, and they assign new reasons when it happens. Parents cross themselves instinctively and shiver when they pass the parishes of the Emillard Sect. Perhaps they were wrong to vote for conversion in the last city-wide referendum?”)
        — and also has more of a narrative arc, or at least a narrative event system

        …then we still have a situation where the text coming out is on a different level (gargoyles, children, parents) than the commands going in (which presumably will be things like BUILD CATHEDRAL, DEMOLISH CATHEDRAL, HOLD NEW REFERENDUM, BANISH EMILLARD SECT, and so on). So instead of asking the player to read the text carefully and pick out the words they think will be useful to type back in, you’re asking them to learn and hold in mind a set of other, more abstract verbs (and nouns, in this case! somehow the player has to know it’s possible to build something called a “cathedral” even before one exists in the city).

        That in turn suggests to me that you’re going to need some explicit method of delineating affordances. Even if you could get the player to learn all the terminology by heart, what gameplay advantage have you gotten in exchange for this accessibility loss? You’ve mostly discarded the thing that makes the parser make sense, namely the close and conversational connection between what’s read and what’s typed, that allows the game to hint semi-obliquely at new interaction possibilities.

  3. Could you confirm us, to the people that are not half knee in the nowadays develop of IF in all its forms, that CYOA + model world tools are the following (copy pasting you):
    Undum, Varytale, ChoiceScript, StoryNexus, inklewriter, Bloomengine, and the gamebook mode for Quest.

    I think too, that the world model with an GUI of hypertext or icons is the best for the mobile devices, phones and tablets. Although I could imagine that virtual keyboard are going to be better and better. The Ipad one is quite good in my opinion. So, an extension for hypertext for Inform7 is highly desirable. Yes I know there is already one, but one that could automatically show the options for the GUI, analysing the state of the world in that moment. Or, one that could allow the author to guide that automatic system.

    However, when I think of use that kind of GUI for my own games, a big problem arise when analysing the basic elements of interactivity that advance the plot, so I could define them as hyperlinks, instead of atom actions.

    For example, think of Dracula 1, my remake of Rod Pike’s game. The very first action is to pay the driver. The good of that action is to discover what that drunk and violent man wants. If you show

    ->Pay the driver

    as an hyperlink, you have already spoiled that action and puzzle.

    So, I’m with Zarf here when he says that “It’s all about the parser”. You know, he is right. It is the opaqueness of the parser as interface that brings all those marvellous moments of great eurekas.

    So, if we want our works on Kindle, Iphones and tablets and such, we must redesign our puzzles, events and actions, to give other kind of flavour because the parser one has been lost in the process.

    Well at least I could imagine a mixed solution for my example, built-in with hyperlinks:

    ->examine me

    ->examine coat

    -> examine pouch

    ->examine money, or
    ->give money (at last!) to the driver.

    But you see, it is not the same thing…

    1. No, I agree it’s not the same thing, and some puzzles are guess-the-verb puzzles (or, at least, guess-the-action puzzles) at their core. But a large number aren’t; and I think A Colder Light does a pretty fine job of demonstrating what fairly conventional IF puzzles might look like when the action is done with buttons. (As you describe, I believe the engine in that game is analyzing the scenario, determining appropriate verbs for each of the objects in the game, and presenting those to the player as clickable options.)

      Could you confirm us, to the people that are not half knee in the nowadays develop of IF in all its forms, that CYOA + model world tools are the following (copy pasting you):
      Undum, Varytale, ChoiceScript, StoryNexus, inklewriter, Bloomengine, and the gamebook mode for Quest.

      I meant that list to be a list of CYOA + model world tools, yeah. They range a lot — Bloomengine works, as I understand it, on a rooms and objects model pretty close to conventional IF, Varytale and StoryNexus have an idea of the storylet as the fundamental unit, inklewriter and ChoiceScript have freely settable variables. I’m sure that list I gave is not a complete list of such tools, though. As I mentioned, there are also some commercial ones that aren’t meant for general use, and a bunch of older tools, and then some borderline things; like, you could probably count Ren’Py, the visual novel maker, as a kind of CYOA tool that just happens to have extremely rich image facilities. (But it still does variables and branching.)

      1. Ah, about + world I mean something more like Inform7 or TADS, etc. Rooms, objects, etc. For example, I’ve used ChoiceScript but it has not rooms or objects (when I used it).

        Thanks for the recomendations, I will cast an eye to A Colder Light.

  4. I wrote about the first Phrontisterion in 1999. I went to 3-4 of the early ones which were always interesting because Chris was there, the folks who would make the journey and it was the only ‘conference’ I’d go to where I could camp at a nearby state park. Chris used to invite folks to camp in his fields but the critters never seemed fine with this and the state park was near by. I actually physically meet Chris on the bus ride up to Crested Butte to Dana Atchley’s Digital Storytelling festival.

    Psst, wanna do a phrontisterion??
    http://www.mediajazz.com/phrontisterion/

    I think the interactive storytelling sweet spot is somewhere among Chris’ thinking, Harry Gotlieb’s ICI concept at JellyVision and old video tapes of Dana Atchley. Still sitting there and folks still swinging and missing

    1. I still think there’s more than one sweet spot. :) But what does your vision of that look like, if you want to go into more detail? Are you picturing something where the storyteller is itself modeled as a conversational agent?

  5. Exciting times… great to know that there’s so much going on.

    I don’t think that tapping commands has to be the death knell of the parser though or necessarily give rise to the kind of laborious sequence outlined by Ruber. For me, the key is taking advantage of the standardized grammar of the parser which is (I’m fairly sure) VERB or VERB + NOUN or VERB + NOUN + PREP + SECOND NOUN. Now, happily, teaching this grammar is also the key to inducting new players into the parser-experience. There can be no better way to do this than by clicking options in a series of boxes (rather than having to produce your commands out of a blue sky).

    The Dreamhold app has the right idea (and of course still allows typed commands by default) –

    http://itunes.apple.com/us/app/the-dreamhold/id517870810?mt=8

    I think that it might be even better if it had a series of boxes for the different parts of the command –

    First box – All the verbs (up to 30 per page as in the example above)
    Second box – All the nouns in scope
    Third box – All the preps
    Fourth box – All the second nouns in scope

    (Of course you can fire a command at the earlier stages so it needn’t be a long winded process).

    You could easily build the kind of complex command mentioned earlier using this – GIVE + MONEY + TO + DRIVER or PAY + DRIVER.

    As a relative newbie, I feel that the IF community sometimes has something of a competence issue – i.e. they’re overly competent! Most of you grew up on Infocom, many of you have logical programming brains etc… now in those cases, the keyboard will probably remain preferable. However, what we’re looking at here is expanding the player base and a tap ‘n’ play interface which (I definitely agree here!) can replicate the complexity of typed commands should be high on the agenda.

    1. Well my example was a little excessive, but it was to make a point.

      About interfaces for building phrases, there are some out there, but not all applies well to all kind of devices. For example, that building could be too slow in something like Kindle, or any device of e-ink. So that’s why a classic hyperlink interface (CYOA) is desirable, but nowadays with more power than traditional game-books.

      Here is a link to a youtube video of a Spanish adventure in 1990. This is something I’ve already shown here, at Emily’s home, however, you will enjoy this. It is in Spanish, but it does not matter, the interface explain itself perfectly:

      I must say this interface rocks, it worked, and work today pretty well, it is relatively fast. But again, this could not work for any device, so this is why we discuss any alternative to the parser. It is not a question that the parser is obsolete, is a question of ergonomics, some devices does not tolerate the parser very much.

      Me myself, I prefer right now hyperlinks with complete actions. Because to build phrases seems like a little puzzler to me, something that alienate me outside of the story. And because right now I only play IF on my Kindle, so any other interface than hyperlinks is just too slow for enjoy.

  6. I don’t see parsed IF ceasing to be a niche product with a small dedicated audience.

    I certainly wouldn’t go so far as to predict a bold future of wealth and success for IF, but I think that there’s the potential for a much larger audience, particularly with the growing numbers of tablet and smartphone owners doing more and more reading on their devices. Of course, you’ve done research on the matter, so it may be a bit naive of me to say so, but even the parser doesn’t strike me as the obstacle it’s sometimes treated as. Acclimatization is the issue, and I still hold out hope that new players can be better and more fluidly acclimated by the way opening scenes are written. More and more, it seems, that’s involved adding direction in the form of prefatory or tutorial style meta text, but I’m not convinced that’s the best way to handle it. What’s needed is the IF equivalent of the opening seconds of Super Mario Bros. World 1:1.

    What has changed is simply this: I have more access to more different tools now.

    And maybe one of the more promising horizons for IF involves integrating those tools. The parser is good at eliciting a certain kind of interaction. It is, for one thing, more free form than a CYOA prompt, and requires the player to really consider the element at hand and how they might interact. But not every moment in every IF game really requires that sort of interaction. It may be that future games will be better served by alternating between prompts, such that the player is only required to write their own actions during those turns where doing so will really add to the meaningfulness of their actions.

  7. The design challenge of make puzzles “cyoa style viable”, is a really interesting one. Despite what I said about puzzles in CYOA with the coachman example, think about the grand puzzle in Spider and Web. Ironically, that puzzle, one of the most grand eurekas in IF history, can be implemented in any interface that it will always work great. Because it uses the interface of a device that is already know by the player, and because that, it will be always at display in any game interface, call it icons, buttons, contextual, parser or cyoa.

    This inspire me greater confidence in alternative methods for IF to the parser (again, as we are discussing, for new devices).

    1. Oy, you think that’s an an example of *easy* puzzle translation? I agree it can *potentially* be implemented in *many* sorts of interfaces, but getting it to work will always be a headache! You more or less wind up designing the whole game around it.

      I have thought about _S&W_ variants quite a bit, starting with Jason Shiga’s proposal for doing it as a (real paper) CYOA book. (See http://eblong.com/zarf/zweb/tangle/shiga.html .) He had a plan for making the puzzle work — the old “turn to page N+100 at any time to take a special action” trick. But it’s not at all obvious that this would be *practical*, for a full implementation of the game.

      More recently, hm, well, I won’t get into details but I can imagine graphical, non-parser implementations of the story. Getting the interface right is a huge challenge.

      1. The thing with Spider & Web is to build the simulation of all devices. To create a proper interface for the devices. Then, that puzzle would fit smoothly.

        I could imagine an interface where you get access to the inventory and then to any device, and the game would produce a menu for the interaction for the device.

        You see, indeed your devices could be implemented in any format of IF, or videogame, or graphic adventure. Now we have a parser,… but wait.. ah! aaahrg! Indeed it is a huge challenge, I forgot the lego brick nature of the devices! Then I discard CYOA for _S&W_, forget what I said before.

        Better port it only to pads and mobiles, with a graphical interface for inventory, with a hold and drag interface…. nah, that would not work either, because you cannot drag the completed assortment of devices into the text… I mean, you cannot interact easily from a graphic inventory to a textual environment :(

        Ultimately, you need an interface for building phrases, it is the only option if you want to maintain the whole game in text, or build the game as a point and click graphic adventure, or shooter in 3D :) (this last is the optimal medium for your story)

        Jokes apart, before I mean about the nature of the eureka. That is easy to produce in any kind of interface. But because the complete devices simulationism, but that… that… that’s another story.

        All that said, I can’t imagine any way to do _S&W_ in a traditional CYOA, it seems an impossible task to me. Maybe simplifying the devices? Maybe giving the reader all devices, build up for use? So I can’t think how Jason and you would accomplish that.

        Apart of that: great mock up!

  8. Hey Emily, one more question about tools. What tool allows to export to epub or mobi, in the form of CYOA?

    Regards,

    1. I don’t know for certain that any do. Varytale and inklewriter are both running in a browser, from a particular site. I know inkle studios sometimes builds epubs, but Frankenstein was a stand-alone app and to the best of my knowledge there’s no way to take an inklewriter project you construct and move it off the inkle site. Undum works via javascript and is quite open-ended; I don’t think there’s a tool for converting it. The Choice of Games people have some way of getting their books to run on various tablets, but those also look like standalone apps to me. And I’ve never heard anything about BloomEngine having or planning to have an ebook export.

      If this is something that matters to you, I think your best bets would be to contact the ChoiceScript people and/or Jon Ingold, and ask whether they currently support that kind of export or have plans to do so.

      1. There’s no necessity to ask, Jon explain everything quite clear and gives us his tool for use at his wordpress site:
        http://threeedgedsword.wordpress.com/the-kindliser/

        Although by the name it appears to be only for Kindle, in reality it produces an HTML game book, and with a external tool (mobipocket), it can be exported to mobi, so, exported to android/iphones/ereaders. Isn’t great?

      2. The Kindliser is cool, but it’s not a method for publishing inklewriter content, and as far as I can tell from a quick look it’s considerably more limited on the type of tracking data it allows the author to retain, which might be frustrating. That’s still cool if you can accomplish your vision with just a few boolean variables, but it’s a considerably more constrained environment than the tools I was talking about above.

      3. Oh yes, but, I want to prototype a pair of things, so, right now I prefer more to have a book, than an app. Regards.

Leave a comment