Kelly checks her work items. Uh oh, a client freeze. The KickStarter milestone’s been slipping and the money is starting to run out. Right now, showstoppers are exactly what they don’t need.

Thank god Jack’s the one on the forums trying to pass a vote on paring back the milestone requirements. If he can’t get the ‘No’ vote lower than 43%, refunding that percentage of the users will send them insolvent. It takes preternatural calm to operate at the intersection of community management and project management.

She takes a deep breath and pulls from the QA repo. There’s several thousand session recordings in here, but her filters only show the busted ones. Sure enough, there’s a new fork in the replay tree and it’s red. “Watchdog violation: Over 1000 frames since input was last polled”. The offending fork doesn’t look much different from its sibling forks: same sequence of button presses, slightly different timings. If not for the freeze, the QA guy on topiary duty probably would’ve coalesced it into the sibling test cases.

Hmm, the work item has a VM image attached, but with everyone pushing changes like mad throughout the morning, she’d rather repro on the current codebase. She enables the audit log on the client that’s allegedly going to be the victim of this scenario. She taps the tip of that red branch and her PC’s displays take on the appearance of a surveillance system as the various game clients start up one by one and begin replaying the session that lead to the freeze. She rouses the cat from her lap and heads to the kitchen for a coffee.

Five minutes later, Kelly plops back down, coffee in hand. Bingo, it’s still busted. The game phase coroutine is stuck. At least it’s deterministic this time. Looks like the player was in the middle of dismounting their horse when the game froze. The coroutine’s waiting on the end of the dismount animation, but it never comes.

Oddly enough, the player’s current animation isn’t dismount. Where the hell did that value come from? Kelly has her IDE generate a data flow tree for the state variable. Her PC grinds away at rerunning execution from the last checkpoint.

The character animation state machine was a mess of amateurish hacks they’d picked up at auction from a somewhat unluckier project that’d gone belly up. They’d come to regret cutting that particular corner.

Aha! The state is passed around as if the authors were laundering a drug fortune, but the root of the problem is that a grapple interrupted the dismount. This isn’t supposed to happen. Dismount is sacrosanct.

Who implemented grapples? She squints at the fine print in the blame margin of the editor window.

“Radko (12/10/21): Fix exploit where jumps cancel grapples“

Hmm, where in the world is Radko Stamboliyski? Remote contractors had been going AWOL since the finances starting looking bad. They haven’t been able to get in touch with him for a week. He could be anywhere in Bulgaria. Hell, maybe the Bulgaria thing was a lie all along? Either way, she’s not getting an explanation for that commit.

A quick check in the animation timeline reveals the problem. The annotation that suppresses the animation being interrupted stops a frame short of the end. Argh! First frame inclusive, last frame exclusive! When will people learn.

One frame glitch. That explains why it survived until now. Hardly seemed worth the panic. Looks like the fangirls might get their Renaissance action-romance after all.

Inspired by:

• Slightly Mad Studios living up to their name
• The Inform 7 Skein
• Reversible Debugging

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.

Cross-domain scripting

Unity Player 3 tightened up the security model to match the same-origin policy of Adobe Flash Player. Basically if you request information from a different domain to the one where the .unity3d file is hosted, the owner of that domain has to explicitly allow it using a file called crossdomain.xml. You’d imagine that would prevent the analytics from working, but it’s not affected.

With this technique the sequence of events is:

• The app makes a Javascript call to the enclosing page.
• Google’s Javascript snippet rolls up all the event data into a query string, then requests a GIF image from their servers with the query string in the URL.
• Google’s server logs the information in the query string, and sends back an empty GIF which is discarded by the client.

Cross-domain restrictions apply to the request of the GIF, but luckily it’s the web browser making the request, not Unity. Loading an image in the browser isn’t subject to Javascript’s same origin policy. It works just as if you were hot-linking the image at Google.

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.