Platforms for writing Interactive Fiction: Ink, ChoiceScript, Inform, Tads (Code Critique)

markcmarino · January 2020

There are so many great languages for writing interactive fiction. I wanted to start a thread for discussing the merits of these languages. Let's use this thread to compare them.

Would it be useful to compare features? Or compare passages of code that create the same effects? Also, I wonder if we should narrow this thread to the first two, since at least Inform 7 is quite different.

Perhaps we could begin with this question? Which is your favorite language (or favorite aspect of a language) for authoring interactive fiction and why?

JoeyJones · January 2020

I wonder if it would be fruitful to compare the Cloak of Darkness examples, as they exist for most authoring systems and they all have ostensibly the same output.

I like writing in Inform7, as the output is human-readable. I've found myself using it to create randomised x generators because of the excellent built-in tools for randomising different text snippets.

When writing choice-based stuff, I'm most fluent in using choicescript, which has the benefit of being quick to write stuff in and has good debugging tools. I find twine comparatively more cumbersome, though the output looks nicer and it has good built-in tools for different tricks you can perform with hyperlinks.

francesvanscoy · January 2020

I was intrigued by the new languages/systems of ABL, Versu, Comme il faut, but they have all seemed to have vanished for various reasons. Are there similar languages available for use?

jeremydouglass · January 2020

@JoeyJones said:
I wonder if it would be fruitful to compare the Cloak of Darkness examples, as they exist for most authoring systems and they all have ostensibly the same output.

This does seem like a good idea. For me that kind of comparative code studies tends to focus my attention on moments of adaptation / translation and on the relative affordances of different languages / engines -- for authoring, or for runtime.

@francesvanscoy said:
I was intrigued by the new languages/systems of ABL, Versu, Comme il faut, but they have all seemed to have vanished for various reasons. Are there similar languages available for use?

"Comme il faut" was the engine for Prom Week, I believe. These research systems are sometimes not put into production at all, just written about, but that one was, so it should be available. You could try asking Aaron Reed if he has it and would share it, or contacting the lab at UCSC.

I'm not too familiar with Versu, but this article claims that the designers got the rights back from Second Life / Linden Labs, and their site is still up at https://versu.com/ -- so you could try asking Emily Short about it.

JoeyJones · January 2020

@jeremydouglass said:
This does seem like a good idea. For me that kind of comparative code studies tends to focus my attention on moments of adaptation / translation and on the relative affordances of different languages / engines -- for authoring, or for runtime.

Here's the first few lines of Cloak in Darkness, where the initial room is created, its description given, and exits defined, along with a message blocking off traveling north.

Inform 7

Foyer of the Opera House is a room.  "You are standing in a spacious hall,
splendidly decorated in red and gold, with glittering chandeliers overhead.
The entrance from the street is to the north, and there are doorways south and west."

Instead of going north in the Foyer, say "You've only just arrived, and besides,
the weather outside seems to be getting worse."

ALAN

The foyer Isa location
  Name 'Foyer of the Opera House'

  Description
    "You are standing in a spacious hall, splendidly decorated in red and
     gold, with glittering chandeliers overhead. The entrance from the
     street is to the north, and there are doorways south and west."

Exit south To bar
    Does
      If cloak In hero Then
        Locate hero At dark_bar.
      Else
        Locate hero At bar.
      End If.
  End Exit.

  Exit west To cloakroom.

  Exit north To foyer
    Check
      "You've only just arrived, and besides, the weather outside seems to
       be getting worse."
  End Exit.

End The foyer.

TADS

startroom: room
  sdesc = "Foyer of the Opera House"
  ldesc = "You are standing in a spacious hall, splendidly decorated in red
           and gold, with glittering chandeliers overhead. The entrance from
           the street is to the north, and there are doorways south and west."
  south = bar
  west = cloakroom
  north =
  {
    "You've only just arrived, and besides, the weather outside
     seems to be getting worse. ";
    return nil;
  }

Hugo

room foyer "Foyer of the Opera House"
{
    long_desc
    {
       "You are standing in a spacious hall, splendidly decorated in red
        and gold, with glittering chandeliers overhead. The entrance from
        the street is to the north, and there are doorways south and west."
    }    
    s_to  bar
    w_to  cloakroom
    n_to
    {
       "You've only just arrived, and besides, the weather outside
        seems to be getting worse."
    }
    is light
}

