Setting Up

Importing Bard Audio into your GameMaker Project

Visit the Releases tab and download the provided .yymp file. Then, in GameMaker Studio 2, load up your project > click on "Tools" on the main toolbar > Select "Import Local Package" from the drop-down menu > then import everything from the Bard Audio local package.

Hooking Stuff Up

Look through the script called bard_audio_system to see some of the main options you can toggle. You'll probably want to set some things differently to suit your project. You'll also need to make sure you have the file sandbox DISABLED inside GameMaker so that the editor has access to your project folders. You can find that setting in "Game Options."

There are a few key scripts you'll want to actually implement to hook this system into the flow of your game. Check out the List of System functions here. There is a persistent global object called objAudioDemo included in the project which implements all these functions to a very basic extent, but you might want to hook them up somewhere that makes sense for you.

Once you are set with that, you should try running your game and have it start in the new 'rmAudioEditor' room that's in your project. This room is the visual editor and will get you to provide your project location to it, then load in all your audio assets and be ready to start designing effects. There are some additional considerations if you want to import external audio assets.

Understanding 'Containers'

Rather than working directly with audio assets, this engine mostly works with audio folders as a way of constructing events out of multiple audio assets. These are built directly from folders inside your Game Maker project, or loaded from external ones. We call these "folders with logic" containers. The terminology is borrowed from software like FMOD and Wwise and might be familiar to an experienced sound designer.

On the programming side, working with containers means you'll be using string names to identify audio events, rather than audio asset ids. Most logic and effects are meant to be designed in the Audio Editor, so that the actual programming tends to be very simple. An audio designer can create an audio event that fades in and out, or goes to a random pitch, or plays a sequence of sounds, or any combination of the above or more, and regardless of what the audio design is, the programmer simply needs to call container_play() to make it all happen.

General Workflow

Using this engine, the process for making audio in Wandersong and Chicory went like this.

1. Em, the sound designer created audio assets using a DAW (her preference was Reaper).
2. She imported audio into the GameMaker project, organizing it into neat folders and naming the folders in a pleasant way with unique names for each one.
3. She ran the game and used the audio editor to define logic for the audio she added. She could define if it was looping, continuous, random, etc. She could create parameters for the audio and hand-craft how the pitch and volume for different sounds would change based on those parameters.
4. She’d send me a list of new containers that she’d created that needed to play in-game.
5. I would add commands to play the new containers in the relevant place in code.

We set it up such that if Em wanted to make changes to the audio design, she’d change the room order in the project so that the game opened to rmAudioEditor when you compiled it. She’d make and test changes in there. When implementing her audio, I’d change the room order so rmAudioEditor was tucked away somewhere unreachable, and just test and play the game as if it didn’t exist.