Advanced graphics for Inform 7

Archive for the ‘Experiments’ Category

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…

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.


Get every new post delivered to your Inbox.