Hi Richard and thanks so much for your exellent and informative post. It's
been quite a relief to find out things aren't always beyond our control,
more like a little thought needs to go into things, as games can be made
accessible, it's just the desire and market isn't quite there yet.
Unfortunately I can't access sudosan, at the moment, as IE won't open the
page, it just clicks away as if it's stuck, but I'll try out the other stuff
tomorrow when I have a bit more time. Things have become much more clearer
with your explaination, along with superb info from Thomas and others on the
list. I really appreciate you taking the time to get this info down, so
let's see where it leads us! Cheers Steve.
----- Original Message -----
From: "AudioGames" <[email protected]>
To: "Gamers Discussion list" <[email protected]>
Sent: Monday, June 28, 2010 1:56 PM
Subject: Re: [Audyssey] Advice on implamenting accessibility into
avisual/graphical game?
Hi Steve and list,
Here're some answers from me...
Question 1:
What is the best combination for accessibility within a visual
environment. E.g, Java (graphics) and self-voicing? Flash (graphics)
and self-voicing? Java (graphics) and a client TTS based program? etc...
Answer:
The choice of technology depends very much on the type of game that you
are going to develop. You need to know the type of graphics
that the game is going to use (3D or 2D) and also the platform on which
the game is played (PC, iPhone/iPad or (handheld) console,
online in browser on website/ Facebook, etc.). There's a wide range of
game technology out there so you first need to be more
specific. But I can tell you this already: Java and Flash are currently
the most popular apps for 2D online/offline graphics,
including a 2D sound engine. Unity, Director, Virtools and Quest3D are the
most popular (in that order) for online/offline 3D
graphics, including a 3D sound engine. Of these, only Director contains
standard TTS functionality.
But there are many options if you choose to develop for another platform,
many including coding (for example C#) instead of
scripting (ActionScript) solutions.
Question 2:
Would 1 approach be more difficult than another? E.g, screenreader over
self-voicing?
Answer:
Again, this depends heavily on your game design and the type of experience
that you want to accomplish. The benefit of screenreader
functionality is that you don't have to produce sound file assets for the
text in your game. If your game contains a lot of text
this saves a lot of money and time. It also saves a lot on the size of
your game (100 text files is much smaller than 100 mp3
files). The downside is that you can't control the sound of the voice on
the players computer, with many people having different
voices. You also need to somhow get TTS working in your game as not that
many game development tools support TTS. Your game will
(partially) sound like any other application and that a lot of expression
thus immersion of the gamer may probably be lost, compared
to a recording of a voice actor. This is one of the benefits of a
self-voicing game - you can make it sound great, original,
expressive and exciting. You can make it sound like a game and not Word.
But of course you need to have the resources (voice
over/actor (=not the same), recording capabilities, time) to do that.
Also, it will make your game a lot bigger. And many
development tools can simply handle multiple sound files.
Question 3:
Are there any examples of such a graphical game which offer a good gaming
experience to both the blind and sighted, which
incorporate audio accessibility?
Answer:
Aside from the obvious ones such as Terraformers and The Blind Eye, that
others have already mentioned, there are several games in
our AudioGames.net database that feature visuals and from which can be
learned. Such as:
http://www.audiogames.net/sudosan/
http://www.audiogames.net/thecurbgame/
http://audiogames.net/db.php?action=view&id=mueckenjagd
http://audiogames.net/db.php?action=view&id=SoundVoyager
http://audiogames.net/db.php?action=view&id=km2000
http://audiogames.net/db.php?action=view&id=tag
Many of the above are accessible but have (light and big) design issues in
one way or the other. Sudosan, which I developed, is an
accessible version of the popular Sudoku puzzle. It is very boring because
solving a 9x9 sudoku takes a lot longer by listening to
each row and column compared to having a visual overview of the puzzle. A
better solution would have been the option of a 4x4 or 6x6
sudoku.
The Curb Game was intended as a (first) simple online blind-accessible
video game, as there were none at that time. What we learned
was that adding visuals double the production time (also see final note
below).
The game KM2000 is an excellent example on how why one should NOT base
your accessible game design on a visual perspective. KM2000
is a racing game in which it was decided to use a top-down perspective and
making it possible for a player to rotate his car 360
degrees, thus resulting in many accessibility issues and in a game that is
almost unplayable. Would the designers have chosen for a
3rd person (like Outrun) or even 1st person perspective, than the game
would have been a whole lot different and better. Lesson
learned: base your game design and game perspective on accessibility first
(only then on sound), and not on visuals (which has a
different possibility space with different properties/dimensions than
sound).
Mueckenjagd offers a similar problem. In this fly-swatting type game, the
player control a crosshair in a 2D plane (x,y). The
crosshair cannot leave this plane and this will bump the edges. When you
see this in action, the mechanic is very clear. But the
mechanic is very unclear in just sound alone (when there is no visual
plane), and it is only enhanced by the minimalistic sound
design for the bump notification (a beep, of course :( ). It would maybe
have been better if the designers choose to use a 360
rotating on 1 or possibly 2 axis.
I've added Sound Voyager as a game with a "good gaming experience to both
the blind and sighted". Both the visual and auditory
assets are designed as abstract and it works quite well. When you look at
many music-driven games, many of the visuals are abstract
shapes (cubes, squares, lines, triangles, etc) with simple animations
enriched by nice lighting and special visuals effects. Sound
Voyager sticks to simple circles and points though, and still remains a
fun game to experience in both sound and visuals.
Final note: Please know that if you want to dig deeper in making
blind-accessible video games, that adding imagery includes adding a
lot of work and expertise. That if you intend to target sighted gamers,
that you must your visuals should be up-to-date to current
standards. This doesn't neccesarily mean 3D, though, it may very well be
2D. It does mean well-excecuted visual artwork, proper
animation, a reasonable framerate, etc etc. Don't make the same mistake
that the non-tripple-A-title-video game industry
unfortunately still makes with sound today: don't add the visuals
sometime later but plan it together with the whole of your game.
Best regards,
Richard
http://audiogames.net
http://creativeheroes.nl
---
Gamers mailing list __ [email protected]
If you want to leave the list, send E-mail to
[email protected].
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/[email protected].
If you have any questions or concerns regarding the management of the
list,
please send E-mail to [email protected].
---
Gamers mailing list __ [email protected]
If you want to leave the list, send E-mail to [email protected].
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/[email protected].
If you have any questions or concerns regarding the management of the list,
please send E-mail to [email protected].
