So, in part 1 we saw a few examples of the output from the Profiler window in Unity Pro. If you have Pro, this built-in profiler can be incredibly useful in determining whether your code is taking up a significant amount of time, and if so, which scripts and functions in particular are responsible. There are also other professional code profilers available for other development environments, such as Red Gate’s “ANTS” which will literally give you a speed recording for every line of code in your project. These types of tools are invaluable if you have the budget for them, but many don’t have access to such tools, particularly beginners and budding indie developers. However, all is not lost – it’s actually possible to measure the speed of your own code within the code itself.

In a nutshell, you can achieve this by simply recording the time before and after the code is executed. In practice there are a few more hurdles involved in getting sensible and useful recordings which I will talk through over the course of this post, however this is the fundamental concept – so the first thing you need to know is how to record time.

I’m aware that my previous post attracted the attention of some non-Unity readers, I will try to make as much of this post relevant to all languages as possible, however it will remain largely Unity-centric!

Unity provides you with the Time class for dealing with time, and pretty much all languages have the equivalent of a “current time” system property. In regular C# (in or outside of Unity) you can use DateTime.Now.Ticks, and in Flash’s Actionscript, there’s getTimer(). The concepts from here on are fairly simple so you should be able to adapt them to any language of your choice.

Before we get started though, it’s important to know one thing about your time variable before you use it – whether it can return a changing value when called multiple times during the execution of a function. In Unity, the most commonly used time properties, “Time.deltaTime” and “Time.time” do not update over the duration of a function. Instead, they only get a new value each frame, and they keep that value until the entire frame has completed. Because of this, they are useless for profiling code within a function!

For example, if we wanted to measure the contents of our Player’s “Update()” function, we might try something like this, where we record the time before and after the contents of the Update() function, and compare the difference:

void Update() {

	float startTime = Time.time;

	// (Some code here which you want to measure)

	float endTime = Time.time;
	float timeElapsed = (endTime-startTime);

}

With the above example, startTime and endTime will always have the same value, because Unity’s Time.time does not change while the function is being executed – which is obviously no use at all because the measured time difference would always equal zero! Instead however, you can use the lesser-known property on the same class: Time.realtimeSinceStartup. This is very useful because not only does it update during the course of a function running, but it is also not affected by your current timescale setting, so it won’t be affected if you’re using slow-motion or other time-stretching effects in your game. If you’re working in something other than Unity 3D, make sure your time function has this important feature!

So to make a measurement, we record the realtimeSinceStartup value before and after the code, and simply subtract the latter from the former like this:

void Update() {

	float startTime = Time.realtimeSinceStartup;

	// (Some code here which you want to measure)

	float endTime = Time.realtimeSinceStartup;
	float timeElapsed = (endTime-startTime);

}

Now any single timing of the same code is likely to fluctuate a certain amount, and the smaller the timescale that you’re trying to measure, the larger the fluctuations will be in comparison. Depending on what you’re measuring, this amount of time elapsed may be very very small – even down to hundredths of a millisecond or less – so to get a sensible reading it’s best to record the same action lots of times and average the result.

One way to do this would be to simply use a tight “for” or “while” loop which repeats the enclosed code a few thousand times. This is fine if you want to quickly test a certain section of code in isolation but it’s not so useful when trying to profile your game while it’s being played in a normal way (eg, baddies moving, bullets flying around, etc). So, to expand on the example that I’ve started building above, to accumulate and average the recordings of our Update function over a larger time period, we could do something like this, which records the time taken to perform the function 500 times (once per frame), and then outputs the result to Unity’s console window:

int numRecordings = 500; // number of recordings to make
float timeRecorded = 0;  // total accumulated time
int recordingNum = 0;    // current recording number

void Update() {

	float startTime = Time.realtimeSinceStartup;

	// (the code here that you want to measure)

	float endTime = Time.realtimeSinceStartup;

	// this section now accumulates the time, and
	// computes the average once we hit the required
	// number of recordings:

	float timeElapsed = (endTime-startTime);
	recordingNum++;
	timeRecorded += timeElapsed;
	if (recordingNum == numRecordings) {

		// calculate and display the average time
		float averageTime = timeRecorded/numRecordings;
		Debug.Log("Avg Time: "+averageTime+" seconds");

		// and finally, reset & repeat:
		recordingNum = 0;
		timeRecording = 0;
	}
}

