The Labyrinth

An audio game's development blog -- In partnership with RIT and ABVI

[labyrinthaudiogame-blog]

June 26

THE CODE IS UP AND RUNNING.  We ran briefly into some quicksand with transferring files to the new developer, but we’ve got it fixed and ready to go. HIGH HO DEVELOPMENT.  There are also some pretty rad ideas bubbling up regarding introductions, tutorial interactions, and mythological elements as well. The team is working on wrangling some minotaurs, fawns, wraiths, dopplegangers, chimeras, and more so that we can get the best quality sound out to our future players.  Wish us luck! More updates to come. 

[labyrinthaudiogame-blog]

May 20, 2015

We’ve hired a new team member for the group! Welcome Valerie as the main code developer for the Summer Semester! 

[labyrinthaudiogame-blog]

May 14, 2015

Graduation and finals have been in full swing and we’re processing all the great feedback we received from Imagine RIT. We’re going to head over to ABVI’s headquarters in a few days to talk to their Voice of the Customer about further feedback and development ideas.  Over the summer we want to really get cranking and get a full level finished. Now that some of you have had a chance to play with the interactions and tell us what you did/didn’t like, we want to apply that information and make a really fun game. More updates to come! 

[labyrinthaudiogame-blog]

Video for Imagine RIT at the Rochester Institute of Technology (2015). Labryinth Audio Game: Developed in partnership with the Association for the Blind and Visually Impaired & Goodwill. Direction and consultation from coaches at the RIT Simone Center for Innovation and Entrepreneurship and the Media Arts Games Interaction and Creativity Center (MAGIC). All sounds from FreeSound.org Character Illustrations by Ashleigh Butler Narration (not included) by Meghan O'Donnell Video development by Lauren Harradine

[labyrinthaudiogame-blog]

April 19, 2015

Rough draft of the world’s most fun game design doc (I mean it’s pretty great) is finished and ready for team review at the next meeting. It’s nice to have a reminder of where we are and where we’re going.  We are officially exhibiting the game in all it’s progress and glory at Imagine RIT in just under two weeks. We're planning to make a 3 sided display board as well with information about the team and Zane is working on code for a demo. Zane and I were playing with the idea of letting people download (Zane would put it on their phones if they wanted) the demo because it shows off the game without BEING the game and would be an easy, subtle way to spread the word about it. Who knows, maybe we’ll even be able to share it online?  The demo itself will be like a scene-select for the game in that visitors can pick one kind of interaction to practice with. For example, they can select "Try Walking" and play through a bit of the level in which they learn how to step, get up to speed, maybe dodge obstacles, and make turns at crossroads. Other interactions would include opening doors, fighting a monster, interacting with an item room, a trap sequence, etc. but is limited by how much he can finish coding by then. As far as I know, Zane is very confident with his ability to make these segments functional for initial interaction demonstrations so that we can get feedback about how well they work for potential users. I’m also considering adding a fourth graphic level to the audio output- Green for Narration. The only thing that would prevent it would be the screen becoming too busy, but there might be some fun ways around that.  We're also working on a simple video that will involve either brief animations or live-action clips of people acting out what the characters will be doing in the game, but it will cut to black and focus exclusively on the sounds mid-clip. To better explain, if we're showing a clip of a character fighting a monster, we would have the person walk around for a little while, then look surprised and draw their sword, and then cut to black and have the rest of the fight scene come about strictly through sound. As suggested by one of our coaches, Professor Jacobs, this will parallel the actual experience of the game, save a little bit of time in recording studios and such, and also give us practice with orchestrating sounds for the scenes in the game. It’s also just kind of a fun thing to watch and an easy way to explain what’s going on in the game.  We also have plans to *hopefully* write, record, and finish an example of a cutscene, but we need to discuss it further in our next meeting. Our main focus is on functionality and finishing the code for main interactions right now, so this is on the "Would be nice" list along with animations and such. (Basically the "Would be nice" list is my list of things to try to work on and finish.) Right now we're just using pre-recorded sounds from an online database, but Forrest will be jumping in soon to start recording, manipulating, and implementing sounds for a more finished demo, though we pushed this to summer development.

[labyrinthaudiogame-blog]

March 9, 2015

New update style- We want to start updating this tumblr as we brainstorm and ideas come up. So far we’ve been playing catch up through older journals, but it’s all new from here on out.  One other interaction idea we were thinking of recently was having the “free run” or Temple Run-esque scenes be triggered after certain open areas for a short distance. This would keep the user on their toes and provide a brief break from the overall story and level goals.  We also just played through a brief audiogame called “Blindscape” which gave us some real inspiration for solving the “WHERE’S THE ITEM” dilemma we’ve been working with. In combination with an itemfinder type of cue (shown through graphic and audio representations as a specified tone and color sequence) the user would be able to approach an area where an item is located and then enter a kind of cut-scene where the character would say “I think there’s something here!” The user would then only need to tap around the screen to find the item and collect it. Once the item is found, the character will snap back into map-space and continue their travels.  Our school hosts a huge annual event called Imagine RIT in May, and our group has been asked to apply to present there. We’re excited at the opportunity and want to use this demo period to our advantage, testing out the different control and interface ideas we’ve been working on all semester, and to get feedback on our initial concepts. Hopefully this experience will give us some more information about what people like about our game, what they’d like to see next, and what they think can use some alterations/extra work.  Chins up and moving forward! On to The Labyrinth! 

[labyrinthaudiogame-blog]

Example of what we might use for the audio cues in the game. Basic graphics. 

Blue- walking; Yellow- item cue; Red-enemy/monster cue.

