If there’s one thing I hate about the development platform of choice (Game Maker), it is the sound engine.
It seems to be lacking so much, both in functionality and stability, that my stomach twists every time I remind myself that my games do eventually need sound effects.
Caveman Craig 1 was whipped up in a month; we had a deadline. As a result not much time was spent on sound. We had to rely on what GM could provide and cop any of the idiosyncracies it has, like some WAV files not loading / playing at all, weird buffer issues, and very limited functionality.
This time round, with CC2, I’ve spent some time researching possible sound engine alternatives. The major problem was, however, that CC2 will not just be released on Windows, and so we couldn’t rely on DLL’s and extensions for all platforms. So I went back to Game Maker to see how I could work with its sound engine. And I believe I’ve had some success!
Firstly, the ‘buffer’ issues I always found in my other games weren’t really buffer issues at all.. I don’t think. There is a “sound_loop” function, but I previously used “if !sound_isplaying() then sound_play();” instead, as it meant as soon as the action stopped (say, preparing fruit), so would the sound associated with it. I wouldn’t need to check if the action had finished and execute a “sound_stop” function. It was laziness on my part, I guess. But I’ve discovered that the “sound_isplaying” function is 1 step/frame out of sync. So, if sound X is not playing, the above code would return true twice before it realises the sound is playing: enough time for the game to play the sound twice, 1 step apart from each other – therefore giving off the impression the sound is not playing correctly. If I discipline myself to use sound_loop and sound_stop, we might not get those issues. Alternatively, if YYG fixed this minor glitch in an update, I will kiss their feet.
Secondly, positional audio in GM is not great. And this is why: each sound file that you load has an ‘index’. You set the position and volume of a sound based on that sound index. So, for example, if you have 5 rocks landing in 5 different places at the same time, and they all play the same sound, only 1 position and volume value can be used. My solution, forgive me if there are technical limitations to this approach (I don’t know how it works in other programming languages, really), would be to give each instance of a sound playing an ID, and choosing the position and volume on a per ID basis. That said, realising that most of the positional sounds are either short or not often played (a rock landing plays a short sound, and the sound of a velociraptor dying is rarely going to play twice, and when it does, positional problems aren’t really going to matter), it looks like we can work with the GM engine after all.
So far, we have implemented a number of the sounds from the original Caveman Craig for testing purposes, and this seems to work just great. I’m looking forward to showing you some more ‘lively’ gameplay teasers soon. Perhaps even with a touch of Ricky’s musical presence!