Now we’re getting somewhere. With this in place, we can get a good idea of the time taken to execute any block of code that we might care about. Note that it doesn’t have to be your Update function that is measured. You might be interested in, for example, how long it’s taking a particular single line your Instantiate function to execute. In this case, you could put the “startTime” and “endTime” recordings either side of this single line, like this:

	float startTime = Time.realtimeSinceStartup;
	Instantiate(enemyPrefab, pos, rot);
	float endTime = Time.realtimeSinceStartup;

The main problem with the method above is that while it works, it would be impractical, messy and confusing to duplicate all this code to each and every Update function, and to every other part of your program that you want to measure in your project. Aren’t you thinking it would be so much better if we could encapsulate the system used here into a simple friendly portable class? So am I!

The next example does just this. It’s a class I have written called “CodeProfiler” which is designed to be placed on an empty GameObject in your scene. For those working in a different engine and unfamiliar with Unity’s conventions, this basically means that the class will be automatically instantiated, and it receives Start() and Update() events automatically from the Unity engine while playing. The reason it requires these events is so that it can accumulate and average the overall frame rate which is then used as a comparison with your own chosen measurements. It has two public functions, “Begin” and “End” which you can call at the beginning and end of any particular code you want to profile. These functions are static, which means you can call them directly just by using the class name as a prefix – so there is no need to find references to the profiler GameObject or script instance.

The full code for the CodeProfiler class is included at the bottom of this post, but first I’m going to explain how to use it and how it works. The script is written in C#, but you can call it from both C# scripts and scripts written in Unity’s Javascript if you place it the appropriate folder.

In order to differentiate between the various parts of code that you want to measure, you pass an ID to these Begin and End functions – which is nothing more complex than a name, as a string parameter. You are essentially just picking a label to name each different reading that is taking place in your code. For example, if – in your game – you wanted to measure the speed of each your Player’s, Enemy’s and Bullet’s update functions, you could add the Begin and End functions in your code like this:

// Player Script:
void Update()
{
	CodeProfiler.Begin("Player:Update");

	// (The rest of your Player update code here)

	CodeProfiler.End("Player:Update");
}

// Enemy Script:
void Update()
{
	CodeProfiler.Begin("Enemy:Update");

	// (The rest of your Enemy update code here)

	CodeProfiler.End("Enemy:Update");
}

// Bullet Script:
void Update()
{
	CodeProfiler.Begin("Bullet:Update");

	// (The rest of your Bullet update code here)

	CodeProfiler.End("Bullet:Update");
}

So you can see in the above examples, I’ve picked the labels “Player:Update”, “Enemy:Update”, and “Bullet:Update” for my 3 entries in the code profiler. I’ve chosen a convention of “ClassName:FunctionName” but you could use whatever you like as long as each entry is unique. Now all that remains to do is to make sure that my CodeProfiler script is actually placed on an empty gameobject in the scene, and hit Play in the Unity editor.

The CodeProfiler updates its results every 5 seconds (the results are the average of the readings over those five seconds), and they look like this:

Avg frame time: 19.6ms, 51 fps
Total     MS/frame  Calls/frame MS/call   Label
0.467%    0.092ms   1.000       0.0933ms  Player:Update
6.429%    1.260ms   6.000       0.2101ms  Enemy:Update
4.036%    0.791ms   16.480      0.0480ms  Bullet:Update

The first line gives you the average time elapsed per frame, and the corresponding “frames per second” that this results in. This includes everything – rendering, physics, scripts, etc.

Underneath are your individual readings for each “ID” that you used when measuring your code. In this example, the three IDs I mentioned earlier are present. Each entry has the following figures:

“Total” shows the percentage time taken of the whole frame time.
“MS/Frame” shows the amount of milliseconds spent on this task per frame. This is the sum if there were multiple calls (for example if multiple enemies all recorded their Update times under the same ID).
“Calls/Frame” tells you the average number of times this reading was measured per frame. In my example, for the player it’s 1. For the Enemy, it’s 6, because there were 6 enemies present during the test all recording their time against the same ID. For the Bullets it’s the same situation, but this time it’s not a whole number, because the number of bullets present varied over the duration of the 5 seconds measured, but it averaged about 16.
And finally, “MS/call” tells you how long each individual call took, on average. This is basically MS/Frame divided by Calls/frame.

These statistics give you some means to assess what impact your scripts are having in terms of your game’s overall performance. A game that is having performance trouble might come out looking something like this:

