Showing posts with label opinion. Show all posts
Showing posts with label opinion. Show all posts

Sunday, 27 November 2016

IFComp 2016: "Whoops!". And other updates.

"Whoops!"

My plan to start reviewing IFComp games in a more targeted fashion was obviously a great one. The problem was it immediately fell down when I passed what time I’d hoped to spend on it to action in the categories of music and ‘life stuff’.

In retrospect, it was dumb of me to start out reviewing in a random order when there were so many entries in the comp. A moment’s planning would have made me realise I’d no chance of getting far into the catalogue overall. The trouble is, reviewing at random is really fun. I remember that from the years when circumstances allowed me to review everything (or close to it) to a certain personal standard, and in a mostly random order dictated by the IFComp site.

Maybe I just won’t be able to do that again, especially if the number of entries continues to rise. So I think I need to say to myself, ‘Right, I’ve had that particular fun in the past, I don’t need to try to recreate it,’ and change to a more targeted reviewing tack next time I come at this.

So, congratulations to Robin Johnson for winning with Detectiveland, and then to all the other entrants for everything else. Also, I know a few people were keen for me to review their IF, and I didn't get to it. I will eventually, but just because it looked like I was probably going to get to it during the comp and I didn't, I'm sorry.

American Financial Restoration Sale

I eventually noticed there was this Black Friday sale thing going on in the USA. If I’d been more on the ball, I might have taken advantage and put Leadlight Gamma on sale again. Instead I was too sluggish on the uptake, so I think I’ll just wait ’til Christmas or something. This way I also get to say I’ve avoided participating in yet more cultural behaviour doled out by Americans.

Works in Progress

My CYOA Extension for Inform 7 has been coming along really well. I need some third party tech put in place before I'll be able to finish it.

I continue to gather notes for my mystery IF project. The phrase ‘mystery IF project’ makes it sound like I’ve talked about it in this blog before, but I haven’t. What is it? Not telling! Yet, anyway.

I’ve been getting annoyed at myself over the past year for losing too many good ideas for the project. When I say lose, I mean that I didn’t write them down or type them up at the moment I had them. I think my lack of vigilance came from the feeling that their graceless accumulation in a few text files was amounting to a disorganised idea splat for the future that would probably annoy me in the future. How would I sort, find or string together relevant bits from the splat? And there are different types of bits in there. Dialogue riffs, character ideas, incident ideas, structure ideas, etc.

