Advanced graphics for Inform 7

Posts tagged ‘experiments’

Sand-Dancer Sans Keyboard: Take Two

I have put up a second version of the hyperlink-based demo, responding to Jon Ingold’s suggestion (here). This version streamlines the input model so that only clicking on a button will issue a command. Clicking on a link no longer automatically issues the examine command; instead, it merely brings focus to the object clicked. There is now an button for examining in the object-focus window, which is how we issue the examine command.

Try the second version.

Update: A third version, implementing Jon Ingold’s suggestion that links not show until hovered over, as well as putting the description for objects in the focus window. The latter is actually my original implementation (rejected pre-release); it both presents the object description w/o the need for an additional mouse-click, and avoids the visual confusion of updating two windows at once.

I don’t feel that showing links only on hover works very well, at least when they “light up” individually: it’s pretty annoying to hunt and peck links in this way. It might work better if hovering anywhere on a paragraph showed all of the links in that paragraph. Unfortunately, the latter can’t be done with CSS, so I won’t be mocking it up here. (Hovering doesn’t work in a touch interface, so it doesn’t really fit the goals of this experiment as I originally defined them in any case.)

Try version 3.

Sand-Dancer Sans Keyboard: An Experiment with Hyperlink Input in IF

I have recently been very interested in what parser IF (that’s text-based “interactive fiction”) might look like in the “post-PC” world brought of mobile computing. What do we do with a game whose core interface is typing, when we’re operating on devices where keyboards, while available, are less convenient and much less central to interaction than on desktop machines? Given the fact that the form factors of smartphones and tablets are encouraging users to explore new forms of interacting with text–as well as to rediscover pretty much unreconstructed older ones–now is an ideal time to consider how we might refashion the interface for parser IF.

[Updating the IF interface more generally has in fact been a topic of interest in recent years, even without any particular reference to mobile computing: The experience of most users has drifted very far from the command-line interface where most IF remains mired, and there has been a recognition that expanding interest in the form will very likely require changes to the interface. For some of the most salient work, see here, here, and here.]

The present experiment is a simple conversion of Sand-Dancer, Aaron Reed and Alexei Othenin-Girard’s example game from Reed’s excellent book Creating Interactive Fiction with Inform 7–thanks to Aaron for his generous permission to use it here! As such, it is a full work of parser IF. However, the player can use links and buttons to play the game through without typing anything at all. (Actually, I haven’t played the experiment all the way through to see whether I’ve accounted for every section of the game. It’s quite possible that I haven’t–but in principle the interface would allow most standard games to be played all the way through without resorting to the keyboard.) You can play the experimental demo here, using the Quixe interpreter. It will look best on a WebKit browser (e.g., Chrome or Safari) and god knows what it will look like on Explorer. Unfortunately, the browser interpreter is a bit slow; perhaps ironically, it’s too slow to play on a mobile device!

Screenshot of an early moment in the experimental demo.

The window is divided into multiple panes, each presenting a different type of information. In the main window, where the story’s text unfolds, the only interactive elements are hyperlinked objects. Similarly, the player’s inventory is shown off to the lower right, where the linked objects are always available. Click on any link in either of these windows, and the selected object will be highlighted in the upper right window, where its description will be followed by a series of buttons that describe actions that can be done with, or are related to, the object. At the bottom of the screen is another set of buttons representing the player’s navigation options, and above these is a narrow area where commands can be typed if the player wants or needs to enter free-form text. Buttons and links alike are implemented as Glulx hyperlinks–they are merely styled differently using CSS with the web interpreter.

For the most part, the entire overlay is procedurally generated. Aaron used the “Get BENT” system that he discusses in Creating Interactive Fiction with Inform 7 throughout Sand-Dancer, and that means that it is easy to use Inform’s “rule for printing the name of” activity to wrap the names of all important objects in links. After a link is clicked, we use object properties (along with a few special-case items) to generate the buttons in the object window (e.g., if the object is a closed container, provide the choice to open it). We also use the built-in conversation suggestions to generate the options for conversation with NPCs and to display them in the same window. This is relatively straightforward, and I had to make only a few minor changes to Sand-Dancer itself to get the thing working.

