This is the talk I was planning to give at EICS 2015, before prevented from doing so by food poisoning.

1. Text Parser Based
Interaction
Michael Heron
Robert Gordon University
@drmichaelheron

2. Introduction
 Accessibility in video games remains an under explored topic.
 Things have improved considerably in the last five or so years, but it remains a low
priority issue for many developers.
 Common resources now exist that give excellent advice to developers
interested in the topic.
 Includification
 GameAccessibilityGuidelines
 However, guidelines by themselves are not enough.
 They often drain nuance from complex interrelationships of impairments
 When followed to the letter, they may result in software that is inaccessible in
subtle new ways.

3. Accessibility
 I’m a lecturer at Robert Gordon University, with a research interest in… well many things.
 One of the more significant of these things is accessibility.
 I am also a massive nerd.
 Shocker, right?
 As such, accessibility within video games is a natural focus that leverages several of my
interests.
 Research into video game accessibility though can be costly.
 And so is usually done ‘after the fact’
 Not a lot of opportunity for experimentation in situ.
 As such, it is my belief that extensive, detailed accessibility case-studies into gaming
interactions offers real benefit.
 The paper that accompanies this talk consists of one such case study.
 Available at http://tinyurl.com/otomf75

4. Game Accessibility
 Accessibility in video games is perhaps the most significant challenge for
accessible design.
 Interaction in games is often tied up in context.
 Interaction in games is often tied to immersion
 Interaction in games comes with a need to mirror, as far as possible, the physical
realities of actions.
 Within a word processor, there is no real difference between pressing a key and
clicking a menu option as far as the interaction itself is concerned.
 There is a world of difference between pressing a button and swinging a wiimote in
terms of the experience a game delivers.
 These are challenges too offered within an environment where interaction
usually must be precise, time-constrained, and synched to in-game activity.

5. Text Based Games
 It’s not my day job, but I spend a lot of time developing within the niche of ‘text based
games’
 Specifically, a niche within a niche – text based multiplayer games.
 What used to be called Multiuser Dungeons, or MUDs
 This is a hobby for me, not a vocation, but it has offered me insight into numerous elements
of game development.
 It is also an area which has scant academic attention since the death of the form as a
commercial entity in the mid 80s.
 Although there has been something of a renaissance of text-gaming in recent years, it hasn’t
reached my corner of the digital world.
 Text gaming of this nature though also offers some insight into command line interaction
generally.
 Applicable to dealing with the complexity of working within a text shell.
 Many of the characteristics of one are shared by the other.

6. The Barriers in Text Accessibility
 Text interaction regimes offer several challenges for those looking to make an
accessible environment.
 They have, usually, a steep learning curve.
 They are difficult to master, relying on recall rather than recognition.
 They require the issuing of complex, precise instructions in written form
 They usually lack alternative interactions regimes, or multiple ways to achieve goals.
 The general assumption of knowledge is high, with the interaction medium itself acting
as a kind of ‘entry barrier’
 These are issues shared, for the most part, with text games and text-based CLI
systems.
 Within my own text-based game, we have identified and worked with several
potential solutions to these issues.

7. The Cognitive Burden - Input
 Written commands can be difficult to construct.
 Wordy
 Requiring precise combinations of literal words and symbolic identifiers.
 May not offer consistent affordances
 The order of parameters given to a command may differ from one command to another.
 Often ‘unintuitive’
 The source of the notorious ‘guess the syntax’ puzzle in text games.
 Relies heavily on recall rather than recognition.
 Relies heavily on assumed expertise.
 The existence of commands is not always well signposted.
 Difficult to remember what’s been done previously.
 And how it relates to future requirements.

8. Cognitive compensations
 Within Epitaph we assessed several compensations:
 Context sensitive introduction of commands
 ‘Hey, you might like to know you can do the following commands here’
 Syntax ‘hints’ based on location in the game world
 Aliases that allowed for adaptable compensation to individual expectations.
 At a simple level, renaming commands.
 At a more complex level, offering programmatic interfaces for contextual activities.
 Syntax highlighting and verbose help hints
 Hyperlinked commands, allowing complex instructions to be issued on mouse click.
 Extensive logs of previous activities, and how these relate to future expectations for
users.

9. Output
 Inputting commands is complex, but so too is reading and parsing the output
 Often full of extraneous detail
 Often ‘spammy’
 Not very obvious what’s most important
 Within games, suffers from an expectation of ‘Chekov’s gun’
 For those with visual impairments, ASCII art ornamentations do not work well with screen
readers.
 Ordering of textual elements can be important when dealing with real-time in-game
situations.
 Our compensations in this regard focus on colour cues, syntax highlighting, and the ability
to remove flavour text.
 Almost anything non game critical can be suppressed.
 We also provide the ability to order elements so as to better serve the requirements of fast
responses to ongoing scenarios.

10. Output
 We provide special bespoke systems for compensating for visual impairments.
 ‘Landmarking’
 Soundgrids
 Narrative combat summaries
 The ‘alt_text’ system for providing alternate output for those using screenreaders.
 Knowing what can be configured is a challenge.
 We provide a comprehensive ‘options’ command.
 But you need to know what all the options do to have full control.
 Thus, we also offer a ‘screenreader’ command, as well as a login prompt, that
sets all of the options to a default value useful for those with impairments.

11. The MUD Extension Protocol
 A game protocol developed for MUDs generally is the Mud Extension
Protocol (MXP), which allows for raw text to be hyperlinked within
supported clients.
 We use this heavily within Epitaph to reduce the burden on players.
 However, within Epitaph there is also a command line shell for developers.
 This is where most of us spend our time, using in-game implementations of
standard linux commands such as ls, more, cp, mv and so on.
 Some of these commands link to external tools which then pipe their output back
into the MUD itself.
 MXP is used for both developers and players to reduce the burden on
issuing complex instructions.

12. Relevance Beyond Gaming
 Many of us work within command line interfaces on a regular basis.
 Anyone who does any of their work on a remote server will have some familiarity with
the difficulties to a greater or lesser extent.
 We assume expertise will be accumulated over time.
 However, in my experience it usually atrophies away between uses.
 We are only briefly expert in the tools that we use occasionally.
 However, the benefits of working on an accessible text game extend beyond
the niche of niches where I dwell.
 It offers some design guidelines that can help improve command line interfaces
generally.
 These are not overly complex to implement.
 It just requires the will to do so.

13. Conclusion
 The game which I develop is not yet an accessible game.
 Attaining accessibility is an ongoing process, and that is never more true than in a fast-
changing game environment.
 However, we have put in place a number of tools that greatly improve our
framework for accessibility support.
 The purpose of this paper is not to argue that this how we ‘fix’ accessibility within
text games.
 Many of the issues here are already addressed in the new renaissance of online
interactive fiction.
 It is primarily to provide a case study of how one particular, unusual gaming
environment has addressed some of the issues unique to its interaction regime.
 The more case studies like this we have as a community of practioners and
researchers, the easier it is to extract the nuance needed for effective accessibility
support.