Troll Your Team with the Wwise Profiler

This is the second post in a short series designed to teach you some simple, but neat, technical implementation tricks with Wwise and Unity.

Last I wrote to you, I introduced you to how to integrate Wwise into Unity using the new Wwise Launcher utility. I hope you all found it stupid simple, because it is stupid simple. At least, much more simple than it used to be.

Today, I’m going to teach you a technique you can use to troll your fellow audio team members. If you’re a solo designer, you can troll yourself I guess.

Or, alternatively, everyone can use this for good because it is in fact, very useful.

Now I give you the power, and it’s up to you what you do with it.

The Wwise Profiler

If you’re at this point unaware of what the hell the Wwise Profiler does (and yes, I was shocked to find there are a number of you… I’m shaming some in particular who I shall not name right now, SHAME!) it’s a built in debug utility for your game.

“What the hell is a debug utility, Adam?”

Okay, well first, if you don’t know what debugging is – you probably haven’t worked in games yet. Welcome – if you stick around, prepare to be horrified when all your work breaks and you don’t know what the hell happened or how to fix it…

OH WAIT – THAT’S EXACTLY WHAT A DEBUG UTILITY IS FOR!

Heh, gotcha.

So when you’re developing a software application (which, is what a game is) unexpected things go wrong all the time. One of the beautiful things about being human is that nobody’s perfect, and since nobody’s perfect we end up making mistakes.

Things like, typing “X, X, Z” for a coordinate system instead of “X, Y, Z” or typing 1 instead of 10. Perhaps (the horror) typing in an incorrect filename.

This happens all the time, and when it does, things go awry.

This is where debug utilities become a massive help.

In programming, a large number of debugging utilities exist down to even being able to watch code operate line by line and operation by operation. You also usually get a “console” that you can print information to in order to get feedback and know what’s going on with your system.

The Wwise Profiler isn’t exactly either of those things, but it’s a bit like a console window.

The Wwise Authoring tool has the capability to remotely hook into a live, running instance of your game’s Wwise sound engine. When it does this, the sound engine reports a large amount of information back. This is how you can mix your game and get live volume data, for example.

The Wwise Profiler will also report back information such as what soundbanks are loaded when, what events fired when, if sounds are looping, when an event stopped, if a sound didn’t fire and why, if voice limits were reached, if memory limits were reached, what voices are being used, etc.

There’s so much information provided, in fact, that you often have to filter a bunch of stuff out just to get to the information you’re actually looking for. It’s a bit hilarious.

Real quick for reference, here’s a shot of an empty Profiler window:

And now here’s a shot of the Profiler with information in it:

Did you see those lines highlighted in green in the 2nd image? Those aren’t normal – they’re custom messages I made. Now, I’m going to show you how to do that. It requires knowing a bit of C# – which I’m not going to give a full tutorial on here.

Writing a Message

I’m assuming you’ve followed my instructions from the last blog and you have Wwise already hooked into Unity (or your C#-based engine/game).

(FYI you can 100% do this in any other engine that you can hook Wwise into, but the code will be different if the engine primarily supports something other than C#. For example, most UE4 code is C++, so you would have to do this using the Wwise C++ API syntax instead of C#.)

Once you’ve done that, put a New Script component on something that you won’t get in trouble for accessing that starts when the game starts. If you’re doing this on a sample project, just put your New Script component on an object in the scene. Name it whatever you want.

It should look something like this in an empty project (though I recommend NOT using the main camera):

From there, open up the script. If you named yours like mine, you should see this:

If you’ve got that, awesome – you’re on the right track. (Note: you may have a different editor depending on if you’re using Visual Studio or not. The editor does not matter, the code does.) Now, follow these steps exactly. If you screw up code and it’s broken on your end, I cannot help you. I can only give you the exact code I’m writing (which I’ll do at the end).

1. Delete lines 1 and 2
2. Delete the Update () function (aka what are lines 9-13 after step 1)
3. Inside the Start function type the below exactly

AkSoundEngine.PostString("HOLY COW YOUR OWN CUSTOM MESSAGE!!!", AkMonitorErrorLevel.ErrorLevel_Message);

4. Save your code

Your final code should look similar to this:

using UnityEngine;

public class wwisemessage : MonoBehaviour {

	// Use this for initialization
	void Start () {
        AkSoundEngine.PostString("HOLY COW YOUR OWN CUSTOM MESSAGE!!!", AkMonitorErrorLevel.ErrorLevel_Message);
	}
}

From here you should be able to remotely connect to your game with Wwise, run your game, and see your message pop up in the Profiler!

Very cool, right?

Now, like I said, you can take this to different parts of your game and troll the crap out of your colleagues with inside jokes.

What’s Actually Happening?

I know there are some of you who aren’t satisfied with this alone. You really want me to actually explain this code to you.

In C# this is what we describe as a “static call”. That’s a fancy way of saying that you don’t need to actually create an object in memory to do something. In layman’s terms, we’re simply telling the running sound engine to send a string of text to the Profiler. That’s what “AkSoundEngine.PostString” means.

The arguments that we send to that function are first, your messsage string, and 2nd a custom “enum” called AkMonitorErrorLevel.

What the heck is an enum, you may ask. Well, an enum is a special type of variable in code that, again in super layman’s terms (programmers are going to axe murder me for this) restricts the content of a variable to specific, pre-decided content.

So “AkMonitorErrorLevel” is an enum that describes what level of error Wwise should recognize your message as. In this case, AkMonitorErrorLevel.ErrorLevel_Message is just telling Wwise that we’re sending a plain jane message. Nothing to worry about. Hence also, why it shows up green in the Profiler.

In addition to ErrorLevel_Message, we also have the option to use ErrorLevel_All and ErrorLevel_Error. I haven’t tested these out specifically, but I bet ErrorLevel_All has no color and ErrorLevel_Error is either red or yellow (at least, it’s a colored message).

With this information, Wwise takes your message and posts it to the Profiler based on wherever you put this line of code.

So if you’re trying to make sure a certain line of code is running in the game, or that whatever data you’re using in code is correct – you can use this to great effect.

Or, of course, you can simply use it for inside jokes and making your team laugh when they least expect it.

Interested in More?

If you like this series and you’re interested in learning more about technical implementation with Wwise and Unity, including programming your own basic custom triggers, sending messages, affecting RTPCs, etc. then enter your contact information below to get on a waiting list for “Basic C# Implementation with Wwise and Unity” – a video course I’m in the process of developing.

By entering your information below you will be signed up to my email newsletter, and your name/email will be attached to a specific interest group that will get further information on the course. Even if you’re on my list, please enter your information again if you’re interested in more information!