Emily Short recently wrote a post about what reasons there are for writing a parser game in AD 2017. In the comments, I added:

For me there’s another reason to make parser games, and specifically for using Inform 7: It’s a fantastic platform for experimental games. if I just have an idea that I want to explore or play around with, as long as it’s narrative and turn-based, I’m very likely to reach for I7 as a tool.

Using I7 cuts away 90% of the boilerplate labor associated with game development: You don’t have to think about or make UI (it’s text input), UX (it’s bad), assets (there are none). You write almost no boilerplate code; everything you write is doing work in defining mechanics, narrative, or environment. I really think more game designers should learn I7 because of its value in that role; even if the thing you make using it isn’t the final form of what you’re making. The 0 to 60 on it is just incredible compared to any other engine or game development tool.

Inform 7, if you’re unfamiliar, is a system for writing parser interactive fiction that uses a purpose-built domain-specific language that somewhat resembles natural English. It’s probably my favourite game development environment to work on, for a lot of reasons.

I believe Inform 7 is uniquely suited to a particular class of game prototyping, and there are two things to point out about this:

  1. If you’re a game developer, there’s a good chance knowing Inform 7 would be a helpful tool to have.
  2. If you’re working on a game development tool, Inform 7 is a good case study for how to build a system that’s good to prototype on.

Also, to be clear, by “prototyping” I really also mean building experimental games and generally any sort of rapid-fire game development. And there are some new technical developments in the Inform 7 ecosystem (more about this at the end of this article) that make it more feasible to use I7 for things like jam games and altgames.

Prototyping in I7

Now, what makes Inform 7 so good at this task is exactly the fact that it’s a specialist tool; it’s built to work on a very specific type of game. This means that not every idea can be prototyped well in I7; but ideas that are within the domain of what I7 does well can be built and played with very quickly.

What I7 does well:

  1. Narrative games;
  2. That are turn-based at least lack real-time/action-based interactions;
  3. And, to a lesser extent, that generally fit the point of view and scale of an adventure game.

Traditionally, this has been used to develop puzzle-oriented adventure games in the vein of Zork, or story-driven, puzzleless descendants of those. But the actual breadth of the tool is significantly wider than that.

The main thing that makes Inform 7 so great as a language for prototyping is the fact that it has a built-in world model that includes some useful assumptions (mainly, about time and spatiality). It’s also a declarative, rule-based language that makes it very easy to think in terms of things, rules, and behaviors and write code that represents those.

In typical game development, you think of a game mechanic then you write an algorithm using a traditional language (such as JavaScript, C#, or Lua) that “performs” at being that game mechanic. In Inform 7, you write things that are much more direct descriptions of game mechanics, almost like you’re writing the rules booklet of a tabletop game.

For example, let’s say we’re trying out a mechanic where the player has an audio recorder, and they go around recording sounds in different places which they can play back for NPCs to elicit different responses. There are two approaches to doing this kind of thing: You could write a big table of NPCs versus sounds, and then automatically fill it out with defaults for pairings that aren’t interesting; but this doesn’t give you the flexibility of building in ad-hoc rules for special situations. What if an NPC should respond to a given sound not just by saying something but by changing the game state in some way? You then need to build the whole system to support everything like that, and you end up with a data structure like this:

"birdSong": {
  "location": "garden",
  "reactions": {    
    "jerry": {
      response: "Ah, yes, the noise of the blue-chested tit.",
      effects: [
        {
          effect: "increment",
          id: "jerryLove",
          offset: 1
        },
      ],
    },
    "martha": {
      response: "Ugh, I hate birds.",
      // We either need a pointless void here, or special case handling code
      effects: []
    }
  }
}

Alternatively, you hardcode everything and end up with a bowl of spaghetti. In Inform 7, this looks more like:

Table of Noises
noise         location
Birdsong      the garden
[And so on]

Table of Reactions
person  noise     reaction
Jerry   Birdsong  "Ah, yes, the noise of the blue-chested tit."
Martha  Birdsong  "Ugh, I hate birds."
[And so on]

Carry out playing back birdsong in the presence of Jerry:
  increment Jerry's love.

This isn’t so much a matter of shorter code as it is a matter of better-structured code. But beyond that, Inform 7 spares us a lot of trouble in building structures to use that data. It has a built-in understanding of actors (ie, the player) performing actions that affect a world model. It’s very easy to go back and add wrinkles to the system or mess around with behaviors, for example:

Carry out playing back birdsong:
  say "The blue-chested tit flies into [the location].";
  move the blue-chested tit to the location.

Building Systems for Prototyping

The key thing here is that Inform 7 is built around rules and behaviors, not algorithms and data structures. It’s designed around the building blocks of gameplay. In this, it stands virtually alone in a desert where almost all game development is done using general-purpose languages that are descendants of systems that implemented business logic for enterprise applications. Native Android games are written in Java, a language so enterprisey that you’re now wearing khaki just from hearing me mention it. Unity favors Microsoft’s improved Java clone, C#. Other game engines often use Lua, a language developed originally for automation in offshore oil platforms (no, really). Most AAA development is done by working with C++, a fate that I wouldn’t wish on my worst enemy; web games are developed in JavaScript, a horrible fate that I have consigned myself to.

Inform 7 is, above all else, delightful to use, at least once you understand it well enough.

Inform 7 is built on top of a giant pile of assumptions. Those assumptions sprout from a particular tradition of game design, of course, but they’re strong ones that end up being broader than they seem: The point of view is a player that moves across discrete but amorphous “rooms;” objects can be carried by this point of view character and manipulated in various ways; time moves along in turns; players act through discrete “actions” that are resolved using rule-based behavior, and events are essentially “batched” as sets of rules that are either triggered by player action or happen independently every turn. Those assumptions all can be discarded or subverted as needed, but they’re there if you want to use them.

A really important consequence of this design is that the speed of getting off the ground with I7 is extremely fast. The I7 IDE itself is a much faster and more lightweight application than a typical game engine or development environment. Ultimately, it does matter that it saves you writing any kind of boilerplate code or implementing anything that isn’t specific to what you want to prototype, test, or experiment with right there.

And a significant development in this now is the new Vorple for Glulx extensions to Inform 7, which allow for I7 games that use a hypertext interface instead of the traditional parser one. That makes it possible to make prototypes and experiments with a UI suited to them, and it makes the tool useful not only for lone experimentation but for building things that can be shared to get feedback on a mechanic or idea before building it up into something bigger.