I just received my grade for my audio project.
I was hoping to receive a B for the project, to inch closer to graduating with a 2:1 GPA, and I’m very pleased to say that a B is what I received!

Overall, the instructor thought it was a very good project. However, it had some glaring flaws, and I received a bunch of very helpful feedback, which I’ll be discussing in this post.

Feedback

Point 1:
No evidence that you’ve engaged with your audio engine’s build process for audio files. Modern audio engines have specific build processes that dictate how sound files are packaged for your game. This is where knowledge of compressed file formats is vital for modern game audio implementation. Your project appears to use the default settings for all of its audio assets. (in Unity, these settings are defined in the Import Settings for audio assets)

Okay, alright, you got me. I’ll be completely honest; I forgot. As a result, all of the audio files ended being converted to the same format, which completely undermines any optimisation done outside Unity. Which leads to the second point…

Point 2:
Original sound files stored in a compressed format. This means those sounds will have been compressed twice; once when originally rendered, and a second time when you build the game.

Like above, this could have been avoided by engaging with Unity’s build process for audio files.

Point 3:
One or more spatialised sounds are stereo files. Applying audio engine spatialisation to a file that is already in stereo will usually cause problems, as stereo files usually have their own stereo information baked into the file. Attempting to apply audio engine spatialisation to a file that is already hard panned left (for example) in the file itself will result in the game spatialisation not working correctly. (specifically the enemy sounds)

What I’m gathering from this feedback is that I should have made the hard panned enemy sound a mono file, which makes sense, since there’s no need for stereo capability for that particular file. Playing devil’s advocate, though, it gave the desired effect in my game.

Point 4:
The background music does not loop cleanly. Either it has clicks or glitches at the loop point or (more commonly) the music is left to fade out before the loop restarts. (specifically m_danger has a short section of silence at the start, which is very noticeable when the sound loops)

m_danger is the one, ominous tone heard on the second screen of the game. In this case, the fadeout is intentional; I tried to have it play continuously, but this ended up being incredibly annoying to listen to, so I changed it to be this way. The other music pieces may have problems too, which could have been solved by cutting them properly; I’m not an audio engineer, though, so I did the best I could.

Point 5:
Code elements do not appear to be designed with scalability in mind. (a lot of the code relies on hard-coded values, which would make it very hard to scale this approach up to a larger project. Some examples are CameraPositioner’s hard-coded enemies, and the movementClips and voiceClips in AudioTester.cs; not only does the code expect these arrays to be a set size (e.g. line 71, voiceClips[Random.Range(0,2)]), but the arrays actually contain a variety of different sounds, used in different contexts)

This specific point represents a crossroads I faced during development. One thing I haven’t mentioned is that I had to start over from scratch halfway through the project, as I wanted to utilize trademarked assets under Fair Use; this wasn’t allowed. This meant I didn’t have as much time to clean and optimize code as I’d have liked. So, I was left with a choice: Should I spend the extra time making the code scalable and expandable, or just go for something that works? In the end, I went with something that works for this particular project. That being said, scalability should always be a priority in any software project. I’d like to write a future blog post on scalability, so stay tuned for that!

Point 6:
Reverb is applied individually to multiple game objects using the Audio Reverb Filter Component. This is a very inefficient way of implementing reverb. If you have multiple audio sources that you want to apply the same reverb settings to, the correct solution is to add a Reverb group in the Audio Mixer, and route those sounds to that group. This means you can run a single reverb process instead of individual processes for each sound, and can significantly save on CPU usage. (specifically the enemy and player game objects; this approach also makes it hard to cope with different environments, were you to expand the game in future)

This one’s on me again, as I did not do much work with Audio Mixers, apart from applying a low-pass filter.

Anyway, that’s all the feedback I got. Most of it was oversight on my part, a few points were due to choices I’d made. Hopefully, this post is useful in some way to you!

What is scalability?