Avg frame time: 110.1ms, 9.1 fps
Total     MS/frame  Calls/fra MS/call   Label
0.285%    0.314ms   5.500     0.0570ms  Player:FixedUpdate
79.270%   87.275ms  107.022   0.8155ms  Bullet:Update
0.004%    0.004ms   1.000     0.0045ms  Level:Update
5.604%    6.170ms   56.283    0.1096ms  Enemy:FixedUpdate
0.900%    0.991ms   2.413     0.4107ms  Enemy:FireBullet

Uh-oh – there are serious problems here: the game is running at around nine frames per second. My CodeProfiler doesn’t measure the time taken for physics and rendering, but it does measure the total frame time, and we can see from the results that the bullet’s Update function is by far dominating the total time taken per frame. The bullet’s update function is also being called many times – an average of 107 bullets per frame, each having its Update function called every frame, for this particular 5 second time-slice. This wouldn’t be so bad if their individual execution time was very fast (which it should be, for a bullet!), however an average of 0.8155ms per call is a long time, so there is clearly something wrong within that function which – when multiplied by every active bullet – causes a huge slowdown.

You might also notice at the bottom of the list that I added an entry for “Enemy:FireBullet”, which is a sub-section of the enemy’s code which is responsible for instantiating and calculating the trajectory for each individual bullet, to see whether that was the problem. I did that by simply adding another call to CodeProfiler.Begin() and CodeProfiler.End() around just that section of code, and choosing the label “Enemy:FireBullet”. The results show that approximately 2.4 bullets were fired per frame, but the code for this only totalled 0.9% of the frame time, so this clearly isn’t the cause of the poor framerate.

So from this example we can clearly see the problem lies within the bullet’s Update function, and it’s not the instantiation of the bullet. If this was your project, you could narrow it down further by adding Begin() and End() calls around smaller parts within the offending code until you can identify what exactly is the major time-consumer in there. It’s very common for for the most time to be taken up by very few or even a single element of your code.

If all your code readings add up to a small portion of the total frame time, but your game is still running slowly, you know the major costs are elsewhere – i.e. graphics and/or physics.

How does the CodeProfiler work? Basically it uses a type of collection called a “Dictionary” to store multiple recordings. A dictionary is a bit like an array, however it stores key/value pairs rather than a simple list of values. (Read more about Dictionaries and other types of arrays and collections in Unity here). The “key” is the string ID that you choose, and the “value” is an instance of the accompanying class “ProfileRecording”. This ProfileRecording class contains just a few variables and functions which allow it to act as a simple stopwatch. The CodeProfiler class creates a new ProfileRecording instance each time it encounters an ID which isn’t yet present in the dictionary, and adds the instance to the dictionary under the given ID. The CodeProfiler uses Unity’s OnGUI functions to display the text on-screen each frame, and each time the “nextOutputTime” is reached, the results are calculated and the text displayed is updated.

When you call the Begin and End function function with an ID, the CodeProfiler looks up the ProfileRecording associated with that ID in the dictionary, and calls the corresponding Start or Stop function on it. Each individial ProfileRecording instance in the dictionary keeps track of how much time it has accumulated. The ProfileRecording class has a Reset function to allow it to begin a fresh recording when required, and also generates an error if the Start and Stop functions are called out-of-order.

(I’m aware that .Net actually provides a “Stopwatch” class with much of the same functionality, however I included this simple custom class instead for the sake of learning and clarity so you can see exactly how this is being achieved, and how the concepts progress onwards from the simpler examples above. Out of curiosity I tested the script using .Net’s Stopwatch class in place of my own, and happily it came out with near-identical results!)

Without further ado, here’s the CodeProfiler class:

using UnityEngine;
using System.Collections.Generic;

// Simple code profiler class for Unity projects
// @robotduck 2011
//
// usage: place on an empty gameobject in your scene
// then insert calls to CodeProfiler.Begin(id) and
// CodeProfiler.End(id) around the section you want to profile
//
// "id" should be string, unique to each code portion that you're timing
// for example, in your enemy update function, you might have:
//
//     function Update {
//         CodeProfiler.Begin("Enemy:Update");
//         <the rest of your enemy update code here>
//         CodeProfiler.End("Enemy:Update");
//     }
//
// the Begin id and the End id must match exactly.

public class CodeProfiler : MonoBehaviour
{
	float startTime = 0;
	float nextOutputTime = 5;
	int numFrames = 0;
	static Dictionary<string, ProfilerRecording> recordings = new Dictionary<string, ProfilerRecording>();
	string displayText;
	Rect displayRect = new Rect(10,10,460,300);
	
