Text parser based interaction

Text parser based interaction

• 1.
  Text Parser Based Interaction MichaelHeron Robert Gordon University @drmichaelheron
• 2.
  Introduction  Accessibility invideo 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 alecturer 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  Accessibilityin 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 inText 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  WithinEpitaph 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 commandsis 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 providespecial 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 ExtensionProtocol  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 gamewhich 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.