Sound sources from freesound.org: cave steps & ambiance: https://www.freesound.org/people/Timbre/sounds/75413/ roar 2: https://www.freesound.org/people/Aetherspire/sounds/263472/ happy flute: https://www.freesound.org/people/madmerv/sounds/27170/

[labyrinthaudiogame-blog]

March 2, 2015

Lauren (general update): So we're beginning to flesh out a potential marketing scheme for the game (target market, how we'll advertise, where we'll need to allocate resources, etc) and have decided to officially start working on our online presence. We plan to post video & text updates, sound blurbs/examples, and graphics such as the logo and map generation examples to hopefully get some people excited about the progress we’re making!  As far as gameplay, we have been considering playing with minimalist graphic elements so that sighted users can know the game is a) loading and b) have something to look at and keep them engaged. However, we maintain the the need and desire to make sure that all important game-related play is purely audio based. Examples of the graphics would be a loading animation and, potentially, an activity dial which would flare up (I'll try to find an example to show everyone) which would spike when the user walked or performed an action. Forrest also suggested that we could have a faded screen in the background with the logo or some kind of image that would fulfill a similar function. We figure it's a reasonable compromise because those actions would also be signified with sound cues and the graphics, again, would be very basic. In addition to these developments, we've been playing with the idea of using voice-command software in the game so that users could have the option to say "Menu" in addition to or instead of using a swipe/tap control mechanism. This option would be decided when the user opened the game so that they could alternate between the two as their surroundings/situation allowed. Forrest and Zane are working really hard on the user interactions for the game and smoothing out the basic bits such as map generation and command-to-sound triggers. We're feeling pretty confident and are hoping to have a fun beta to premier at Imagine RIT by May. Still on track.   We also took some time the other day to look back at our original notes from our first meeting with the Heart of the Customer and expectations of the game. It was reassuring to be reminded of what the game's core elements need to be for once beyond all of our little details and "What ifs".

[labyrinthaudiogame-blog]

February 23, 2015

Zane:

Forrest and I spent the majority of the meeting discussing user interaction and how we could incorporate the running aspect without visual cues. First we talked about the screen input styles and came up with how the screen will be divided. The left and right most sides of the screen will be reserved for the stepping and running buttons, in order to continue forward. The center section of the screen would be reserved for all other swipe and press actions. Swiping up would cause the player to jump, sliding down would cause the player to jump/crouch, depending on whether or not the player was moving at the time. Turning left and right would obviously be left with swiping to the left or right. The ‘action’ button, the interaction which can change with the situation, would be left with tapping the screen. This could be in certain intervals, patterns, areas.

Next we discussed  how we would navigate an area, namely when running. The problem arose of not being able to know when something was ahead. So we came up with the idea of warnings, but we wanted to avoid annoying noise or nuance breaking sounds. So for example, when approaching a patch of water you could fall into, your footsteps would become wet steps instead, and you would know the water was directly ahead of you. Didn’t changes in your environment could indicate different traps or moves. Like the sound of a snapping string when approaching a trap.

[labyrinthaudiogame-blog]

February 2, 2015

Zane: On Monday, Forrest and I met to discuss the gameplay aspects of the game. We mainly wanted to focus on how the user would interact with the environment and what would draw the player into the game and make them enjoy their time. The first aspect we looked into was movement. Many games, including Papa Sangre, make the character move around an open environment, which can be disorienting and at times boring when you spend a length of time searching for something, only to just miss it numerous times as you walk by. While free movement isn’t a complete loss, it does take more patience than most players usually have for mobile games.

Based off of this, we discussed set-motion games. these would be games similar to Temple Run and such, that set you in a direction. We spent a fair amount of time discussing the possibility of a run factor involved in the game. This would include sound cues that the player would have to react to, like a trap springing or running water you have to jump over or avoid. Pings or other noises to the left and right would cue a swipe to turn effect. ( Would this limit exploratory abilities? Temple Run involves minimal autonomous interaction with the environment and would create a straight up reaction-game. Still a fun idea, but a very different concept from what we’ve been discussing. )

Another possibility we discussed was turning to face pings that can be anywhere around you. Similar to an ear test, where you may hear a tiny ping and have to face, but in this case there would be a blood thirsty monster to fire at (or minotaur/enemy). A small problem arose from the quality of audio when it comes to differentiation between noise in front of you and noise behind you. This was something we decided we needed to look into for more information.

We spent a small amount of time talking about audio cues within the game; changes in footstep noises, mumbling, running water to show environment. The idea of a guide character came up as well. Guide characters are often essential to player in order to show them what to do, without being blunt about it. They can give hints like “Maybe we should knock,” cueing the player to tap the screen. One idea for a guide character is another survivor in the Labyrinth. This would allow for a strategic aspect. That character could distract the enemy/monster while you set up a trap or vice versa. The other idea we were still entertaining was the idea of your sponsor, the person who placed you in the Labyrinth, contacting you to give you information, directions, add a little tension in the game and drops “Big Picture” information essential to keeping the mystery of the story alive. This person would communicate through a mic in one ear, that only the player would hear. Forrest: We also briefly brought up the concept of voice controlled games such as There Came an Echo which use API’s like Microsoft’s or Intel’s and the phoneme recognition that comes along with that. Phonemes are parts of syllables that make up words when processing spoken word using voice recognition software. We discussed the possible error that might be involved in this, but also brought up was the impressive degree of accuracy shown for some other games made using these. That said, we also thought that to avoid error prone problems in such a context we could try recognition of simple phrases or sounds.