GDC 2014 Wrap-up

Wow! What an incredible conference GDC was this year! Our booth was awesome, incredibly busy, and full of amazing friends and partners demonstrating how talented the wide Unity community is. But while the show was great for us, it was truly amazing for developers everywhere.

10 short  years ago, Unity was just 3 guys in a basement trying to create tech to enrich the lives of developers. Who would have thought that the company we started and technology we built would grow into this amazing community and have such an incredible impact on the industry!


It’s humbling to see our mission to democratize development succeed in a golden age of creativity. We want to continue providing the best tools to empower you to create awesome games and become successful. This means keeping the largest number of supported platforms, increasing the usability of the tools to make sure you can experiment and iterate quickly to realize your vision, and providing services to help you connect your games with great audiences.

Unity’s acquisition of Applifier, creators of the awesome Everyplay and GameAds services, was a big step in our new journey to democratize the bits that sit outside of creative game development. Connecting players with your game and your studio is easily one of the biggest challenges to modern developers. Of all the solution we have seen (and we’ve seen many) the Everyplay replay sharing network is the coolest way to help a game connect with an audience, and for current players to find out more about the games they’re playing. You can read more about this announcement here.

Our other big announcement was Unity 5! This is a leap forward in graphics fidelity, adding physically-based shaders and real-time global illumination with Enlighten – but this major cycle is about more than that. The unified shader architecture, real-time lightmap previews, and revamped audio system are there to make your lives easier and games better. The best part of this is that what we announced at GDC 2014 is just Unity 5.0: there are a lot more major additions coming in this cycle to get excited about.

Check out the Unity 5 announcement and make sure to check out the preview video as well.

Our Unity 5 announcement also brought news of our 19th platform, WebGL. We have been hard at work with Mozilla behind the scenes on this and couldn’t be more proud. Seeing Dead Trigger 2 look so good and run so well with real meaty gameplay is amazing. You can see Mozilla’s blog about our work together and the video demo below.

Along with the Unity 5 announcement, we also discussed the future of the 4.x cycle, which includes two more big releases: 4.5 and 4.6. Unity 4.6 is especially noteworthy as it marks the release of our much anticipated new GUI system. We can’t wait to get it in your hands!

If the games and developers hosted in our Games Pavilion this year are any indication, we can expect a lot out of you all in the next couple of years. Not only did we have top notch visuals covering a variety of genres and styles, we had a group showing off just how powerful the tools can be for small teams. Just look at Team Colorblind, a team of two, creating Aztez for seven platforms, including all of the consoles! So thank you to 5 Bits Studios, Amplitude Studios, Dynamighty, HB Studios, Infinite Fall, Madfinger Games, Press Play, Proletariat, Snowcastle Games, Team Colorblind, ustwo, and Witch Beam Studios for making us look good! And, if you haven’t seen it yet, check out our new game reel from GDC that showcases some of the games that were at our booth along with a few others.

GDC 2014 turned out amazing! The industry as a whole lept forward, and we’re extremely proud of the part we played in this transformation. It’s exciting to walk side by side with so many of you into the future of the industry.

– David Helgason


A vote for a bug

Due to popular demand, we have decided to open our bug database to the public. Take a look at the issue tracker and vote on the bugs that are most important to you here.

We want to enable you to search our known bugs easily, so you can identify problems in your games and find workarounds faster. As a user, you can also comment on bugs, vote on bugs that are important to you, suggest workarounds you found or add information. We will use this information in our ongoing prioritization of bugs, so you can have a very real impact on the future of Unity.

When you have logged in with your Unity Developer Network account, you will have 10 votes you can place on active bugs. If a bug is resolved or in other ways removed, the vote is returned to you. You can always see a list of your own votes on the site.

Privacy has been a huge concern for us, so ANY bug which reveals ANY information about the submitter will NOT be made public. It is a manual task for QA to mark bugs public and the default is that a bug is NOT public. Likewise, we are not sharing projects, logs, attachments or communication on any bug even though it might help others. We simply can’t risk any privacy to be invaded.

The bugs you will see on the site are all confirmed internally in Unity. They are reproducible and acknowledged. If you have sent a report to us, it will not be visible before we have processed it, so it may not even become public, depending on how we decide to handle it. The fields we use are set specifically by us, so no part of what you write will be public without editing and your email address is nowhere on the site.

We are very excited about opening up this new way to communicate with you. We hope it will result in an even tighter and more relevant prioritization of bugs. Enjoy, and use your voting power!

Cutting edge AAA shading technology for all

Physically-based surface shaders in the Asset Store

So… physically-based surface shaders. Physically-based what? I hear you say. Even though we consider ourselves a company with its finger firmly on the gaming pulse, some of us had to have this explained (not the graphics team I hasten to add).

