Atomic Reaction Sounds

We have sounds for reactions between atoms now, so you can hear when the level catches on fire, or when acid corrodes - even though there may be hundreds of atoms reacting!

And, let's talk about casting spells: how can a solo developer make sounds for each of the hundreds of possible spells in this game?

(Spoiler: dark FMOD rituals... after spending some hours reading the manual.)

The levels in this game are composed of millions of pixels ("atoms"), some of which can react with each other - for example, water quenches any burning atom, and acid will eat through most atoms.

Obviously these "reactions" should play sounds, but naively playing a sound for each reaction would result in an earsplitting cacophony of sound: even a small blob of acid eating terrain would play hundreds of sound effects.

Instead, I play just one looping sound for each type of reaction, by calculating the average location that the reactions are happening at: ¹

Click to play (needs sound!) The red crosses show the weighted average reaction position, which is used to position the sound relative to player characters; if you're wearing headphones you can hear where the sound comes from.

This system isn't perfect: for example, it's possible for a far away large-scale reaction to "pull" the sound position away from players, making sounds softer than they should be.²

But since reactions are usually caused by players near themselves, it should be okay for now?

Casting Sounds

In most games, when you cast a spell, you hear a predetermined sound that's synchronized with the spellcasting animation.

In this game, the spells are formed dynamically, by mashing together elements in combinations like "Fire, Acid, Arcane" (Burning Corroding Death Beam) or "Shield, Life, Water, Fire" (Healing Bounce Mine) - so sounds need to adjust to mix of elements being cast.

Aside: When I started down this "atom-based elemental spellcasting" path, I hoped that just implementing sounds for atom reactions would be enough - but they are nowhere near "punchy" enough to make spellcasting feel good.

Fortunately, the FMOD audio library's whole shtick is dynamically adjusting sounds, so after reading the manual for a few hours I realized I could craft an adjustable "element active" sound:

Click to play (needs sound!) A demo of the basic 'elemental active' sound loop in FMOD Studio (FMOD's built-in sound editor). At the top I use the mouse to adjust how much of each element contributes to the mix of sounds (which the game does itself during gameplay). The amount of an element sets the 'cursor' position (white vertical line) on the sheet (middle of the screen) between 0.0 and 1.0, which can then 'automate' (control via those red horizontal lines) volume or crossfading between different sound samples. For example, you can hear that a 0.05 of water is a soft hiss, but 1.0 of water is a loud waterfall.

Combine that with an adjustable "element impact" sound and with a bunch of spell-shape-specific sounds, and you get spell sounds!

Click to play (needs sound!) A small demo of some spells with sounds.

I also updated my over-complicated spellbar animation system to support playing sounds when elements get summoned or combined too.

Playable web build‎

Aside from the stuff above, I've also fixed a bunch of bugs that were piling up - for example, arrows can no longer fly through walls - and added a few more sounds, like a splash sound when you jump into water.

Press F1 for help, including to see keyboard/mouse controls. Mobile devices probably won't work! By playing you agree to our Privacy Policy and Terms of Service.

I actually calculate them on a chunk-by-chunk basis (each chunk is 32x32 atoms), and use the per-chunk average positions to calculate a total weighted average position.

Or, a more complicated case: imagine 2 players at opposite ends of the screen, who both cause the same amount of acid to eat away at terrain next to them: the average sound position would then be in the middle of the two players, and so (because sound attenuation is based on distance of the sound from the closest player) the sound would be heard as being "softer" than it should be.

To be honest, I'm not really sure how to fix that elegantly: it feels like I should calculate sound positions on a per-player basis (only looking at nearby atom reactions) and blend between the multiple per-player sound positions somehow?

And, there's a similar problem waiting in the wings too: calculating "envelopment" of a sound. That is, in a singleplayer context, if there's a small reaction on the left and a large reaction on the right, you probably shouldn't only hear the sound in your right ear just because the reaction's sound position got "pulled" to the right.