The word scalability, according to Oxford Languages, means “the ability of a computing process to be used or produced in a range of capabilities”. Specifically, this refers to a piece of code’s ability to handle increasing or varying levels of demands, according to its utility. For online games, this can, for instance, refer to properly managing server load (more players), while hardware scalability refers to designing the game to run properly on a wide range of devices and platforms.

The focus of this blog post, however, is on code scalability. In broad terms, code scalability refers to a series of principles a programmer should follow, in order to create code that works in a wide variety of scenarios/scopes, as well as code that will accomodate the increase of a game’s scope.
Scalability also has a wide range of benefits, including ease of adding features, simplified debugging, reduction of technical debt, and the ability of less technically inclined people to tweak the code (not that I’d ever let an artist touch MY code).

An example of scalability

QUICK NOTE: I will be using Unity-specific C# for these examples, but the principles apply for any OOP language.

Let’s take a look at some examples of good scalability and bad scalability.

Let’s say we’re building an enemy for an RPG. The simplest way to implement this enemy would be something like this:

public class Enemy

{
string enemyName = “Goblin”
int level = 5;

   public void Attack()
{
Debug.Log(“Goblin attacks!”)
}

}

This code is very barebones, but implements an enemy class. However, it’s very, very bad and inflexible code - so bad, in fact, that the code-savvy among us are probably screaming furiously at the screen.
In short order, the issues with the code are:

Hard-coded, private values

We have an Enemy class, however both its name and level are hard-coded, which means it’s part of the code. Just like magic numbers, this is very bad for a few reason. The first reason is that we can’t manipulate it, and since we can’t manipulate it, we can’t test/balance it without going into the code and changing the value every time. It’s also hard for outsiders and non-coders to read, compared to a variable with a fitting name, such as “enemyName” or “enemyLevel”.

This leads to the second point - the code is hidden away due to its access level. Keeping as many variables private as possible is good, though in this case it’s bad. What if your designer wants the name to “Orc”? They’d have to go into the code to do it. With the “public” keyword, we could expose the variable in the editor, thus making it easier to change.
In order to make the class scalable, we would create a new class that inherits from the Enemy class, and we can then define our variables there instead. However, there’s still another issue.

Writing specific code in non-specific class

Did you notice that the code in the Attack-function specifically mentions “goblin”? This is an example of using specific code in non-specific classes. Say we have an Animal-class, and we’d be looking to define a bunch of different animals that inherit from this class. If we then have a function in the Animal-class called Bark, that would mean every class that inherits from Animals would be able to bark, which is great for dogs, but not so great for elephants.
The point I’m trying to make is that you want to define the overarching variables and functions in the base classes, and then add specific variables and functions in their children.

Using these principles, we would then have code that looks like this:

public class Enemy

{
public string enemyName;
public int level =;

   public void Attack()
{
Debug.Log(enemyName + “ attacks!”)
}

}

and

public class Goblin : Enemy

{

   public void GoblinChop()
{
insert code here
}

}

Using these principles, we have now designed a very simple system that can accomodate several different kinds of enemies. So let’s quickly go over some other principles that are good to follow:

Keep the code clean and commented

I cannot stress the importance of clean, commented code, especially if others have to read it. This can save hours of work. Strive to stick to naming conventions, use sensible variable- and function names, and make sure to comment why the code does what it does.

Reuse code wherever possible

Having to learn new functions takes time, so why not reuse the ones you already know? This is where generic programming and templating comes in handy, as we can define template functions which we can then define when we need to!

Strive for simplicity

Whenever you write new code, you should ask yourself the following question: “Is this too complex? Could this be done in a simpler way?” The answer is usually yes. While complex code is great to show off to others, simple code is easy to ready and, in many cases, will be easier to maintain. Therefore, stick to simplicity.

That concludes my blog post on scalability.

The project contains spatial localisation, attenuation, reverb and many other interesting audio buzzwords.
The core design principle for the game was “simplicity”. Basically, I wanted to see how effective Unity’s built-in audio handler was at processing audio for a simple project.
While this meshed well with the scope of this project, if it were to be any bigger, I would have implemented third-party audio software, like Wwise or Fmod.

A brief overview of the project