Interfaces like this one have a clear benefit where players new to IF are concerned. Possibly they will be easier to navigate than the standard interface, but whether or not that is true, the presentation of full commands in buttons provides a mechanism for teaching the basic command grammar. Over time, clicking on buttons like “examine the letter”, “press the red button”, “ask the lawyer about copyright law” and so on will teach not only those individual commands, but the overall gestalt of the parser interface. Presumably this would lower the bar to playing unadorned parser IF.

As to the more focused question of whether the interface demo’ed here is a productive direction, I leave that to you. (I’m still too close to the micro-choices I’ve been making to evaluate the experience as a whole.) Please give it a shot and let me know in the comments how you found the experience. Even better, if you hold sway over someone with little IF experience, see what they think. (My wife says it solves most of the problems she has with IF–barring the map–but that’s just one data point!)

Final note: There are plenty of technical weaknesses in the implementation of the overlay interface, including both missing features and some bugs as well. For this reason, I am not releasing the source code as I normally would–I don’t want anyone to use this particular code as the basis for their own project.

Try the demo.

IF Gameplay Experiment: Experiential Movement

Interactive fiction’s basic spatial model, with its emphasis on discrete container-spaces, more or less does away with theexperience of travel. The player zips instantaneously between rooms, and while this works pretty well in most indoor spaces, there can be a certain sense of loss, especially when the “room” represents a wide field, a vast hall, or a long street. The character of these spaces depends in large part on the ways in which we move through them–the sense of space & distance, passing time, shifting vistas & perspective, and the people, plants, and things we might interact with while we’re advancing. IF’s instamovement sucks this experiential element out of travel, and thus robs IF authors of a powerful tool for presenting fictional worlds.

I’ve been thinking about ways to bring the experience of travel into IF, and particularly of how to do so with minimal changes to existing conventions. The experiment I’m posting today makes no change at all to the underlying spatial model: There are three rooms, each representing a segment of street in an imaginary city. When the player types walk to <a location>, however, the game doesn’t move him on immediately. Instead, short messages are meted out in real time, describing the changing space, people met on the street, etc. After a few of these messages are displayed, the player is moved into the next room, and another set of messages appropriate to that room are displayed. The process continues until the player arrives at the destination. Click here to play through the example.

As a technique, I think it works reasonably well; I hope that the rather dull text of the example doesn’t detract too much. Though I’ve presented the example using only text, it would work nicely using a graphical map that indicated the real-time steps through animation; a moving dot or icon, for example (this isn’t quite as difficult as it might sound!) Of course, there are potentially a number of  things that would need to be further worked out or refined, depending on how you wanted to use this in an actual game. How to deal with randomized environmental messages, for example, or NPC movement…

New Releases: Glimmr Form Fields and Glulx Input Loops

UPDATE 11/3/2011: Glimmr Form Fields is now available in release 3 of the full Glimmr release zip archive, as well as at the Inform 7 extensions library.

I’ve finally come to the end of a rather quixotic quest. A strange bug bit me while I was finishing up the main Glimmr package a few months back: I wanted to leverage Glimmr’s capabilities to create a relatively easy way for authors to offer HTML-style form fields within an IF game. Why on earth did I want to do that? Not for any good reason; in fact, I still haven’t come up with a practical IF-related use for it that would justify the hours it eventually took from me! Other than perhaps to remake Bureaucracy (see image below for a form from that game).

Screenshot of color picker

A simple RGB color calculator made with Glimmr Form Fields

In the end, I had to create two extensions to accomplish this goal: Glimmr Form Fields and Glulx Input Loops. (If you’re curious about the form fields, you can download compiled example games here; this will let you see how it works without firing up Inform 7, installing dependencies–of which there are many–etc. See the note about interpreters below.) A short discussion of how the one led to the other follows.

The basic mechanics for graphic form fields were easy and I was able to put a prototype together in just a few hours. I had good, general-purpose yet customizable ways to control text entry into the field, the backspace key, moving the cursor within the field, and so on. This rested (and still rests) on a couple of subterfuges: First, of course, the “text” in the form fields is not actually text but individual letterform graphics strung together to form words. Second, one doesn’t type really anything “into” the text fields; instead, we are receiving per-character input in the main text window and converting that for display in the graphics window.