In response to these note-organising problems, I downloaded and am trying out the writing software Scrivener. (Interjection: Holy crap, it's on sale for Black Friday! I must buy now! Buy Buy Buy!) I find it’s working well. It allows me to store all my notes, research materials and prose for a piece in a single document in ways that make it easy to index, connect and rearrange that material. I expect I will produce the text of the IF project in Scrivener and then port it into my CYOA extension. It turns out that I can actually make a pretty direct correlation between blobs of text in Scrivener and choice nodes in a game.

An incidental bonus is that using Scrivener is looking like a good way to write manuals, too, and I expect to have to write a manual for the CYOA extension. I may even be able to publish it directly as an e-book from Scrivener.

Monday, 17 October 2016

IFComp 2016: It's a third of the way through.

IFComp is about one third of the way through and I've reviewed one sixth of the entries. I started suddenly this year (ie no thoughts even the day before about reviewing entries) and defaulted to doing what I did the first time I reviewed IFComp, which was in mimicry of what everyone else was doing – trying to review everything. I review partially for all of me, authors and reviewing (judgement).

Reviewing everything used to be more doable because there were far fewer entries. Now there are almost 60, and pausing to take stock of what I'm doing, I think that continuing to adhere strictly to my randomised playlist and then just stopping suddenly when the comp ends with a big, randomly determined unplayed/unreviewed list remaining is not going to satisfy me. Aiming to be satisfied is a carrot that helps you keep reviewing at speed, especially in any kind of time fight.

So I'm going to break off the randomised list and prioritise playing and reviewing more things I expect I want to play and review. In reality this makes little difference to onlookers because they haven't seen my list and they don't know what I want to play and review. It probably favours returning entrants, since there are a lot of authors whose second+ game I want to check out because I liked something they did before.

Maybe it's more useful to list a few things I'm deprioritising or know I won't review:

  • Where someone entered two games and I know it's them because they didn't disguise themselves with more silly pseudonyms, I'll only review one, just to spread reviews around.
  • Steampunk games are deprioritised because I just don't like steampunk. I'm still interested in playing Felicity Banks's alt Australia game because I'm Australian, but I give no commitment right now. I promise nothing!
  • I'm not reviewing Rite of Passage because I helped test it, and re: Slicker City, as ASchultz is a friend of mine I'll probably hold on his game until after the comp.
  • I'm not interested in Manlandia. And I think I am probably not interested in This is My Memory… based on other reviews. But the latter is also short.

Friday, 1 July 2016

An important reinforcement of news not about ME

People who know and have done a lot of IF, and who either love organisation and oversight, or are highly driven by cause, and/or who exhibit a mixture of all of the above qualifications, have formed the non-profit Interactive Fiction Technology Foundation

Its homepage is http://www.iftechfoundation.org/

Its facebook page is https://www.facebook.com/iftechfoundation/

The way I read it, the foundation's plan is to help look after the tools, services and culture of IF in a way that should take the pressure off a random collection of individuals to have to do so. In this light, I'm reminded of how all the individuals have done pretty stellar jobs holding the structures aloft to date.

I guess most people involved in making IF, including myself, have pointed their attention at the bits that interest them and tried to help keep those bits going, or contribute to them or maintain them. And sometimes there have been bits You are interested in personally, but which you don't have the skills to help with. At a low level, the do-what-you-can and hope-for-what-you-want experience has probably been a bit frustrating for everyone involved. I don't expect a pile of instant solutions from the new foundation, but I'm glad and grateful that the IF folk who feel they can or want to or must address such issues are thinking about the long term.

I like helping people with things I can help them with, but I hate organising stuff. Just thinking about itARRRRRRRRGHHH!

Tuesday, 24 May 2016

Loitering with the Joneses of technology

– I've reviewed mystery adventure The Black Lily, from IFComp 2014, on IFDB.

– I participated in an IF podcast last week, but I don't know when it will be around.

– My Inform CYOA extension is pretty far along. I hope to release it sooner rather than later so that it can ward off the ravages of age. Tools are particularly susceptible to those ravages. Some of them get ravaged before they even get out the door. I reckon the important thing is not to dawdle in the doorway. Whether due to feature creep, or to the high and impatient current speeds of all of modern citizens, technology and history, you can be left palely loitering in the doorway with your outmoded tool.

This happened to me in 2012 with a GameSalad project. That this was only four years ago surprises me; it feels like much longer. Such time collapses are illustrative of the point.

I spent months using GameSalad to build the engine for an overhead viewed point-and-click adventure game with a dash of action. But not difficult action. The iDevice touch interface wasn't going to be slick enough for tight control. I was building this engine for a ghostly horror type game I was going to call Hedra.

GameSalad was in development heat at the time. Every time it got updated, I had to redo more stuff in my game. Plus Apple's Retina technology was coming in. Suddenly it came to GameSalad. Then everyone had to figure how to trade in double resolution graphics as well. As a one-man band, I was having a hard enough time tuning the engine per se to keep up with the Joneses of technology, and eventually I gave up on the whole thing. My demo no longer runs properly on my current Mac. It needs an old version of GameSalad on an old Mac or a bunch of updating, and even if I did update it, I'm no longer in the headspace or flush of interest to make that game.

I think this all makes Hedra the only computer game in my gamemaking history that I invested solid time in but which didn't get off the ground. I've got a decent number of incomplete games behind me, especially back on the Apple II, but I consider those to have gotten off the ground because they reached the point where they had either a bit or a lot of game content going before I stopped working on them. Hedra doesn't exist except in my head; all I've got is part of an engine that was intended to turn into it later.

Having only abandoned one project late in the fundamental development stage strikes me as a fortunately low stat. I think the rate has probably been helped a lot by most of my projects having been all me. The moment you become part of a development team, you can face exponentially more complex completion factors, but technology affects all projects.

Friday, 22 April 2016

Dumb stories from the past episode 387: Failing to review Gotomomi

Gotomomi by Arno von Borries was the first game I tried during IFComp 2015 and the first I didn't write about because, due to the silly capriciousness of life, my post would have been more than 50% stupid stuff not to do with the game itself. It wouldn't have been a review of quality, only a bedraggling post by someone who gave up on the game anyway once they did get it going.

It's not that you can't give up on a game and say why, but when you factor in the extra-game elements in this case, plus that it was to have been my first review of the comp, I felt it was just going to be an unwarranted disservice or aggravation to the game's author and a crummy start for me. Because of time pressure during IFComp – too many games, barely enough time to write about them in detail unless the planets align during a particular year – I know that I'd always rather just move on to the next game if something weird happens. On the plus side, all entrants are equally subject to this kind of prejudice of haste amongst judges, reviewers, players.

It now occurs to me that I probably shouldn't have talked up this anecdote. Anyway, I'd just had a birthday and been given a major gift: an iPad Mini 3. My mum and dad gave me that, and my sister gave me a physical keyboard to go with it. I thought something like, 'Wow, watch me play IF out in the world using these bad boys!' and promptly took them to the local shopping centre. This place is a hub for some quite hoity-toity fashion shopping in Sydney, so you shouldn't in any way underestimate the glamourousness of the people who swan about in it, or of its architecture, while you're in the process of imagining what it might be like. I wasn't there due to my glamour, though. I was there because it's local to me and an attractive and airy place, and because I sometimes have a coffee there.

So I sat down at a table with a coffee amidst all the glass and marble and light and broke out the iPad Mini 3 avec keyboard. I forget exactly why I picked Gotomomi to kick proceedings off, but I do broadly remember that I picked it believing it would suit my circumstances. After I started the game using IFComp's online player, I was horrified to discover that the player didn't play nice with my physical keyboard. The iPad kept toggling the virtual keyboard and 'continue' prompts. In other words, after typing a command on the real keys, I always had to tap a particular small spot on the screen to prep the iPad to return focus to the physical keyboard. I persevered with this scheme for a little while because this was pretty much the iPad's maiden voyage, and I was deliberately trying to have A Nice Time. But I was being dumb – you can't play a game this way. So, having mucked about, rather in vain, with the open-ended game that is Gotomomi, and having tried not to associate it with my being stymied right on commencement of IFComp, I finished my coffee and went home with a small thundercloud over my head.

Some games later I revisited Gotomomi on my desktop computer. I wasn't enjoying its vague open-ness, though I thought I was onto something when I got involved in a task as specific as gutting fish. This fish-gutting scene in Gotomomi is the Tetris of fish-gutting scenes. I know that Tetris has already been implemented in the parser at some point by one or more smartarses, but having played Dead Man's Hill, I can say in retrospect that I found the mountain of tiny granules of typed actions required to progress through Gotomomi's fish-gutting scene – under time pressure – to be agonising and infuriating, rather than a witful simulation of weapon-handling, which it was never meant to be. And I wasn't even sure whether I was progressing or not. Alarm bells were ringing on my sanity, plus I probably did remember my sour afternoon at the shopping centre after all. So I just downed tools and said, 'That'll do, Gotomomi. That'll do.'

And that's my dumb story from a year ago.

Monday, 22 February 2016

Sylvia - Depression in the movies! and elsewhere

The other day I watched Christine Jeffs's 2003 film Sylvia, a biopic about poet Sylvia Plath starring Gwyneth Paltrow, for the third time in life. It's a film I like a lot and find affecting, and which I feel motivated to write about in the context of various artistic efforts seeking to convey the experience of depression, including the IF Depression Quest.

Plath took her own life in 1963. I will be talking about that, and about related and unrelated non-G-rated ideas in what follows.

Gwyneth Paltrow as Sylvia Plath

Monday, 15 February 2016

New beginning, new beshminning!


The game title A New Beginning indicates that there have been a series of beginnings. Or at the very least, one other beginning before this one.

What should the words 'The Final Cut' mean in a game title? I reckon something along these lines:

'This is the last and most definitive version of this game! The producers who got in the way of our vision and the cack-handed editors who failed to assemble the product correctly the first time we solid it to you have all been swept aside. At last we can present to you what we would have presented to you in the first place if it hadn't been for all these jerks and idiots. Also note that this is the last time we will be presenting this product to you, and we're doing it really definitively.'

But what do the words 'The Final Cut' mean in the pretty dumb-sounding title of the game -

A New Beginning: Final Cut ?

They mean: 'Hey. The game's on Steam now, and we got it working on Macs. Plus we added achievements and more localisation. PS The game is exactly the same as before.'

It's hardly Ridley Scott being denied final cut on Blade Runner then getting a chance to edit it how he wanted about ten years later.

In conclusion, all roads are imperfect, but some are dumb, and brainless use of terms like 'The Final Cut' and 'Director's Cut' in the process of glomming a few extra words onto the end of a game's title in order to flog it anew is part of the dumb road.

Sunday, 17 January 2016

1-Carolyn Vaneseltine interview 2-Open Apple podcast & drive noises 3-Apple Time Warp podcast 4-Inform 7 doings

This is one of those Cadbury Roses blog posts with an assortment of topics.


1. Carolyn Vaneseltine interview

I listened to and enjoyed the new interview with IF author and Sibyl Moon blogger Carolyn Vaneseltine on Ken Gagne's Polygamer podcast. The conversation 'ranged across Twine, Inform, and Choice of Games, how to develop games without knowing how to program, the difference between “game design” and “game development”, and the upcoming Global Game Jam (Jan 29–31...)'.

The Game Jam talk caused me to think back on my two experiences of Global Game Jam to date, in 2011 and 2012.

If you're someone who's interested in going to Global Game Jam and would like to know (even) more about what it might be like, or you're someone who likes stories about hothouse game development, or you're someone who likes stories about hothouse game development written by ME in particular, you might enjoy these two accounts of my times at Global Game Jam:

2011 Global Game Jam, Sydney, Powerhouse Museum

2012 Global Game Jam, Sydney, Rosehill Gardens Racecourse


2. Open Apple podcast & drive noises

As a dyed in the wool Apple II head, I listen to the Open Apple podcast every month. It's about Apple II stuff, and the majority of it is about Apple II stuff that's happening today, because people are still producing software and hardware for Apple IIs. Those vacant hardware card slots Steve Wozniak built into the computer just keep paying off.

My 1990 Apple IIGS computer was completely re-energised last month when I bought a CFFA 3000 card for it. This card goes in one of the slots and adds a USB / solid-state storage facility to this 8/16-bit computer. And you don't have to limit yourself to any one kind of storage. You can use any modern computer to copy any kind of disk image onto a USB – 5.25-inch floppy images, 3.5-inch floppy images, hard drive images, images using any operating system the computer can handle – and you can boot up any of these images from a menu. This card, apart from being an enormous convenience, lets you pretty much eliminate the biggest point of failure for these older computers from your system: the moving parts disk drives and the decaying magnetic floppy media that go in them.

A price to pay for cutting out the real disk drive is that you no longer get to hear what the drive is doing. The drive sounds on the Apple II are particularly audible and organic. You can tell what the I/O is doing by listening to the kinds of grinds and clicks the drive is making. Particular games make particular sequences of sounds while loading, or at particular points during play, that basically become part of the aesthetic of the game on this platform.

(As an aside, here's a link to Antoine Vignau's Youtube channel 'Cracking Senses', which aims to pass on Apple II software-cracking lore and techniques. In these videos, he boots up various copy-protected Apple II disks in a drive with the top off so that you can see which head movements go with which sounds. A lot of copy protection schemes are identifiable by their drive sound signature.)

The thing I most miss when playing adventure games that I originally played on the Apple II on newer platforms is the contribution of the disk drive sounds. Major accomplishments in the Sierra Online or Infocom games were often accompanied by a pause for some heavy loading from the drive, perhaps with eccentric chugging sounds.

In emulation, this part of the Apple II experience is kept alive by the Virtual II emulator. Virtual II contains samples of all the different head and spin movements made by the 5.25-inch drive, and it strings them together in response to the movement of a virtual head to output the same sounds a real drive would make when interacting with a particular disk.


3. Apple Time Warp podcast

Another Apple II podcast I listen to is Apple Time Warp. I'd say that I listen to it regularly except that there have only been two episodes so far, and there were two years between them. But I have listened to both episodes.

This podcast is co-hosted by John Romero and features him talking to 80's Apple II game programmers about their games, tech tricks and memories of the software industry.


4. Inform 7 doings

In my Inform 7 doings, I produced the first example game for my WIP CYOA extension over Christmas. Predictably, it immediately revealed dozens of bugs and shortcomings in the system. So I've been attending to all those, and perhaps soon I will be able to move on to the easier examples.

After those are done I intend to make a full project using the extension. In matters of minor irony, this project will require almost none of the bells and whistles the extension makes available. But that's sort of forgetting that the meat and potatoes features of the extension are significant ones. The project will be friendly to all of desktop, website, iOS and screen reader play out of the box.

Sunday, 27 December 2015

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.

Wednesday, 9 December 2015

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.


Wednesday, 7 October 2015

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.

Sunday, 30 August 2015

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.

Wednesday, 5 August 2015

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.

Sunday, 21 June 2015

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.


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:


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

Tuesday, 9 June 2015

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.

Saturday, 23 May 2015

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.

Sunday, 3 May 2015

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.

Thursday, 30 April 2015

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.

Sunday, 26 April 2015

Accessibility observations part 1

This is the first of a number of posts I will be making about figuring and programming accessibility into your interactive fiction game project.

I speak not as an expert, but as a game author who has now spent a fair bit of time trying to do this. I just released a large Inform 7-programmed game (Leadlight Gamma) which I tried to make fully and explicitly accessible, so my goal here is to share what I've learned about the issues and technology involved along the way. The game is fresh so I'm still learning. In other words, I'm still getting feedback about this aspect of it from the real world.

When I say accessibility, I refer primarily to making the content of your game available to players who have various degrees of visual impairment. This is because formatting game material in a way that maximises its compatibility with screen reading software (the software that reads text aloud to a player) is something you can have a significant degree of control over as an author or programmer. Solutions to some accessibility problems are entirely beyond your control, but IF has always had this gaming strength for players with limited or no sight because the content is essentially text and the games don't depend on reflexes.

The subject of accessibility came to my attention last year when I set out to program a new, more modern menu-generating extension for Inform 7. Right now I'm trying to update it for the latest version of Inform. When I asked about people's needs and wants in such an extension, Neil Butters on the intfiction.org forum described some of the quirks of the way his screen reading software interacts with IF. I then sought to program the extension to cooperate with screen readers. In programming Leadlight Gamma, I sought to extend accessibility principles across the whole game.

This kind of accessibility work doesn't just apply to a game itself, but to related materials, too. Here is an example from the 'learning from my mistakes' department: I drew attention to my game's accessibility upon its release, but the homepage I'd built for it was not as accessible as the game, something a blind journalist quickly pointed out to me. In real terms, this means my website content did not play nice with screen-reading software.

The world of IF technology remains querulous (will this or that interpreter run my game? Will there be pictures? Will there be sound? Will things change colour when I want them to? Can I control the fonts? Will it run online? Will it run on Macs and PCs? etc etc) and I've learned that life with screen-reading software can be as querulous in general. There is no perfect software which can interpret all websites in some idealised fashion because there is infinite variety in website design, programming methods and presentation. Screen reader users have to develop habits and nouse which allow them to find the information they want when online, and some sites don't cooperate with their software at all.

In the case of the Leadlight Gamma website, I had just spent a lot of time redesigning it and my other websites using responsive technology. That is, website code which strives to produce a fluid, attractive and logically presented website on the fly, no matter how big or small or oddly proportioned a user's screen is, or whether they're using a desktop or mobile device. The Rapidweaver themes I'd invested in to get this done did not consider accessibility. My solution was to code a plain text version of the site with screen reader-friendly navigation. I put a link allowing a visitor to switch to the text version of the site at the head of the graphic version.

In a future post I will talk about presentation issues within a game. That is, what you can do to present content helpfully within an IF interpreter screen.

Something you may be interested to watch is journalist Robert Kingett's video how blind people use the web. You can see/hear a screen reader in action and look at some examples of websites which work with one and websites which don't.

Saturday, 11 April 2015

Lo, an astrolab!

This is Wade Clarke saying these things to you. I have just established Wade's Important Astrolab, a blog (and virtual astrolab) where I can infrequently post about interactive fiction (IF) that I have made or that others have made.

The blog title is courtesy of the IF name generator and was originally just 'An Important Astrolab'.

It pained me to have to reject the following blog titles I also derived from the IF name generator –

Wade's Sweet Pyramid of Anharos
Wade's Ooze of A Coherent Narrative
Wade's Literacy Night Out
Wade's Journey into Holy Joystick
Wade: Got Mummy's Crypt?

– but I felt I didn't want to go Super Wacky because then there'd be a danger of the title gradually becoming annoying with the passing of time. So Wade's Important Astrolab it is.