Audio System
Soundtrack
-
Soundtrack -
Guncaster Soundtrack
-
Guncaster Soundtrack -
Overview
Give it a listen!
The audio system in Guncaster evolved from a simple sound playback manager into a robust, gameplay-reactive system. It started as basic functionality for 2D, 3D, and music playback and turned into a dynamic, efficient, and highly customizable toolset that enriched the player experience.
Contributed Breakdowns
AUDIO SYSTEMS
Features
Some of the details I used to Add immersion to the gameplay experience:
Audio Pooling and optimized playback using Unity’s IObjectPool
Volume sliders per sound category + global master
Combat and ambient tracks that blend based on game state
Scriptable objects for sounds that Configure pitch, loop, mixer group, and falloff
Pitch variance to repeated sounds
Audio pitch changes with time scale
Sound Playback Control:
Single: One instance allowed at a time
Frequent: Queued to prevent sound spam
None: No checks in place
Timeline
Iteration 1
This sound system was straightforward and inflexible. It allowed developers to call sound cues through script only, featuring three audio types; 2D, 3D, and BGM clips. It did feature dynamic music fading, a feature we would later utilize. For testing purpose it worked just fine but lacked any meaningful impact.
Iteration 2
Entering late into development, the sound system rework helped fix issues we were having whilst adding to the overall game experience. The audio could be called by events, was being pooled, used scriptable objects for common sound settings, and utilized mixer groups among other things. Best of all, the sound system reacted with gameplay making it that much more immersive.
Breakdown
The original audio system in Guncaster was a simple manager that handled basic sound playback in 2D/3D space and supported background music with dynamic combat transitions. It worked, but it lacked flexibility, performance optimization, and depth. In the final stretch of development, I completely rebuilt it into a far more powerful and responsive system
The new audio system is built on Unity's IObjectPool, ensuring that sounds are efficiently reused instead of constantly created and destroyed at runtime.
At its core, it uses ScriptableObjects to define and assign sound configurations across gameplay elements. configurations could control looping behavior, pitch variance, falloff distance, and the target mixer group for fine-tuned audio routing.
Additional performance enhancements included the introduction of frequent sounds and single sounds. Single sounds prevented overlapping by allowing only one instance in the scene at a time (useful for UI), and Frequent sounds, which use a queue system to limit how many can play at once, reducing audio spam and preserving clarity.
Mixer groups are fully integrated, giving players volume control over different sound types via in-game settings. A global master slider controls overall volume, while additional sliders handle SFX, music, and ambient layers separately.
It featured blending audio tracks for both combat and passive music tracks. These blends happened based on game state and really added flavor to the combat in game.
The cherry on top for fun and interactive sounds was my introduction of dynamic pitch. To push immersion further, all audio pitch was tied to the game’s Time.timeScale. When time slows down for a punch or during menu transitions, sound pitch shifts in real-time with it, creating a cohesive and cinematic experience.
What Went Right
The sound system did more than just play sounds and music at the end of the day, it actually interacted with the game in a fun way. This was something I had intended to work into gameplay and was surprised at just how much it added. The pitch shifting during combat added a lot of oomph to the punches and pig impacts.
The settings control was extremely easy to setup and extended into subsections easily. This made it able to hit multiple points of audio. For example, you could control volume sliders on the music, the spells, the enemies, the environment, and if I wanted more.
The way the system turned out made it really easy to call sound cues via inspector events which made design a breeze.
The music fading which started in iteration 1 was very easy to port into iteration 2 and was the perfect touch to round off the way the sound system interacted with gameplay.
What Went Wrong
What went wrong with the sound system was mostly its first iteration phase. a large majority of the project utilized it and it became a pain point in the projects final stretch as we were adding sounds to the game. To add to that, coding a system rework in the final month of development was not smart, it worked in the end but could have been disastrous if it failed. Lastly, the combat and non-combat track fading was a last minute addition, that happened because we got our soundtrack done late. This is another one of those, “I’m sure glad it worked" moments that could have been bad.