	void Awake() {
		startTime = Time.time;	
		displayText = "\n\nTaking initial readings...";
	}
	
	void OnGUI() {
		GUI.Box(displayRect,"Code Profiler");
		GUI.Label(displayRect, displayText);
	}
	
	public static void Begin(string id) {
		
		// create a new recording if not present in the list
		if (!recordings.ContainsKey(id)) {
			recordings[id] = new ProfilerRecording(id);
		}
				
		recordings[id].Start();
	}
	
	public static void End(string id) {
		recordings[id].Stop();
	}
	
	void Update() {
		
		numFrames++;
		
		if (Time.time > nextOutputTime)
		{
			// time to display the results		
			
			
			// column width for text display
			int colWidth = 10;
			
			// the overall frame time and frames per second:
			displayText = "\n\n";
			float totalMS = (Time.time-startTime)*1000;
			float avgMS = (totalMS/numFrames);
			float fps = (1000/(totalMS/numFrames));
			displayText += "Avg frame time: ";
			displayText += avgMS.ToString("0.#")+"ms, ";
			displayText += fps.ToString("0.#")+" fps \n";

			// the column titles for the individual recordings:
			displayText += "Total".PadRight(colWidth);
			displayText += "MS/frame".PadRight(colWidth);
			displayText += "Calls/fra".PadRight(colWidth);
			displayText += "MS/call".PadRight(colWidth);
			displayText += "Label";
			displayText += "\n";
				
			// now we loop through each individual recording
			foreach(var entry in recordings)
			{
				// Each "entry" is a key-value pair where the string ID
				// is the key, and the recording instance is the value:
				ProfilerRecording recording = entry.Value;
				
				// calculate the statistics for this recording:
				float recordedMS = (recording.Seconds * 1000);
				float percent = (recordedMS*100) / totalMS;
				float msPerFrame = recordedMS / numFrames;
				float msPerCall = recordedMS / recording.Count;
				float timesPerFrame = recording.Count / (float)numFrames;
				
				// add the stats to the display text
				displayText += (percent.ToString("0.000")+"%").PadRight(colWidth);
				displayText += (msPerFrame.ToString("0.000")+"ms").PadRight(colWidth);
				displayText += (timesPerFrame.ToString("0.000")).PadRight(colWidth);
				displayText += (msPerCall.ToString("0.0000")+"ms").PadRight(colWidth);
				displayText += (recording.id);
				displayText += "\n";

				// and reset the recording
				recording.Reset();
			}
			Debug.Log(displayText);	
				
			// reset & schedule the next time to display results:
			numFrames = 0;
			startTime = Time.time;
			nextOutputTime = Time.time + 5;
			
		}	
	}
}


// this is the ProfileRecording class which is simply included
// directly after the CodeProfiler class in the same file.
// The ProfileRecording class is basically for "internal use
// only" - you don't need to place it on a gameobject or interact
// with it in any way yourself, it's purely used by the
// CodeProfiler to do its job.

class ProfilerRecording
{
	// this class accumulates time for a single recording
	
	int count = 0;
	float startTime = 0;
	float accumulatedTime = 0;
	bool started = false;
	public string id;
	
	public ProfilerRecording(string id)
	{
		this.id = id;
	}
	
	public void Start() {
		if (started) { BalanceError(); }
		count++;
		started = true;
		startTime = Time.realtimeSinceStartup; // done last
	}
	
	public void Stop() {
		float endTime = Time.realtimeSinceStartup; // done first
		if (!started) { BalanceError(); }
		started = false;
		float elapsedTime = (endTime-startTime);
		accumulatedTime += elapsedTime;
	}
	
	public void Reset() {
		accumulatedTime = 0;
		count = 0;
		started = false;
	}
	
	void BalanceError() {
		// this lets you know if you've accidentally
		// used the begin/end functions out of order
		Debug.LogError("ProfilerRecording start/stops not balanced for '"+id+"'");	
	}
	
	public float Seconds {
		get { return accumulatedTime; }
	}
	
	public int Count {
		get { return count; }
	}

}

Of course this is a simple script and could be vastly improved on. It has significant shortcomings, and does not do a number of things which perhaps it should, such as:

- Sort the results into any particular order
- Deduct the average time taken for an “empty reading”
- Give similar results to Unity Pro’s profiler *
- Graph the results.
- Make you a much-needed cup of tea.

I’ll leave these as an excercise for the reader. May I recommend starting with the last item first.