Pre-HTML form fields from Infocom's Bureaucracy, by Douglas Adams (screenshot by Moby Games user Belboz)

It was the latter that caused me real headaches. Not because it was difficult to create something basic, but because I wanted the user (player) to be able to interact with multiple fields, clicking on one to type and then clicking on another to enter text there. Inform’s built-in input routines are very simply structured, and this turned out to be a sticky problem: Multiple fields easily led to nested loops that would quickly crash the program, or lead to other difficulties.

So, I had to make a bit of detour, and get an education in the finer points of Glulx input and Inform 7‘s (and Inform 6’s) implementation of input (special thanks to Zarf, the creator of Glulx, for his help–and patience). In the end, I decided to more or less rewrite the library input routines. Without going into great detail, the Glulx Input Loops extension gives the author many more hooks for decision-making within the overall “loop” of input to action-processing. It also introduces named input loops, as well as the idea of the “secondary” input loop, which shares input-handling with the “primary” loop; this goes a good way toward preventing the kinds of nasty nesting problems that can result when some types of input spawn new requests for input.

A diagram of primary vs secondary input loops

A (perhaps somewhat cryptic to the uninitiated) flowchart showing the relationship between primary and secondary input loops as defined in the Glulx Input Loops extension.

The new hooks provided by Glulx Input Loops let me complete Glimmr Form Fields as I wanted, avoiding the issues with event nesting. Glulx Input Loops also resulted in the keystroke input experiment I posted a month or so back. I hope that it proves to be a useful extension, and I think it will, particularly to those experimenting with alternate input paradigms.

I’m still asking myself why I dedicated myself to implementing form fields, though. The end result is pretty neat, but its neatness is not really IF-related… Who knows, maybe someone will think of something to do with it; the tool is there, at least. In the meantime, if you have your any ideas for using Glimmr Form Fields in IF, please feel free to leave a comment below–I’d love to hear that someone might actually get some use out of it!

A note for Mac users who might want to check out the Glimmr Form Fields compiled examples: If you are using a Mac, you probably default to using Zoom or Spatterlight as your interpreter of choice. Neither is a good fit for Glimmr, however. The current version of Zoom ( has a few bugs that impact heavily on Glimmr games, while Spatterlight is too old to have taken advantage of recent advances in speed (or bugfixes). Please consider downloading Gargoyle instead. (Gargoyle is also recommended for Linux and Windows users, though the latter have the option of Windows Glulxe/Windows Git.)

A minimalist exercise with Glimmr Form Fields, showing just one field.

A minimal implementation of Glimmr Form Fields.

An Experiment with Keystroke Input in IF

While working on another project, I found that I really needed much more control over Inform’s input loops. I put together an extension to solve the problem, Glulx Input Loops. While the primary impetus for GIL was rather arcane, the final extension also allows for the game’s primary input loop to accept any type of input in place of “line input” (the standard typed text input familiar in interactive fiction). For example, if you want your game to be played entirely with hyperlinks—no typing at all—you could make that change by writing, essentially, a single line (you’d also have to include one of the numerous extensions that implement hyperlink input).

Anyway, while contemplating what kind of example code I could include with this extension, I thought about the way that Nethack has you chain together single keystroke inputs to build commands. For example, to eat something, you key in “e” for “eat”, followed by another letter for the edible inventory item you’re keen on. I wondered whether something similar might work for interactive fiction, and so I threw together a quick experiment to explore the question.

The result is a bit underimplemented—you can only enter, at most, VERB + NOUN inputs—and there quite a few issues are left hanging that any full-scale game would need to address, such as how to provide contextual lists of items, how to allow the player to refer to things outside her immediate environs, how to handle conversation, and so on. Still, it at least gives a good sense of how this kind of thing could work. You can play the example online, browse the source, or download a gblorb for use on your favorite desktop interpreter here:

Under Doom (An Interactive Experiment)

Reflection: I’m not sure whether this fills any real need. A similar interface that used hyperlinks would be more practical for mobile devices, for example, and for most of us working on a full-size computer, typing a full word isn’t really a whole lot less work than hitting a single key. Comments welcome.