Physically-based surface shaders are a revolutionary (and really cool) way of doing shading that generate far more realistic and vibrant results. What distinguishes them from other shaders is that they actually mimic the behaviour of surfaces in the real world by following the law of energy conservation: the total amount of specular and diffuse reflection always equals the amount of incoming lighting energy.

The huge advantage of physically-based surface shaders isn’t just the exceptional visual fidelity they achieve, it’s that they look incredibly lifelike irrespective of the lighting conditions under which they’re used. Steel will look like steel whether it’s reflecting bright sunlight off a knight’s breastplate or used in a handrail on a dark and dreary New York backstreet. There’s no need to adjust your shader settings to get things looking ‘right’ when authoring different environments.

Physically based surfaces can have a wide range of reflective behaviour, making it easier to give shiny plastic, metal, wet stone and everything in between a unique visual identity. The Alloy Physical Shader Framework by RUST LTD, available now on the Unity Asset Store, brings this technology to Unity Pro.

Physically-based surface shaders are finding their way into many of the latest AAA productions like Killzone 3, Metal Gear Solid 5 and RYSE. RUST LTD’s Asset Store product is different in that it makes this technology accessible to small teams – or even individuals. By the way, RUST LTD are the team behind Museum of the Microstar – our DX11 contest winning entry. Museum of the Microstar used an earlier version of Alloy and showed its use scaled to intense heights.


The workaholic perfectionists at RUST LTD have spent 2 years working day and night to get the product to the point where they’re happy enough to release it, and somehow they’ve also found the time to come up with lots of learning material to help you guys get started. The Alloy package ships with a comprehensive sample scene, including over 30 complete materials with interactive controls so you can get up to speed fast on how to get the most out the set. Also, if you find yourself needing even more out of Alloy, the set is configured to make extending it with your own variants as easy as possible.


“Being indie, and having worked so much with small teams and students, we wanted to make a tool that people like us could use. Artists and game designers without the resources of a full studio behind them now have accessible tools.”
Anton Hand, Beard Warrior at RUST LTD.

Alloy is built around a Normalized Blinn-Phong BRDF, which provides a great balance of speed and sophistication, and is fully compatible with DX9 and the light pre-pass renderer of Unity’s deferred mode. The Alloy set contains variants for all the common visual characteristics you might need including rim lighting, separated occlusion maps, detail maps, and several types of translucency.

Lastly, for those who don’t want the headache of managing cubemaps in complex environments, Alloy includes a complete set that uses Radially Symmetric Reflection Maps (RSRMs), a general-purpose blurred reflection texture that makes baked surfaces look shiny, without looking like perfect mirrors.

In an upcoming post we’ll dive deeper into both the technical details of Alloy, and the implications of developing content for a physically-based pipeline… stay tuned!

So, whether you’re a large team looking for that AAA graphics punch for your next-gen console game, or an indie trying to add wow factor, Alloy is ready for you. Check out these downloadable projects and demos made with Alloy, or simply purchase directly from the Asset Store.

Come Learn with Learn

