IEP Objectives :  Expanded Core Curriculum Games for Visually Impaired Students

IEP Goals

ObjectiveEd.com is our new company where we are building Expanded Core Curriculum games for visually impaired students, based on each child’s Individual Educational Plan. 
The child’s progress in mastering skills in our curriculum-based games and interactive simulations are preserved in a private secure cloud, visible to the school team in a web-based console . 
If you are a Orientation and Mobility specialist , click for additional information on learning about these types of games as a tool for maximizing student outcomes, relating to their 
IEP and 504 plan .

Programming a Blindfold Game

I’ve been working on a new game – Blindfold Piano Tiles.  This game will, amongst other things, teach you single octave melodies, such as Mary had a little lamb.
To play the game, you lay the phone in landscape mode on a table, and press one of eight keys.  There are 4 keys on the bottom, numbered 1 to 4, and 4 keys on the top, numbered 5 to 8.  The game tells you which keys to press, such as 3, 2, 1, 2, 3, 3, 3 and then you press each key in sequence.

So here’s the problem.  When you press a key, it should sound the musical note while your finger is pressed and stop sounding when your finger lifts from the screen.  And if the game was saying something when you start playing, it must stop whatever it was saying or sounding, and respond to the key you are pressing.  Without that, the game feels unresponsive.
Here’s one way to program this:  when you press a key, anything that was being spoken stops.  If the game starts saying “Press each of these keys: 3, 2, 1, 2, 3, 3, 3”, as soon as you press the first key, all speaking stops.
When you press the first key, “3”, it stops speaking and starts sounding the musical note that corresponds to key “3”.  However, when you press the second key, “2”, it also stops speaking and starts sounding the musical note that corresponds to the key “2”.  Which means you don’t hear the first musical note.  And if you move through the keys quickly, you won’t hear any of the musical notes, except for the last one.
Another way to program this is to only stop speaking before the first musical note is keyed, and not have the second key affect the sounds of the first key.  That works, but then you encounter the next problem: remember, when you press the key, the musical note starts.  When you lift your finger, the musical note stops.
If you press and lift your finger too quickly, you don’t hear the entire musical note.  For example, if you quickly tap the “3” key, the note is only played for that length of the tap.  A quick tap might be as short as one-tenth of a second, and that’s not long enough to hear the musical note; you actually need about one-third of a second.
So, to program around that problem, you could make each musical note last at least one-third of a second.  But now, if you quickly tap 3 keys, your tapping will be ahead of the notes, so that the first musical note is still playing even though you’ve typed 3 keys.  And if you tapped the wrong key, it’s not clear which of the three keys was wrong.
So, to program around that problem, the game needs to prevent the user from typing faster than one key every one-third of a second.
To solve that, the game now says “Don’t type so fast”, and honks at you.  Of course, you won’t want to listen to the entire sentence of “Don’t type so fast” over and over again, so that the second time you type too fast, you just want to move on, and try again.  Which means the solution to only stop speaking before the first musical note is no longer valid – that sentence can occur whenever you press keys too quickly.
You wouldn’t think that something so simple – sounding a musical note when a key is pressed – would be so hard to program.  These are just some of the complexities of building a game, and why we test the games with so many different visually impaired people before publishing it to the App Store.