I've read a lot about to what extent the possibility of a naturally readable output in Inform7 is a desirable feature, but I haven't seen often expressed what is surely it's most salient feature: for the bulk of code in an interactive fiction (defining locations and objects and giving them descriptions), Inform7 is capable of being much more succinct than other languages. In the above example, it expresses in three lines what TADS does in six. It does this by compacting a lot of meaning into each sentence. For instance, the reason exits aren't listed in the code snippet above is because they're folded into the sentences which introduce new rooms elsewhere in the code. The line The Cloakroom is west of the Foyer. both creates an exit west from the Foyer, it also defines a new room into existence. This would have to be at least two lines in other languages.

aplotkin · January 2020

Not just defining and describing objects! I7 is good at expressing the kind of operation which is common in parser-based games:

now all metallic things held by the player are on the magnet;
now everything on the magnet is magnetized;

You've just visualized that whole scene and maybe the puzzle that it's part of, haven't you?

Now, I qualified that with "parser-based". The two lines above embody a bunch of assumptions that are built into Inform. The world consists of objects with properties and locations. "X held by Y" and "X on Y" are relations that define location. ("Metallic" and "magnetized" are not built into Inform; they'd be defined by the author for a particular game.)

Choice-based games may not have those assumptions at all, so it's harder to compare Ink, Twine, and Choicescript to the other languages mentioned in this thread. There are Cloak of Darkness samples for those languages, but they don't tell you all that much.

The whole point of CoD was to compare the experience of building parser games in different languages. It made sense because Inform, TADS, Hugo, and Alan were all made by Infocom fans trying to produce "more games like Zork"! So the game produced by each CoD sample was essentially identical in play to all the others -- or if it wasn't, it indicated a deficiency of the language.

(That is: Twine can't produce a game which plays like the CoD standard, but that's not a deficiency; it's a completely different focus for what the system is trying to do.)

aplotkin · January 2020

That said, I'm really interested in comparing Ink and ChoiceScript. That's because I've never used either of them beyond reading the manual.

Just as with parser-game dev tools in the mid-90s, there's now a surge of people designing choice-game dev tools. (I see one was just announced on the intfiction forum today!) I'm sure there's even more happening behind the scenes at various game studios, as developers wing up one-off proprietary systems. Ink and ChoiceScript are just the cases where studios (Inkle and ChoiceOfGames) decided to open-source their tools.

It would be great if this resolved into an industry standard, but that will require more years of banging on the tools.

markcmarino · February 2020

ChoiceScript and Ink are worth comparing as they are both light-weight scripting languages that look like markdown and can become quite complex in the right hands. One way to compare these languages is by comparing what their documentation foregrounds. Both languages feature a system of choice and flow to the results of those choices, but the ChoiceScript manual seems to foreground variables while the Ink foregrounds word replacement.

In my mind, ChoiceScript (and consequently games in ChoiceScript) are epitomized by assigning variables (or "stats," as the manual calls them). I would argue these stats are extremely important in and fundamental to the world of ChoiceScript games. Here I'll draw some code from the ChoiceScript basic documentation.:

 *create leadership 20
 *set leadership 30

"Note that *create is only allowed to appear at the top of startup.txt. You can use *set anywhere you like. For example:"

What do you prefer?
*choice
  #Leadership
    *set leadership +10
    *goto action
  #Strength
    *set strength +10

"Once a variable has been set, you can check the value of the variable like this:"

  #Run for class president
    *if leadership > 15
      You win the election.
      *finish
    You lose the election.
    *finish

The key features of ChoiceScript in my mind is set. This might be an overly deterministic reading (reading into the code what the way I view the effects), but notice how changing variables does not involve an equals sign and checking variables in conditions does not require parenthesis or curly braces.

Setting variables in Ink looks more like this:

               ~ strength = strength +10

Not a huge difference. The equals sign, repeating the variable to increment or decrement is not all that much -- though over tens of thousands of lines of code, every character counts. More significantly, notice how changing variables is in the Advanced logic section of Ink documentation.

By contrast, what epitomizes Ink to me is word replacement. Here are four kinds of word replacement form the Ink documentation:

Word replacement that moves through the variations and stops at the last "One!"
The radio hissed into life. {"Three!"|"Two!"|"One!"|There was the white noise racket of an explosion.

Word replacement that loops through the variations each time you see the text, so that the variation after the last ("Sunday") is the first ("Monday").
It was {&Monday|Tuesday|Wednesday|Thursday|Friday|Saturday|Sunday} today.

Word replacement that disappears after the last one has been seen.
He told me a joke. {!I laughed politely.|I smiled.|I grimaced.|I promised myself to not react again.}

Word replacement that is randomized each time you see it.
I tossed the coin. {~Heads|Tails}.

I don't see word replacement (other than through variables) in the basic ChoiceScript documentation (though I am sure it is possible). But again, note how its makers frame this as a basic aspect of the language and have attempted to facilitate it. This word replacement aspect is what attracted me to Ink in the first place. After using Ink for a bit to make a game (called Salt Immortal Sea), I found myself returning to Undum, a JavaScript-based system and trying to get it to do all of that word swapping. I certainly, missed the ease of Ink then!

Again, without being overly deterministic, I suspect that these basic attributes of the languages permeate throughout games made from them, especially since new authors will rely so heavily on the documentation. Just like new BASIC users who had just bought their Commodore 64 learned from a little program known to us as 10 PRINT, new IF authors are starting with the demo code in the documentation and their first impression of the language gets framed by what is highlighted there.

What do you all think?

aplotkin · February 2020

There's also the question of how the "choice and flow" is structured -- what facilities exist to support more complex game structures.

Again, my reading of the docs is hasty, but Ink has several abstractions (knot/stitch, gather/weave/nested-weave) which look richer than ChoiceScript's (scenes, goto, gosub). And certainly the Ink games I've played are way more complex than the CS games. But I haven't played recent CS games; I don't know what they look like when the author pushes the boundaries (as Heaven's Vault pushed the boundaries of Ink).

jeremydouglass · February 2020

Just for reference, here is a link to Roger Firth's Cloak of Darkness page with the specification that helps the examples serve as a kind of Hello World / Rosetta Stone.

The question of ChoiceScript / ink having their own idioms -- and thus needing their own tests / Rosetta stones -- recalls an early test by Dan Fabulich posted on intfiction.org:

Dan Fabulich, Oct 2012:
I did a quickie implementation of Cloak of Darkness in ChoiceScript at one point; IMO it was a very awkward translation. It failed in its core task of demonstrating the similarities and differences between parser-based languages and choice-based languages. IMO the parser-based tools are all helping the author build roughly the same kind of game, stories with exploratory puzzles, of which Cloak of Darkness is a reasonable example. Choice-based games often include no puzzles at all, and are usually tightly plotted, with no opportunity for free exploration (except on subsequent replays).

This Jason McIntosh post from 2018 also seems relevant:

Jason McIntosh, iftechfoundatioin.org 2018:
Having established this matrix, we the IFTF accessibility testing team would then prepare an original work of IF that would exercise the accessibility features of its platform. This, admittedly, is me rolling in a new idea, but I humbly report it’s based on y’all’s conversation so far. I envision this game as similar to “Cloak of Darkness” (http://www.firthworks.com/roger/cloak/), except tuned for accessibility: to get to the end of the (very short!) game, the player must interact with the game in a variety of ways, including ways that might present an unintended challenge to players with disabilities.

For example, one “puzzle” might involve opening a lock by looking at an image of a note and typing in a code found in that image. The game will include “alt text” for that image, and it’s up to the play platform to display it correctly, and under the correct conditions. Similarly, there may be a puzzle that involves ASCII artwork, or listening to an audio clip, and so on.

There are some joys in cross-media and cross-platform comparison, of course -- even (and perhaps especially) when the two platforms share few features, but are attempting to express the "same" thing. It tends to celebrate what things do differently -- so a ChoiceScript COD might actually not involve the same events, actions, or puzzle design to better express the "same" mysterious operatic vignette in a ChoiceScript-y way. For me that kind of cross-comparison recalls working on "Benchmark Fiction"[¹] with Christy Dena and Mark Marino back in the pre-CCS days.

Douglass, J., M. Marino and C. Dena. 2005. "Benchmark Fiction: A Framework for Comparative New Media Studies." In Proceedings of the 6th Digital Arts and Culture Conference (DAC 2005), pp. 89-98. Copenhagen, December 1-3. ↩︎

dcuartielles · February 2020

This might be a little off-topic, but last week I taught an interactive fiction class at Malmo University. Considering I had 40 students and just one week, I went for Twine, which as you know is a VPL rendering a choice-based HTML5 experience. Considering I worked with students with previous JS knowledge, it was pretty great relying on Twine for the students to focus on the narrative and adding some nice effects on top later.

As a base for the exercise I gave the students the following short story I published last year:

https://thisismold.com/process/manufacture/the-rise-of-the-autotrophs#.Xjiq2llKicw

The experience consisted in dividing the class in two groups aka "company1" and "company2" that operated as design studios having to produce a narrative fiction piece in the same universe as the short story, including 4 levels. You can see the results after just 4 days of programming here:

http://cuartielles.com/courses/k3/pi2020/

If I had gone for a more textual-based approach, I have the feeling (and I insist, this is just a feeling) that it would have been a lot harder to achieve the same level of result given the timeframe. On the other hand Twine and its HTML5 rendering approach allows for a certain degree of code-intervention after the rendering, or even creation of your own story template.

Making a parser-centric text-based game requires a different approach than the one here described.

danfabu · February 2020

Hi! I'm Dan Fabulich, cofounder of Choice of Games and author of ChoiceScript.

IMO, the three most important differences between Ink and ChoiceScript are platform support, language richness, and how they handle updating stats over time.

Platform Support: Ink was designed to plug into an external game engine, especially Unity. ChoiceScript was designed with the web in mind; even the native apps that Choice of Games provides are basically just fancy webviews.

Language Richness: Ink includes a bunch of language features that will be familiar to programmers; ChoiceScript basically has goto, gosub, goto_scene and gosub_scene. This makes sense, because Ink is intended to be used/consumed by someone with the technical chops to integrate it with a game engine. ChoiceScript is intended to be used by total novices to coding.

Updating Stats: Ink and ChoiceScript games use a technique that we call "delayed branching." https://www.choiceofgames.com/2011/07/by-the-numbers-how-to-write-a-long-interactive-novel-that-doesnt-suck/

In delayed branching, we summarize the results of a bunch of earlier choices in numeric scores ("stats"). The stats might be ability scores (strength, dexterity, charisma), personality scores (anxiety, happiness, confidence), etc. Later on in the game, you can say "if charisma is high, then X, else Y."

When you delay branching with stats, you can (collectively) honor the previous choices that the player made, without tracking each individual decision the player makes. It's like a democracy, where the player's earlier decisions are "voting" for what happens later in the story.

ChoiceScript uses a system called "FairMath" to track high/low stats, like this: "*set leadership %+ 20". %+ 20 doesn't increase leadership by 20 points, but some fraction of 20. If leadership is very high, then %+ 20 will have little/no effect; if leadership is low, then %+ 20 will add nearly 20 full points. FairMath ensures that stats always remain between 1-100 points.

Ink doesn't provide a way of doing this, and it's normally not used. Instead, Ink games will typically just write "~ leadership++" and add a point to leadership. On occasion, they'll write something like:

~ leadership_options++

Pick leadership!
~ leadership++
You picked leadership.
Pick strength!
You picked strength.

And then later you can check whether "leadership / leadership_options > 0.5", i.e. whether the player picked leadership more than half of the time.

Using averages like this makes the player's leadership score less sensitive over time; as you've made a bunch of leadership decisions over the course of the game, near the end, the stat is mostly locked in, resistant to change. FairMath does exactly the opposite, allowing a player with low leadership to gain lots and lots of leadership right at the end of the game (because it's easy to raise a low stat).

Of course, you could write a function in Ink to do FairMath, but I've never heard of anybody trying it.

JoeyJones · February 2020

For anyone interested in comparing the code, I've written up a short example game identically in both Ink and Choicescript. Apologies for any errors.

Here it is in Choicescript.
And here it is in Ink.

Some more key differences perhaps not covered by Dan above:

Ink allows you to test whether a passage was seen, as each passage label can be tested later. This is an elegant way of avoiding a profusion of flags.
While choices can be nested in Ink, I ran into trouble trying to nest choices and set passage labels within the nests. I don't know if I was just doing it wrong, but the IDE gave an error and so I resorted to (what is probably best practice) of splitting up my choice bodies. Everything can be as nested as you like in Choicescript.
Ink has an IDE. Choicescript I believe has a third party one, but I've never used it.

In most of the core capacities, they're more or less identical and even the ways of phrasing conditionals are similar. @{options 1|2|3} is very similar to {options: 1|2|3}.

markcmarino · February 2020

@danfabu Thank you and all for joining us here. I would be interested going forward to reflect on how the FairMath features in Choicescript along with its other affordances lead to certain kinds of interactive narratives -- and to do the same with Ink. Not to suggest the language is totally deterministic but that affordances in a language lead authors in particular directions, I suspect.

Howdy, Stranger!

Categories

In this Discussion

Platforms for writing Interactive Fiction: Ink, ChoiceScript, Inform, Tads (Code Critique)

Comments