* Unity’s profiler seems to assign larger times to function calls than those recorded by simply checking the time at the beginning and end of a function – I’m guessing this is because it includes other things such as the time taken for the Unity engine to actually invoke the function (which is done via Reflection for MonoBehaviour events like Update).

In part 3 of this series, I’ll be examining the performance of various common code structures and techniques in Unity and shedding light on some faster alternatives, as well as exposing the “voodoo” optimisation techniques that some of us use just-in-case, but which actually provide little or no benefit!

Optimizing code in general can be a controversial subject, and upon wading into the topic even ankle-deep, you are bound to encounter the well-known quote, “Premature optimization is the root of all evil”.

It’s from a 1974 paper by Donald Knuth, in which he warns programmers against wasting “…enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs”. *

This is good advice, and experienced programmers understand it. However the advice is more problematic if you don’t have so much experience in programming, because your ability to even estimate which parts of your project might be “non-critical” are not yet well developed. This makes the advice rather unhelpful to those who perhaps need it most. So, this article is an attempt to shed some light on the subject, as well as being an introduction to some of my optimization tests that I have been putting together.

The specific goals of optimization in Unity tend to revolve around making your game run faster so that it plays at an acceptable rate. There are occasionally other goals, such as reducing memory usage, or even drawing less battery power, but as a starting point I will be focusing on optimizing for speed.

For a game to run at an acceptable speed, it needs to reach a certain acceptable number of “Frames Per Second”. Each frame, your game has to execute all the relevant code, calculate physics, play sounds, and display the graphics in their current state. Each of those tasks takes a certain amount of time to complete, and to achieve a speed of (say) 30 frames per second, the computer must calculate everything it needs to display the next frame of your game in one-thirtieth of a second. The relative time taken for each task can be thought of as its “cost”, and the total time available to you each frame, can be thought of as your “budget”.

Understanding and identifying the relative sizes of the costs in your project is a crucial first step. Without doing this, you are essentially working blind. Imagine trying to make a car go faster by adjusting the angle of its aerofoil, without noticing that there is a trailer full of rubble attached to the back. Or trying to balance your monthly food budget by selecting between the two cheapest brand of tea-bags, while at the same time forgetting to cancel your weekly delivery of caviare. The differences in scale within the operations in your game can be even larger than these examples.

I regularly see questions in Unity forums and chat rooms which ask about whether a certain function is faster than some other function, or whether one kind of loop or data structure is faster than another. These kind of comparisons are sometimes valid, and there is a place for looking for optimizations at that level of detail – however it’s vastly more important to first be able to understand whether these things are relevant at all in the overall view of what is taking up time within your game each frame.

The first thing you should know is that unless you’re doing something very unusual, your code is probably not taking up a large portion of that time. Back in 1974, and indeed in many modern day programs in the wider area of computer science, your own code would be the first place to look to speed things up, however things are very different when you’re working within a high-level games-focused environment like the Unity engine. For a typical Unity game – particularly a desktop or web game, there is usually an awful lot going on that isn’t connected to the speed of your own code at all. The rendering of the graphics and the physics engine calculations are likely to be taking up the majority of the time it takes for you game to complete a whole single “frame”.

I can give you a couple of examples using the profiler which comes with the Pro version of Unity:

The above game is a kind of aerial combat game. Listed under the screenshot is the output from Unity’s profiler, showing the relative time taken for each of the listed functions running in the game. You can see the camera render function at the top of the list, taking 38% of the frame time. Next is physics engine taking up a similar sized portion of time – there are lots of objects flying around, mostly debris in the above pic. After that comes the GUI rendering (which is drawing the radars, target sight and the on-screen text), then Particle system code (unity’s built in code, not code I wrote), then “Overhead” which is pretty vague but I guess it’s just some underlying cost of Unity doing its stuff.

Finally we reach the first item in the list which contains any code at all that I wrote myself. The Jet’s FixedUpdate function, weighing in at 2.5% of the frame time.

This is the main script for the player’s jet in the game, but also this script is on about 6 other enemy jets in the game too, and even has the AI code in there. So that single entry is actually running all 7 jets in the game.

This isn’t a tiny script – the FixedUpdate function is about 500 lines long, dealing with applying forces to the jet object, targetting, firing, ammo, and also contains the AI code for the enemy jets!

Here’s another example:

At the top, you can see the RenderCubeMapReflection class is taking up a whopping 35% of the total frame time in the above game. Below that is the main camera’s rendering function, at 22%. TheRenderCubeMapReflection class is responsible for building a cubemap texture from 6 camera angles from the car’s position, which is then used as the reflection of the car in the game. The camera’s Render function then renders the single view from behind the car that we see in the screenshot.

