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 anice sense of how a parser-based game with a hyperlink UI can differ from a CYOA-style game with a hyperlink UI.

A Colder Light

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.

[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.

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 reimagines the art for Deadline, using a noir-flavored photo by Flickr user emdot

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.

The original box art for Infocom's Deadline (1982)

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.

Download Animated Title Page, or the source code and assets. Comments welcome.

The "Scourge of the Vampyr" demo

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 Glimmr Canvas Animation

Screenshot of the "Eased Movements" demo. Movement simulated (poorly).

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.

The player's avatar, headed east toward adventure (click for full screenshot)

This demo introduces a few more of the animation presets that are built into Glimmr Canvas Animation (more on GCA). First is the reel animation, which is the familiar flipbook-style swapping out of images to suggest change or movement. The Scourge of the Vampyr demo uses a simple four-image walk cycle to depict the player’s avatar moving from room to room.

Of course, there’s also the familiar motion preset, showcased in both Demos 1 & 2, which actually moves the sprite that represents the PC over the map. However, it’s deployed with a twist here: most of the time, the window framing is centered on the avatar, so the map appears to move while the character walks in place (ah, relativity!)

The demo also employs some other effects. If you look very closely as the character enters the crypt via the stairs, you will notice that the sprite increases in scale as it nears the bottom of the stairs, from 75% to 100% over 4 animation frames. The staircase is only a single 16 x 16 pixel tile, so the effect is subtle–look carefully!

Much less subtly, there’s are some fairly old school lighting effects when you light your lamp in the darkened room on the far right side of the map. This combines two other presets not seen in previous demos, the flicker preset and the fade preset. Basically, we “stack” these two animations together to create a single effect: we fade the room in, while randomly flickering the room out of sight entirely. (The fade effect, with a bit of easing, can be seen by itself by turning off the lamp again in the same room.)

A quick note on the images, all of which are CC-licensed: The sprite animations for the avatar, as well as most of the tiles used to construct the map, come from Sean Howard’s Free Pixel Project. The sarcophagus tile comes from David Gervais.

The Inform 7 source code for the demo can be found in the documentation section (still a stub) of the Glimmr Canvas Animation extension, available here for the time being.

Download Demo 3: The Scourge of the Vampyr. Comments welcome.

For this installment of the demo series, we delve deeper into the facilities that Glimmr Canvas Animation provides for dynamic tweening. Briefly, “tweening” is short for “in-betweening”. In traditional animation, animations were organized around key frames–the critical points in any sequence. These keyframes were drawn first, and then the “betweens” were filled in to connect those key moments smoothly; because they were less critical, they were often filled in by the lower ranks of the animation team. In computer animation, keyframes are defined by the user, and the tweening is done automatically by the software.

Glimmr Canvas Animation (GCA) is no different, though it doesn’t really use the concept of the keyframe. Where programs like Flash have a master timeline punctuated by user-defined keyframes, each GCA animation track can be thought of as a self-contained timeline separating two keyframes–the starting and ending points of that particular motion or effect. GCA builds sophisticated and customizable tweening into all of the preset animation types via the use of “easing” equations that interpolate movement between the starting and ending points.

Easing equations

The term “easing” refers to motions in which the acceleration changes over time. The term may seem strange, but think of it in terms of easing into a chair–your body moves more slowly as you approach the cushion. Easing equations can imitate this sort of gradual slowing as the motion reaches the endpoint, and they can also do much more, such as imitate the bouncing of a ball, or overshoot the endpoint and snap back.

Three terms are used to describe all of the equations provided in GCA. “Easing out” describes a sequence in which motion starts out moving rapidly and then slows, more or less gradually, to a stop. “Easing in” is the opposite–slow to fast. “Easing in-out” combines the two effects. Different functions can be used to qualify these three basic categories: “quadratic easing in” for example, or “circular easing out”.

Easing equations can be employed very flexibly. In fact, I’m using the word “motion” only because it is convenient. In fact, easing equations can be used on any continuous field of values, not just coordinates in space. For example, the first demo in the series employed easing when zooming the size of images. Instead of proceeding from 50% of actual size to 100% by equal intervals, the zoom was “eased” using a cubic ease-out equation that starts out rapid, increases slightly in speed for the first 1/2 or so of the duration, and then slows comparatively rapidly. Combined with a purely linear diagonal movement of the image toward the center of the window, this eased zooming provides a gentle impression of arcing movement (go ahead, try the first demo again to see this).

With GCA, all of the preset animation types allow you to apply easing with a single setting, such as “the easing of the movement track is cubic easing out”. This includes not only movement and zooming tracks, but also fader tracks (changes in opacity), and even reel animations (i.e., sequences of images). If you set the duration of a reel animation to more or less frames than there are images in the sequence, GCA will use the track’s easing to scale the images available to the number of frames required.

GCA has 16 easing equations built in, from purely linear to a quadratic curve to a parabolic bounce. If you’re not satisfied with these, you can also add your own equations.

There is no need to understand or use the mathematics of easing to use GCA (unless you want to add your own equations), but an example, and particularly a graph of the function, couldn’t hurt. Here is the cubic “easing out” equation and a plot:

(The four parameters listed at the bottom are used as the inputs to every easing equation. Once an equation is set up, the only variable that changes is t, which in GCA is the number of the current frame of the animation track.)

The departures from linearity in the plot–that is, from an imagined straight diagonal line running from the origin in the lower left to the upper right–describe the changing velocity of the motion.

The demo

Finally we get to the demo: Eased Movement, as its name implies, showcases eased movement in Glimmr Canvas Animation. The demo is actually a visualization tool as much as it is a demonstration, in that it is designed to show the effect of any combination of easing equations on movement.

Wait, a combination of easing equations? Yes. GCA allows you to specify independent easing equations for each axis of movement, horizontal (x) and vertical (y). This opens up a host of new possibilities, because the application of differential accelerations produces different paths of movement, not just varying speeds.

Screenshot of the demo. Motion trail is simulated (poorly).

Once you’ve downloaded the demo, try the following to see the different concepts we’ve been talking about in motion (minor pun intended):

• Before you do anything else, click anywhere in the central black area to the move the ball. This is plain old linear movement. Dull!
• Now, select a different (not linear) easing for the x-axis by clicking on the easing type in the left column. Then select the same easing type in the right column. Finally, click in the central area to move the ball to that point. It should move in a straight line, but the acceleration patterns of the motion should conform to the easing selected.
• Now, move the ball to the lower left corner of the central area. Click on the linear easing link in the left column to reset the x-axis. Leave the y-axis set to whatever nonlinear easing you’ve been messing with. Finally, click to move the ball to the upper-right corner of the central area. Notice that the path of the ball matches the shape of the graph displayed in the right column. This is a nice, simple demonstration of the operation of differential easing.
• Finally, set the easing for the x-axis to a nonlinear setting that’s different from the y-axis easing, and move the ball in diagonal lines. Try a few different combinations and note the variety of paths you can get.

Enjoy!

Download the demo game here. To view the demo, you will need a Glulx interpreter, such as Windows Git or Zoom (see links at right). Note that this demo will not work in Gargoyle, nor in Spatterlight. If you’re a diehard Gargoyle aficionado, drop me a line; I can send you a test build in which the hyperlink bug is fixed.

Almost exactly four years ago, I released my first “work” in Inform 7, a pre-Glimmr extension to enable very simple and primitive animations. Graphical Window Animation hasn’t worked with any Inform build newer than 5Z71; with Glimmr well underway, I saw GWA–limited to just one graphics window and (effectively) one image–as a dead end and didn’t bother to continue maintaining it.

Instead, I set my eyes on eventually capping the Glimmr suite with a powerful animation library that would move well beyond the simple flip book approach taken by Graphical Window Animation. I dithered for a long while, thinking that before I put the extension together, I’d like to have a sophisticated system of virtual timers running behind it (Glulx has only a single timer, but you could theoretically track things in such a way as to imitate any number of separate timers firing events independently). I didn’t have a whole lot of interest in creating that system, though, so I just let things languish.

But I’m happy to say that Glimmr animation’s moment has now arrived. Glimmr Canvas Animation, 10,000 words of Inform code, is complete. As I try to work myself up to writing the documentation, I thought I’d preview the code demos here on the blog. This will make for a bit of a drawn-out release, but maybe it’ll entice someone to help me write the documentation (a task I always dread)! In the meantime, the demos should be fun.

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 you can build up very complex animations using them. To display a rolling ball, for example, you might have:

By moving the sprite a few pixels each frame for 12 frames, while cycling through a simple flip book-style animation “reel” depicting slightly different images of the ball, we give the impression that the ball is rolling across the screen. In Glimmr Canvas Animation code, this would look like this:

animate the roll track as a motion animation targeting the ball and ending at {300, 100} at 24 fps with duration of 12 frames;
animate the spin track as a reel animation targeting the ball at 24 fps with duration of 12 frames, cycling.

GCA includes a number of presets like this that make even complex animations a matter of one or two lines of code, including motion, reel, zooming, flickering, and more. Presets can be applied to any of the display properties that Glimmr provides, and there is support for tweening using a number of different easing equations (authors can also add their own). You can also create completely custom animations that do whatever you like.

The Demo

Let’s move on to the good stuff. For this first demo, I’ve chosen to highlight user interface animation. The game presents four thumbnail versions of the map illustrations from Dell Map-Back murder mysteries in a grid. Click on any one of them to see it enlarged; we use two animation tracks, scaling the image to full size (using an easing effect) while moving it to the center of the window. Click the cover again to return it to the original thumbnail size and location; the return movement is independent of the enlargement, and uses another two tracks. In fact, if while you have one cover enlarged and you click on another, all four tracks will fire simultaneously, so that one cover will zoom out while the other zooms in.

All of this UI behavior is handled in a single short “carry out” rule. Type SOURCE CODE in the demo file to see the rule.

Hope you enjoy the demo. The second in the series should be along in a week or so.

Download the demo file.

Demo game file
Source code (extensively commented)

Glulx games don’t yet have access to the system clock (though this is in progress), but of course an analog clock in an IF game will most often need to show game time rather than real-world time. Inform 7 tracks game time very simply by default–1 turn equals 1 minute–but this can be customized, and there are extensions to help. This analog clock demo, though, doesn’t change anything in Inform’s default handling. Instead, it overlays real-time on top of game time; in other words, each turn takes one minute, unless you spend one minute thinking about, in which case 2 minutes will pass. This probably isn’t a solution that would be appropriate for most games, but it’s convenient for demonstration purposes!

Why does the clock look like it’s from the early 1990s? Well, Glimmr draws lines by coloring each pixel individually. This can be slow enough as it (depending on a variety of factors), and I haven’t attempted to incorporate antialiasing to soften the edges of the lines. Once support for Glulx floating point math is added to Inform, I may experiment to see whether antialiased line-drawing is feasible. Until then, the only way to get nice, smooth lines will be to use individual images for each tick of each hand of the clock (Glulx doesn’t support dynamic rotation of PNG images). For a clock like this one, this would require at least 180 individual PNG images: 60 for each hand, all the way around the dial; optimally, though, the hour hand should have even more, since there ought to be 30 hour-hand positions (one for each integer degree) between each numeral on the dial. Building a clock out of 181 images is certainly doable, and on the programming side it’s not very hard. But unless you have a method of automating the process of creating the images in the first place, that part sounds to me like an exercise in crushing boredom…

Creating the Clock

While the basic drawing commands are implemented, as mentioned above, in the Drawing Commands extension, the window-managing Glimmr Canvas-Based Drawing extension does not have a corresponding graphic element to handle angle+distance lines. Graphic elements (g-elements) are objects that control drawing to a graphics window: specify a few properties for the element (such as the coordinates where it should be drawn), and it will be automatically scaled to fit and drawn to the window. So, the first order of business was to create a type of g-element that would have all the properties of lines (such as line-weight and color), but also have an angle and a length that could be specified. This required just a few lines of code; see the source code for the demo to see how it was done (link above).

Once this new “ray primitive” type was defined, the next step was to define three rays, one for each hand; differing lengths, line-weights, and colors serve to distinguish the hands from one another, like so:

Table of Hands

The clock face base image

Note the display-layer property: elements on lower layers are drawn first, so this indicates that the hour and minute hands are drawn on layer 2, with the second hand superimposed on them (layer 3). Layer 1 is the clock face itself, which is simply defined by a PNG image, since it doesn’t need to change. (I made it without antialiasing so that it would match the look of the hands.)

The elements will be displayed with these parameters in the window whenever it is redrawn without any further work from the author. To update the clock is thus pretty simple: we just need to set each hand to the appropriate angle for the time we need to display. Each digit on the clock is separated by 30 degrees (360° ÷ 12 digits = 30°), and each minute/second is separated by 6° (360° ÷ 60). Knowing this, it’s not difficult to write a routine to update the hands:

To update clock:
    let H be the hours part of the time of day;
    let M be the minutes part of the time of day;
    if H > 12, let H be H - 12;
    let Hh be H * 30;
    let Hh be Hh + (M / 2);
    let Mh be M * 6;
    now the angle of the hour hand is Hh;
    now the angle of the minute hand is Mh;
    now the angle of the second hand is seconds passed * 6;
    follow the window-drawing rules for the graphics-window.

Note that we advance the hour hand in 1° increments, roughly once every two minutes, to reflect the hour hand’s geared relationship to the movement of the minute hand.

Finally, because Inform’s implementation of the time of day doesn’t include seconds, we need to advance the “seconds passed” variable used above according to a 1 second (1000 millisecond) timer. For each tick of the timer, we increment the seconds count, and when it moves above 60, reset it to 1 while also advancing the time of day by one minute. To see the sweep second hand moving we also need to update the clock every second. This routine runs every time the timer ticks and takes care of all of these:

Glulx timed activity rule (this is the seconds increment rule):
	increment seconds passed;
	if seconds passed > 60:
		now the time of day is the time of day + 1 minute;
		now seconds passed is 1;
		update the status line;
	update clock.

And that’s really all there is to it. One thing that might be of interest is that, in the demo, the clock’s hands are both objects in the world and graphic elements; the player can see and refer to them even though their primary purpose is to bundle properties for drawing. The demo also implements a few commands for messing around with the clock. Please see the demo’s source code for all of the details (linked at the top of the post).

NOTE: The demo game file is a gblorb file. To play it, you will need a Glulx interpreter, such as Gargoyle, Windows Glulxe, or Zoom (see links at right). Mac users: a long-standing bug in Zoom screws up the colors; Gargoyle is preferred.