So you’ve decided to download and check out this newfangled “Unity” thing. You open it up, create a project, and are presented with the Unity editor.  At this point you’re probably thinking to yourself, “OK, now what?” That’s where we come in. We are the Unity Learn team and our goal in this crazy, hectic world is to labor tirelessly to bring you the best content to learn from and utilize in your games. Of course, now you are probably thinking to yourself, “That’s an interesting claim, faceless-internet-article-writing-man, but certainly your content can’t help me. I make special games!”  Nay, I say to you. Our content can help anyone learn to use Unity to make all kinds of games. Just look at what we have to offer (the Learn portion of Unity’s website can be found at


You like tutorials. We get that. That’s why we’ve made a bazillion of them and we keep adding more. We get that you’re too busy to read all sorts of words. That’s why our tutorials are video tutorials in stunning high definition! You never have to guess where an option is or what a button looks like. Just grab a bowl of popcorn and your favorite caffeinated beverage, queue up our videos, and follow along. You’ll be a pro in no time (warning: watching videos actually takes some time due to them not existing inside a black hole)!


Come check our newest initiative: Live Training! That’s correct, come hang out with a real person as we teach concepts and answer questions in real time! Right now you’re thinking, “Blargpfpfpf” (that’s the sound of your brain exploding). Not only do we deliver content live, we actually really enjoy it! Come check out what we have scheduled. You can also watch past sessions to see just what you’re getting yourself into. We look forward to seeing you there. I mean you specifically, John (your name is probably not John, but if it is, I just blew your mind).


Perhaps you’re the type of person that prefers to drudge through tons of documentation. Never fear, we have that too. Chances are most of your questions and curiosities can be resolved simply by flipping through the posted articles and examples. So feel free to dive right in. There’s nothing wrong with being a lone wolf. We won’t tell anyone.


It can be very frustrating when you have a specific question that no resources seem to address directly. Luckily, Unity has a fantastic community. While not directly controlled by the Learn team, it’s still on our page and so it will be mentioned here (and there’s nothing you can do about it). Stop and in say “Hi” to fellow Unity users in the forums. Also, swing by the Unity Answers section to ask specific questions and get an amazing level of help! We’re all in this together!


The Unity Learn team is a giant collection of superhuman awesome-sauce.  We are here to provide you with content and to lower the barrier to entry into game development. We recognise that you would rather make games than learn to make games, so let us expedite the process for you. Swing by our live sessions or check out our pre-recorded videos to start learning.

Got questions, comments, suggestions, snide remarks, or personal anecdotes? Hit us up on twitter:


@mikegeig (That’s me!)

@willgoldstone (He’s like a British Ryan Gosling)

@theantranch (a.k.a Little Angel)

@robotduck (He is an actual duck… no kidding)

@rodulator (Scottish and angry, best leave him alone)

Now go and make games. We expect to see progress!

Occlusion Culling in Unity 4.3: The Basics

The following blog post was written by Jasin Bushnaief of Umbra Software to explain the updates to occlusion culling in Unity Pro 4.3.

Unity 4.3 includes a plethora of improvements. One of the completely re-implemented subsystems is occlusion culling. Not only has the interface been simplified and the culling runtime itself revamped, a number of new features have also been added.

In this series of three posts, I’m going to go over how the new occlusion culling system works in Unity 4.3. This first post goes through the basics of how occlusion culling is done and what the basic usage is like with the user interface. The second post focuses on best practices to get the most out of occlusion culling. The third and final post focuses on some common problem scenarios and how to resolve them.

rsz_01_window_menuBut let’s start with some basics. Occlusion culling refers to eliminating all objects that are hidden behind other objects. This means that resources will not be wasted on hidden stuff, resulting in faster and better-looking games. In Unity, occlusion culling is performed by a middleware component called Umbra, developed by Umbra Software. The UI, from which Umbra is controlled in Unity, can be found in Window – Occlusion Culling, under the Bake tab.

How Umbra Works

Umbra’s occlusion culling process can be roughly divided into two distinct stages. In the editor, Umbra processes the game scene so that visibility queries can be performed in the game runtime, in the player. So first, Umbra needs to take the game scene as its input and bake it into a lightweight data structure. During the bake, Umbra first voxelizes the scene, then groups the voxels into cells and combines these cells with portals. This data, in addition to a few other important bits is referred to as occlusion data in Unity.

In the runtime, Umbra then performs software portal rasterization into a depth buffer, against which object visibility can be tested. In practice, Unity gives Umbra a camera position, and Umbra gives back a list of visible objects. The visibility queries are always conservative, which means that false negatives are never returned. On the other hand, some objects may be deemed visible by Umbra even though in reality they appear not to be.
rsz_02_umbra_workflowIt’s important to realize that, while this system appears similar to what was shipped with previous Unity versions, the entire system has been basically rewritten. A lot has changed for the better, both internally and externally!

How to Use Umbra
There are obviously a few considerations in getting the best out of occlusion culling. Ideally, you’d want the least conservative result as fast as possible. There are, however, tradeoffs involved. The more accurate (i.e. the least conservative) results you want, the higher-resolution data you need to generate. However, higher-resolution data is slower to traverse in the runtime, yielding slower occlusion culling. If occlusion culling requires more frame time than it saves by culling, it obviously doesn’t make a whole lot of sense. On the other hand, very quick culling isn’t of much help if only a few objects are culled. So it’s a balancing act.

03_occlusion_uiThe way Umbra lets you control this balance is by having you define a couple of bake parameters. The parameters determine what type of input the bake process should expect and what type of data is generated. In the runtime, using Umbra is as simple as it gets. If you’ve baked occlusion data and the camera has occlusion culling enabled in the Inspector, Unity will use Umbra automatically.

Smallest Hole
The input is controlled using the smallest hole parameter. When voxelizing the occluder geometry, smallest hole maps almost directly to the voxel size. This means that if your geometry contains intentional holes, gaps or cracks that you wish to see through, using a smallest hole smaller than these is a good idea. On the other hand, a lot of the time the geometry contains lots of unintentional cracks that you do not wish to see through. A reasonable voxel resolution will patch these up. It may help to think about smallest hole as the “input resolution” of the bake.

Note that setting smallest hole into a ridiculously small value means that baking will be unacceptably slow and/or take up a monumental amount of memory in the editor. In some rare cases, it may even cause the bake to fail due to insufficient memory. Then again, while using a larger value will be faster and more memory-friendly, it may cause Umbra to not see through things like grates or fences. So bigger isn’t always better either. In general, a smallest hole as large as possible without visible errors is desirable. In practice, we’ve found that values between 5 cm to 50 cm work fairly well for most games where the scale is “human-like”. The default value in Unity is 25 cm, and it’s a good starting point.

Smallest Occluder
While smallest hole mostly deals with what type of input geometry you have, smallest occluder determines what kind of output data is produced. In essence, you can think about smallest occluder as the output resolution of the data. The larger the value, the faster it is to perform occlusion culling in the runtime, but at the cost of increased conservativity (false positives). The smaller the value, the more accurate results are generated, but at the cost of more CPU time. Obviously higher-resolution data will mean a larger occlusion data size as well.

So as the name implies, a small value means that very fine features are captured in the occlusion data. Under the hood, this directly maps to how large cells Umbra creates. Lots of small cells mean lots of small portals between them, and naturally it’s more expensive to rasterize a large amount of small portals than vice versa.
The effects of changing smallest occluder can be seen in the picture below. Note how the depth buffer, which is essentially what Umbra sees, loses detail as smallest occluder increases.

rsz_06_level_of_occluder_detailIn most games, keeping smallest occluder slightly larger than the player, so around a few meters, is a good default. So anywhere between 2 and 6 meters may make sense if your game’s scale isn’t microscopic or galactic. The default value in Unity is 5 meters.

Backface threshold
Perhaps the most difficult parameter to grasp is called backface threshold. While in many cases you don’t really need to change it, there are some situations in which it may come in handy to understand how it affects the generated data.

First, it’s important to note that the parameter exists only for a single purpose: occlusion data size optimization. This means that if your occlusion data size is OK, you should probably just disregard backface threshold altogether. Second, the value is interpreted as a percentage, so a value of 90 means 90% and so on.

OK so what does backface threshold actually do then? Well, imagine a typical scene that consists mostly of solid objects. Furthermore, there may be a terrain mesh whose normal points upwards. Given such a scene, where do you want your camera to be? Well, certainly not underneath the terrain, that’s for sure. Also, you probably don’t want your camera to be inside solid objects either. (Your collision detection normally takes care of that.) These invalid locations are also ones from which you tend to “see” mostly back-facing triangles (although they may of course get backface-culled). So in many cases it’s safe to assume that any location in the scene, from which the camera sees a lot of back-facing triangles, is an “invalid” one, meaning that the in-game camera will never end up in those locations.


The backface threshold parameter helps you take advantage of this fact. By defining a limit of how much back-facing geometry can be seen from any valid camera location, Umbra is able to strip away all locations from the data that exceed this threshold. How this works in practice is that Umbra will simply do random-sampling in all cells (see the previous post) by shooting out rays, then see how many of those rays hit back-facing triangles. If the threshold is exceeded, the cell can be dropped from the data. It’s important to note that only occluders contribute to the backface test, and the facing of occludees doesn’t bear any relevance to it. A value of 100 disables the backface test altogether.

So, if you define the backface threshold as 70, for instance, to Umbra this means that all locations in the scene, from which over 70% of the visible occluder geometry doesn’t face the camera, can be stripped away from the occlusion data, because the camera will never end up there in reality. There’s naturally no need to be able to perform occlusion culling correctly from underneath the terrain, for instance, as the camera won’t be there anyway. In some cases, this may yield pretty significant savings in data size.

It’s important to stress that stripping away these locations from the occlusion data means that occlusion culling is undefined in these locations. “Undefined”, in this context, means that the results may be correct, incorrect (pretty much random) or return an error. In the case of an error, all objects are simply frustum culled.

Of course in some cases, there just happens to be some amount of back-facing geometry in valid camera locations too. There may be a one-sided mesh that has been, possibly erroneously, tagged as an occluder. If it’s a large one, it may cause the backface test trigger in nearby areas, resulting in culling artifacts (=errors). This is why the default value of backface threshold in Unity is 100, meaning the feature is disabled by default.


Feel free to experiment with the parameter. Try reducing the value to 90, which should drop a lot of data underneath terrains for example. See how it has any noticeable effect on the occlusion data size. You can go even lower if you want. Just remember to do so at your own risk. If you start popping into rendering artifacts, increase the value back to 100 and see if it fixes the problems.

To be continued…
In the next post, I’ll go into some best practices and recommendations for how to get optimal results out of occlusion culling. Please visit for more information about Umbra.

Part II
Part III


Get a bundle of cool games and support a great cause!

Hello everybody! I’d like to tell you about Super BR Jam, an amazing and unique game jam in Brazil supported by Unity that was held November 22nd-24th. 

A huge group of experienced Brazilian game developers including companies such as Critical (Dungeonland), Behold Studios (Knights of Pen and Paper, Chroma Squad) and Swordtales (Toren) pulled the brakes on their internal projects and came together for the entire weekend to make brand new games.

And here’s where things start to get interesting: All games developed during the Super BR Jam will be made available for purchase at a “pay what you want” model. However if you pay above 5 USD you’ll also get:

– Dungeonland All-Access Pass

– Magicka

– Magicka: Wizard Wars

– The Showdown Effect

– Knights of Pen and Paper +1 Edition

– Project Tilt

– Out There Somewhere

– Qasir Al-Wasat: A night in between

The best part: all proceedings from the bundle sales will go to charity! The chosen charity was Solar Meninos de Luz, a private philanthropic organization which supports formal and complementary education and basic health care to 400 children in impoverished communities in Rio de Janeiro, Brazil.

Dinomancer by Critical Studio

This is what Mark Venturelli, former Game Designer at Critical Studios said about the event: “Wow. I was completely blown away by how amazing the people were. We wanted to show the world how strong our indie scene is here in Brazil, and how we are working together and helping each other. This is a very different game jam: we are selling the games and 100% of the profits will go to a school for poor children in Rio. I think this noble cause really gave everyone an extra incentive to come together and create things that are absolutely bursting with love and care. We still have a few days to go, so we are all still working together – this time to boost the publicity on the event and try to raise as much money as we can.”

Saulo Camarotti, CEO and Founder of Behold Studios said, “At first we thought this would be just another game jam, where we would get some friends together to make a game in very few hours. We decided to make a game that would force us to stretch our skills, to go beyond what we did before, and when we were done (after a lot of sweating) we realised that all that hard work that we put into proving ourselves was directly connected to the help that we would be providing to the children and volunteers at Solar. It was an incredible experience! We are definitely interested in participating again and helping other charities.”

Alien Kingdom by Behold Studios - 01

After the event I was really glad to find out that 18 out of the 24 games were made with Unity and the results are very impressive!

You cand find out more about Super BR Jam and purchase the bundle at the website

So wait no further! The bundle will be available only until December 4.
It’s a great way to buy some cool games at a ridiculously low price and have a nice, warm feeling in your heart at the same time!

Link to site:

 More about the games made during the game jam:

Alien Kingdom by Behold Studios (PC + Mac)
A massively cooperative online strategy game in a beautiful alien world. This game cannot be described in words, just go play it!

Previous games from this developer: Knights of Pen and Paper, Chroma Squad

Kureizy Japanese TV Show by Swordtales
Like a Nintendo game if everyone at Nintendo had a stroke at the same time

Previous games from this developer: Toren

Legend of HUErule by BitCake Studio (PC + Mac)
A simple online RPG with adorable low-poly visuals where your party must work together to defeat increasingly difficulty waves of bouncy monsters

Previous games from this developer: Project Tilt

Cinerea by Otus  (PC + Mac)
A lone woman wandering through alleyways is the theme of yet another mysterious and atmospheric game from Otus.

Previous games from this developer: Niveus

Dinomancer by Critical Studio

Previous games from this developer: Dungeonland

Thunderstruck by Pocket Trap
Defend your castle using the power of lightning! A challenging but rewarding game that looks absolutely adorable

Previous games from this developer: Ninjin, Hell Broker

Final da Zuera by Hoplon

As the crowd of a soccer game, choose wisely how you will cheer for your team

Previous games from this developer: Taikodom, Heavy Metal Machines

Gory Creatures from Across the Yard by Pigasus

You are a crafty pig defending your yard in this polished 3D tower defense game

Previous games from this developer: Adventurezator

Seal League Gravity Ball by Critical Studio

Space seals play football with no gravity. Do not worry, they all have magnetic suits to hover around. And lasers. Can be played with 2 or 4 players locally.

Previous games from this developer: Dungeonland

Unity web hack: embedding Asset Store items made easy

You have a website, right? Or a blog? When posting about the Asset Store, it’s good to show which one of all the amazing assets are you talking about. Keigo Ando from Unity’s office in Japan found out how to do this the easy way!

After embedding this code, all the necessary info like name, category, price and rating shows up, together with a picture and a link. When somebody’s done reading your post, they can hurry up and buy the asset. Needless to say, this is especially useful if you’re a publisher.

For example, paste this in (in the text view, if you’re using WordPress):

script src=”″ type=”application/javascript”/script

and you’ll get this:

To embed other assets, simply find their Content ID at the end of the URL of their asset store page. 11228 is the Content ID of our 2D platformer:

Screen Shot 2013-12-04 at 1.45.11 PM

This is the general script:

script src=”{CONTENT_ID}” type=”application/javascript”/script

It’s just a little convenience feature, but it can save a lot of time.
This should work with most content management systems for websites. The only condition is that you should be able to embed a script tag.

You can choose between different preview sizes and even embed multiple items. For a complete list of possibilities, head over to Keigo’s demo page.


Game Metrics: Their True Nature and What You Shouldn’t Live Without

This featured guest article by Christian Thurau on game metrics, from essential to advanced, and their value in game development. Christian has a PhD in data mining and machine learning, and he is the CTO of GameAnalytics, one of the latest Unity official Asset Store Service Partners.

Facts about Christian:

Favorite games: Old-school shooters, mostly Quake 1, Team Fortress, and Bioshock

Favorite GA tool: Heatmaps

Favorite metric: Playtime

Analytics has become a much-discussed topic in game development in recent years, not only for F2P but across the entire industry. While it is still creativity, intuition, and experience that matter most in creating successful games, statistics on games and players have become an integral part of game development.

Unfortunately, analytics have become somewhat notorious as tools for monetization, used to influence player behavior to maximize revenue. What is less known is that metrics are just as useful in increasing fun and engagement. Hopefully, with this article, I can shed some light on the true nature of game analytics and break through the shadow of corporate greed that clouds its horizon.

It’s all About Engagement

The first and most important question with any analytics tool is what exactly you should track. While you would need to see into the future to know every metric you’ll ever need, there are some clear must-have measures that will provide a very solid starting point. Generally, these basic metrics can be placed in three broad categories: Acquisition, Monetization, and Engagement.

You may have already figured it out from the introduction, but of these three categories, I believe engagement is the most important, mainly for two reasons:

  • Some engagement metrics sit at the base of player lifetime value calculations, a metric that is used exclusively to ensure user acquisition with a positive return on investment.

  • Engagement relates closely to the game’s “funness.” It is a measure of the degree to which your game fulfils, so to speak, its destiny. There’s no reason to attempt to improve on other metrics if engagement is low.

Of course, the priority of these metrics might change according to individual game needs.

If you have never tackled analytics before, this might be a lot to take in. The good news is that the free GameAnalytics’s SDK for Unity automatically takes care of all the basic tracking needs I mentioned. All you have to do is interpret the results.

For example, we estimate engagement by generating both retention and session metrics.

  • Day 1, day 3, day 7, day 14, day 28 retention: “Day X Retention” refers to the percentage of users who return to the game X days after installing it. This metric can be used to track how new builds or features of your game perform. The more often people return to the game, the more satisfied they are with the experience and the more likely they are to spend. On the other hand, low retention, depending on when it manifests itself, can indicate anything from a weak core loop to low production value or an endgame that offers insufficient content.

  • Daily active users (DAU), monthly active users (MAU), and the DAU/MAU ratio: The number of people who use your game on a given day and in a given month can give you key insights into its popularity, as well as allowing you to plan for growth and server loads.

  • Session length, average session length, and number of sessions per user: Sessions describe when and how long players engage with your game. Average session statistics can paint a clear picture of how your game fits in the player’s lifestyle—whether it’s played in short bursts on the bus or train, for example, or the player really likes to allocate a lot of time to get into the experience. Using session lengths, you can tweak the game experience to match the most popular (and natural) play styles. If you are using in-game advertisements, you can also look at sessions to estimate ad exposure and thus ad revenue.

Money (and Where It Comes From) Matters

Once you achieve solid engagement numbers, monetization and acquisition metrics come into play. GameAnalytics generates a number of fundamental metrics to allow you to estimate your income:

  • Revenue: the amount of currency, converted to USD, collected on a daily basis. You should always display revenues segmented by acquisition campaigns to identify your best-performing acquisition channels. Also, it is recommended that revenue from in-game purchases be distinguished from advertising revenue through custom event hierarchies.

  • Average revenue per daily active user (ARPDAU) and average revenue per paying user (ARPPU): how much users actually spend, both in absolute terms and compared to the total number of users. The bigger the ARPDAU, the better the chances your game will be self-sustaining.

  • Conversion rate: the percentage of users who make an in-game purchase for the first time on a given day. You can use conversion rates to assess the effectiveness of different special offers, for example.

  • Number of paying users and number of transactions: how many users and transactions occur in a given period. Flat numbers can sometimes be misleading; it’s helpful to look at the trend lines for the number of paying users versus the number of transactions in order to determine if you need to adjust the in-game product prices

Acquisition metrics have only recently been introduced into the GameAnalytics tool, so they are a bit on the basic side:

  • Paid vs organic users: comparison of the number of users who came to the game in a natural manner (word of mouth, friend invite, or stumbling upon it in the Game Store) to the number of users acquired via an advertising campaign. This basic metric can point to what is known as the K-factor, or the number of additional users that each user introduces to the game. This is very difficult to calculate without tracking all in-game invites, but the paid vs. organic users metric can at least give you a rough estimate. The K-factor is essential to determine whether your user acquisition campaigns pay off.

  • Number of installs by country, build, acquisition campaign, or other factor: the number of times your game is installed. The installs metric can show what iteration of your game is most popular and where the game performs best. The number of installs also gives you a rough overview of where your game is in its life cycle.

Remember, though, that you can segment all of the other predefined metrics by acquisition campaign parameters, as well. This ultimately allows you to make the best decisions when it comes to user acquisition.

Advancing to the Next Level

The more you get the feel for using analytics as part of game development, the more you’ll find the need to track data that is unique to your game. This is easily done with GameAnalytics, which is centered around the concept of abstract events. An event is simply anything that could happen inside of your game; this can be a rocket that gets fired, an item that is picked up, or a banner that gets clicked. No matter what is important to your game, you can track it using GameAnalytics events.

Note, however, that while the old mantra of “there’s no data like more data” is certainly true, selecting which custom events you should track is crucial. You should always design the desired metrics in advance; otherwise, you’ll risk wasting a lot of time to get your head around what is basically clutter.

As nothing beats solid statistics when it comes to optimizing in-game economies, you could start with tracking specific item purchases. Then, you can easily gather statistics on your best-selling virtual goods, find out what works and what doesn’t, and ultimately get rid of useless items and optimize item pricing.

For even more advanced uses, combine user progression events with the funnel tool to open up a new world of tracking possibilities:

  • New user flow: Having a perfect first-time flow greatly improves the retention of your game. Data on where users drop out is essential for tweaking the learning curve.

  • First purchase: Identifying what item is being purchased first by players can help you understand what motivates players to spend money. This ultimately allows you to maximize conversion rates.

  • Missions and achievements completion: Since achievements and missions are optional in most games, their completion rate is a good indicator of what type of content is most popular among players.

  • Level progression: The players’ progression through the game is a good indicator of how much of the original game content has been consumed, allowing you to time your content updates perfectly.

There are a ton of other useful analyses you can do with the free GameAnalytics tool, and we are continuously working on new, exciting features to help you build better games.

Our Gift to the Unity Community: 3D Heatmaps

Last but not least, I want to mention that there’s one GameAnalytics feature that is exclusively available inside Unity: 3D heatmaps. Heatmaps visually depict the frequency of events, directly over the game-level architecture. Let’s assume that you are already tracking players’ death events. With the 3D heatmap visualization, you can determine exactly where in the game players are dying. You may notice bottlenecks, such as narrow bridges where players tend to bump into each other or where they are simply more exposed. If you also track killer positions, you may also notice exploits, points where players camp out to ambush their enemies. Heatmaps are not only a great tool for fine tuning game balance; they also help in verifying that your game is played as intended.

I’ve barely scratched the surface of heatmaps with this short example, but you can read a lot more about them on the GameAnalytics blog. There are some nice visual examples there, as well. Maybe we’ll be able to delve into the details in a future article.

You can read our blog for many kinds of insights into data analysis in games, from in-depth introductions to the basics to real-world case studies. We invite leading industry experts and researchers to contribute to our blog on a regular basis.

Get the GameAnalytics SDK—it’s all free, with no data limits!

The GameAnalytics SDK for Unity is right here in the Asset Store:


Unity Test Tools Released

Through the past 2 years Unity QA has expanded and built tools, frameworks, and test rigs for internal use, something we have previously blogged about. Through all this work we have done, we have created a lot of value internally in Unity and we want to give our users access to these awesome tools. Today we have released version one of the Unity Test Tools on the Asset Store. Get it here:

Thus we made the decision to make Unity Test Tools available for our users, which we hope will help you attain a high quality in your code while developing your games.

Unit Test

The lowest and most efficient level to do automation is at the unit level. We have decided to use nUnit as the basis for our unit test framework, which is a well known framework for those already writing unit tests.


We have ensured that the integration to the editor is intuitive and simple, with the option of having automatic execution on every recompile, so you have immediate feedback while you write your code. Another important aspect of a test framework is the ability to make a build pipeline where unit tests are executed without a head and the Unity Test Tools give you this option as well.

Integration Test

In order for you to test the integration between components, objects and assets, you need a higher level of tests and for this we have made the Integration Test Framework. Integration tests are also the easiest way of starting to write automation tests on a game in development, since they don’t have requirements on the architecture of the code.


The simplest use of these would be to make a scene, use assets and gameobjects, and set up the conditions you want to verify. The execution is as simple as with the unit tests, where the execution will cycle through the scenes containing tests and execute each test for you. This framework can also be integrated into a build pipeline seamlessly, so you can test all levels of your project from commandline.

Assertion Component

The assertion component is able to monitor the state of gameobjects while in playmode and pause the game if the condition is met. The primary use is debugging, where you can make the game stop in the exact frame the condition is met, thus enabling you to see the entire picture of when it occurs.

To help manage the assertion components, we have added an explorer which is similar to a list of breakpoints in code, so you have an overview of the states and where the components are placed. The component can evaluate complex conditions runtime and thus is more powerful than a normal breakpoint.


In order to enable the build and release pipeline, we have made it possible for you to disable assertion components in release builds, thus making sure you don’t hit them in a released game.


In the package you download you will find a full set of examples and a comprehensive documentation on how each of the tools work.

The Future

Releasing the tools is just the beginning for us. We will be committed to release tutorials and patterns which will help you structure your projects such that they are testable. We will also continue improving on the tools and increase integration into Unity, all with the aim of making it easy for you to start testing your projects.

Happy testing!

Occlusion Culling in Unity 4.3: Best Practices

The following blog post was written by Jasin Bushnaief of Umbra Software to explain the updates to occlusion culling in Unity Pro 4.3.

This is the second post in a three-post series. In the previous post, I discussed how the new occlusion culling system works in Unity 4.3. I went over the basic usage and parameters that you need to know in order to get the best out of occlusion culling. In case you missed it, check it out here.

This post gives you a list of general recommendations and tips that should help you get the best results out of occlusion culling.

Good quality occlusion

It may seem obvious, but of course the first thing to make sure is that your scene actually contains meaningful occlusion. Moreover, the occlusion should preferably consist of good, large occluders if possible, as opposed to fine details that only accumulate as occluders when looking at from a certain angle. Umbra will generally not be able to perform occluder fusion, so even if your lush forest with lots of foliage will occlude something behind it, it will do so only once the individual occluders are “accumulated”. So in this sense, the trees and forests in general will be pretty bad occluders from Umbra’s point of view. On the other hand, a mountain is a good occluder and Umbra will certainly be able to capture it into the occlusion data as expected.


Object flags

There are two main types of objects Umbra cares about: occluders and occludees. The former are just geometry and Umbra treats them basically as a single, solid model. The latter are the ones whose visibility Umbra actually tests using the occlusion data. Occluders consist of pretty much all geometry that have the “Occluder static” flag set, and unsurprisingly, occludees that have the “Occludee static” flag, respectively.

02_object flagsAs a rule of thumb and by default, you can and should set most if not all your renderers as occludees in order for Umbra to cull them. Also by default, most of your static renderers can be occluders as well. Just make sure that if your renderer is non-opaque, it shouldn’t be an occluder either. (Unity will actually issue a warning if this is the case.) This naturally includes transparent objects and such.

But also, if your object contains very small holes (consider e.g. a cheese grater or a bushy plant) that you wish to see through, but reducing the value of smallest hole globally doesn’t make sense (see the previous post as to why), simply removing the occluder flag from the renderer is the correct thing to do.

Furthermore, because occluders are considered solid, correct culling can typically be guaranteed if the camera doesn’t intersect an occluder. This means that if e.g. the collision system cannot prevent the camera from flying inside an occluder, you should probably remove the occluder flag in order to get meaningful results.

Object granularity

Given the fact that Umbra does object-level occlusion culling, it doesn’t make a whole lot of sense to have objects of several kilometers in size. Such massive objects are very hard to cull, as some part of the object is almost always visible, especially combined with Umbra’s conservative culling. So, splitting up e.g. the terrain into multiple patches is typically a good idea, unless you want the entire terrain to always be visible.

In terms of occlusion culling, typically the best object subdivision is a natural one, meaning that naturally distinct objects should probably kept separate in culling as well. So chunking objects too aggressively typically doesn’t help. One should group only objects that are similar in terms of visibility. On the other hand, too fine-grained subdivision may introduce some unnecessary per-object overhead. In reality, this becomes a problem only once there are tens of thousands of occludees in the scene.

Maybe it should be emphasized that only the object subdivision of occludees matters. Occluders are considered to be a single big bowl of polygon soup anyway.

Watertight models

In the previous post, I briefly described how Umbra first voxelizes the occluding geometry, groups these voxels into cells and then connects the cells with portals. In the process, Umbra is always conservative, meaning that in various cases Umbra considers the occluders slightly smaller than what they are in reality, or conversely, the empty areas slightly larger.

This means that if there happens to be an unintentional hole in your occluding geometry, one which rather than getting patched up is retained by voxelization, there’s a good chance it’ll become somewhat magnified in the final output data. This may lead to surprising “leaks” in occlusion. The camera may be looking at a seemingly solid wall, but things behind the wall don’t get occluded because there’s some unnoticeably small crack somewhere.

So, while voxelization does patch a lot of unintentional cracks and gaps in the occluding geometry, it’s still highly important to try to model the geometry as water-tightly as possible. In the next post, I’ll describe the Visibility Lines visualization which may help you debug these kinds of issues.

Finding the right parameter values

Admittedly the hardest part of using Umbra is finding the right parameter values. The default values in Unity do a good job as a starting point, assuming that one Unity unit maps into one meter in your game, and the game’s scale is “human-like” (e.g. not modeled on a molecular level, nor is your typical object a planet or a gigantic killer-mech-robot).

03_occlusion_uiA good rule of thumb is to start with relatively large values and work your way down. In case of smallest hole, for instance, the larger value you can use, the swifter is the bake process. Thus, you should tune it down only if/when you start experiencing culling artifacts, i.e. false negatives. Similarly, starting with a relatively large value for smallest occluder typically makes sense.

Then you can start adjusting it downward and see how Umbra culls better. Stop when culling starts taking up too much time and/or the occlusion data becomes too large.

As for backface threshold, start with 100. If your occlusion data is too large, or if you happen to get weird results when the camera is very, very  close or possibly even intersects an occluder, try using 90 or even a smaller value. More on this in the next post.

To be continued…

In the next and final post, go over some common issues people tend to run into when using Umbra. In the meantime, go check out for more information!