If we also add on GUI.Repaint (which is used to draw the GUI), this comes to about 67% of the frame time just used for rendering graphics in this game. The physics comes in much lower in this game, because there is basically only a single moving object in the game. The two most expensive script functions – which are basically responsible for pretty much all the gameplay (Car.FixedUpdate at 12.5% and Car.Update at 8.9%) come to just over 20% combined.

And here’s an example of a simple racing game running on the iPhone (a 3GS model), using Unity’s iOS profiler output:

iPhone Unity internal profiler stats:
cpu-player> min: 13.8   max: 32.4   avg: 20.1
frametime> min: 28.2   max: 52.1   avg: 34.9
draw-call #> min:  13    max:  17    avg:  14 | batched:    80
tris #> min:  5096  max:  6932  avg:  6100 | batched:  5358
verts #> min:  4052  max:  5798  avg:  4950 | batched:  2920
player-detail>
physx:  8.4
batching:  1.2
render:  4.5
mono-scripts> update:  2.3   fixedUpdate:  3.2 coroutines:  0.0

So again we can see that although the time taken to execute my code does have some significance, it’s certainly not the dominant factor in determining how fast the game runs. I think from these three examples, the take-away message should be:

Make sure you know whether you need to optimize your code at all.

Compared to everything else going on in your game, it’s entirely possible that all of your code falls into the “non-critical” part that Knuth was referring to. If the first two games above were running slowly, and they needed to be optimized, it would not be sensible to start optimizing the code first, or perhaps even at all in the case of the jet game. There are clearly other things which are massively more important in terms of framerate – the number of particles, the draw distance, the number of draw calls, the image effects (particularly the car’s reflection!), the number and complexity of physics objects, etc.

As for the iPhone game above, there may be a case for optimizing the code, but only once the physics have been double checked to be as simple and efficient as they can possibly be – since they consume the most time per frame.

Now, somewhat ironically, I started writing this article as an introduction to the low-level optimization tests I have been putting together which test the relative speeds of various common structures and techniques used in unity game programming. However this whole thing may have accidentally ended up sounding more like a warning to avoid code optimization altogether! This is not what I’m saying, because code optimization does have its place – particularly when targeting iOS or Android devices. It’s just important to make sure that you have a good overview of where the processing time is really being spent in your game before diving into the code to try to make it faster, and I guess this article will act as a primer for that.

In my next post on the subject, I will be getting down to the nitty-gritty of code optimization in Unity,  including the results of my performance tests, and some examples of how you can measure the speed of your code yourself, even if you don’t have access to Unity Pro’s profiler – so stay tuned!

Just posting to announce a new game that I recently finished working on at Skive. It’s another Unity 3D game, called “Damage Control“. ,It’s a much smaller production than our previous Unity game, but hopefully offers some bite-sized lunchbreak-style fun!

It’s an unusual action puzzle game in which you control a demolition wrecking ball with your mouse. You can swing the ball at the building to demolish any part you choose, however behind the front facade of the building are different coloured layers of brick.

The goal of the game is to match a “target pattern” (shown top-left) within a time-limit by knocking chunks out of the building front to reveal different coloured layers beneath.

Anyway, this video probably gives a better idea than my rambling!

The game was produced in a particularly short time-frame (25 days), and uses a Flash front-end for the interface, instructions and level-select screens.

You can play it at:

http://kitkat.co.uk/Flash/#/need-a-break/games/damage-control

And you can read more about how this Unity game tied in with the KitKat site here:

http://blog.skive.co.uk/index.php/2010/08/24/kit-kat-music-brands-biggest-ever-digital-spend/

This is the latest browser based racing game from us at Skive, this one being a Formula 1 racer with a unique feature: By using a custom Google Maps interface, you can create your own tracks on real roads – pretty much anywhere in the world – and the game will dynamically generate a 3D racetrack which matches your route.

The idea is to be able to experience Formula 1 coming to your home town – so you could create a route which goes along your street, past your local shops or school, etc. Of course you can also choose to build anywhere else in the world too, if you feel like exploring! Combining Flash and Unity 3D technologies with route, altitude and satellite data from Google maps, this project breaks new ground when it comes to technology “Mash-Ups”.

If you’re logged in and finish 3 laps of your new track, it gets saved to the database and will show up as a marker pin along with everyone else’s tracks around the map of the world. You can share your tracks via facebook and twitter, and challenge your friends to beat your times on any course.

