Cadet 227 - Developer Diary Entry #2

Listening to: Nothing.

Thank you for the continued support! It’s very awesome knowing that people want to see something like this happen. I’ve even got a few e-mails from folks volunteering their help, as a voice actor or to help with sound music! I can’t even wrap my head around dialogue trees just yet, as you’ll understand near the end of this post with the difficulties that arise with simple room descriptions. I will address the dialogue game mechanic in a later post though since, in all honesty, I have thought about it. That’s not to say I won’t need other voices though. A person can only listen to my voice for so long before wanting jump out a window.

The correspondence with visually impaired computer users continues as well as additional outside research. It looks like JAWS is the main screen reader, so I’ll have to download a demo and try it out.

I’ve learned that when the online Flash version goes up, which is only a piece of the game due to its size, it will have to be embedded in a very plain page. Just like how we scan through pages and look for keywords within sites, I’m sure we’re all guilty of blazing through an RSS reader for posts that appear remotely interesting, visually impaired computer users do the same. The problem is that they have to listen to each piece from beginning to end or skip it. That means while we can pick up keywords at the end of a sentence or even in the middle, visually impaired users must get the gist from keywords at the beginning. They can’t skip to the end. They can’t skip to a word in the middle. It’s possible to change the speed of reading on the reader, but there’s still no jumping around. All in all it’s a new way to view how sites are to be laid out to provide the best accessible user experience.

This is another reason why the full game will have to be a download. I don’t want to have to have a user go to the site, navigate to play, enter the page, tab to the embedded file, turn off their screen reader (there are certain keys on the keyboard attached to functionality within the screen reader, like “B” being like Tab, cycling through elements on a page), play the game, turn their screen reader back on and possibly confuse them on how to move on to another site. Also keeping track of customized settings for different screen readers is impossible, so it could end up as a big punch in the face. As a download, expectations for what’s going to happen are set in place. You know you’re going to start an application and can set the screen reader to the appropriate settings, rather than trying to figure out a workaround in hopes it doesn’t conflict with any other accessible software running.

The game is planned to use a few keys. The arrow keys will have you move from room to room. The spacebar is the action button. The keys A, S, D and F are the other keys: secondary action (kind of unsure of this), repeat the last piece said, brief description and full description. You never have to move your left hand from home row and right hand from arrow keys. I believe ESC will be the only time you move your hands, and that’s to quit the application. The game saves at every room, so there’s no real fear of losing progress.

As a player moves from room to room, they are not forced to listen to the full room description. They’ll most likely check out a full description the first time they enter a room for the first time by pressing F, but there’s no reason to hear it all every time you walk in. The brief description, accessed by pressing D, will simply list the room title and the exits. This keeps me in check in making sure that the mental map created from navigating the station and mine is compelling, but straightforward. People would probably shoot me if I decided to make the mine 27 4-way intersections with 11 turns at every section. I can barely remember where I leave my wallet without drawing a map.

While writing the script and recording the audio, I have to find the right places to split the pieces. If the player presses any key during dialogue, it will skip it and move onto the next part. They can press the S key to repeat the last thing said. An issue I can see is if a dialogue block plays, let’s say it’s in three parts, and the player presses the S key during the second part. Will it start the second part over? Will it start the first part over? How will it continue the dialogue block? I have an idea in place, but these are the things that need to be tweaked to make sure the experience isn’t annoying as hell and allow players to feel like they can move at the speed they want to.

This is another reason why copious amounts of dialogue for one situation or description will be avoided at all costs. I can imagine a person sitting through three sentences/parts in a dialogue block, but not fifteen.

I just realized that allowing any key to skip dialogue may prove to be a problem. The player won’t know which part they can skip and which part of the dialogue block they will start next. They may then press to skip repeatedly and end up skipping the whole dialogue and accidentally starting it all over again (imagine using F to skip dialogue). Maybe I will shift repeating the last dialogue string to A and skipping the dialogue piece to S. I know some users will have the patience to listen to the start of a dialogue piece before skipping, which may mitigate the problem, but I’d hate to punish those who don’t.

The initial tutorial is written. I have the story, not actual dialogue, written up to the end of the first day of mine scanning. The mine scanning takes in-game days. The first day will be very short, allowing the player to understand how it works. The second day will be the longest in the mine. The third will be the big climax inside the mine, station and everything else.

I’m currently looking into the cost of licensing James Taylor’s “You’ve Got a Friend”. From the way things look, it’s going to be prohibitively expensive for Donationware. If it’s possible to work something out, it will play a hopefully memorable moment in the game.