No longer updated.

Just a note to say this blog is old and no longer updated. I most likely won’t see or reply to comments here. For up-to-date goings-on, find me at robotduck.com

Epic Kite Day

Epic day flying kites.

 

Young Game Designer’s Week – Day 5/5

The week is complete!

This afternoon was crunch time as we made sure all students finished their games and tested them as much as possible. Those who had finished helped play-test each other’s game for the rest of the afternoon and one or two just managed to solve their final bugs in the last hour!

Out of the ten students, eight chose to upload their games to Kongregate, so without further ado here are the links. Enjoy!

Coat Man Begins

RC Maze Of Fortune

The Rondo of the Eternal Diva Demo

Professor Ball and the Quest for the Ears

Jeep Racing

Boson Barrage

Llama’s Adventure

Desert Tank

A huge well done to all the students for learning so much and getting their games finished. The week was a total success!

Young Games Designer’s Week – Day 4/5

Day 4 complete. At the start of today I introduced the idea of “Feature Lock”, meaning the deadline for implementing new features. Our feature lock deadline is the end of today. Tomorrow (the last day of the course) should be reserved for play testing, bug fixing, polish and publishing. This means all the core gameplay mechanics for the game should be complete and working, even if some parts of the game are still using placeholder art, or have no sound, for instance.

The students all made a lot of progress again today, with some games looking almost finished by lunchtime, while others are cutting it somewhat finer in terms of getting a finished playable game ready for tomorrow. One of the difficult parts of running this workshop is making sure that everyone understands how much we can and cannot get done by the end of the week, and which elememts to focus on. For example, having a working title screen, lives system and game over screen which allows the game to be restarted is more important than finding some royalty free music for each level, or tweaking particle system effects!

Anyway, here are some more screenshots of the games. We have a really nice mix of styles including 2D platformers, first-person maze and exploration games, driving games, tank combat, a vertical scrolling shooter and the LHC Particle game mentioned above! We’re hoping to get them uploaded by the end of tomorrow so they will all be playable.

Young Game Designer’s Week : Day 3

Day 3: All the students are well into their own game production now. Today featured a lot less teaching up on the big projector and more one-to-one time with each student tackling the challenges unique to their projects.

I introduced the idea of setting “milestones” as a way to track progress and ensure students are concentrating on the highest priority areas of their game development first. This is to ensure we don’t get bogged down in details (such as artwork) before we have all the basic game mechanics implemented. Many of the students ended the day with the functionality implemented for a title screen, game over and end-game conditions, and other “core mechanics” they’ve chosen such as collecting items, opening doors, etc. We still have a long way to go with only two days left though, so I’m trying to instil the idea that tomorrow (Day 4/5) should be considered the last day in terms of implementing features, and Day 5 should be solely about testing, polish (and adding any extra art to replace placeholders), and publishing.

Some snapshots of some of the games in development:

Young Game Designer’s Week – Day 2

Day 2 complete!

This morning I covered a lot of ground. By lunchtime I wanted all the students to have come up with a simple game design document showing the plan what would be in their game. First of all though, I wanted to give a wider view of some of the different styles of game that can be made with Unity, since we spent the majority of the time yesterday looking at things via the standard first-person controller prefab, and I really didn’t want to end up with ten first-person cube-firing physics shooters at the end of the week!

I demonstrated a range of different pre-made types of “player control” as alternatives to the first-person control we used yesterday. We had:
– A rotational third-person character with an over-the-shoulder camera view.
– A directionally-controlled character with a higher overhead style non-rotating camera view (rpg style).
– A physics-ball control similar to marble madness / super monkey ball.
– A generic flying “vehicle” which could be used for anything from a bird to a jet fighter
– A steerable car using wheelcolliders and suspension

I also ran through a list of the types of interactions and game-like activites that are particularly easy to achieve in Unity, such as
– Collecting items
– Physics challenges (building/toppling stacks, see-saws, swinging or hinged objects, etc)
– Numeric counters (ammo / health / targets or checkpoints hit)
– Trigger and Collider events
– Animation (eg, doors opening)

I also presented a short slideshow explaining a useful design “tool” described by Charmie on the funstormgame.com blog which is basically a simple diagram which helps you look at a game in terms of layers, with the game’s “core mechanic” at the centre, surrounded by secondary mechanics, then game progression, and finally the ‘story’. The article is a good read, and the slideshow I made was basically just a bulletpointed version of it.

Armed with this inspiration, the students were able to come up with lots of ideas – a few of which were possibly on the ambitious side given that we now have 3.5 days remaining, so I had to help them by suggesting simpler compromises – and by lunchtime each student had their own mini game design doc, complete with a “core mechanic” diagram describing their game.

In the afternoon, everyone dove headlong into making their games, and while going round the room solving individual problems, I also tackled lots of common game features on the projector for everyone to see, such as how to make a title screen, level progression, time limits, more complex trigger mechanisms, 2d camera work, the terrain engine, GUI text and 3D Text.

By the end of the day I was seeing the beginnings of lots of interesting games:

Young Game Designer’s Summer School – Day 1 Complete

Day 1 complete! The starting skill level of the students is little-to-no experience with Unity or game programming. Some of them have done a little coding in other languages, and some have done some quake mapping using quake level editor tools.

This morning was spent mainly getting familiar with the editor, the various windows, creating primitives, manipulating objects in the scene view, importing simple assets (textures, 3d models), materials. In the afternoon we all created a very simple game together designed to quickly tie in a lot of basic concepts such as collisions, prefabs, instantiation, physics, and some simple scripting covering applying forces, sound sources, spot audio effects, detecting collisions and destroying objects with explosions!

Our sample game involved spinning flying saucers flying over a simple scene, with the first person controller modified to fire physics objects when the mouse is clicked. When the saucers were hit, they fall to the ground before bursting into flames.

From tomorrow the students will be branching out with their own game ideas – starting with making a simple game design and specification document, including deciding on what are achievable targets within the remaining four days. Should be interesting 😀

Young Game Designer’s Week – Summer School

This morning saw the start of Young Game Designers Summer School at South Hill Park’s UK Digital Media Centre.

I’m leading this week-long course as we see whether ten teenagers (14-18 years) can learn Unity and make a game in a week, as well as picking up some game design theory and techniques along the way.

I’ll be live-blogging/tweeting as we go and encouraging the students to do the same, so watch this space for updates through the week, or follow me on twitter!

Code Optimization in Unity : Part 2

“By measurement to knowledge”

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!

Code Optimization in Unity : Part 1

“Code Optimization” : the pursuit of modifying code to work more efficiently.

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

This is an unreleased prototype car racing game with 3 AI opponents, collectible items and physics objects strewn around the track. The profiler output is different, and most of the numbers (except those marked with #) are measured in milliseconds. I’ve cut out a few of the less relevant things, plus the items which came in at zero (such as skinned mesh animation – since this game doesn’t use it). My average frame time is 34.9ms (which works out at roughly 30fps), and of that time, my scripts (update & fixedUpdate) take up about 15% of the total frame time, physics take 24%, and rendering takes about 12%. I’m assuming the remaining time is simply the overhead of the unity engine running on the iPhone.

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!