Implements

On Wednesday, I had the opportunity to actually integrate the early sound system build into a few projects to see if it would explode horribly. So far it hasn't, although a number of inevitable bugs have been revealed by the in-project testing, which were fixed on the fly.

The current version of the sound system is now active in Blockets, Bullet, and the non-GFS project Migration. It went straight into both Blockets and Bullet with no real problems, and the coder on the Migration Project (Michael the Machine) is currently working to allow the system to talk to the gameplay engine he's written (most of which sits outside Unity and interfaces with the scene through a single class).

There was some good feedback from my fellow developers about what other kinds of functions they would like to see in the system, as well, which I diligently wrote down on my list.

I also had a chat to the Islands team about sound for their game, and this was what really got me thinking - their game has five unique areas with distinct soundscapes, which means I need a bigger and more complex class structure to contain this stuff and allow things to be called when required.

Without further ado, this is a list of ideas that I will be considering for the next build of the sound system, in no particular order.

- functions to fade sounds in and out and set volume

- functions to set up sounds that need to be attached to gameObjects (and possibly functions to kill them if they are no longer needed)

- "Sound Scape" objects, which contain all the sounds for a specific area of the game, with master play, stop and fade functions

- "Sound Sets", which contain arrays of related sounds (eg. various similar explosion sounds), so you could do things like this:

• play the sounds from the array in a set or random order at a set or random interval
• play a random one-shot sound from the set

-"Paired Sound" objects, which contain an 'initialisation' sound (eg. a jetpack firing up) and a looping sound that seamlessly follows it

That's my thinking so far, and what I will be working on with regard to the sound system over the next week or so. Other suggestions for useful things to do with sound are most welcome!

Bang! (Clay pigeons are fuckers)

The first build of the Sound Effects Handler for Unity is go!

It is a single invisible GameObject that sits quietly in your scene until you invoke one of its public static methods from another script, whereupon it makes some kind of noise. It is dead simple, but it took a while for my thinking to progress to the stage where I could make it so.

The basic premise of the handler is that it centralises all of the sound effects contained in the scene.

As far as I know, Unity is designed to handle sound by attaching to objects AudioPlayer components, the functions of which are then called from that object's script. While this approach has its uses, it is one that I can only imagine would be immensely frustrating for a sound designer who had no contact with the game other than to provide sound effects.

Funnily enough, this is the role that I am taking on with all of the class' projects bar Horse. I decided that I wanted an interface that allows me to put all the sound effects into a scene and then say to my fellow developers this:

"Here are your sounds. This is what they are called. Here are some simple lines of code to make them play or stop, which you can call from any other script in the scene. Have fun, please try to leave my code alone, and call me over if you have problems."

And this is exactly what I plan to do.

At a glance, the SoundSystem prefab I have built looks like this:

The script property called "Sound Clips Input" is a public array where you put all your sound clips.

You may notice that some of them have pretty weird convoluted names that will be impossible to remember when you want to call one. The solution is in that Text File property of the script.

The Text File links up the names you want to attach to the sound with their initial file names. At the moment, it has to be set up by hand, but for the scope of these projects, it won't take long enough to be an issue.

In my example project, the contents of the text file look a little something like this:

blues=13-Gritty Harp 1

rocket=18380__inferno__hvrl

bang=65731__Robinhood76__00759_explode_2_distant

On the left, the new name for the sound. On the right, separated by an '=' symbol, the original file name. This gets read and set up inside the SoundSystem script when the scene starts. Simple, no? (As testing progresses this week, I will put some thought into if there are more efficient ways to manage this.)

The Sound Object Input property contains a template "Sound Object", which is a GameObject containing a blank AudioSource. This is what I use to create and play what I call 'state-based sounds' - those that loop continuously when an object is in a certain state e.g. character footsteps. This template shouldn't really be editable - I suspect there is a way to link up script properties to assets in code rather than the inspector, which I will look into in a later iteration.

At the moment, the Sound System script contains three public static functions with which developers need be concerned. They can be called from any script in the game. It does not require an explicit reference to the SoundSystem object within each script. Just use this syntax:

SoundSystem.functionName(parameterA, parameterB);

These functions are as follows:

playOnce(string Name, GameObject Caller)

This function plays the sound with name Name once at the position of the GameObject Caller, and then immediately destroys the AudioSource and cleans it up. (For those interested, it uses Unity's built-in playClipAtPoint function).

The Name should be the name of the sound as specified in the text file, and the GameObject is the object at which you want the sound to occur. Usually this will be the object the script is attached to, which would be written as this.gameObject.

startLooping(string Name, GameObject Caller)

This starts the sound with name Name looping continuously at the position of the GameObject Caller.

It does this by instantiating the Sound Object Template prefab at the position of the Caller object and changing the blank AudioSource clip to the clip called Name. This new object is then parented to the Caller object, so that if the caller object changes position, the sound effect will pan and fade accordingly.

If there is already a Sound Object attached to the Caller GameObject, the script will simply call Play() on the AudioSource component of this object, rather than creating a new object.

stopLooping(string Name, GameObject Caller)

This finds the looping sound with name Name at the GameObject Caller and stops it playing.

If this function is called from an object that has no such sound playing, the Sound System will print an error to the console.

So, that's the basics of the Sound System.

I have also collated a bunch of placeholder sound effects to be used in most of the games, so I will be implementing and testing the system with the rest of the class this week. I have a list of things I would like to iterate on as I progress through the rest of semester, and I am sure my fellow developers will have useful things to add to it.