Advanced graphics for Inform 7

Here are mockups of two other Kerkerkruip characters. The overall arrangement is a minor variation on the mockups in the previous post. I have moved the character name–which is always set in the same font used to render the character itself–to the right column; this provides more space for the illustration. These mockups also incorporate the character’s written description, which I’ve just pulled straight from the game.

First up, the chain golem. I’m not completely happy with how the illustration itself turned out–I need to figure something else out for the hair especially–but I do like the many different ways that chains and their entanglements are portrayed, from straightforward to pretty abstract.

Mockup of Chain Golem

And second, Miranda with her (Shaolin) monk’s robe and nunchucks. I picture her as kind of a girlish Grace Jones, which I think comes through fairly well in the illustration. (The pose, of course, is classic Bruce Lee.) I decided not to try to make her look like a typical cartoon woman–think exaggerated secondary sexual characteristics–which may actually not have been the wisest choice. Finally, I’m not sure that the topknot adds anything, but I’ve had some feedback that it does, so there it is.

Mockup for Miranda

Update: Here’s a second version of Miranda, with some tweaks to make her a bit slighter. She does look more “feminine” now, but I hope still a bit androgynous.

I have begun my first Glimmr project (aside from the extensions themselves, of course): I am working on an animated title sequence for Kerkerkruip, Victor Gijsbers’s excellent interactive fiction roguelike. Kerkerkruip has recently moved into a new, open phase of development, with the source code on github and design input being actively solicited, so this is a good time for other folks to get involved as well!

Since this blog has been silent for a time’s-stitch of months, it is probably worth contextualizing a bit. Kerkerkruip is written in Inform 7, a system for writing text adventures. I have written a suite of extensions for the system that allows users to realize something close to the full potential of Inform 7′s otherwise barely-there support for graphics. Those extensions are collectively known as Glimmr. You can explore Glimmr in more detail through other posts on this blog; in particular, there are a number of posts on its animation capabilities.

So, the plan for the title sequence is pretty simple: First, we show the Kerkerkruip cover art. Then, because Kerkerkruip is primarily a game of tactical combat vs. interesting enemies–including a golem made of chains, a bouncing exploding ball of flesh, and a telepathic slug–we present a rogue’s gallery of the characters that the player has engaged with.

I have chosen to “draw” these character portraits using a kind of typographic collage, using only letterforms to render lines, volumes, patterns, etc. I’m posting drafts of them to Pinterest as they’re completed. There are a couple of more finished examples later in the post; I am also linking to a few of my touchstones for the style used. (You might think of the form as a lower-resolution version of the examples of “typewriter art” that have hit the web lately.) This approach seems an appropriate nod to both interactive fiction and to roguelikes, the former because of its emphasis on text–of course–and the latter for their association with individual ASCII symbols to represent game entities. At the same time, this sort of typographic collage doesn’t fall afoul of the “retro” sandtrap (as straight-up ASCII art likely would). Finally–and critically!–the technique shifts the execution from a problem of draftsmanship to one of design. That’s a place I feel a lot more comfortable.

The sequence is still in the planning stage. Here is the current breakdown:

  1. Fade in on the Kerkerkruip cover art and let it hover a moment.
  2. Cross-fade to a typographically collaged version of the cover art’s cell bars, then zoom forward, through the bars, to show the game’s main menu options.
  3. At any time after we arrive at the main menu, the player may make a selection from the menu to continue. The main menu itself may have some very minor (read: eye candy) movement.
  4. Once the main menu is in view, the rogue’s gallery will begin animating alongside, flipping at a leisurely pace through the enemies that the player has faced one by one. A few statistics summarizing the player’s encounters with each enemy will be displayed next to it.
  5. The gallery loops until the player makes a menu selection, at which point the menu fades out and the screen selected appears.

Here are a couple of mockups of entries from the rogue’s gallery, featuring the giant tentacle and the reaper, a serial killer who dresses up like Death:

 

 

 

The visual metaphor is of a stack of placards, which we’re shown one at a time; they are intended to vaguely resemble character cards in a game like Yomi or Magic: The Gathering. The statistics to be shown are not final; we’ll need to see what’s feasible/desirable to keep track of. If there aren’t enough different statistics, information about the character itself could be used.

Thoughts/comments on the plan or the mockups are welcome!

Jon Ingold of inkle has released a new game, called A Colder Light, that I recommend highly as a short, satisfying quest with a fun central mechanic.

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.

A Colder Light

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.

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.

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.

Title page for the demo

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

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.

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.

Follow

Get every new post delivered to your Inbox.