I started designing a database and looking at server-side programming languages. After I’d been working on this for a couple of days, I thought “logging events and aggregating statistics is incredibly common, someone must’ve done this already. If only I could use their code…”

Then I realised, Google Analytics. Duh!

Google Analytics logs web traffic numbers and gives you a nice user interface for slicing and dicing the data. Not only had they already written the server code, they also run the server for you! It’s free for the first 5 million page-views per month. I’d been reinventing the wheel.

All I had to do was trick Google, by feeding them a special fake page view whenever a player dies. I soon discovered that Google was way ahead of me. They already have an API for tracking ‘events’ that happen on a page. People seem to mostly use these for integrating e-commerce sale figures into their web traffic reports, but it’s equally suitable for tracking in-game events.

Setting Up

If you sign up for Google Analytics and put their Javascript snippet in the page with the game, you’re all set. You’ll need your own domain name, or a subdomain at the least to sign up.

Here’s the code you need to run in Unity whenever something happens:

Application.ExternalCall("pageTracker._trackEvent", new object[] { category, action, label, value} );

Um, that’s all of it. This is a non-blocking call to run a Javascript function in the page that holds the Unity Player. I haven’t investigated triggering events from a standalone app yet.

The line above will work with the standard Javascript that Google hand out upon signing up. Note that you won’t be able to test it locally – it needs to run on a page hosted at your domain. If you run it locally, you’ll get an error in the Javascript console saying ‘O not defined’.

Data Model

By now you’re probably wondering what the 4 parameters are to our function call:

• Category. This is a free-form string used to categorise your events. It’s the highest level of organisation applied to your events. I’ve been storing a concatenation of the game name, version number and level ID in here.
• Action. Another free-form string which represents the type of event. I’ve been using actions such as “killed” and “game_start”.
• Label. This is an optional string parameter to the action. For example, the killed action uses the label to store the cause of death.
• Value. This is an optional fractional number parameter to the action. For example, I keep the length of the game session in here when I send the ‘game_end’ action.

Analysis

So what’s all this look like from inside Google Analytics? It’s a batch processing system, so first you need to wait overnight for your data to come through. Next, log in, pick your site and select ‘Event Tracking’.

You’ll see a hierarchy of categories and actions, like so:

Yes, those are real numbers. Some day I’ll get around to promoting this site.

If I want a breakdown of causes of death in Glob Arena, I hit the ‘killed’ link and get this moneyshot:

Glorious.

Limitations

Thankfully, collecting personally identifiable information via Google Analytics is not allowed. Not only is it a sleazy thing to do to your customers, it’ll get your account banned.

This means that you’ll only get aggregate information on player behaviour. You can split the statistics up into sub-populations using the Advanced Segments tool, but it won’t ever show you a log of some individual’s actions. Google Analytics is no substitute for asking someone to test your game, while you look over their shoulder.

When I tried to figure out what I was smelling, I realised it had come from the pokies machines in a pool hall that’d walked past. I still can’t pin down exactly what it was. Pine chipboard cabinets riddled with borer and marinated in tobacco smoke? Maybe I can just smell the coin-op?

It’s so heavily data-driven that all the game code is written in script and the native code layer is almost entirely hidden (only in the pro version C++ plug-ins can be created). The engine contains most of the systems you’re likely to need for a game: 3D rendering with shaders, a level editor, a 3D asset pipeline, a physics engine, a rudimentary GUI system, network state synchronisation and RPC.

Unity is the subject of all kinds of hyperbole around the web. Back when I first heard about it, I wondered how much of the praise was down to Mac-heads who were simply delighted that the authoring tools were Mac-only. Since then, they’ve ported the tools to Windows and I’ve discovered that it really is pretty damn nice. It’s extremely quick to learn – I had a playable prototype of the game mechanic that I was trying out on Day 2 of using it.

Unity’s greatest asset is its clean design. It has a beautiful component architecture where you write update methods and event handlers in script, encapsulate them into component objects and then assemble them into game objects via drag ‘n’ drop. Exposing tweakable parameters is merely a case of declaring a component member public.

Unity is my first choice for prototyping, but I’m doubtful it’d be flexible enough to ship a full-scale game based on it. The drawbacks are:

• No script debugger. The editor offers excellent facilities for inspecting and changing object properties in a running game session, but there’s no line-by-line script debugging.
• No load/save framework. In spite of all the network serialisation stuff, you’re on your own when it comes to writing out a save game. There’s Dot-Net’s object serialisation and I/O though, so it’s not completely low level.
• The GUI framework looks to be somewhat bare in places. No modal dialogs for example.
• The physics API is an intelligently chosen 80% solution. It caters to the common uses of physics. If you’re in the weird 20% like Portal or Braid, you’ll probably spend more time fighting Unity than worthwhile.

That said, it’s superb for what it is and it’s been getting more flexible with every release. It’s a taste of the future of game development. Ideally, the only code required for a game should be gameplay-specific. Middleware has been getting steadily more and more comprehensive, and I can see the day when the only folks working on engine-level stuff work at Unity, Autodesk, Epic and Intel.