Joan Colimon

Project Overview

The AudioNaut

• Type: Audio Game (No Graphics)
• Developed In: 48 Hours for a Game Jam
• Engine: Unity3D

Summary

The AudioNaut is an audio-only game created within 48 hours for a game jam. It is designed to be played entirely without visual input, leveraging audio cues to guide the player.

Objectives

• Primary: Develop a complete, playable audio game within 48 hours.
• Personal: Investigate accessible entertainment and enhance sound design skills.

Project Inspiration and Research

In my research and engagement with communities of gamers with visual impairments, I noticed a significant gap in high-quality audio games. While some mainstream companies are incorporating accessible features in games like Spider-Man 2, God of War Ragnarok, and The Last of Us, these are adaptations rather than audio-first games.

To bridge this gap, I researched several audio games and watched interviews with developers to understand best practices in creating immersive audio experiences. This included studying titles like Blind Driver, Lost and Hound, and classic audio game by Kenji Eno, such as Real Sound: Kaze.

Tools and Technologies

• Unity: The main game engine, with all elements organized in a single scene with parent objects that activate as the player progresses.
• FMOD: Used for advanced sound effect creation and management, offering more comprehensive capabilities than Unity’s default options.
• Audacity: Audio editing software used to tweak and optimize sounds for integration into FMOD.
• ElevenLabs.io: AI voice generation tool, chosen to create human-like voices for a more immersive experience.

Development and Game Mechanics

The entire game is designed to operate within a single Unity scene, leveraging a structure where elements are activated sequentially to play specific sounds. Each element is an object that, when activated, plays a series of sounds. Upon completing its sequence, the object deactivates, triggering the activation of the next object and its associated audio playback. This pattern is consistent across various game stages, including language selection, game over and winning parts and the main gameplay loop.

Language Selection

• When the game starts, players choose their language. Depending on the selection, a different structure of objects is loaded, ensuring the appropriate audio cues and instructions are played in the selected language.

Main Gameplay

• Navigation and Signal Detection: Players use audio cues to locate radio stations.
• Station Interaction: Players repair stations by holding the space key, filling a repair meter from 1 to 100.
• Return to Ship: After repairing three stations, players follow audio cues to return to the ship.

Game Reset

• When the player loses, the game resets the positions of objects and the states of repairs. This ensures that each new attempt starts from scratch, maintaining simplicity and efficiency in the game’s design.

Justification for Single Scene Approach

• Simplicity: Managing all elements within a single scene simplifies the development process. It reduces the complexity associated with scene transitions and ensures a seamless experience for the player.
• Efficiency: This approach minimizes loading times and resource management overhead. By resetting object positions and states, we can efficiently manage game state transitions without reloading scenes, ensuring a smooth and responsive gameplay experience.

Game Loop Design

1. Start and Setup

• Language Selection: Player selects the language.
• Tutorial and Story Introduction: Brief tutorial to introduce controls and story context.

2. Main Gameplay Loop

a. Navigation and Signal Detection

• Objective: Locate the first radio station.
• Mechanics:
  • Use directional controls to navigate the map.
  • Follow audio cues that indicate the strength of the radio signal.
  • Audio cues become stronger as the player approaches the station.

b. Station Interaction

• Objective: Repair the radio station.
• Mechanics:
  • Once within range, press the space key to start repairing.
  • Hold the space key to fill the repair meter from 1 to 100.
  • Avoid rapid key presses due to cooldown mechanics.

c. Repeat for Multiple Stations

• Objective: Repair a total of three radio stations.
• Mechanics:
  • After repairing each station, audio cues guide the player to the next station.
  • Each station’s repair process involves the same mechanics as the first, with potential variations in signal strength and obstacle placement to increase difficulty.

3. Return to Ship

• Objective: Return to the spaceship.
• Mechanics:
  • After repairing the third station, receive a signal directing back to the ship.
  • Navigate using audio cues, similar to the initial navigation phase.

4. Endgame and Evaluation

• Objective: Successfully return to the ship before the oxygen runs out.
• Mechanics:
  • Final navigation challenge, potentially with increased difficulty or time pressure.
  • Audio cues continue to guide the player back to the ship.

End States:

• Success: Player returns to the ship, triggering endgame audio narrative and credits.
• Failure: Oxygen runs out, triggering a game over audio cue, with an option to retry or exit.

Feedback and Iteration

Feedback Highlights:

• Game Controls: There were suggestions to add the game controls to the descriptive text below the game for better accessibility, as some players missed them during the initial playthrough.
• Tutorial and Instructions: Feedback indicated a need for a more interactive and less overwhelming tutorial. Breaking down instructions into simpler, self-paced steps would help players better understand the game mechanics.
• Immersion and Urgency: Players appreciated the immersive experience and the sense of urgency created by the sound design, although the intensity of some audio elements (e.g., the character’s breathing or the volume of the voice at the satellites) needed balancing.
• Rotational Controls: Many players found the 90-degree rotation too coarse for precise audio navigation. There were suggestions to include finer rotation controls or options to freely rotate while keeping 90-degree snap buttons for quick turns.
• Boundary Issues: Some feedback highlighted issues when reaching the spaceship at the end, where players could overshoot the target area, causing confusion and potential disorientation. Implementing boundary checks to prevent this would improve the user experience.

Applied Changes:

• Sound Adjustments: I tweaked the sound values to improve the calibration and ensure a more accurate and immersive audio experience.
• Controls in Description: The game controls were added to the descriptive text to ensure players could easily reference them.
• Tutorial Enhancements: Future iterations will include a more interactive and segmented tutorial to ease new players into the game mechanics.
• Rotational Control Options: I am exploring finer rotational controls and possibly adding Q/E keys for 90-degree snaps for more precise audio navigation.
• Boundary Enhancements: Added boundary checks at the spaceship to prevent players from overshooting and getting disoriented.

Lessons for Future Projects:

The feedback received was incredibly valuable and has informed several key lessons for future projects:

• Interactive Tutorials: Creating tutorials that are easy to follow and allow players to learn at their own pace.
• Flexible Controls: Offering multiple control schemes to accommodate different player preferences.
• Player Feedback Integration: Continually seeking and integrating player feedback to refine and improve game mechanics and overall experience.

The overall feedback was positive, with many players praising the immersion and sound design of The AudioNaut. I am excited to apply these insights to future projects, continuing to explore the possibilities of audio games and striving for even greater accessibility and player engagement.

Conclusion

Working on The AudioNaut has been a transformative experience, enhancing my skills in sound design and accessibility. Creating an audio-only game within 48 hours challenged me to rely solely on audio cues for navigation and interaction, which proved to be both demanding and rewarding.

Through this project, I learned the critical role sound plays in creating immersive experiences. Tools like FMOD and ElevenLabs.io were instrumental in crafting a rich audio environment. Testing the game with both blind and sighted players provided positive feedback, confirming the effectiveness of our design choices.

The experience reinforced my commitment to developing accessible games and has shown me the importance of inclusive design. By focusing on sound, I was able to create a game that not only entertains but also highlights the possibilities for more inclusive gaming experiences. I am excited to apply these lessons to future projects, ensuring accessibility remains a core focus in my work.