Just smash the buttons, man (or, a regular dev's road to Unity UI)

Ok, the title may be a little misleading. Stupid, but also misleading. The theme of this devlog is menu sounds. 

So, for a beginner, life should be simple: You want sounds to your buttons in unity, go find a tutorial, do what they do, and that's it. But I also do this for fun, so I didn't, until I actually had to.

The first thing, whatever approach you choose, is to find the sounds. I found 2 sources for that: https://www.zapsplat.com/ and youtube creator dashboard. Admittedly, the second one I found out through a youtube guy that talked about getting sounds. That part I looked up as every normal person should (

* Obviously not sponsored

Next thing is to somehow play the sound when you click a button. Unity has a component called AudioSource, that can play sounds, so I attached that to the GameObject that holds the logic for the buttons, and is also the parent that is highest in the hierarchy of my menu. It holds a script that has all the sounds that need playing and the logic to play them. So when the button that is clicked fires an event, the parent is notified, and plays the sound. And it works, most of the times. 

So, now the question you could have is, when does it fail? Well, some of the buttons also fire events for changing scenes, for example: reset, quit to menu and stuff like that, so the sound is cut in half. That shouldn't be much of a problem, but it is.

Now comes the half-frontender in me: Let's make it async/await, and wait for the sound to finish, then do the thing it is supposed to. I had a bad feeling about it, but I wanted to do it, just so I can see it work.

So, the script calls for the async sound to play, and awaits its completion. The async method that plays the sound and then awaits the duration of the sound. So, all the logic just chills while the sound is played, and then continues with life. 

Problem #1: You have to stop the player from doing weird stuff everywhere while he waits! Your code awaits fine, but the guy playing your game has all the freedom to do whatever he likes while your sound is playing.  You can stop him from doing that in couple of ways. 

Solution #1: Be a strict parent!

- He can have control over his mouse, so he will know that the game didn't crash, but you can stop him from clicking in a number of ways. Slap a big "Loading" panel in his eyes, so there is nothing to click, or change the cursor so that the "loading cursor" notifies him something is happening. You can just put a semi-transparent panel to dim the whole screen (and also get in the way of collision).

Solution #2: Be a fun parent

- Show an animation, or a loading screen that has something fun to say, so the player is not annoyed. That also prevents him from clicking around.

Solution #3: Realize your method is stupid, and change it (go for the standard solution)

-So, the thing that bothered me is that I don't like waiting, however fun you have while waiting, if you are waiting a lot, it will get old. So I searched around, and I found that I could have an object that doesn't die when scene is destroyed, with DontDestroyOnLoad().

Ok, the ones who work in unity have been screaming at me from the start of this text, and I am sorry for that (if you are still here). The procedure is, create a new SoundManager object, that deals with sounds, whenever a menu sound is made, it should play it, and it should also be easily available, so you could make use of a modified singleton pattern (if you don't know, use google). It will not die between scenes, and it will never be created twice, if you make use of singleton, so you are covered.

If anyone needs more detail, or code snippets, I have those, I don't want to weigh down this article with everything at once.

Hope someone had fun reading this. If you have any questions or need more details comment freely.

Cheers