Here’s a video of the game in action:

Notable features:

• Intuitive custom track designer built on Google’s route finding technology.
• Dynamic 3D world created to match your design.
• Analysis of real satellite & terrain data used to decide placement of trees, buildings and open space.
• Real altitude data used to create track height and surrounding hills.
• Realistic scales and Formula 1 speeds.
• Dynamic driving assistance adapts to your performance – casual gamers and skilled drivers alike should find the game equally enjoyable without the need to fiddle with menus and settings.
• Community features allow you to race other people’s tracks, and share your tracks with others.
• Adaptive quality degradation ensures very high visual quality on high-spec machines, while low-spec machines prioritise framerate – without the need for manual settings.

You can play the the game here:

http://racing.vodafone.com/hometown

However you might also like to try some of these direct links to tracks which I think show off the game quite well:
(try and beat my times on these!)

• Bristol River Run (England)
• The Serpentine (Hyde Park, London, England)
• Presidio of San Francisco (California, USA)
• Happy Valley (Hong Kong, China)
• El Grado Dam (Spain)
• Banff: Tunnel Mountain (Alberta, Canada)
• Ct. Gilles Vielneuve: (Montreal, Canada)

And finally, some stills – for those of you who like that kind of thing!

Certain types of motion in Unity allow you to avoid this question altogether, such as Slerping (a.k.a. using spherical interpolation) from one rotation to another. Sometimes you need to be more explicit in your code however, and in these cases you often need to deal with and make decisions based on the angles themselves.

Some situations involve completely free-moving objects that need to turn in any direction, such as a spaceship that can fly in any direction in 3d space. Other times, you have more constrained situations (eg, a boat, car, or any other object which is turning but constrained to some kind of surface) where you simply want to decide between a clockwise or anticlockwise direction when turning.

This tip tackles the latter of the two, where you need to make a decision about turning clockwise or anticlockwise based on arbitrary rotations or directions as input.

An example of this would be an AI controlled car, which might need to turn towards a target (another car, or the next waypoint, for example). You don’t want to use interpolation, because that would preclude realistic car physics. You wouldn’t want it making a 270 degree turn to reach a target that was 90 degrees to the left, but how to determine which way to turn?

These situations usually boil down to one of the following cases, where you need to find:

1. the angle between two rotations,
2. the angle between a rotation and a target position,
3. the angle between a rotation and a target direction, or
4. the angle between two direction vectors

The key to solving anyof the above lies in the fact that whichever case you have, you can convert it to the last case – where you simply have two directional vectors to compare – and from there you can use a few simple math functions to return the angle you want. Unity provides some very useful functions in its API which help along the way.

Starting at case 1, you have two rotations (which in Unity are represented by Quaternions).

A rotation can be converted to a directional vector by multiplying the quaternion by the world-relative “forward” direction. Forward in Unity is represented by the positive direction along the Z axis (i.e. 0,0,1) and there is a handy alias to this value on the Vector3 class called “.forward“, so assuming “rotationA” and “rotationB” are our quaternions, we can get our two directional vectors like this:

// convert both rotations to direction vectors:
var forwardA = rotationA * Vector3.forward;
var forwardB = rotationB * Vector3.forward;

var forwardA = objectA.transform.forward;
var forwardB = objectB.transform.forward;

var forwardA = transform.forward;

var forwardB = target.position - transform.position;

The final part of the puzzle lies in the fact that you want a signed angle (i.e. either a positive or negative angle). That is, you want to know more than just the numeric difference in angles, you want to know whether to turn clockwise or anticlockwise to get there. To get a signed angle doesn’t really make a lot of sense in 3D space, because the direction of rotation from one direction to another could be in any 3d direction (not just in one of two ‘flat’ clockwise/anticlockwise directions).

For this reason, it usually makes sense to compare your vectors on a certain chosen 2D plane, and ignore the 3rd axis. For example, in the case of cars you’d probably want to compare the “Top Down” directions as if on a map, ignoring the inclines of hills. This would be the X-Z plane in Unity.

To convert these vector directions to numeric angles in this way, you can use the Atan2 function, like this:

// get a numeric angle for each vector, on the X-Z plane (relative to world forward)
var angleA = Mathf.Atan2(forwardA.x, forwardA.z);
var angleB = Mathf.Atan2(forwardB.x, forwardB.z);

