31 January 2016

Forwarding trigger events

Sometimes when developing any kind of game you want to have a function called on an object A (not necessarily a GameObject) when object B hits a trigger defined by object C. For example, A can be your game controller, B your player's avatar and C a trigger next to a door. When the avatar walks into the trigger you want to call something like

GameController.Instance.LoadLevel("nameofthelevel");

So you write a "DoorTrigger" monobehaviour with a public string member for the name of the level that should be loaded when the avatar walks into the trigger. Perfect.

The things is that this is a very common behaviour; often you just want to call one simple function on another object when the player (or something else) runs into a trigger and often the trigger object and the callee for the function is not the same object. Writing a new class for every occasion is cumbersome.

In the UnityEngine.UI namespace we have the EventTrigger class that solves exactly this issue, but then for input events. When a ui button is clicked the code for doing something with that event is often not in a monobehaviour on that button, but likely in some PanelController class that controls the panel. So you use the button's functionality to forward the event to that controller. The EventTrigger class does the same thing for other ui objects than buttons.

So we thought to take a peek at the open source implementation of EventTrigger and see if we could mimic the same easy editor interaction for physics trigger events. We finally came up with a class called ForwardTrigger that can be found here. It is very similar to the code of EventTrigger but a lot less complicated, since we don't have to deal with InputModules but simple trigger events.

We introduced a PhysicsTriggerEventData class that tells you what object the trigger was and what object the collider was. We also copied with very little changes the code of the editor for that class so that we can now forward physics trigger events as easily as we could forward click events:

A working example is hosted on this bitbucket repository called "UnityToolset". This repository will become the place where I'll add all code that I frequently use in multiple Unity projects (as long as it is not under NDA) and also all code that I write about on my blog. I welcome all feedback on this project!

06 January 2016

Unity crash dumps to the rescue!

My last post ended with me being disappointed about the state of our webgl build of Kweetet. I'm happy to say that I solved a lot of the remaining issues in the past holidays, against my expectations! The WebGL build might be a viable production target after all.

Nevertheless we still need a standalone build, because it's clear that WebGL is not fit for older systems. The memory usage has become less (around 1GB) but it's still a lot and we have a target audience that sometimes has only that.

Creating a standalone version went fast, i was done in a day, but that doesn't come as a surprise since standalone windows and webplayer builds are very alike.

A colleague of mine always had the weirdest crashes in the webplayer. It was always only on her pc and we could never reliably reproduce it. The log of the webplayer pointed in various directions, but we could never determine the cause of the crashes. Now with the standalone build she had the same crash and behold: there was a crash.dmp file! I've always made builds for mobile and web platforms so I had no idea that standalone build generated dump files. I opened it in Visual Studio immediately. I couldn't do much with it at first, but googling around brought me to this thread on the Unity forum where I learned that Unity has a symbol server! There you can download the pdb files for a standalone build, or even better, you can add the server to your debugger settings in Visual Studio:

Once you've done that you have an accurate callstack of the crash. The callstack was completely different than anything reported in the webplayer log files, but it explained completely every crash my colleague has had. It was an easy fix after that.

Trying to reproduce hard to find crashes in the webplayer or even the webgl builds with a standalone build can really pay off.