I’ve been somewhat dreading adding sounds to the game. But I have to, there is no question. This just means finding sound assets, choosing them, and all the tedious finicky work that comes with it. Thankfully, the technical details (which I can describe below) are fairly easy with Unity and some organization.

Now, I do not want to directly link any sound clips to weapons or whatever. The main reason is that I want them all organized and I am likely to reuse and swap clips around. I want to be able to do this quickly. In other words, all my clips will live in an asset:

I already have a sound manager system, which is where I will reference the clips.

And the asset can then have a list of all the sound effects and the clips that should play for it.

Adding new effects is a matter of adding new entries:

And it’s much easier to add new entries than to actually find clips for them. In fact, knowing myself, I am adding a warning for clips I’m using multiple times:

And then I can start adding the “abstract” sound effect value to whatever things need them, such as weapon fire sounds in weapon definitions:

I can then wire the player and mobs to ask the sound manager to play that sound effects when they fire. Sound manager can look up the appropriate clip.

I can pass the coordinate of the sound and convert that to a real-world position to play the sound at. For example, player is pretty much always centered. But enemies can be in any direction, so the sound should reflect that slightly.

One problem is I need to also control some other properties of the “origin” of the sound. Such as volume. But I don’t want to hardcode any of this either, so another asset it is:

This can define how different “sources” produce sound. For example, enemy gun shots are slightly muted, because there’s so much of them.

And here’s how it all looks:

Hmm, well I guess here we have the fundamental problem of blogging about sound. Just say “pew pew” noises whenever you see screenshots from now on.

I can similarly define a mob hit sound:

And then have mobs specify this in their definition:

The the player and mobs can trigger these. But these are very subtle, because there’s a lot of them and they are generally “less important”:

It’s hard to explain what sounds right, because to me everything sounds wrong — I’m just not a sound engineer and never will be.

Through all this I’m discovering an issue I didn’t quite consider, because I never quite made a game with the camera system I have here. In short, the camera doesn’t necessarily point at the play–in fact–it rarely does. This means the audio listener, which is what Unity uses to decide “where” the player hears from, is not where the player actually isL

This is weird, because the player hears their own shooting as offset to the side if they pan the camera. This is logical, but it’s weird to listen to. In other words, I need the listener to follow the player. I cannot just put the listener stuff on the player, because Unity needs a listener and it can only have one, so I have to make it part of the camera system and only tell it to move to player during gameplay. So the hierarchy now includes a dedicate listener positioner logic:

And this is much better.

But there’s another much more complex issue that is now apparent. If the player fires a shot and stays still — all good. But if they then move, so does the sound. In other words, the sound comes from where they originally made it (blue – player, red – sound):

And again, this is more or less logical, but completely weird with the sort of camera and layout I have here. If the player runs and shoots a weapon they hear the shots “behind them” and that’s just wrong. So I need to move all my audio sources together with the player. This is getting messy very quickly.

Thankfully, I can think of the entire positioning differently. I don’t actually care where the sound is, as long as it is heard correctly. I don’t actually need to move the listener if I spawn the sounds relative to it. In the game world, the sound is somewhere around the player. So I spawn the sound relative to the listener at the same offset. Then the player can move wherever they like, the sound will remain at the same location to the listener — because neither move (green – listener, orange – actual sound):

So instead of camera system moving the listener, I will have the sound system position sound playback relative to the listener:

And this solves the issue nicely.

The issue is that now I can’t play any continuous sounds since I assumed everything is “absolute”. That is, if there is some object emitting a constant sound, it will keep emitting where the player first heard it. That’s what I want for my gunshots, bullet hits, explosions, etc. But that’s not what I want for continuous sounds.

For example, I can add a teleport buzzing sound when the player gets near. I can define it for my prop:

But now I need a whole new logic for my continuous playing audio sources, because I will be moving them around as the player moves. So I set up the hierarchy and new scripts:

And the actual source is a pooled element that will remain active as long as needed:

For this, I need to add some timed logic to the props to detect when the player is near and activate/deactivate the sounds.

So now the continuous audio sources keep the same distance to the listener as the player is to the prop. They are set up as 3D sources, so they fade away as the player moves away and eventually fade to 0. Soon after, the prop also removes the source altogether. The logic is like this (green – active; red – inactive):

Disabling them altogether is somewhat premature optimization: to pool the sources rather than just leave them playing constantly and let Unity “optimize” sounds it can’t hear. But I rather do it now and avoid issues later, since I have to control them anyway and I can let the pool handle all the updating. I might eventually add ambience to a lot of locations, especially via level generation.

For now, I am also keeping all sound options standard, for example, the fade distance. I can all wire them on individual sound effect basis, but it doesn’t seem like it matters much. Volume control is sufficient for pretty much anything I am doing now.

So that about wraps up the technicalities of getting sound effects working. The rest of work is just adding them to everything that needs aural feedback and finding clips that I like and can use. Mostly just trial and error until it sounds right.

MicroRogue DevDiary #69 – Sound effects
Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *