Dreaming of a white fish Inform XMAS

It was Jean Baudrillard who postulated that we'd all end up speaking in ironic quotes in the hyperreality he also postulated. I think he also coined the phrase 'hyperirony', but Google isn't confirming that point right now, and the ace essay I wrote about this during my degree is both twenty years old and not located in the house in which I'm typing this post on an iPad+bluetooth keyboard combo.

I'm weary in life of being spoken to in ironic quotes I don't understand, but of course when I do it to others (minus the 'not understanding' part) I expect I'm doing it well. I choose source material judiciously, not from obscure hipster cartoons screening on pay TV in another country, for instance.

Often I choose to quote The Simpsons, as they have covered almost everything, and usually done it better and funnier than others. So, my general XMAS message is:

"Have a – nice Christmas!
Have a – nice Christmas!
Have a – nice Christmas!
Non-Christian friend"

PS I am irreligious.

---

In Inform-dom, we have been gifted a new version of Inform. It's 6M62:

http://www.intfiction.org/forum/viewtopic.php?f=7&t=19449

I like these letters, 6M62. They look bold and ground-touching. Not like my least favourite letters of late, '6L02', who looked veritably frail and consumptive.

---

In my own Inform-dom, I am well advanced in progress on my CYOA extension. There's still lots to do, though. More coding, making examples, some testing. But the work goes on. This is no vaporware.

Occasionally I speculate on the 'you need an interpreter' paradigm of most parser-based games that grew out of the modern community. Sometimes it feels like it just shifted the obligation to update software so that it keeps working from one group of people to another. That's a simplistic summation, but in the current situation, I don't think I ever worked out if anyone has a particular idea about where the emphases of compatibility should be. The core idea that the games are just words and that users should be able to control the appearance of the words is a good one, except for the million exceptions including graphics, sounds, and various UIs that authors want to use. And being an author and not being able to control stuff can be maddening. So even when the onus is left on the interpreter to be kept up to date (and not your game), from an author's perspective, you may end up with multiple versions of your game where one thing is broken in each one depending on where/how the user plays it, or where it never looks the way you'd really like it to.

That sounds a bit dispiriting, an effect enhanced by me writing it in a dispiriting fashion. But it's not like this is a new situation. Plus, this is XMAS! So get confident, stupid! The reason I vexed on these points a little here is as a prelude to pointing out how I'm going in almost the opposite direction of my traditional design impulses (which are author-biased and pro specificsim) in my choice-based extension. It harkens back to the 'the game is just the words' idea. The author links the word(s) to a choice or, uh, link, but the player can receive these any way they want. If you (THE PLAYER) want hyperlinks for your touch device or for clicking on with a mouse, you can have them. If you want letters of keys you could press, you can have them. You can also have both. So the approach is intended as a bit fire-and-forget for the author. Stop programming interfaces and just put your content in, and expect it to work on desktops, mobiles and in screen readers.