// get a numeric angle for each vector, on the X-Z plane (relative to world forward)
var angleA = Mathf.Atan2(forwardA.x, forwardA.z) * Mathf.Rad2Deg;
var angleB = Mathf.Atan2(forwardB.x, forwardB.z) * Mathf.Rad2Deg;

// get the signed difference in these angles
var angleDiff = Mathf.DeltaAngle( angleA, angleB );

Hope this comes in handy out there in Unityland!

I tried out a number of new things while putting this together, including:

• Procedurally generated spherical terrain
• Spherical gravity
• Custom grass shader
• Depth of field effects
• Explosion effects (not detonator)
• Intuitive auto-targeting of enemies

Whether this ever makes it to the status of a finished game remains subject to the mysterious tides of fate.

What I can share:

- It’s a racing game
- It features very fast cars
- It has procedurally created tracks, meaning it has… INFINITE LEVELS!

Here’s some video. (The track building process has had gratuitous animation added for artistic effect):

And here are a few stills of the procedural system with some explanations:

First a track surface mesh is build based on a 3d spline curve

Detail objects are added along the roadside

Non-intersecting locations are calculated for larger roadside scenery

A heightmap is computed which fits the spline, and objects are automatically grounded to it

And here are a few in-game shots of some of the possible track layouts:

• Create a default particle system from the menu in Unity’s UI
• Delete just the “Particle Animator” component
• Check the “One Shot” option in the emitter settings

Now you have a static set of particles. The min & max emission controls how many particles there are (you should probably set them both to the same value, unless you want a random value somewhere between the two). The default particle textures are already fairly suitable as they are have a fuzzy glow look. Try these values for a very quick nebula-like effect:

• Min size: 0.1
• Max size: 0.7
• Min & Max emission : 200

You might want to set one of the ellipsoid size dimensions smaller than the others, to give it a sort of oval shape instead of spherical. And of course you could  use some custom particle textures, colour variations, and adjust the size to fit your game.

When I tried this, I found that having two particle systems in the same location worked really well, where the first particle system serves to show the larger blobby white areas, and the second particle system has the size values turned right down so that the particles are tiny specks, and the emission values turned right up (to 2000 or so).

Using two particle systems

The settings for the first particle system are:

• Min Size: 0.3
• Max Size: 3.5

And for the second particle system:

• Min Size: 0.01
• Max Size: 0.03

And apply these settings to both systems:

• Emit: On
• One Shot: On
• Simulate in world space: off
• Min Emission: 2000
• Max Emission: 2000
• Ellipsoid: X:8, Y:4, Z:8

Then add the second system as a child of the first system (by dragging the 2nd onto the 1st in the hierarchy). Because they are not set to simulate in world space, you can then just rotate the parent particle system and the whole nebula will rotate including the tiny dots in the child particle system.

(until I sort out proper hosting for my unity files on this blog, you’ll have to make do with pretty pictures and video!)

Sometimes it’s looking into a section of the manual or API that I’m less familiar with. Sometimes it’s reading up on developments in the technologies that surround my field of work. Sometimes it’s helping out with a question or two on the Unity forums, or the IRC channel (which are both places that I go looking for help myself too, sometimes). This often results in “saw-sharpening” because my favourite type of questions are the ones where I sort of know the answer, but I have to quickly look up / test out that knowledge to confirm it. This has the effect of hardening what was vague knowledge of a particlar area into a small chunk of concrete experience, which effectively adds to the array of tools and know-how that I have at my disposal when approaching my own work.

In this new “Quick Tips” category, I’m going to be documenting these short & sweet nuggets of information. In effect, this is a kind of excuse to get a bit more content posted here in the tiny amounts of spare time that I have. They won’t be full tutorials, they might not be useful to everyone, and they will almost certainly vary wildly between beginner and advanced levels – but if you’re interested in the occasional sharpening of your Unity blade, please feel free to subscribe or follow!

Making full use of Unity’s physics engine, and some of the pro features such as refraction in the ice shader, full-screen glow and ambient occlusion (although these features are automatically deactivated if the frame rate drops too low).

The demo will fill your browser window, so if you find its running at too slow a frame rate, you can always reduce the size of the window. You can also manually flip up and down through the quality degradation steps, by holding down ‘Q’ and pressing ’1′ or ’2′.

Use arrow keys to control the scoop and exacator body, and use WSAD to control the tracks. Enjoy!

Mmm, refractive bump mapped ice!

Time to get cracking!

Once you manage to navigate your way to the ice block, it’s fairly easy to break

My work here is done!

Or is it?… destroy the rest!

The Skive Unity3D Christmas Demo – Click here to play!