The core of the project is a dynamic music system, which plays music based on the player’s position relative to the enemy.
It’s based on a state-machine, and looks like this:

Calm
There are no enemies near the player. The music player will play short pieces of music every 10-15 seconds.
Danger
There is an enemy one screen away. The music fades to a very ominous track, and footsteps can be heard from the next screen over.
Imminent danger
There is an enemy on screen. The music fades to an oppressive track, which will loop as long as the player remains. In the background, a timer is started - more on that later.
Hunted!
An enemy has seen the player, and is actively hunting the player. The music switches to a frantic track which will override any other state, until either the enemy or player is dead.
Dead
The player has died. A short, disappointing track plays.

A word on music transition

The singular most challenging part of this project was to seamlessly transition between the “imminent danger” and “hunted” tracks.
While you can ask Unity to wait until an audio piece has ended to play another, it’s a bit more difficult to get it to play an audio track exactly at a specific time.
For this project, I wanted the music to be played at the end of the current bar* of music.
In order to calculate the length of a bar, I had to do a few rudimentary calculations.

First, I calculated the tempo of the track via Garage Band on my iPhone, which turned out to be 110 BPM.
Then, I divided this number by 60, in order to get the beats per second.
With the beats per second calculated, I simply had to multiply by 4, in order to get the duration of a bar.
I then started a timer when the player enters the “danger” state, and when this timer reaches the calculated duration, it can change to the “hunted” track.
* A bar of music is the amount of beats indicated by a time signature. For 4/4 time signature, this is 4 beats, while for 3/4, it would be 3 beats.

And that concludes my project!
Thanks for reading.

Cause & Consequence is my honours project.
It is a 2D sandbox game with a dynamic crime AI, based on Fuzzy Logic.
As the sole developer, I will be producing all aspects of the game.
In the following months, you will be able to follow the development on my blog!

Who am I?

If you’ve stumbled upon this blog, or simply haven’t bothered to read the name printed no less than 4 times on the front page, I guess short introductions are in order.
My name is Adam Grann, and I am a Danish programmer based in Dundee, Scotland.
I’m currently enrolled at Abertay University, where I’m studying Computer Game Applications Development (CGAD), which I’m looking to finish with a 2:1 GPA this summer.

What kind of programmer are you?

I consider myself to be a generalist. That means I can do (or learn to do) pretty much anything regarding programming.
I like to think of myself as a “life-long” scholar, and am of the belief that one can never know enough about anything.

That being said, I have a special fondness for 2D games in all shapes and sizes.
I believe there’s an innate craftsmanship to these games that (mostly) can’t be replicated by 3D games (generalizing I know).
Don’t get me wrong though; I still love 3D games - I just prefer 2D.

I love collaborating in teams, as there is a massive amount of knowledge one can glean from working with others.
I’m also fond of working on my own, as that lets me live out my ideas and test new methods.

Why Scotland?

Time for a bit of a rant!
Scotland is a great country of innovators and trendsetters. They’ve long realized that video games are here to stay; that’s why they have great traditions, industry and education when it comes to games.

Denmark, on the other hand, is way behind.

Until recently, there were only a handful of video game-centric educations, and none of them had very good reputations. There’s also been next to no support from the government, who have been trying their best to pretend like the industry doesn’t exist, even though it’s the single largest form of media in the world.

As there were no options suitable for me in Denmark, I decided to relocate to Scotland to realize my dream of becoming a game programmer.

And that concludes my very first blog post!
In the future, I’ll be looking to share tips, tricks and observations from my journey as a programmer.

So stay tuned!

This is a simple server/client game created in Unity.
Basically, you just launch the server, and then you can connect to it.

Download link.

It is written in HLSL, and contains two lights (one directional, one spotlight), a heightmap, and a directional blur. It also contains shadowmaps and a wireframe mode. All parameters can be manipulated.

Download link.

Rollio is a game I made in collaboration with a team of skilled designers, artists and a programmer.

I was responsible for prototyping the gameplay mechanics and animation system, as well as implementing all 2D elements (including the UI) and audio.

Download link.