Now, one of the eternal vetters of ideas at intfiction.org, Peter Piers, said 'What if the author wants to override something? eg block hyperlinks, or keypresses, or whatever.' Certainly it remains that there are ways to do this, but as work on this extension has continued, I've realised which basket it's throwing its eggs into more forcefully, and that is the 'let the player control the interface' basket. The controls are simple and plugged into the game by the extension, so it's an extremely far cry from having to hack Gargoyle's template to force it to print in your particular favoured shade of ectoplasm green :(

So! This extension has a design emphasis about how it's going to do things. I think it's a good one for this project.

ANDROMEDA 1983

Marco Innocenti has just released ANDROMEDA 1983, an 80s'n'8-bit-styled fun-emphasising remake of his first Andromeda game, Andromeda Awakening from IFComp 2011. It's as if Andromeda Awakening had been released in 1983 for the Commodore 64, Apple II and ZX Spectrum as an adventure game with graphics and music. I produced the looping SID chippy soundtrack for the game.

1983 ain't heavy. As Marco said on intficiton.org,

"DISCLAIMER: this is not REALLY intended as a REAL GAME. It's 50% a joke and 50% nostalgia. You, Constant Readers, will tell me where do you fall. It's pretty short, it won't kill your time too much...

PS: Don't expect anything easy or polite to the player. What's actually there, trying and helping the player, was made by the Inform people and it's still there because it was too much struggle to remove. Honestly, it is a feeling I wanted to replicate, and that feeling had no synonyms, most of the time."

As a fan of the original game, I got an extra kick out of 1983, but play-wise it can stand on its own. It obviously wasn't worth trying to reproduce all the complexities of the original game in this format, so it's become a new, simpler game using some of the same basic story, locations and ingredients.

As a grizzled Apple II and Commodore 64 veteran, what really bowled me over when Marco first showed me this were the graphics. It's a very specific aesthetic he's recreated incorporating both the colour palette of the Commodore 64 and some of the pixel-dithering tricks used to produce textures on the considerably less colourful Apple II screen – as if the game's creators had indeed tried to port the game's graphics as consistently as they could across these different 8-bit machines.

Inform 7 news: Wade Clarke's new Menus and Basic Help Menu now available in the public library

After much file-wrangling by the Inform extensions file-wrangler, Mark Musante, for which I am grateful, two new versions of extensions of mine have debuted in the Inform 7 public library this week. They are Menus version 4 and Basic Help Menu version 3.

• If you're using Mac OS X, the extensions are available from the public library section in the Inform 7 application. With your internet turned on, click the Extensions tab at the lower right of your window, then the Public Library tab in the top right corner. The extensions are in section 11.2 - 'Out of World Actions and Effects' - 'Helping and Hinting'.)

• If you're using another platform, visit the rough'n'ready for-now folder equivalent of the public library online: http://www.emshort.com/pl/payloads/

About Menus 4

As previously advertised, my Menus is a significant update of Emily Short's old/classic Menus with a lot of additional features which make it more modern and flexible. I consider the most important of these to be:

1. Single keypress operation – no need to scroll a cursor about, and
2. Has a screen reader mode for screen reader-compatibility

These features alone make a menu system powered by this extension far more accessible to anyone playing on a mobile device or using a screen reader. In this light, I strongly recommend that folks wanting to add menus to any new Inform 6L38 project build it with my Menus extension rather than the old Menus.

By the way, I should point out I'm not obliviously shaving skin off Emily Short's nose. I discussed the state of the menus extensions with both her and Inform code maestro Dannii Willis, and we've all been looking at ways forward. My Menus extension doesn't have exactly the same API (Application-Programming Interface) as Emily's, so it's for the sake of compatibility with old projects that the old Menus remains in the public library rather than being replaced by mine. Also, Dannii has plans to revamp Emily's extension in such a way that it will have some of the features of mine but will also retain Emily's API for backwards compatibility. If that comes about, that may be the extension which replaces Emily's in the library.

Basically, my extension is ready to go now, addresses some accessibility issues, has some cool and powerful extra features and has already been through three iterations of polishing and bug-removal.

If you're wondering why I changed the API in my extension, I had to to support some more of its advanced features, like the book mode with automatic pagination.

About Basic Help Menu 3

This extension is the equivalent of Emily's old Basic Help Menu, just recoded for compatibility with my own Menus and with the help information updated to reflect the times in which we live. It adds a Basic Help Menu to your project which contains some how-to-play parser IF info.

IFComp 2015 review: Taghairm by Chandler Groover

All the mini-reviews of the Twine game Taghairm have been like this: 'Taghairm – it's the game for people who don't like cats!'

Well, I hadn't played Taghairm yet, I hadn't even met it, but I was starting to develop a manic pissed-off response to this repeated consumer advice. Don't tell me I can't enter into some fiction, presumably about maiming cats, just because I like cats!

After the teenaged part of my brain stuck its middle finger up at all those reviews, I went off to play Taghairm.

An all-spoiler review follows, and incidentally, it contains no user help about what a 'Taghairm' even is. I'm guessing enough other reviewers will have covered that by now.

Work in progress: CYOA Framework for Glulx

I've broken off my IFComp game-reviewing streak to take advantage of time and motivation opportunities to work on a new extension for Inform 7. It's called 'CYOA Framework for Glulx' and its goal is to help folks produce hyperlink/keypress-driven CYOAs in Inform. I want the results to be author and player-friendly, flexible and easy to publish online.

By coming off the back of Inform the extension also supports a lot of cool things that aren't always handled well by other CYOA producing systems: Proper UNDO, transcripting, game-saving (by named files with a save dialogue, or by a single-keypress quicksave slot; the author can decide which) and, if you want it, the full world model. But I'm also putting in a switch so you can turn the world model OFF. This way you can just connect nodes of prose to each other with choices if that's what you need.

With previously available tools, it's been difficult to stop Inform 7 running everything through its 'press RETURN' parser. As an author, that's exactly the thing I don't want it doing when I'm trying to collect and react to discrete keypresses or clicked choices. My way to get around this in the past worked okay, but was super-hacky, and certainly couldn't support the world model, genuine UNDOs, genuine time management or non-manually managed game saves. I should point out I have nothing against super-hackiness per se if it gets the job done for an individual, but if you're making a tool for other people to use, super-hackiness is neither portable nor user-friendly.

The background on why I'm making this extension now:

Before knuckling down to work on my planned big parser game set in the Andromeda universe (click this for my blog post about that) I felt I wanted to get another smaller IF out. I decided it would be a CYOA, because even a small parser IF takes me ages.

As I discussed my super-hack approach to making an Inform 7 CYOA over on intfiction.org, Andrew Plotkin mentioned that he'd made an experimental extension called 'Unified Glulx Input' which might be able to help with this project. I tried it and it really did. Then climbingstars chimed in with some extra UNDO help I needed.

After programming away at my extension for the past week, I've just shared a minor tech demo of the work in progress on intfiction. I have a thread open to get feedback on it (the first post has links to the demo). I'll report back on future progress with the extension in this blog.

* I've only released one thing with my previous super-hacky method, an Apple II CYOA game I ported to Inform 7 and put inside Leadlight Gamma as an easter egg. What's interesting about that one is that it also fakes some BASIC line numbers. Each node is identified by its original BASIC program line number from Applesoft.

IFComp 2015 review: The Insect Massacre by Tom Delanoy

The Insect Massacre is a Twine hyperlinks game about which it's possible to expose little more than the blurb does if one is to avoid specific spoilerdom. That blurb is:

"A short murder mystery set aboard a space station."

The title is explained in a neat way which I will also not explain here. Actually, this review will be only non-significant-spoiler by my standards, so there is no text hidden behind a cut.

I found the game's mystery intriguing. The events of the story are concrete enough to provoke speculation, but blurry enough around the edges so as to ward off absolute explanation. Multiple plays are required to investigate multiple angles. Each session requires little time.

The game's aesthetic delivery was beguiling on the first playthrough, if a bit confusing in terms of indicating who was speaking in each scene. The speech is effected with colour-coded names matched to coloured lines of text. My proper gripe is that on the second and subsequent plays, the unskippable Twine delays, pauses and fade-ins that were enforced on material I'd already read felt pointless and tedious. Text is basically not a temporal delivery vehicle like music or film, especially text in a branching story. I don't know if Twine provides capabilities for authors to set options for this kind of thing (eg author-enforced pacing the first time material is encountered, material skippable with a mouseclick the second+ times?) but if it hasn't, it should. If it has, I hope more authors will start using it when it is appropriate to do so.

Fortunately, The Insect Massacre is short enough, even on replays, that it isn't too hurt by its eternally slowly-fading-in text. It is particularly good at making the player guess at the implications of the choices it presents, and not because the choices are at all vague, but because of carefully deployed elements of the game once again not discussed in this spoiler-minimised review. I continued to think about The Insect Massacre afterwards.

IFComp 2015 review: Pit of the Condemned by Matthew Holland

Pit of the Condemned is an Evade-The-Wumpus-like game in which you play a convict sentenced to die at the hands of The Beast. The site for your intended death is an abandoned city that's now used only to host deadly spectacles. A bloodthirsty public watches your struggles from innaccessible locations overhead.

In the paragraph above, I just summarised a mixture of information from the game's blurb and from its opening scene. And the blurb component of that info is not even fully present in the game, meaning if you didn't read the blurb, you'd never know it. Unfortunately, the above summary is about all there is to the aesthetic of Pit. None of the implications of the game's setting or vaguely Hunger Games-sounding society come up during play. It's purely about the mechanic of moving through a large network of empty rooms and searching for a weapon or escape route while the beast chases you.

Pit is a short game to play, and in its simplicity it again ('again' in the context of my reviews of this year's IFComp entries) reminds me of the BASIC games David Ahl collated in books for the then new microcomputers of the 1970s. Unlike War of the Willows, the game I made this comment about the first time around, Pit doesn't have enough additional adornment or flair to sell its universe, to make its chase vivid or exciting like it needs to be.

Further reviewage with spoilers below.

IFComp 2015 review: Pilgrimage by VÌctor Ojuel

Pilgrimage is an atypically macro-scaled parser adventure which somewhat dazzled me with one brief-prose-vivid, new and geographically far-flung location after another. It's also a game whose finishability, as in the player's ability to complete it without being severely gated by a walkthrough, I would rate as close to zero percent. But then even with the walkthrough, I wasn't able to clear the game. Pilgrimage does list several testers, so I'm going to assume that I ran into some kind of circumstantial bug rather than that the game is literally unfinishable.

Pilgrimage's PC is a Roman woman (ancient Rome) of significant alchemical learning who leaves her hometown seeking further knowledge of an existential entity known as The Great Work. She is like Carmen Sandiego in that each move she makes in one of the traditional IF compass directions tends to take her to an entirely different country.

I was very interested in Pilgrimage's play up to a point, but its macroscopic strengths also turn out to be the source of its gameplay weaknesses. Aesthetically, it's an appealing game which seems to have a lot of erudition of research behind it, and one which keeps throwing surprises in the content and in the PC's behaviour.

What feels most novel about Pilgrimage is the way it scales the world it creates. I've hardly played any parser games that place a series of huge environments (cities, countries, et al.) in a series of single locations like this one does, and when I have, those games were more interested in the map connections between the locations rather than the locations themselves. So whether by not knowing conventions or by ignoring them, Pilgrimage sports a novel style. One I'd like to steal from at some point. In this regard I'd have to recommend the game to anyone who has a history with parser games. But have the walkthrough handy.

For full reviewage with spoilers, read on.

IFComp 2015 review: Ether by Brian Rushton (but not THAT Brian Rushton)

The 'not THAT Brian Rushton' quip is a minor joke you'll get once after you've typed CREDITS in this game.

Ether is a charming parser adventure in which you play a flying nautilus that must collect and manipulate objects in a world of pristine X-Y-Z elemental axes. Air pressure varies along one axis, weather virulence along another and temperature along the third. You can move up, down, west, east, north or south, or in combinations of these directions, to fly around within the virtual cube of the gameworld.

The nautilus has positively-tinged existential concerns and enjoys doing the things it does. The game's puzzles are uncomplicated and almost arcade-gamey in some ways. Also arcade-gamey is the manner in which the nautilus can acquire various power ups as it goes along.

Considering Ether's technical polish, its environment assembled from graceful, procedurally generated prose, its general ease of play and short playtime, I find it easy to recommend it to any compgoers – except perhaps those who find themselves boggled by spatial relationship problems. Nautilus's challenges are light by the standards of such problems, and there aren't even that many of them, but I suspect that some people simply can't handle this kind of 3D thing in prose.

Further review with spoilers beyond the cut.

IFComp Thought Splatter: How/why I review

I'm writing this piece in a Mac program called Typed. It's one of those simple word processors whose goal is to minimise distractions. It has only a handful of features and no user interface; the window is just a faintly transparent square into which you type words. The program also comes with some zen ambient soundtracks, a cute feature but not one I ever use or which personally interests me.

When you open an empty Typed document, a random quote about writing from a famous writer sits on the screen until you start typing. For instance, today's quote was, "Writing is its own reward," by Henry Miller.

I'm about to write something about why and how I review things, for instance these IFComp games. (If you're an IFComp entrant and nobody's reviewed your game yet, you're probably thinking, 'Quit stalling, review boy, and get back to the bloody reviewing.')

I'm doing this because a network of blog mirrors is beginning to reflect some community conversation about the nature of IFComp and the nature of IFComp reviews.

Carolyn VanEseltine has written a good summary of why IFComp presents crossed purposes for numerous parties. And then Juhana Leinonen, or 'Junana' as I call him (* I called him that once. Twice now) chimed in on the history of criticism in the modern IF culture. I think what Carolyn wrote is all correct. If anything, I think it's even more complicated than what she wrote. However, I think only entrants need concern themselves with the complexities, and only if they're finding feedback on their game – or lack thereof – strange or annoying, or the reviewing culture weird or harsh or just confusing.

In the same way that there's a tradition of movie reviewers descending upon Cannes each year for that film festival, there's a tradition of IF fans/folks/reviewers/hangers-on descending upon their blogs to write about IFComp entries each year. For some of these folk, this will be all they put in that blog for the whole year. Then they'll pack up and go back to their rainy hometowns until the next competition. For others, this will just part of a continuum of stuff they write about IF.

Amongst both campers and yearly visitors, some just write down their gut reactions to games in the order the reactions occur. These can be all subjective and all disorganised, with no real judgements formed or passed. Just 'I like A', 'I hated B', etc. That's a valid way to come up with your scores for games in the competition, but without process or insight, it doesn't make for written criticism of any quality.

Further along the spectrum, you've got people with lots of reviewing practice, or experience, or educated critical skills, or some mix of any or all three. (I HAVE ALL THREE. YOU HEARD ME.) And still, all of these people have different personal interests and motives for reviewing. These motives are rarely or infrequently stated because everyone, most of the time, is just getting on with following their agenda, not constantly (or sometimes - ever) explaining that agenda. Hopefully the agenda will come through in the writing itself over time.

Agenda mismatch is one of the greate sources of reviewer outrage at some game, and/or entrant outrage at some reviewer's review of their game. To put my shoe back on my author's foot, the worst review I ever got was one in IFComp 2010 for Leadlight. It was written with what felt like ill-informed malice. While blowing off steam, I read more of the reviewer's reviews. I came to the conclusion that this reviewer and I were living in almost entirely different universes of concern. In turn I realised that such a person was never going to be a valid barometer of my game.

It's hard to remember such stuff when members of 'the press' seem to be befouling your work. But I did discover that if you go to the pub and read a terrible review aloud to friends over a drink, it may suddenly become high entertainment. This is a good perspective-restorer. (If you don't drink, you probably don't even need the drink, either.)

Because I'm here and talking about the subject, I will attempt to describe my IFComp reviewing agenda.

First, I like playing IF. Reviewing it doubles as a way of ordering what I think about it and recording my memories of it. I enjoy writing per se and I enjoy crafting reviews. I think I transmit a mix of personal observation, writing/programming craft and a degree of encouragement.

I definitely don't review these games with a primary goal of improving the state of all IF so that it can meet some sort of high bar that is constantly travelling away from everyone. I may do that in other contexts, but definitely not in IFComp.

This is partly because I'm aware of the zillion conflicting IFComp agendas already described. In IFComp reviews, I skew encouraging, but not with bland sugar-coating, I hope. And inevitably, as with any individual, there will be games I don't like at all.

It's also partly because of empathy for creators. I identify more with creating than criticism, though I claim to do both capably. In my case, it means I can rarely fully transform into 'the hanging judge', even at times when I would like to.

It's partly because I'm a positivist when it comes to story art. I have extremely highly tolerance for minor variations and I am attracted sometimes just to the part of something that gives it its taste, even if other elements are conventional or just not working. For instance, as a big horror fan, I've seen about 850 horror films, and I have soft spot for almost every one of them at some level. That doesn't mean I give them all 10s on IMDB – far from it. I can still score them in a ranking / semi-objective sense amongst all else I've seen while storing positive memories about elements of them. I am addicted to collecting the experience of watching horror films and films per se, and a related motivation goes into me playing a range of IF games.

The final 'it's partly because' is that it's partly because I'm aware that I have a knack for helping people to get where they're going with a creative project. I don't encourage people to make something the way I'd make it, but I concentrate on helping them to get it working along the axes that are of interest to them, or along axes I expect the creator's audience will benefit from. My IFComp reviews don't have time or interest for doing this at length (that's what playtesters are for) but I do touch on these subjects. Since this behaviour is an element of my nature, I don't go around fighting my nature in terms of the overall outlook of my IFComp reviews.

One other weird factor is that this community is sufficiently small that if you both make games and review them, other people who both make games and review games, and whose games you've reviewed, will be reviewing your games at some point. This is hardly ideal given the frequency with which it has to happen. Some people can review as if they're in a tower on the hill, and of them, some review like they live in the tower full-time, others as if they can at least move into the tower for the duration of the review. I'm crap at either in this close context. The more I interact with someone one-on-one, the less useful I am at reviewing their games for an audience. That's not a tragedy – I just don't review stuff for the outside world in any case where I don't think I can do a sufficiently objectivity-infused job for any reason. Other folk will step in to review such things.

So, I've taken a shot here at summing up here the interests, strengths and motivations of mine which describe how and why I write the kinds of reviews I write.

As you'll have seen, I'm also trying to write a non-spoilered intro blob for each IFComp entry. I do this for people who want a bit of a lead on a game and more info about it than the blurb gives, but without signficant spoilers. I stole this schtick off Emily Short as I like its goal, though sometimes I gnash my teeth with it because I tend to write better pieces overall if I can just spoil all I want. Sometimes I find the writing balance clunky, like when 75% of the review is the intro and 25% is the 'spoilery' bit. I just do what I can with it.

Obviously you'll encounter reviews completely unlike mine, and it's good that we have a range of styles and concerns and positions on various spectrums available. Somewhere inbetween all the output must lie some truths.

Note for authors – Just remember the pub trick if some review gives you the shits, and remember that this thing goes for six weeks and we're barely anywhere yet. Though if that causes you to reach for a straitjacket, maybe don't.

IFComp 2015 review: War of the Willows by Adam Bredenberg

War of the Willows is a combat game, requiring a Python interpreter to run, in which you must put down a giant, killer willow tree that's menacing your kingdom. Put it down mano a mano.

I doubt that anyone would have guessed this about the game based on the blurb –

"Did you see the clean air of the hilltops? Wind waves tumbled down through the trees, tore the drift of lavender smoke... Did you see then, in the cinder that glowed in the pewter cup, did you see how Death would wrap its roots around our throats?"

– except perhaps for the presence of that subtle pun about the roots wrapping around our throats. It's like that moment in the original Resident Evil when Chris Redfield, having polished off a building-sized carnivorous plant, says, "I think we got to the ROOT of the problem." (His emphasis, not mine.)

War of the Willows wraps a randomised combat game of obscure mechanics – one that at heart is not entirely unlike the kind of thing that appeared in David Ahl's 1978 book BASIC Computer Games – with a poetic and sometimes heavy-leaning text delivery. When a game starts by quoting a chunk of Edicts from the Bible, that's heavy. The original prose that follows flows in a similar, stansa'd vein. Poetry + combat = a highly novel entity, and once you get stuck in, you'll probably be hooked on trying to win at least once. But the game throws up tons of very obvious design issues. Primary amongst them: requiring the player to deal with way too much repetition of prose and key-mashing.

I discuss the game in more detail below the cut, but first I'll comment on Python installation after the asterisk.

* I chose Willows next in my playing because it looked like it required the most 'extreme' format (Python) relative to the other games. Well, Alan's never been a picnic either, admittedly. I relate to this situation, having asked players to tackle Leadlight on an Apple II emulator in 2010, but I did throw a lot more helpful setup material at players than this author has.

I'm playing comp games on OS X, so I'll share some setup info here for people who are also on OS X and want help running Willows. For PC and other formats, someone else will have to talk about that.

Apparently Macs with OS X 10.8 or later came with Python 2.7 preinstalled (the version Willows was written in) HOWEVER this statement may not apply if you reached 10.8 or later by upgrading from earlier OSes, as I did.

If you've got an app in your applications folder called 'IDLE', you've already got an installation of Python on your Mac. If not, you can go to this Mac Python page and get Python 2.7. It's only 22 MB. Just download the version applicable for your Mac and doubleclick to install it.

With Python on your Mac:

• Right-click the War of the Willows game file you've downloaded (PLAY.py) and choose to open it with the app called IDLE
• Two windows will appear, a shell and PLAY.py
• Click on the PLAY.py window to make it active, then choose Run Module from the Run menu at the top of the screen (shortcut F5)
• To restart the game, make PLAY.py the active window and choose Run Module again

IFComp 2015 review: The Sueño by Marshal Tenner Winter

For IFComp 2015, Marshal Tenner Winter (MTW) brings us his 656th game, The Sueño – or Here's Goo In Your Eye! as I like to think of it after considering the cover art by Gwen C Katz:

The Sueño (quoth the game: it's Spanish for dream) is a parser adventure in the mystery/thriller/Inception genres in which you play a broke uni student who hits up a sleep study for some cash, gets into lucid dreaming and finds disturbing stuff in there.

The game's slowish start feels necessary in retrospect in that it establishes a game environment in which the PC is able to bring some subtle dreaming tricks to bear on puzzles. Interest and mystery increase significantly in the game's latter half set in a deserted town, but the end text felt disappointingly rushed to me. There's a fair bit of low level tech/grammar polish wanting throughout, but by the same token MTW again demonstrates that it can be OK to let Inform's default messages blot up a lot of obligatory crap that most players won't be deeply interested in. I'm too anal retentive as an IF author to try to live out this idea, but I'd say it's one of the reasons MTW's been able to produce at least 13 parser-powered IF games in just a few years. He's been in almost every kind of IF comp that's going (Ectocomp, IFComp, Introcomp, Shufflecomp, Spring Thing) plus he's got a series featuring a coarse, nameless hardboiled detective, which kicks off with The Surprising Case of Brian Timmons.

The Sueño's oneiric game mechanics feel open-ended enough that if anything, I think the whole could benefit from going bigger to exploit more of their possibilities, at which point it might get too big for IFComp. But one knows what is commonly said to one: Better to leave 'em wanting more than less. I certainly recommend this game to parser mystery/thriller/Inception interestees.

It took me about 80 minutes to complete The Sueño. I used the nifty and diegetic (meaning 'present in the game's reality') hint device a fair bit, and I turned to the non-diegetic walkthrough file about 2-3 times.

For extended reviewage with full spoilers you can

IFComp 2015 review: Darkiss Chapter I: The Awakening by Marco Vallarino

This is how I like my vampires: Solitary, dangerous and with vile motivations. As opposed to ubiquitous, shiny and Mormonesque (Twilight).

Admittedly the anti-hero of Darkiss isn't as powerful as a vampire usually would be, but that's because the good guys previously killed him, leaving him with the inconvenient side-effect of weakness. The player's job in this classically styled parser adventure is to get vampire Martin Voigt back into fighting, biting shape.

I think this might be the first time a game has ticked the IFComp rule that a previously released game is OK to enter if it's been translated into a new language. Darkiss was originally released in Italian in 2011. That word 'Darkiss' did stir recognition in my brain when it showed up in this year's game list, and that's because I've previously trawled IFDB for all games tagged or labelled as 'horror'. There, I'd seen in passing the listings for Darkiss, its sequel and its spinoff.

With some help from the location-sensitive hint system, I completed Darkiss in about an hour. It's puzzly, solidly implemented and relishes the protagonist's intent of evil vengeance. As might be expected, it's also just slightly off in some of the translation, but the core translation is resilient. The off notes don't affect game mechanics or player understanding, just the ideal reading of the prose. I only had one comprehension problem in one room, and it doesn't seem impossible that that problem was present in the Italian original.

Darkiss may skew a bit traditional for some. I enjoyed it a lot.

One word of advice: This is a game in which you have to be extremely thorough in searching and re-searching everything you see. However, you don't have to guess at the basic presence of stuff. Just peruse the room descriptions carefully.

For a few more details on the game's trajectory and how it plays – more specific than what I wrote above, but still pretty free from specific spoilers in Darkiss's case – you can dare to

IFComp 2015 review: Paradise by Devine Lu Linvega

UPDATE: Paradise has been withdrawn from IFComp. I am surprised (and mildly embarrassed) that even as I noted it had been online in public for so long, I simultaneously didn't recall that this was against the entry rules. As a player-judge I'm not disturbed by its loss, as it simply wasn't a very scoreable entity in the context of this competition. But I tried it and I think a lot of IF folk will find it worth looking into as a creative tool:

Paradise is a text-based online world/system for any number of players/users in which anyone can create, walk around in and inject simple programming into textual objects. The objects aren't modelled to be anything in particular, but typical uses for them include making locations and putting choices and objects into those locations. Interaction is via a mixture of parser-like typing and clicking on hotlinked words.

In my first session in Paradise, I created Cafe De Los Muertos, placed it in a location recommended by the implementors and put something inside it. If you get into Paradise and want to visit the cafe, use the command WARP TO 8020

As an open-ended project which began four years ago, and one which may not contain any goal-oriented adventures that are easy to find, Paradise was likely to have scored poorly in IFComp. However I think that whether you like parser IF or clicky IF, or both, Paradise might appeal to you as a creative tool. There's nothing to stop you building a game or experience in Paradise and then linking others to it. Another big plus is that neither creators nor players (and technically, the two aren't distinguished from each other) require accounts or passwords to log in or to protect their creations. You can just visit the website and start doing stuff.

Text objects in Paradise are called vessels and operate on a concept of enclosure. Such basic concepts are explained in tutorial vessels you'll encounter soon after logging in. Basically, every vessel is inside another vessel. So you could make a location (one vessel) by typing 'create grassy meadow', then put an object inside it (a vessel in a vessel) by typing 'enter grassy meadow' then 'create chest'. If the object has compartments, they could be vessels in the object vessel. But there are no actual programming rules about the nature of vessels. You could stick a whole new world inside an object if you like – after all, it's just another vessel. You can also pick up editable vessels and put them elsewhere, or embody them, the latter being the means by which you create an avatar. You wouldn't want to be driving a default object like the teapot forever.

The most basic kind of programming lets you attach any useable Paradise command to a vessel through a 'use' link, which can also be activated by typing 'use such-and-such'. You can then repaint the word 'use' as something else – read, press, etc. – whatever word you want the player to type to use (enter) the vessel. You can nut this stuff out by following tutorial topics which consist of locations and dialogue, not boring old instruction files, or by just typing 'help'. More advanced programming is available, but it would be possible to put together an adventurous structure or CYOA adventure with the basics alone.

I suppose what's annoying about the interface is the fact that you can't get away from having to keep switching between clicking links and typing things. Or clicking a link and then having to hit return to execute it. My other gripe is that allowed punctuation in creator content is quite limited. No apostrophes take, no capital letters take in some circumstances, no exclamation marks take (actually, maybe that last one is a plus), etc. For the more literate-leaning, these things might bug.

I still think Paradise is pretty cool. I'm personally interested in exploring more focused material than what I saw here thus far, but I don't even know how big the place is or what's already in there. I could easily have missed tons of stuff.

IFComp 2015 review: Arcane Intern (Unpaid) by Astrid Dalmady

Arcane Intern (Unpaid) is a clickable Twine CYOA about a young woman (I think? Sex not definitely specified that I saw) who loves the magicky Rebecca Butler books and who gets an internship with Praecantatio Publishers, the publishers of those books. The internship is curiously boring... OR IS IT? (actually not boring.)

With its dues to Harry Potter and some commentary on young adults' possible relationship to Harry Potter books, the game is probably a must play for people who are, uh, interested in Harry Potter. It also has something to say to people who look at non-child people who like Harry Potter and think: 'What are they thinking?' It's got clean presentation, some suitable writing and sports lightly modelled adventure gaming in its middle stretch.

Having said all that, I didn't like it for a fair while, then suddenly I did. My full review of this game explicitly talks about an ending. My non-spoilery summary is: it's a fantasy narrative that folks who like young adult fantasy material will likely dig. There are a few swear words in there, otherwise it would merit a G rating.

IFComp 2015 review: 5 Minutes to Burn Something! by Alex Butterfield

5 Minutes to Burn Something! is an incarnation of the most staple of staples of the IF Competition: A parser game in which you have to solve an impractical physical problem in a closed environment using a disparate bunch of props before a time limit runs out. Other staple factors include the environment being the player's apartment, a wack approach to humour and the prose's fixation on the PC's crummy ex.

IFComp 2015: Wade's overspiel

The Interactive Fiction Competition of 2015 has begun. There are 55 entries. I want to congratulate the entrants for entering and I want to thank Jason McIntosh for organising.

The purpose of my overspiel is to say that I will be reviewing some of the entries this year. I will be doing it here in this blog. I will be reviewing titles which specifically appeal to me from the outset or which serendipitously take my fancy. Learn more by continuing to read this post.

* The cut below this line is a test to test whether Blogger's Jump Break feature prevents information from appearing on the Planet IF blog feed. If you've enjoyed this post so far, please click 'Read More' to continue to enjoy further informational reading on the topic of my overspiel –

Ghosterington Night source'n'assets

Last week I released release 3 (sorry about the double 'release') of my 2012 Ectocomp mini-IF 'Ghosterington Night'. The reason for the update is that I want to keep the game's publicly available source code up-to-date. It's now compatible with the latest incarnation of Inform 7, 6L38. The game was originally written in 6G60 of the previous generation of Inform.

The game's source is organised and commented. I'm trying to maintain it as an example of a small but whole and up-to-date Inform 7 game that new authors (or anyone else) can look at and take ideas from.

I've also included the game's two multimedia assets, a title graphic and a short theme tune, in the download. This will let anyone generate the whole game on their own computer. The first few comments in the source code tell you what has to be where, file-wise, but really there's almost no fiddling involved. Exercises like this have been made considerably easier by the new Inform, which supports game-specific extensions that won't interfere with a user's personal extension library.

The game and source code are available on IFDB.

Switching to Andromeda

Through things I said recently in a podcast, and in extremely vague form on the front of my Heiress Software homepage, I communicated that the next Inform 7 IF game I would do would be 'the murder one'.

I expected and expect this to be very difficult to do, for concept and design reasons. That's on top of my having had few specific story ideas for it yet.

The thing at the moment is that I need my creativity to be bolstering my motivations in life in general, not vexing me. Persisting with the planning stage of something really difficult ('the murder game') has been vexing me. So I've decided to switch to a project I'm confident will start to give me some gratification immediately. The third listed project on the Heiress webpage, namely 'A sci-fi game set in the Andromeda universe'.

---

If you don't know about the Andromeda games, they're a series of parser-driven sci-fi adventures started by Marco Innocenti with Andromeda Awakening, which he entered in IFComp 2011. His sequel, Andromeda Apocalypse, won the 2012 IFComp. Then Marco held two Andromeda Legacy competitions in which he invited other IF authors to make games set in the same universe. I co-judged both competitions.

The first comp produced Joey Jones's Andromeda Dreaming (the winner) and Paul Lee's Tree and Star. Both games expanded on the Andromeda mythologies in interesting ways.

The second comp produced Jim Warrenfeltz's Andromeda Ascending (the winner) and Joey Jones's Andromeda Genesis (not on IFDB now, but probably will be real soon thanks to my badgering).

I'm replaying all the games at the moment. I need to revisit Ascending in particular to remember how it fit in. I found Genesis to be disappointing when Jones's Dreaming was so good.

Collectively, the Andromeda games show that the concept of different authors producing IF parser games set in one universe is both viable and doable. The games fit together far better than anyone involved expected – not that there was even a rule saying they had to – and what's interesting is that the connections were produced entirely by the individual authors. There was almost no oversight or top-down coordination. The authors just kept generating material that fit into the sockets of mythology established by the original game, and by Marco's 'cheat sheet'.

I suppose there are actually a lot of examples of this kind of thing going on in fiction at large. What immediately comes to mind is Star Wars's expanded universe. All of those offshoot novels and comics that had to submit to some rules set above them. Maybe what helps the phenomenon work in any venue is when the people involved are attracted to the original material enough that they want to stick to its rules. The more you follow some of the rules, the more you may feel like you're a part of the entity you admire.

Andromeda is not Star Wars. This is unfortunate in the sense that I would like to be involved in a franchise that would rake in millions of dollars. But Andromeda Awakening has something in common with Star Wars in that it established a universe mysterious, charming and open enough to attract admirers interested in expanding it. The results so far have shown an impressive coherence of aesthetic, and been impressive in general. And I want to join in and add my bit.

---

As this will be a full-sized game, I'll have the luxury of my bit being large-ish. I've had some good conceptual ideas and specific story ideas so far, and I continue to cogitate on them and write them down (type them in) as they come.

Technically, I'm concerned about progress on various Inform fronts based on the example of the past few years. (I list these gripes and apologise for them about once a year on intfiction.org. This year they are additionally informed by my experience of selling Leadlight Gamma.) My concerns will probably cause me to skew towards having fewer bells and whistles in the game than I'd like. There are lots of Inform play venues with no sound, no graphics, no colours or none of the above. There's no up-to-date Mac interpreter. No Mac interpreter advances for four years. No screen reader support on Macs.

I found it headachey trying to get Leadlight Gamma to deal with all these hurdles as best it could in a commercial context. A wise man (David Kinder) once said to me, 'Don't write around interpreter bugs.' That inspired me to strike forward as much as I could, but when I found I was going to have to tell players to be mindful of problems A and B and C and D to compensate for all the exceptions in the game delivery system, I slid backwards, because I don't want to tell players that stuff in the case of a commercial game. People don't want to pay for a game and then kick off their experience with it by reading through a list of potential problems and omissions it may exhibit.

Ultimately I balanced the game features so I could retain some moderately advanced tech (the dynamic map works everywhere) and only have to warn players about a few possible problems. Doing all the accessibility work on Leadlight Gamma and then not being able to share it with Mac users remains a particularly teeth-gritty point.

Regarding the content of my Andromeda game, I won't say more than what I've already said. I'm not much for talking about a thing I'm working on. That's what interacting with the thing once it's finished is for. I know that's not what the kids want these days. They want ceaseless updates and promo stills and character information and stretch goals and not-too-spoilery-spoilers and personality videos and ARGH!!!...

I might cave in later. Otherwise, at least on the front of this game, I'll see you when it's done. Which will not be for a fair while, obviously.

Leadlight Gamma - The sale I'm running and the competition I'm not

Have you noticed what month this is? Me too.

Do you know which events took place in the month of August five years ago? The events depicted in my game Leadlight.

Having noticed this anniversary, I'm announcing

THE VERY AUGUST LEADLIGHT GAMMA SALE

Until August ends (about a week from today) you can buy Leadlight Gamma on itch.io for $1

You can still throw larger amounts of money at me during this time, but that's hardly the point of a sale.

After the sale window closes, the minimum price will revert to a more diabolical value. Maybe $6.66.

In technological developments: The game is now direct link-downloadable to the Frotz iOS app from itch.io. Consider this a news item if you already own it, since any new files or features that are added to the itch.io page are available to anyone who has ever bought the game.

---

In other news: I briefly considered running a competition, too, with a prize for the first player* to send me a screenshot of the final easter egg from Leadlight Gamma's tour mode. However I've already donated a prize to IFComp, and I'm feeling too unemployed, ill and covetous to part with any of the horror-related items I was considering putting up for a Leadlight comp. So I shan't run one!

I will say that I think most people would find the final archive item shown in tour mode to be relatively surprising.

I view Leadlight as kind of a hardcore game, but by the standard of hardcore games, an easy one. It's considerably easier to finish the game per se than to finish it with all 80 points. So I saved Leadlight Gamma's tour mode as a reward for players who do get 80 points and who have thus demonstrated their commitment to the experience.

* Anyone mentioned in the game credits would not have been eligible to participate in the comp. But these people don't need to fret anymore, since I am not actually running the comp, only the sale.

Finishability

Reading Jimmy Maher's July 31 2015 instalment of The Digital Antiquarian - The 14 Deadly Sins of Graphic-Adventure Design (or, Why Ron Gilbert Hated Adventure Games) stirred my thoughts on adventure game finishability. I'm using this cod word to describe the extent to which players can finish an adventure game without heavy or total reliance on hints and walkthroughs.

I hated Space Quest and the majority of Sierra's walk-around-on-screen-while-typing games for all the reasons described in Maher's article. I hated them as a teenager when they came out, so this isn't revisionism. They seemed to combine the wasting of player time with being a jerk about the wasting of player time, and also sported a finishability of zero. I remember Police Quest in particular as a game where you occasionally had to type in chunks of the manual verbatim or die.

Sierra's attitude to testing their games on real players before release (they didn't) was a dumb one. Let alone testing them for finishability. But I don't think you can ever fully quantify finishability. The more testing you do of your game, the more accurate a picture you get. But you still can't guarantee particular results for every single player. Probably the best you can do is to envision a core player demographic for your game (whether narrow or broad) and hope that its experience, if represented in the testing sample, will be reflected at large.

Looking for something I can test, I like to subject my games to the following:

At the strictest level, I'd like at least one tester to be able to clear the game with no help from me or anyone else. Extra-game hints don't exist at this stage, so I don't have to worry about cheating.

If this first condition is not achievable or reasonable, a step down is that I'd like to see one or more testers clear the game with no extra-game help except conversation they have amongst themselves.

If it turns out that someone who isn't a total freak can prevail under the strictest conditions, that's reassuring, and failing that, having one or more folks prevail under the second-strictest conditions is pretty reassuring. Having tested these conditions means I can say, 'Yes, a human cleared this game with no hints, so I expect other humans can do the same.'

In modern times, I have yet to make a game so big or difficult as to render these tests too onerous. Maybe my philosophy will be tested when I do make such a game, but I suspect it will still be my starting point for thoughts on the topic of verifying some kind of reasonableness in my game.

I think I started fishing around for more concrete ideas on testing finishability due to my experiences with Anchorhead (Anchorhead's IFDB page). I found it hard, and the nature of its hints and walkthrough were such that they kept tipping me into cascades of needing more hints and walkthrough. I got bored, then offside, then I gave up, since I'd spent too much time just typing in commands from extra-game documents.

Anchorhead is held in massive esteem, so I seem to be a minority of one in having had this particular experience with it (and other similarly difficult games with similarly styled hints) but on the other hand I've never heard anyone say, 'I cleared Anchorhead without any hints or walkthrough,' during any of those discussions.

It must be a tough life to be a puzzle-sporting adventure game when such a game is subject to complete spoilage by hints. Players will overcome problems in the game or they will not, and the latter path can lead to a total halt.

I'm playing Forbidden Siren on the PS2 at the moment, my latest pick from my backlog of survival horror games. And I'm relying on walkthroughs from start to finish (Chris Pruett recommended using walkthroughs in his review of Siren) – a situation which I'd normally regard as defining a failed game, even in the action genre. But Siren is so cripplingly hard, but also novel and good, that I've found the experience to be worth it. Even in using the walkthrough, my ability to execute the solutions described in the walkthrough is massively tested, and the game is still atmospheric and clever and frightening.

This reminds me of why I'm so anxious about the nature of walkthroughs and hints for pure, non-action adventure games. It's because their use can eliminate the experience of playing such games, rather than just facilitate the having of one in the first place.

Leadlight Gamma interview on IndieSider #26

For episode 26 of the video/podcast series IndieSider, the show's host Ken Gagne invited me on to talk about Leadlight Gamma and IF. This episode is out today.

IndieSider's structure is that episodes start with a game overview/demo (about 8 minutes in this case) then the interview plays over gameplay footage (about 30 minutes in this case). Or you can get an all-audio version.

Ken pointed out that I've already talked about making Leadlight per se a fair bit in various media in the past, so the focus of this episode is on porting the game, releasing it commercially and other stuff.

You can watch the video (or get the audio) and peruse episode links on the IndieSider/Gamebits homepage:

http://www.gamebits.net/2015/07/15/indiesider-26-leadlight-gamma/

Or if you're Youtubey, you can watch the vid there:

https://www.youtube.com/watch?v=vUbDcvYbkPI

I hope you enjoy your trip through this door.

Thanks again to Ken again for having me.

Vlad The Impaler review (on Steam - Mac /PC)

I've reviewed the CYOA-RPG gothic IF Vlad The Impaler on IFDB: My review.

It's a game I've replayed a lot more than I might expect for a game whose replayability I specifically criticise. But maybe what I like about it isn't all down to how it was intended to work.

The game is available on Steam for Mac / PC: http://store.steampowered.com/app/295850/

Accessibility observations part 5

In part five of this accessibility miniseries, and most likely the final one, I talk about writing text descriptions of graphics in your IF project.

Graphics in IF – they're on the rise!

Allow me to set the scene for this episode by saying that the IF projects of today are increasingly making use of graphics. Again.

To qualify this broad and vague statement, what I mean is that adventure games started out as text. Then they combined graphics and text. Then the commercial scene went into a mode where the graphics became the engine instead of the text (eg point-and-click). The non-commercial scene remained focussed on the text, but today, as more powerful IF creation tools and add-ons are becoming available to a wider range of people, more of those people are adding graphics to their text-centric games.

For the cause of making IF accessible, the ideal is that authors provide text descriptions of all important graphics. Again, I think that allowing a player to switch these on or off as part of a blanket accessibility mode, or via an explicit 'provide text descriptions for graphics' toggle option, is a good idea.

Which graphics should one describe using text?

Deciding which graphics are 'important' in the above-mentioned sense should not be too hard. It just requires the application of some commonsense and an assessment of the function of different graphic elements in your game.

Any graphic presented to the player as part of primary game content should be described. I define primary here to mean that the graphic is presented as part of the story or narrative experience, or that it's presented in any way where the player is directed to do nothing during a particular moment but view that graphic.

Graphics that constitute the user interface (pretty borders, window frames et al.) are non-primary by my definition. This is where you need to assess what these elements are doing for the player. In turn, you will be able to decide whether a description of them is warranted, and if you think it is, when and how it should be supplied.

As an example, if your multi-window interface is capped by a magnificent crest graphic for decorative and atmospheric purposes, that's probably worth describing. When should you do so? A good opportunity might be once per game session on first presentation. So after a boot, you could present the text description of the crest when the interface first appears, then maybe never again in the same circumstances until the game has actually been closed and rebooted. Alternately, not again until the player has at least exited to a main menu and then returned to the game interface as part of a new or restored game.

The important thing is that text descriptions of non-primary elements that you still deem to be of some importance should not be printed too frequently. Nor should they be printed so infrequently or unpredictably that a player who wants to read them again would have trouble finding them.

Run-of-the-mill window divisions, whether prettified or not, are unlikely to be worth describing, except perhaps as part of an overall description of a very pretty interface. Remember that your user interface is essentially functional. As the author, you took the time to arrange the UI elements to convey important game information in a certain way. For players who don't have full access to the visual UI for some reason, your focus should always be on finding methods of conveying the same important information to them. Some of these methods will be non-analogous ones; that's why describing the aesthetics of the divisions of your interface is unlikely to be valuable in most cases. You're not just replacing the interface verbatim with words. You're redirecting whole streams of information. The end product will still be words, but which words you stream and when and how often must all be determined by the emphases of your game.

How to actually write text descriptions of graphics – an exploratory case study

Leadlight Gamma has about 30 graphics that are primary content. I wrote text descriptions for all of them, an exercise which proved to be fascinating and challenging.

When I initially thought to do it, I looked online for relevant examples of this kind of writing. I thought that there might be particular styles or conventions or rules to follow that other people had already worked out for this sort of thing. There weren't.

I found that The World Wide Web Consortium tried to provide a standard HTML mechanism for supplying text descriptions of online images, but that this mechanism, the longdesc attribute, has barely been used by anyone. It was removed from the HTML5 standard for four years and only reinstated in February of this year, 2015.

For information on longdesc and similar text description mechanisms in HTML, click this line to visit the DIAGRAM Centre.

So the internet had no demonstration material to offer me. The closest thing I could think of was the style of narration used to deliver audio descriptions of movies on DVD. At that point I thought, 'It's time to just have a go at writing these things.'

Thus it turns out that as I blog this info, there is the opportunity for authors to be a bit pioneer-y in the field of writing text descriptions of graphics. There are few precedents. I worked out what I thought was the appropriate way to write my descriptions for Leadlight Gamma by experimentation, and so below I will share the thought processes I followed. Something to keep in mind as you read is that I have a lot of experience as a visual artist, so some of the approaches I bring to bear may not come naturally to people who don't draw or paint. And my text descriptions came out pretty thorough; you may only want or need much simpler text descriptions for graphics in your project. However, if you have no instinct for this kind of thing yourself, it might be worth collaborating with someone else who does.

I began by sitting down with the game's title page in front of me – which I'd drawn myself four years earlier (I have yet to work out whether it helps or hinders to be the author of the image you're trying to describe) – and considered what I thought the picture was saying, how I thought it should be described. That second point quickly led to me asking myself: 'Why do I feel a sense of obligation here? Obliged to do what?'

I realised that I thought it was important to address compositional elements in each picture for the sake of objectivity. A picture has been drawn or framed in a certain way, and has specific content, and that specificity is what I'm trying to get across. So if a sad-looking girl is on the left side of the picture, I will say that she's on the left side of the picture. It's not enough to just say that it's a picture of a sad girl. I got into the habit of trying to describe the position of important elements relative to each other in each picture. Sometimes the composition of an image leads the eye in obvious ways, and this can be used as the cue for the order in which to describe things. At other times, a general macroscopic to microscopic cataloguing approach did the trick. In the case of complex pictures featuring many interrelated elements, I discovered it can be hard to disassemble them all into words using this objective approach.

Obviously descriptions needs to cover more than just what is where. For each image, I described the medium (Photo? Ink illustration? Painting?) the way the medium was being used (If it was a drawing, how was it drawn? Freehand? With a ruler? By crosshatching? Shading?) and in many cases, the orientation (Portrait? Square? Landscape?).

Then there was the human and tonal content. What expressions and attitudes did the characters exhibit? What were they doing? I tried to be careful here to report on what could be seen in the image rather than on what could be projected into it.

Overall I was trying to be both completist in the sense that I would not omit descriptions of anything important from the picture, but also succinct in that I did not want to belabour points. If a whole description became a little laborious to read at times (usually when I was describing where a series of things were in relation to each other) that was okay with me if it meant the picture was accurately described.

In case you were wondering, colours are worth mentioning/describing. There are many webpages on this topic you can Google up, but here's just one of them which I think summarises things rather handily:

Webpage link: Why Describe Color in Video Description?

Finally, here are a couple of images from Leadlight Gamma followed by the descriptions I wrote for them. The first image was drawn by me, the second by Steve Amm.

"A loading splash screen briefly flashes up the name of the publisher, “Heiress”, in a pink-red font. It is replaced by the Leadlight Gamma title page, a high contrast black-and-white ink illustration. The right side of the image shows a beautiful teenaged girl with elaborate jet hair in profile by a window. She has adopted a subdued ballet stance. Her eyes are downcast as if her thoughts are directed inward. Her arms are slightly raised as she stands on the toes of her left foot, her right leg raised behind her. She wears a crushed T-shirt, a tutu and black tights. The venetian blind on the window is raised but askance, and the bright light from outside throws the shadow of the girl’s en pointe leg onto the wooden floor behind her.

The left side of the image is a black panel containing the game’s title text. In the top left corner of the panel, gothic white lettering spells out “Leadlight”, then the word “Gamma” follows beneath it in glowing red. In smaller white lettering, towards the bottom left corner of the panel, is the byline “by Wade Clarke”.

In the bottom right corner of the image is the artist’s signature: “Wade 27/1/2010”."

"Freya’s ballet class sketch is a lead pencil drawing filling a tall, narrow sheet of white paper. The linework is lively and agitated, giving the impression the drawing was executed quickly. There is a lot of white space showing.

The sketch shows eight girls in leotards doing barre work. Half the girls stand on one side of the barre, the other half opposite them on the other side. The girls' legs and arms are extended in unison. Movement lines show the motion of their legs. The barre itself runs from frame right up towards frame left at an angle before ending against the mirrored wall of the dance room. The mirror reflects all eight dancers and gives the illusion that a column of sixteen girls are all working at one long barre as wide as the sketch. The mirror reflection has been drawn sparsely compared to the rest of the image. The girls in the mirror are depicted as quick, simple outlines devoid of detail.

The artist has signed her name, “Freya” in the bottom right corner of the sketch."

Something new, something old, something blue, something blorrowed

The something new is that adventuregamers.com reviewed Leadlight Gamma.

Collectively, the something old, blue and blorrowed is that I've gathered up the first five proper text adventures I made (about 25 years ago), and the design notes I found for three of them, for my site Wade-Memoir. In chronological order they are:

Dungeon Of Death (1988)
Complex (1988)
The Sword Of Evil (1988) (with original notes)
Dark Arts (1990) (with original notes)
Demon's Keep (1990) (with original notes)

The book that got a 13-year-old me from approximating adventure games on the Apple II with a bunch of hectic GOTO statements to building BASIC programs that had real databases of verbs and nouns in them was Usborne's Write your own Adventure Programs for your Microcomputer; you can download a PDF of it from the linked page. The engine for the demo game in that book, Haunted House, became the starting engine for my games. I wrote five games with it, making things a bit better each time.

Today, I don't think Dungeon of Death or Complex are much good. They're just what got me started.

The Sword Of Evil is starting to get decent, though it still has no save/restore features.

Dark Arts and Demon's Keep are sufficiently respectable fantasy games of the two-word parser variety. Though Dark Arts still has too many empty rooms in it.

Today we have a wide variety of sophisticated and flexible systems available to help us make these games. We also have effectively unlimited RAM. While revisiting my old games is of personal interest for me, what I think may be of particular interest to folks who weren't around in that era is the demonstration of the amount of planning required to write games like this back then. The Usborne book told me to plan and list everything on paper before even touching the computer, so that's what I did. Have a look at my design notes for Dark Arts or Demon's Keep to see what I mean.

Demon's Keep was the last adventure I wrote from scratch for the Apple II. After that I switched to using the Eamon system, and went in for more RPG content and fewer puzzles.

Accessibility observations part 4

Today, I talk about the non-alphanumeric spray.

What is the non-alphanumeric spray? This is a phrase I came up with (and which I quite like) to describe one of those moments in a text-based game when the game suddenly prints something like this –

!@#*&!@(!!!!!!!!

– or a row of 80 hyphens, or any other kind of solid run of characters that aren't letters or numbers.

The author might be using a spray for textual effect reasons. For example, to convey comic book or Q*bert-style swearing, or to present the output of a computer going berserk. Or the spray's purpose might be to provide visual formatting, like a row of hyphens used to draw an ascii line across the screen.

Most screen readers have configurable verbosity settings so that the user can control how much punctuation they want to have explicitly read out to them. For instance, at the most explicit level, a row of 80 hyphens would be read out as:

"Hyphen hyphen hyphen hyphen..." (80 repetitions – the user is likely to skip ahead once they get the idea, if they have the capability, but there will be circumstances in which they won't have the capability)

At the opposite end of the verbosity scale, this spray might be abbreviated or omitted altogether.

Like any player testing out what elements of a game's UI are important to them via experimentation, a screen reader user can set the verbosity to a level that gives them as much or little non-alphanumeric information as they need from your game. What is worth thinking about as an author is that (a) there will be circumstances and pieces of software in which users can't configure verbosity, and (b) that you might want to convey alternative information to vision-impaired players during spray moments – and if you do, what will it be?

Again, this is where having a screen reader mode in your game can help. Ask the player if they want this mode on at boot time, and if they do, then you can customise spray stuff throughout your game accordingly. What I did in Leadlight Gamma in this regard was to strip out excess punctuation and any ascii visual formatting. The combat prose in particular is normally full of asterisks, plus signs and hyphens; I suppressed those for screen readers. I also chopped out screen dividing ascii content. In other cases, I actually went the other way, expanding abbreviated questions so that they'd be read out more nicely in English.

The more esoteric the use of your spray, the more creative you might need to be in your alternate solution. To return to the computer going berserk example, maybe you think you would like the player to hear something like 'Exclamation hyphen exclamation open parentheses exclamation...' (times 20) at this particular moment in the game, to convey the berserkness. But remember that if user software verbosity is set to low, such content could effectively disappear. So it's probably wiser to come up with an alternate piece of English prose to convey the berserkness and drop that in instead if the player has turned on screen reader mode.

I think I've got one or two more small episodes to come in this series.

Inform 7: Menus version 3

In 2014 I wrote an updated version of Emily Short's venerable Menus extension. Right after I completed it, the huge upgrade of Inform (6L02) came out and the extension broke.

Kind people posted a supposedly fixed version of my Menus to Github, but it wasn't really fixed – don't use that one, which is version 2. Then the project was in limbo for ages because I didn't want to touch the new Inform until after I'd finished Leadlight Gamma.

Yesterday I finally got around to working out what broke in my extension (indexed text substitutions) and fixed it. So today I present Menus version 3, which is good for 6L38 and should be good for 6L02:

Download the menus_v3.zip from my dropbox

In the zip you will find the files Menus.i7x and Basic Help Menu.i7x

(There is a degree of chaos in the I7 extensions management world at the moment. I just want to say that if you're one of those people helpfully filing stuff in Github or whatever, please feel free to file these appropriately. Thanks.)

Here's the summary of the extension from the docs, then I'll give a bit more detail:

Lets you include a menu system of help, hints and/or other information in your Glulx or Z-Code project. This is an upgrade of Emily Short's Menus extension featuring user-friendly single keypress controls and a more sophisticated UI. It also has configurable options, a book mode with automatic pagination, isolated message content to make translation to other languages easier and a Screen Reader mode. Old Menus format tables can be upgraded for use with this extension with a little work.

So first, there is no more moving a cursor around with arrow keys to choose things. Every option is activated by an automatically assigned keypress.

There is no more of the repeated transcript clutter that used to happen with the original Menus.

You don't have to back out of all menus to get back to the game. You can exit straight to the game with a keypress (your position is bookmarked for your return). You can also jump to the topmost menu at anytime while in the menus.

You can still use the hint-dispensing mode familiar from the original Menus.

You can toggle screen reader compatibility at any time.

The extension no longer relies on the ESC key, so it's compatible with virtual devices which don't offer one.

The extension always shows contextually-sensitive instructions in the status window, or in the main window if you're using a screen reader.

All content is automatically paginated for a book mode (move through all content with left and right arrow keys). You can let the player switch between menu and book mode as they please, or you can force one or the other. In book mode, hints can be gathered at the back of the book, with warnings about their location. Or you can just block them from book mode.

If you're having trouble compiling your menu system, there's a debug mode which shows everything that's happening during the startup scan of your content. The extension can diagnose a few common errors itself.

The 'you can't choose option H' bug from previous versions is gone. (Thanks Hanon Ondricek)

Finally, if you happen to want ye olde Basic Help Menu, I've also made a compatible version of that.

... So if you're in the market for a menus extension for your brand new Inform game, I encourage you to use this one. It's modern, extensively documented and accessibility-friendly.

Also, in the selfish reasons department, I don't want to move a cursor around with arrow keys in your game anymore. Sorry, but in these shiny times, that's too angrifying.

Accessibility observations part 3

It's been longer than I intended between posts in this accessibility miniseries, but I had work troubles and I had holiday non-troubles.

Today: Menus.

Lots of IF projects make use of menu mechanisms. The player's choice from a menu might trigger a branch in gameplay or reconfigure some aspect of the game presentation. The whole menu system might be a self-contained ecosystem outside of the game world, a way to present browsable material like game instructions, hints or about-the-author information. An IF project may feature any or all the above mentioned modes, or more.

I had thought it would be easy to start to talk about designing menus which lean to screen reader-friendliness, but I've realised this is actually a complicated area. Different IF platforms handle text output and player input in different ways. Some projects can be played online, some offline and some both ways. Anecdotes from the recent discussion topic about accessibility over at intfiction.org suggest that screen reader compatibility with online CYOA games is variable.

By the way, notice how I included all of the words 'the recent discussion topic about accessibility over at intfiction.org' in the hyperlink, rather than just attaching it to, say, the 'intfiction.org' part. This approach is an accessibility help for web content in general, since screen reader users can hop amongst hyperlinks as landmarks. If they're scanning about to see what links are on a page, or looking for a particular link, just having a single word for the link might not make it clear where the link's going to or why it's there.

Now, I can also imagine that if you elongated all body text links of a link-heavy page in this fashion, the result might be visually painful for sighted users. This situation strikes me as an example of one in which it's good to be aware of the accessibility issues, but where individual writers and authors need to work out the best approach and balance for their own content in particular cases.

Back to the menus – so there's probably a lot of work to be done in the future by game and screen reader engine programmers in getting the two worlds to be able to talk each other more consistently. As is the case with many IF projects, work on this kind of thing to date seems to have been done mostly in isolation, where interested individuals program up solutions to existing problems. As an example, I point to the Win Glulx and Win Frotz compatibility addons for the open source screen reader NVDA (search for 'Win Glulx' and 'Win Frotz' on the target page). However, the scope of my posts is about what game authors can do today.

First it's worth remembering some of the principles of typical good menu design that will help any player:

• Don't make menu entries too long.
• Don't include too many entries in one menu.
• Don't use too many submenus within a menu. A bit of popular neuroscience in editor circles says that readers of a book will find more than five levels of heading too confusing, and that readers of a webpage will find more than three levels of heading too confusing. The latter is probably applicable to IF menu depth.
• When possible or relevant, use a consistent delivery style and author voice for the menu entry prose.

Screen reader programs can read one line of text at a time under the user's control. This means that as an author, you can expect that a player who is using a screen reader will be able to browse up and down through your menu options if they need to be reminded of the content of any of them.

On the other hand, a player using the built-in text-to-speech features of their computer's OS and/or of an interpreter itself probably won't have the same luxury. They may have to listen to a read-through of the whole menu, then go through further full reads if they need to hear any option more than once. Players in this situation are unlikely to enjoy encountering long menus or unnecessarily long menu options.

If the principal input device is the keyboard, as is the case for the majority of parser-driven games, assigning a unique keypress to each menu option (eg 1-9, then A-Z as needed) is a good way to go. I went with a system like this for my new Inform 7 Menus extension in 2014. So did Daniel Willis when he wrote a new menu extension for Kerkerkruip. We happened to write our extensions independently of one another but roughly at the same time, both with screen reader compatibility in mind. My extension broke in the major new version of Inform and I have only recently fixed it – see my blog post about Menus version 3.

If the principal input device is the mouse (ie the menu options are hyperlinks) a screen reader user should be able to activate the options the same way they can activate links they have selected on a webpage... if the game itself is being delivered by a webpage. The screen reader functionality for clickable links within a game delivered by an IF interpreter is probably unknown turf for now.

EDIT - OK, it's not so unknown. In response to my comment here, Daniel says in a comment on this post: "Just one comment, which is that the feedback we got from some of the guys at audiogames.net was that not only do links work in screen readers, but they prefer them. So Kerkekruip's menu uses hyperlinks when the game is in screen reader mode."

A menu presentation which is pretty anti-accessible is one that involves a moveable cursor as the selection instrument. There are all kinds of problems for the user, including keeping track of the location of whatever ASCII element has been chosen to represent the cursor, and the tediousness of having to move that symbol around with keypresses while potentially listening to re-reads of the menu choices. In an all-text environment, the method for updating the display with the cursor's new position might also involve reprinting the whole menu in the game window; again, this is unhelpful for screen readers.

The old standby menu extension for Inform 7, Emily Short's Menus, exhibited most of these problems, which is why both Daniel Willis and I happened to have similar ideas about updating it at the same time. I'm not ragging on Emily's Menus per se – obviously it's been a terrific thing (and generally the only thing!) allowing users to add menus to their Inform games for years and years.

In the next episode: The topic of non-alphanumeric characters, at least.

Leadlight Gamma reviewed at Gamerz Unite

Leadlight Gamma just received a positive review over at Gamerz Unite. It's fun to see it on a site with a big focus on LAN parties. That's to say, not on a site where I might traditionally have expected it to be reviewed.

I think it's a fun time for IF in terms of being able to see a wider range of reactions to your game if you let a wider circle of people know about it than just traditional IF circles. This effect has probably been more evident – or maybe more transparent – to people producing choice-based games, since they travel more easily than parser-driven games. And sometimes their authors had no connection to longstanding IF circles in the first place.

So there are buyable parser games around like The Warbler's Nest or Death off the Cuff or Hadean Lands or Leadlight Gamma, et al., which have appeared and said, 'Here I am.' (Hadean Lands said it louder, but I think you get where I'm coming from. Textfyre also released parser games commercially, though with a more fully-fledged business model which, as I understand it, proved hard to sustain.) Other buyable parser games, like Cypher, still go with the 'It's the return of the text adventure' schtick. We're in a time where I expect you can get traction (albeit different kinds of traction) either way, but I think increasingly you don't need the 'ye olde' schtick. There's so much serendipity in the kinds of games a person can buy now that I think a parser-driven game looks like just another type in this context.

I would say it's more important that the game or project is good than whether it solves problems the IF community has raised about whether the medium faces some kind of developmental blockage. And of course, the two goals aren't mutually exclusive.

In my previous big game, which was Six, I explicitly tried to make a super helpful parser. If I did that game now, the only thing I would change is that the instructions would be delivered in tutorial form as well, on top of their written form which exists both in the game and in a booklet. But I don't intend to revisit it just for that.

Accessibility observations part 2

Here in part 2 of this n-part series (where n is probably 4) I begin to discuss what I've learned about how the way you format your game material on the screen can help or hinder screen reader users.

Some formatting approaches are inherently helpful or not helpful while others may be particularly helpful for a particular game design. In other words, integrating an accessibility layer into your game is like integrating any other layer of design whose goal is to help deliver your game optimally to the player. If you're thinking about a segment of your audience that has reduced vision or no vision, and which uses a screen reader instead of sight, you need to think about how the screen reader will react to your material the same way you'd think about how an eye reacts to a visual UI. In either case, you want the relationship between the instrument of perception and the game content to be as intuitive as possible.

Because we're talking about games which are essentially text, the currency of screen reader software, the good news is that neither the formatting considerations involved nor the solutions to problems – at least the ones I've encountered so far – are generally too difficult. They simply require thought and perhaps a little programming action. Or no programming action, if you're lucky. The majority of existing IF projects already play pretty well with screen readers, excepting their status bars or extra windows (to be discussed below) and menu systems (next post!). And since it's probably also true that the status bars in the majority of IF projects aren't doing much, that issue at least is a minor one for those games.

So how does a screen reader interact with the text? It can simply read through all text on a screen for the user, but its focus can also be moved about in an intentional way.

Consider first the example of webpage content. The human eye can tell headings from body content from links at a glance. Someone using a screen reader doesn't get that overall view. So they can either sit through a reading of all the content to find the part they want – which they might do if they're new to their software, or expect to be interested in the whole page – or they can use shortcut commands to jump to different types of content. For example, to the next link or to the next heading. It's easier for the software to identify these kinds of landmarks if the website being scanned has been coded in a conventional or accessible way. Features like flash navigation or graphics standing in for words can make navigation tedious or intolerable.

An IF project is usually delivered in a far more linear way than a webpage. Text is dispensed in the order it's meant to be read, and it's intended that the player always reads (or scans) everything that the game dispenses. The main exceptions are likely to fall in the areas of information contained in status windows, or in other extra windows or novel bits of user interface a game might make use of.

In a screen reader, switching the focus to the status window or any other window is generally an intentional action the player must take. This is fine if the player is only expected to check the status window occasionally. In a game where important information is being updated there all the time, the author could consider offering a screen reader mode which dispenses part or all of the same information in the main window every turn. This includes things like exit lists or important PC stats (à la Leadlight Gamma) which might change every turn. If a user gets tired of seeing these in the main window or finds they don't need them any more in a particular game due to familiarity, they can just turn them off.

If an IF project uses lots of sub-windows, that might be fine if the player only needs to check different windows semi-frequently. Kerkerkruip is an example of a game which mobilises a number of windows and has been received well by screen reader users. Its extra windows don't necessarily have to be consulted frequently, keyboard commands can be used to quote the same information you'd get from them and important stat info is quoted automatically in the main window at relevant moments in the game.

So the point is that if you have more than one window or panel in your game screen, you need to think about how you're using those panels re: accessibility. If some extra window content needs to be viewed so frequently that you can imagine it would be a pain to have to intentionally switch to and from it all the time, it's a good idea to program in appropriate accessibility-enhancing alternatives.

To be continued in part 3.