A Colder Light is also a descendant of the hyperlink-only web interface that was elaborated in prototypes here, here, and here. I beta-tested the game and I think that, in addition to being a good game, it provides a nice sense of how a parser-based game with a hyperlink UI can differ from a CYOA-style game with a hyperlink UI.
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.
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.
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!
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.
Download the demo game here. To play the demo, you will need the latest version of your favorite Glulx interpreter, such as Gargoyle, Windows Git, or Zoom (see links at right). Users of the Spatterlight interpreter are advised to upgrade to Gargoyle.
To date, the demos that I’ve released for Glimmr Canvas Animation have been either simple visualizations, or have gestured at nonstandard interfaces that have not really been seen in parser IF before. Which naturally raises the question: what can animation do for the vast majority of text games–the ones that are just text? This new demo, Animated Title Page, is one answer to that question.
In recent years, there have been some developments in the way that IF games present themselves at start-up (and before), including the increased use of cover art, largely thanks to Emily Short’s cover art drive from a couple of years back, and the growing popularity of “title pages” (see, e.g. Make It Good, or Jon Ingold’s plug-and-play I7 extension). This Animated Title Page demo continues this trend. In contrast to most IF, which opens with nothing more than a couple of paragraphs of text and the famous blinking cursor, Animated Title Page suppresses the main text window in favor of a graphical presentation, showcasing the cover art along with a list of basic options, such as starting a new game or continuing a saved one.
The demo, which pretends to be the classic Infocom game Deadline, also prefaces the title page with a fun and overly dramatic animated rendering of the original game’s marketing tagline: “A locked room. A dead man. And twelve hours to solve the murder.” This text rushes out at the player, making a whooshing soundas it rockets by. There are also fade-ins and fade-outs, animated button depresses, and other effects.
It is worth noting that, despite the dynamic animations, the demo is actually quite simple from the standpoint of art creation. The art consists entirely of rasterized slugs of type (made using the font Dirty Headline by S. John Ross of Cumberland Games), and of a single photo (sitting by emdot). These elements are animated together using commands provided by the Glimmr Canvas Animation extension. Similar designs should be well within the capabilities of most authors. The source code for the demo is available at the link below, should you want to try to modify it for your own purposes.
The demo is substantially complete, but there are a few more refinements that could be implemented. It would be nice, for example, to be able to skip the animations entirely to fade in directly on the title screen; it’s probably a bit much to have to watch even 20 seconds or so of introductory animation every time that you open the game. More radically: Nearly all other modern games, from casual to triple-A, employ an automated system of save slots so that the player never has to interact directly with the filesystem to manage her saved games. Such a feature would be easy enough to build into a Glulx project, and of course save slots would be a natural fit for a graphic interface like the one presented here.
If you are interested in the extended set of Glulx features (graphics, hyperlinks, etc.), be sure to grab the newly released versions of Gargoyle (Windows, OS X, Linux) and/or Zoom (OS X). These lay to rest long-standing bugs as well as make available some of the latest additions to the Glulx standard, such as floating point support and some refinements to sound capabilities.
Glimmr Canvas Animation–previewed here, here, and here–has been released and is available for download at Google Code. (The extension can also be downloaded from the Inform site, though without the image assets needed to compile the examples.)
What is Glimmr Canvas Animation? Glimmr Canvas Animation sits on top of Glimmr Canvas-Based Drawing and allows for graphic elements of any type to be animated. GCA is built on the concept of the animation track. An animation track handles one kind of animation effect for one graphic element, but tracks are stackable, so it’s possible build up quite complex animations. GCA allows for flipbook-style animation of sprites or background images, for dynamically scaling graphic elements, for (limited) fade-ins and fade-outs, and much more. All of these preset animation types can be invoked in just one or two lines of code, or tweaked and customized with as much additional logic as you like. GCA supports 15 different equations for the automated “easing/tweening” of animations to make them more natural or more interesting. The extension includes a robust debugging log, as well as a number example code demos (see screenshots in this post).
There have been a number of new features added to Glimmr Canvas Animation since it was first previewed. The most notable of these is the introduction of “virtual timers,” which allows multiple concurrent animations to run at different speeds. The beta version of GCA required all animations to run at the same speed, so this should allow for more flexibility.
I hope you’ll check out GCA!
Download the demo game here. To play the demo, you will need a Glulx interpreter, such as Gargoyle, Windows Git, or Zoom (see links at right). Users of the Spatterlight interpreter are advised to upgrade to Gargoyle.
For Scourge of the Vampyr, the third installment of the Glimmr Canvas Animation demo series, I’ve finally prepared an example where the connection to familiar IF game mechanics is clear. Unlike Demo 1 (a UI mockup), or Demo 2 (a visualizer for eased movement), Demo 3 shows us a graphical map of a familiar adventure terrain–the crypt of a vampire, to be precise–using animation to provide movement and effects. Read the rest of this entry »