The benefits of a good 2D content workflow

This tutorial takes you through the implementation of a real production workflow. When we talk about workflow it means the steps and processes used all the way from the initial authoring until the content is actually running in the game. Regardless of the number of applications needed in the chain from beginning to end, at a high-level a workflow consists of 3 major steps: authoring, exporting and importing.

For some it may seem odd that we need both an exporter and an importer since tools like Unity are able to import data directly. The reason we need both is because we’re essentially creating our own intermediate file format that acts as the glue between any two applications in your workflow, in this case between Photoshop and Unity. This eliminates the need for an external application to be able to read and parse an application’s native file format, and allows chaining of applications to process the content as it moves from one application to the next.

Authoring

It all starts with great content, and the first workflow we’ll look at is using the industry standard workhorse Photoshop. One of the great things about Photoshop is it’s simplicity to get started. Creating and editing imagery and graphics is painless and easy, and as your needs grow there’s an arsenal of tools and techniques at your disposal. The problem is that image files by themselves don’t have much ability to express useful meta-data for games in the same way that 3D models are able to do. What’s more, 2D is inherently in need of more meta-data given it’s limited nature of just being pixels.

So what we want to do is imbue the image with useful information so that ultimately we know how to use the image in a game. To do that, we can use groups and layers to organize and tag them with what we need.

We also need an example of 2D content that is useful and represents a realistic use. One of the last games I worked on before joining Unity was a simple 2D hidden-object game called Goddess Chronicles, and so we’ll use that as an example. In a hidden-object game the general idea is to find certain items that are hidden in plain sight in a scene such as the example shown below.

Depending upon the game you’re making, the meta-data you need to capture will be different. For this game the design called for 2 basic kinds of imagery: “scenery” and “items”.

The importance of layers

Scenery is the non-interactive content that’s there to provide the bulk of what’s seen, communicate a theme and support the gameplay by providing an environment where items can be hidden. So scenery will be placed into a group named “scenery” and we don’t need to care about the art layers in that group because they’re non-interactive. The items are the things you’ll actually be searching for within the scene and comprise the core gameplay. These are placed in groups that are named “item” and, unlike scenery, the art layers are important and each item can have up to 4 unique layers associated with them.

“Whole” layers are required for all items. Usually once an item is found there will be some effect such as zooming the item up, or placing it into the player’s inventory, and we need the whole image so that it looks right.

“Obscured” layers are used when you want to create the illusion that an item is behind something when in fact it’s floating in front of it. By erasing the pixels that should be hidden it tricks the eye into thinking that it’s actually behind something. In theory we could use whole images for everything, but there are many situations when it’s tedious for the artist to draw everything as separate pieces in order to hide an item, plus using the minimal amount of images in the game will increase the runtime performance.

“Shadow” layers are used to help visually place the items into the scene and look like they belong there. Shadows are kept separately from the whole or obscured image so that if the whole image is zoomed up or moved it doesn’t have an odd looking shadow following it, and instead we can just hide the shadow in the scene once the item is found.

“Hotspot” layers are used to increase or decrease the area which the item can be interacted with. For example if you hide a golf club in a scene it could be very difficult to click or tap on. By using a hotspot you could make the interaction area bigger and easier to use.

So putting all this together we can use groups to designate whether something in our scene is scenery or an item, and we can use the art layers for items to hold the whole image for the item and optionally include obscured, shadow and hotspot images. The image below shows a set of layers for some scenery and an item. The item group is labelled “item:Beads” and contains 2 art layers called “whole” and “hotspot”. The scenery group is labelled “scenery:Column” and it contains any number of art layers that can be named anything since scenery layers aren’t special and we don’t need to keep track of them.

The end result is that we have a well composed scene where the group and layer names are encoded with what we need to give them meaning in our game. You can download the package at the end of the post and have a look for yourself. The next step is to now get all this exported.

Exporting

Once we have some content, we need some way to get it all out for the next application in our workflow, which in this case is Unity. What we want to export are the images used to construct the scene along with the meta-data describing the position, order and other information. In order to do that we need a way to interact with the application at a low level with something that understands how to do that. Fortunately for us, Photoshop is scriptable using javascript and this will do exactly what we need.

In fact quite a few Adobe apps are scriptable including Fireworks, Illustrator, Flash and others. We can use this capability to write our own exporter that can prepare the images for use in Unity and also capture the meta-data we need to make them meaningful. Adobe provides useful documentation and a script editor and debugger called ExtendScript for free.

If you have the Creative Suite, it’s probably already installed on your system. On Mac it can be found in the Utilities/Adobe Utilities – CS6/ExtendScript Toolkit CS6 folder for the latest Creative Suite. On Windows, you should be able to find it at C:\Documents and Settings\\Application Data\ Adobe\ExtendScript Toolkit\3.8.

Pretty much anything you can do in Photoshop can be scripted, and if there isn’t an API for a particular thing you want to do, you can record actions and convert them to command codes that you can paste into your scripts (alpha channel operations, I’m looking at you!).

For our purposes, we need a simple script that basically:

• Checks to see if we have an open document,
• Makes sure the document has layers to export,
• Prompts the user as to where the exported files should be placed,
• Loops through the layers from back to front, trimming away the empty space, saving the image to disk and capturing the position and filename in an XML formatted string,
• And finally saving out the XML data to a file.

The final exporter script is in the tutorial package. To use the script you place it in the Presets/Scripts sub-directory inside your Photoshop application directory. The script contains comments that explain what it does so I won’t go through all of it, but I will cover some of the more important parts.

Firstly, the scripts are written in javascript which makes it easy to learn and use. The javascript engine used by Adobe isn’t very fast, but it works and is debuggable with the ExtendScript editor which makes it very useful.

Since the meta-data is actually the part that gives meaning to the data, we need to spend the most time figuring out exactly what meta-data we need and how it should be formatted. I use XML as the way to specify the meta-data since that makes it really easy to parse later on in Unity. Based on the game design we know we have certain data that will be needed in the game. An extract of that data looks like this:

<?xml version="1.0" encoding="utf-8"?>
<HogScene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <layers>
                <Layer>
                        <type>Scenery</type>
                        <name>Scenery 01-4 background</name>
                        <images>
                                <Image>
                                        <type>Whole</type>
                                        <name>Scenery Tree.png</name>
                                        <x>25</x>
                                        <y>63</y>
                                </Image>
                        </images>
                </Layer>
                ...
        </layers>
</HogScene>

So our exporter script will capture these simple XML elements during export and when it’s all completed write that out to a file.

In our exporter script, we start off with creating some file scope variables that we need for convenience and then call the “main” function which is defined right after that. The basic way this works is that when you run your script it’s evaluated and executed from top to bottom. You find examples on the internet where some code is contained in functions and some is not, and I find this a bit confusing. So I put everything into functions and call the entry point explicitly as a matter of convention.

Inside the main function, there’s a couple of interesting parts. The first one is the line:

duppedPsd = app.activeDocument.duplicate();

Duplicating the active document is highly recommended for two reasons. The first is that in Photoshop if you touch anything in a document, even expanding or collapsing a group, it causes the document to be marked as dirty. So if we didn’t duplicate the active document, the process of exporting would always cause it to be marked as dirty. When the artist quits Photoshop or closes the document they will be prompted to save, and they may not remember if they made changes to the document or not and will likely just save it. This will cause the timestamp of the file to be newer than the exported files, and once checked into version control will be confusing because a designer, producer or programmer won’t know if they need to re-export the file or not. This creates an endless cycle because the file will always be newer than the export. By making a duplicate it will leave the original document in it’s original state, which still may cause a problem, but that’s then a production process problem and not something we’re causing.

The second reason for duplicating the document is simply that things will go wrong while creating your own exporters, and when things go wrong it will leave your document in an unknown state. So by duplicating it we always have our untouched master copy to work with.

The next thing of interest in the main function is:

removeAllTopLevelArtLayers(duppedPsd);

Since we’re using groups as the containers for the things we’re interested in, we can let the artists or designers add art layers that aren’t in any group (“top level”). They can use this for concept or photo references, screen layout guides, or placing placeholder elements like a game HUD. So we clean up the duplicated file by removing these images before processing.

Other than that, the main function calls the export function, then creates and writes the XML file containing our meta-data.

The export function exportLayerSets is a recursive function. A recursive function means it calls itself if needed to “drill down” into our groups to find the lowest level group that is deepest in the scene.

function exportLayerSets(obj)
{
        for(var i = obj.layerSets.length-1; 0 < = i; i--)
        {
                exportLayerSets(obj.layerSets[i]);
        }
        ...
}

It does this by simply looping backwards through the list of groups, and if one of the groups has a group inside it, then it recurses and calls itself again with that group and so on. We loop backwards because in Photoshop the bottom-most layer in the list is the first one and groups and layers higher in the list are drawn on top of lower ones. So we process everything back to front.

Once we have an actual art layer, we then look at the group name and see if it starts with “item:”, “custom:” (which we used for HUD elements) or else it’s assumed to be scenery.

if(obj.name.search("item:") >= 0)
{
        ...
}
else if(obj.name.search("custom:") >= 0)
{
        ...
}
else // must be a scenery group
{
        ...
}

For items, we then loop through the art layers, switch on the layer and export whichever of the known types we support.

// process layers
for(var layerIndex = 0; layerIndex < obj.artLayers.length; layerIndex++)
{
        sceneData += "<Image>";
        obj.artLayers[layerIndex].visible = true;
        switch(obj.artLayers[layerIndex].name)
        {
                case "hotspot":
                        saveScenePng(...);
                break;
                case "obscured":
                        saveScenePng(...);
                break;
                case "shadow":
                        saveScenePng(...);
                break;
                case "whole":
                        saveScenePng(...);
                break;
        }
        obj.artLayers[layerIndex].visible = false;
        sceneData += "</Image>";
}

When we find something we want to save, we call the function to save the image as a PNG file. This function collapses the image and trims the left and top in order to determine the X and Y coordinates of the image. Then we trim off the right and bottom and save it out, and capture the meta-data into the XML string.

function saveScenePng(psd, imageType, fileName)
{
        // we should now have a single art layer if all went well
        psd.mergeVisibleLayers();
        // figure out where the top-left corner is so it can be exported
        // into the scene file for placement in game
        // capture current size
        var height = psd.height.value;
        var width = psd.width.value;
        var top = psd.height.value;
        var left = psd.width.value;
        // trim off the top and left
        psd.trim(TrimType.TRANSPARENT, true, true, false, false);
        // the difference between original and trimmed is the amount of offset
        top -= psd.height.value;
        left -= psd.width.value;
        // trim the right and bottom
        psd.trim(TrimType.TRANSPARENT);
        // find center
        top += (psd.height.value / 2)
        left += (psd.width.value / 2)
        // unity needs center of image, not top left
        top = -(top - (height/2));
        left -= (width/2);
        // save the image
        var pngFile = new File(destinationFolder + "/" + fileName + ".png");
        var pngSaveOptions = new PNGSaveOptions();
        psd.saveAs(pngFile, pngSaveOptions, true, Extension.LOWERCASE);
        psd.close(SaveOptions.DONOTSAVECHANGES);

        // save the scene data
        sceneData += ("<type>" + imageType + "</type>
                                <name>" + fileName + ".png</name>
                                <x>" + left + "</x><y>" + top + "</y>");
}

When we run the exporter on the file, we should end up with a directly of cropped PNG files plus an XML file with the same base filename as the original document such as that shown below.

Now that we successfully exported all our images and meta-data, we move to the next application in our workflow which is Unity and get the files imported. I’ll cover this in my next blog post. Thanks!

You can download a Unity package with all the files for this tutorial.

Unity Technologies was one of the sponsors, Ilya Turshatov and I gave a short presentation and were present there as mentors for those loooong 30 non-stop coding hours.

The format of the event:

• Teams up to 5 people
• 30 hours to develop your game (you are allowed to use frameworks and engines)
• 5 minutes to present your game
• The jury chooses the winners according the following criteria: game play, technologies used and innovations

Some statistics:

• 61 participant
• 20 teams at the beginning and 18 teams that actually made it to the end.  5 teams used Unity. There was one game on Flash, some even used HTML tables and jQuery.
• 264 cans of RebBull drunk
• 70 pizzas eaten
• 18 table football matches played
• 6 movies watched

Winners and some more…

The most pleasant part was that the 1st and the 3rd places were taken by the games made with Unity!  And the overall impression was that games made with Unity looked more finished, stable and with no obvious bugs during the presentation.Now a bit about the projects themselves. I will mention only some of them, which we found the most interesting, though I must admit that all projects were quite compelling.

“Tomato Wars”

by Patriotic Games won the 1st place by the jury’s decision, as well received 2 Mobile license (which they needed) from us. The game play was “bloody”. You are a tomato and you have a rifle and you make tomato juice from all other tomatoes that attack you in packs. The choice of the guns is available, all the objects are breakable. Oh, oh… and you have bombs *evil laugh*.

“Titanium”

by Empty. by Empty. Shake, rotate, turn – do whatever you want to get those damn’ rings on the Titanic’s funnel. Quite addictive, the girls from the HR department were constantly asking for updates every now and then during the Hackathon. They got the 3rd prize and also received Unity licenses.

“Divine Path”

by Creators.   A student and two schoolchildren created the whole new world (Asset Store rocks!).  It was not something extra impressive, but for 3 guys with no actual experience it looked not bad, and in some cases it looked more compelling than the projects made by professional developers. The main concept of the game was the lost world with no people left where your main goal was to find the evil god. You wouldn’t find any tasks or hints in this game (as according to Creators it’s too boring just to carry out the missions), as well as you cannot exit the game so easily J Before leaving you need to find the “save point”, e.g. the doors in the house. They received 1 Unity license as an encouragement not to quit the attempts, and to go on with their experiments.

And here are some photos from the event.

Designing content for multiple platforms becomes far easier if you think a few things through before you start. If you get your processes right, it’s easy to use Unity to build high wow-factor games across a range of devices.

Ten top multi-platform tips

1. Does this make financial sense? It sounds obvious but, before starting your project it’s as well to think carefully about the financial benefits of deploying your game to multiple platforms. On the one hand, making a successful game available on just one platform ignores easily acquired additional revenue. On the other, the costs involved in porting your game go beyond simply acquiring an additional add on license and clicking publish.

2. What about my demographic? Different platforms have their various strengths and weaknesses and are more or less widely used in varying contexts. Consider whether the type of interaction and game play your game is based around is suited to deployment to the platforms you’re targeting.

3. Start with your two most widely divergent platforms. If you plan on developing a game for three or more platforms, it makes sense to start by weighing up what you need to do to get your content to outlying platforms. By considering this first you will automatically cover much of the ground involved in developing content for your remaining platforms.

4. Beware obsolescence. Mobile platforms change at bewildering speed and supporting legacy versions of a platform that are becoming more obsolete by the day may, ultimately, just add to your costs.

5. Abstract out platform-dependent plugins. If, for example, you plan to build leaderboards and achievements for Apple’s Game Center be sure to build a leaderboard manager which abstracts the leaderboard calls and then makes the Game Center calls. That way it’s easy to add, for example, SteamWorks leaderboard support later on.

6. Ensure resolution independence. Plan how your HUD, UI, on-screen controls and buttons will be depicted at various aspect ratios. Design the UI layout in a modular way so you can space out elements without a re-design. Remember that, in Unity, you can specify resolutions in percentages.

7. Build high res source art. Let Unity do the downsizing for you. This prevents late-stage art reworking for e.g. iPhone Retina displays. Plus, when you need poster-sized promotional art, you won’t want to cry.

8. Think optimisation into mobile games from the start. Use light probes to store lighting information and bake this information into dynamic objects, work with simple specialized shaders and detailed, high-contrast textures, use object pooling techniques and profile early and often.

9. Consider investing in additional tools. Owlchemy Labs’ Multiplatform toolkit is available from the Asset Store. Amongst other things this end to end solution can ease scaling, strip redundant assets from your platform-specific build and help you manage and apply global asset compressions.

10. Frequent use of compiler directives. Unity supports platform specific compilation so you can partition your scripts to compile and execute a section of code exclusively for a specific platform.

Just over a year ago I joined Unity as a Trainer and Consultant. In this role, I’ve been travelling to customers around the world helping them learn how to get the best from our technology. I’ve visited games companies, universities, research centres and simulation customers, and the locations have spanned the globe, from Texas to Saudi Arabia, to Singapore. (TL;DR Videos Below!)

During this time, I’ve also been helping to build up the range of training material that we can offer to customers. A lot of this material has grown organically, some based on customer requests for training in specific areas, and some based on creative ideas that tie together Unity’s features into learning projects.

The style and focus of the training courses vary widely. I’ve visited customers who needed a crash-course for their junior developers, or training for experienced developers moving to Unity from a different environment. I’ve also visited teams of experienced Unity developers in the middle of projects who wanted a quick boost of technical knowledge to help get their project to the finish line.

In my beginner crash-course, I take trainees on a tour through Unity’s main features, bringing everything we learn together into a finished game – which usually involves plenty of flying saucers, explosions and sound effects. This seemingly simple project covers many of Unity’s core features such as the art and asset pipeline, physics, components, scripting, prefabs, particle systems, audio, and helps get developers who are new to Unity familiar with the editor.

A common request from games and simulation customers alike is training for our new animation system, and its integration with physics and pathfinding. For this, I run through the entire system from scratch, creating a third-person controller and NPC characters with many of the common games actions such as mouselook, strafing, sprinting and crouch walking. We learn how to import, edit and retarget animations, through to building up state machines and integration with input. We examine how to get the pathfinding system to properly control root-motion animated characters, and how to make sure our characters can interact with physics objects properly. This whole section takes about two days to complete, and serves as a solid foundation of knowledge for building character-based games in Unity.

Simulation customers often want to build applications for training purposes themselves, and the individual requirements in the Sim field vary so much that there’s no one-size-fits-all training program. Their goals can range from small mobile applications showing how to maintain a piece of equipment, to virtual reality workplace safety training, to ocean-going container ship simulation, and the training I put together for each customer attempts to meet these needs, giving them the understanding they require to make the best use of our tools.

One project I use for Sim customers begins with a model of a stapler. I show the trainees how to start with the bare 3D assets, and build up an interactive training application which allows an end user to progress through the maintenance steps. Obviously the point here is not to teach how to use a stapler! – what the trainees learn are the skills required to build whatever kind of equipment-based training applications they need.

The videos below show a broader cross-section of the content of training we’ve delivered so far to customers.

If you want to learn more about Unity and want training, contact your account manager to find out more.

Unity Training – Basic

Unity Training – Games Focus

Unity Training – Sim Focus

Start spreading the word as soon as you press Go, and target the audiences you know will want to play your game.

“We targeted sites and blogs where there is a high concentration of people interested in RPGs, like RPG Codex”, says Jonas. “We knew our target audience and we found them and talked to them. Even though the audience for some of the RPG sites we targeted is smaller than that of general news sites, the quality of the exposure we got was much more valuable”.

Jake and Tamas spread the word through their Chicago-based community of developers. “It’s a great community here of independent developers that really helped us out”, says Jake. “I also emailed my contacts at blogs like rock paper shotgun and indiegames.com. Within a week of launching we met our funding goal and over the next three weeks we earned an extra 15-20% on top”.

Klaus says they benefitted from enthusiastic backers who have their own networks who promoted their project. “You can actually follow people on Kickstarter and get a notification when they back a project. So they end up acting as a kind of ambassador for your game”.

About the money: Set a realistic and modest funding goal, offer nice rewards not just for the highest tiers, but the most popular ones, and be prepared to learn as you go along!

Jake says that when it came to their funding goal, “we decided to be really specific about where all the money was going. Kickstarter is still a really valid option for just starting out and setting realistic and precise goals, such as ‘I need $200 to pay an artist or $300 to pay the band’”.

Michael and Aaron set their funding goal for the minimum amount they needed to complete Blindside and anything above that would go towards extra production value. “You should also expect to lose about 10% of what you raise to fees for payment services, to Kickstarter itself, and to people whose credit cards don’t work”, says Aaron. “And make sure your tax structure is correct! You don’t want to end up raising a lot of money and then losing a big chunk of it to poor or incorrect tax reporting”.

By reading up on other Kickstarter campaigns, the team at Logic Artists learned that the most popular tiers are 15 or 30$. “So, you want to get people to pick $30”, says Jonas. “We offered beta access for $30. But it’s is hard to figure out what rewards should go with what tiers, especially the high-level tiers. What kind of reward do you offer for $10,000?”

Jake and Tamas also provided physical rewards, such as posters and CDs. “We did a really bad job of budgeting the time it would take to make the items and forgot to include shipping costs, so it cut into the money, but we made up for the loss with some of the extra funding we got”.

“Tiers are a huge thing to nail the campaign”, says Klaus from the Back to Bed team. “We figured out early on that we’d have to make new tiers with physical rewards. People reach a limit where they don’t want to pay for digital items, they want t-shirts. One reward we offered was a framed piece of artwork, and that was quite successful”.

And beyond the money: Whatever happens, take the long-term view that you are building up a new community of people interested in your work

“Now we have this community for our game! We’ve even had to hire a community manager”, says Ali from Logic Artists.

“We’re all invested in the game now”, says Jonas. “We use our Kickstarter community as testers and get a lot of valuable feedback. We even gave them access to our bug trackers”.

“It’s been really nerve wracking. We bet our reputation on it and it was so much work. But Kickstarter has been a way for us to show our skills and make a name for ourselves as a brand new studio about to release their first commercial product”, says Jonas.

“In game design you always want people to test and iterate and tell you how to make it better”, says Michael. We didn’t have a budget for testers. We didn’t have an office. So it was fantastic to have this huge community invested in BlindSide. It was the easiest play-testing experience I’ve had and we got tons of feedback. It was remarkable and really helpful”.

Jake and Tamas had about 30 people sign up as beta testers and “the feedback was extremely helpful”, says Jake. “We also sent out a monthly newsletter to our approximately 200 supporters, showing them some secret stuff and prototypes”, he says.“These were the folks connected to the game since its inception, so they talked about it and spread the word when it was released”.

As Jake sees it, supporters who act as evangelists for your work are as valuable as the money itself. He talks about a friend of his whose Kickstarter campaign failed to reach its funding goal, but who walked away with a huge community.

“We were hearing about Kickstarter exhaustion already when we launched our campaign”, says Jake. “I know the landscape has changed, but I think the platform is still there for folks doing small, realistically established projects. We were totally ecstatic. To us it was great that you could be a creator and decide for yourself what it means to be successful. And the support we got early on has been amazing for us and super helpful”.

We just released 4.2 beta 2 this week and I will give you an honest status on the quality and bug situation in Unity.

Current situation

Our rapid iteration for 4.2 took a hit because a lot of our developers attended GDC 2013 and we had some issues with an update of our build software.

As of writing this, we have 40 bugs to fix before we will be able to call it a release candidate, but we will naturally get some bugs during the beta phase we need to fix, so a reasonable call is 60 bugs left. How long it takes to get them done is a different matter on which I shall not speculate here.

Burnup

It is good fun to take a look at how much we put into the release. From a QA perspective, this is one of the biggest bug fixing releases we have had.

We will hit 500 bugs fixed before 4.2 goes to final release. This includes 100 regressions from this or previous releases we have put in, so this release does bring  an improvement in quality as well as features.

42% of all the bugs fixed have been found and reported by a customer, which we are deeply grateful for.

4.2 Customer bugs

Since 4.2 has been in alpha for quite a while, we have already had a good number of incidents (bug reports users submit, which we convert to bugs if we can reproduce them).

196 have been reported, 14 are still not processed and 119 have been reproduced and converted to bugs. Out of those 119, 30 have been fixed, so bugs which are not of a high priority are getting postponed in order for us to have as little code churn as possible. It should be some comfort that we are releasing faster if your bug has not been fixed this time around.

Bug Clusters

From a QA perspective it is always very interesting to see where the bugs are clustering, because clusters unfortunately indicate more issues to be found. The report I made for this highlights overall bug clusters and clusters specifically from user submissions, so we can see if there are patterns of bugs where QA is not doing well enough.

In this graph I see no immediate warnings, which is a sign that we haven’t introduced any big and buggy areas; at least not areas where users have reported many bugs to us yet.

Looking at the entire codebase, we have the following picture:

The numbers show priorities 1-7, where 1 and 2 are the ones slated for fixing in 4.2. Assets management lights up, but it is also a very big area. In total we have just over  2000 active bugs, which is not scary in a codebase the size of Unity’s, but we need to be vigilant about keeping this number down.

So that’s the current situation with our codebase. With all the work being done to solve the highest priority bugs I hope you will find 4.2 to be yet another improvement in our effort to give you the best and most productive tool for producing your game.

We are planning to change this upon Unity 4.2′s release: the stable release channel will be updated to 4.2. This means that any released 3.x and 4.x Unity Web Player content will be played back with the 4.2 runtime. If you have any web player content out there, you will need to make sure it runs well in 4.2.

If you have any live Web Player content authored with Unity 3.x or 4.x, please test it against the current 4.2 beta runtimes – and please tell us if you run into any problems.

We try hard to ensure that no regressions exist in new runtime versions, and we have a lot of test coverage – but, when we miss something, we’d prefer that you find it, and that we correct it, before we ship!

To test your content against the 4.2 runtime:

1. Go to http://unity3d.com/webplayer/setup/
2. While holding the alt/option key, right-click on the Unity Web Player Content. (In older versions of the Web Player Plugin, the release channel menu would appear when right-clicking without holding down the alt/option key. This will change in 4.2.)
3. From the popup menu which appears, select Release Channel -> Beta.

When you have changed the release channel in the Web Player to the Beta channel, all 3.x and 4.x content will be played back with the current beta release. Currently, that is Unity 4.2b2.

If you do find issues with your live Web Player content, please file a bug, and make sure to mention it’s a web player regression in the bug report. It is also a good idea to subscribe to our new web player update announcement mailing list, where you can discuss web player regressions and where we will announce future updates.

 In the past, we have received questions about which runtime will be used for each channel. To clarify the Web Player channel feature, here’s exactly how it works:

The Unity Web Player will always use the available release channel with the oldest runtime version which meets two criteria:

• The runtime version is not older then the Unity version the content was built with.
• The runtime version is not older then the channel selected in the Release Channel popup menu

By default, the Unity Web Player uses the Stable channel.

For example, assume the Stable channel is at 3.5.7, Release is at 4.1, and Beta is at 4.2. If the channel selected in the Release Channel popup menu is Stable, then:

• 3.2 content would play with the Stable channel (3.5.7)
• 3.5 content would play with the Stable channel (3.5.7)
• 4.1 content would play with the Release channel (4.1)
• 4.2 content would play with the Beta channel (4.2)

If the same setup is used, but the channel selected in the Release Channel popup menu is Release, then:

• 3.2 content would play with the Release channel (4.1)
• 3.5 content would play with the Release channel (4.1)
• 4.1 content would play with the Release channel (4.1)
• 4.2 content would play with the Beta channel (4.2)

It’s that time of year again! With Unite 2013 fast approaching in Vancouver, it’s time to start thinking about the 2013 Unity Awards as well. The ceremony will take place at the Vancouver Convention Centre this year on August 29. If you’re interested in nominating a project (game or otherwise) for the Unity Awards, please read the submission guidelines and then follow instructions to complete the submission process. Thanks and look forward to seeing you at the show!

The Unity Awards: What are they?

Each year, we hold awards for our global developer community in several different categories in order to recognize the most impressive games and other projects being made using Unity. The categories this year include:

• Best 3D Visual Experience – Submissions for this category will be judged based on artistic merit including thematic and stylistic cohesion, creativity, and/or technical skill.
• Best 2D Visual Experience – Submissions for this category will be judged based on artistic merit including thematic and stylistic cohesion, creativity, and/or technical skill.
• Best Gameplay – Intuitive control, innovation, creativity, complexity, and fun are what make games enjoyable and entertaining–we’re looking for games that excel in one or all of these areas.
• Best VizSim Project – Unity projects come in all shapes and sizes; this year we’re looking for projects that have some real world grounded applications for visualization and simulation.
• Best Non-game Project – Unity-authored products that fall outside of games including projects such as art, advertisement, interactive books and comics, digital toys, interactive physical installations, and informational programs will want to submit for this award.
• Best Student Project – This award is for projects worked on by students currently being completed as part of the curriculum of an educational institution. Projects will be judged based on creativity, technical merit, and overall artistic cohesion among graphics, sound, and presentation.
• Technical Achievement – Any project that provides an excellent example of technical excellence in Unity including but not limited to graphics, scripting, UI, and/or sound.
• Community Choice – This category will be voted on at a later date on Unity3d.com by the community of game developers.
• Golden Cube (best overall) – This award is for the best overall project made with Unity in the last year. Everything from technical achievement and visual styling to sound production and level of fun will be taken into account to choose an overall winner.

Qualifications

Pretty much anyone making games with Unity can submit their projects for consideration in the Unity Awards. There are some simple rules for eligibility that all entrants will need to follow.

• Only Unity-authored projects are eligible for nomination
• Projects must have been released from July 1, 2012 to June 30, 2013 to be eligible with the exception of student project submissions which must have been part of the coursework in the 2012-2013 school year.
• Any projects nominated for previous years of the Unity Awards are ineligible for the 2013 Unity Awards with the exception of projects that were previously student work and have since turned into finished commercial projects.

One thing to note about these rules is that it’s OK to submit a game for consideration even if you aren’t totally sure if it will be ready by the June 30th cut-off. We will be checking to make sure any games being considered for a finalist slot meet all of the criteria first.

What Happens After Submitting a Project for Awards Consideration?

The Awards committee at Unity Technologies will look at each submission using the judging criteria for each category. Six nominees from each category are chosen as finalists and are invited to participate in the Unity Awards ceremony taking place at Unite in Vancouver.

How are Unity Awards Winners Chosen?

Once the finalists have been chosen, all of Unity Technologies employees will be invited to cast their votes on what they consider the best of each category. This is true with the exception of the Community Choice Award, which is chosen by our developer community via a poll on Unity3d.com, which will be posted in July.

Where Do We Submit Projects for Awards Consideration?

Nomination submissions are now open. They will close on June 30 at 12:00am PDT. Simply follow directions and fill out the form located at the following the link:  http://unityawards2013.unityproposals.com/

Make sure to spread the word to those you know that have released projects between July 1, 2012 and June 30, 2013!

We talked to four indie teams who got their games funded with Kickstarter. The teams and their games are very different from one another, but it turned out there were strong commonalities in their approach to Kickstarter. We hope their tips will be helpful and their experience encouraging to any of you thinking about launching your own Kickstarter projects. Read on to hear from the customers themselves!

Don’t start with Kickstarter. Make a game first. Make lots of games, or a demo or trailer, and share your work as much as you can.

The customers we talked to all had solid games development experience behind them by the time they launched their Kickstarter projects. Some had even released their games. They had communities and networks of people interested in their work. They carefully thought through and prototyped their ideas long before launching on Kickstarter so that they had high-quality content ready to show potential backers and press.

Chicago-based Jake Elliott and Tamas Kemenczy are co-founders of Cardboard Computer. They launched a Kickstarter project for their game Kentucky Route Zero in January of 2011. Jake had been developing games for years, and one of his projects, “A House in California” was a finalist for the Nuovo Award in the 2011 Independent Games Festival (IGF).

“It helped me a lot that I had been publishing games for a while. It’s been really important for me to work on small projects and to publish my stuff as much as I can”, he says.It took Jake and Tamas five months to create the Kentucky Route Zero trailer for their Kickstarter project. “We wanted something very concrete. We made a concept trailer, it was a ton of work, but very useful, because we nailed down the aesthetic”.

The game Back to Bed had already been released in 2012 by the Danish National Academy of Digital, Interactive Entertainment (DADIU). Then, in February of this year, two new studios founded by some of the former students who worked on the first Back to Bed game launched a Kickstarter project.

“Our game was so far along in the process so we weren’t looking to integrate all new features”, says Back to Bed project manager Klaus Pedersen. “We went to Kickstarter to cover the final stretch of production for a new version. The core gameplay was already done. We needed the funding mainly for the Unity Pro licenses so we could polish, tweak and release on multiple platforms”.

Copenhagen-based Logic Artists successfully funded their RPG Expeditions: Conquistador in September of this year. They also created a high-quality demo but released it late into their Kickstarter project. Although the timing of the demo wasn’t perfect, once it went live it gave their project a critical advantage.

“It was really important for us to show people what we could do”, says producer Ali Emek. His colleague game designer Jonas Waever says “For us it showed how important it is to finish a demo and release it. It can be small, but make it polished, put it up for download and say to backers that you need money to finish this game”.

Find the unique hook in your game that will attract potential backers.

As Klaus from the Back to Bed team says, “I think backers are savvier – they want to see quality and have a playable prototype. They want to back things out of the ordinary, daring and creatively risky projects”.

Jake and Tamas made it clear to backers that music would play a key role in their game, with a sizable chunk of their funding going to pay the band upfront. The original bluegrass-inspired soundtrack and multilayered “magic-realist” look and narrative helped make Kentucky Route Zero a critics’ darling shortly after its release late last year.

Aaron Rasmussen and Michael T. Astolfi are the U.S.-based team behind the game BlindSide. They got funded in December of 2011, and released their game in May 2012. BlindSide is based on Aaron’s experience of being temporarily blinded following a high school chemistry accident. On their Kickstarter page they describe their game as a “survival/horror adventure game with no graphics at all. Navigate a 3D world using only your ears and what’s between them.”

“We prototyped our idea really quickly and tested out core game play within 24 hours”, says Michael. Aaron adds, “At the minimum we had to say ‘yes, this game is going to be fun and it’s something we want to pursue’”.

“Supporters found Aaron’s story fascinating and we used that to create an interesting and unique game experience”, continues Michael. “Our idea of audio-based virtual reality with a mobile device presented them with a whole new experience they hadn’t had before”.

Polished content increases your chances of attention from industry bloggers, news sites and organizations—attention you can leverage in your Kickstarter campaign.

The first version of Back to Bed got a lot of critical praise, including nominations at both Nordic Indie Game Night 2012 and Unity Awards 2012. The game also won in the Student Showcase at IGF 2013. All of this recognition gave the Kickstarter drive a huge advantage. They could share the accolades with their backers and get extra coverage for their Kickstarter project on sites such as Polygon and Gamasutra.

Jonas at Logic Artists says that shortly after releasing their demo, they featured a video of people playing it at their booth at the Gamescom expo.

“It was a fully playable demo with a fair bit of polish”, he says. “It was the biggest boost for us when we could show the Gamescom video, because at the time nobody knew who we were”.

Catch Part II next Friday: spreading the word, budgeting, and using Kickstarter to find the people that will care about your work

Let’s start with some numbers—big numbers. It’s forecasted that in 2013 the market will increase by 470%, from 231.8M USD in 2012 to 1090.9M USD in 2013.

Fueling this growth in a massive way is Kakao Talk, a mobile messaging service that last year expanded its platform to include social games.

Now, currently in South Korea, 90% of mobile devices are running on the Android OS. And 97% of mobile users have Kakao on their phone.  What Kakao does is it provides a social graph API for the games it hosts, so that players can communicate with friends in their Kakao network: pass on rewards, invites, and points, and compete against them and compare scores. Currently if you log onto Google Play Korea, almost all the top rated/selling apps are ones designed to integrate with Kakao’s ubiquitous platform. In terms of revenue ranking by country, South Korea holds the number 2 spot on Google Play, after Japan and before the U.S.

So where’s Unity in all this mobile social gaming frenzy? Well, pretty much everywhere!

Kakao has released 120 games to date and up to 40% of those are made with Unity! The top 5 games on Google Play are made with Unity and it’s been estimated by some Korean press that the No. 1 game is making up to 1M USD per day. So there is a lot of potential financial success to be won by our customers.

Based on customer interviews we have conducted we know that our user base is wide but all of them are experiencing a new level of freedom and fun by creating with Unity. We have server developers who enjoy the smooth experience of client-side programming with Unity; MMORPG Client developers who love the speed and efficiency it offers for mobile development, and artists who learned programming and games development by using Unity. The common reasons they chose Unity include multi-platform support, followed by ease of use and a fast development cycle.

A universal story

We just wrapped up our first Unite Korea regional conference (which grew out of the “bootcamp” we held last year) and there is much excitement and positive feeling for Unity from the Korean development Community. The Unity “story” is universal. Just like in so many other regions, we have passionate developers in Korea who want to break into the huge mobile market.  And when they are introduced to Unity and start playing around with it, they are struck by its incredible ease of use, by the speed with which they can create their content, and by the possibilities that suddenly open up for them. That’s powerful!

Unity has grown incredibly over the years, as a platform and as a company. We’ve lived through several huge shifts in the industry, having seen (and participated in) the growth of mobile and the complete and incredible vitalization of indie game development. And with a teeny bit of pride I think it’s fair to say that Unity played a part in this. It’s also awesome to note that there are a LOT of independent developers in Europe— specifically the Nordic region—that are breaking new ground in both creative freedom and financial success.

Unite Nordic is all about this new energy in games development. Both my keynote and several of the amazing speakers will speak to this and how Unity, and game developers in general, look ahead on a bright future indeed.

The conference is one of discovery and learning that will be useful to anyone diving deep into Unity or honing their craft. And I’m humbled that we’ll be visited by an insane lineup of rockstar guest speakers. Check out some of them below and see the full schedule for the entire list of talks, including deep looks at Unity being given by our own Unity staffers.

Rock Pocket Games – Skjalg Sturlasson Mæhr – The studio behind Oliver and Spike will talk about how it is important not to lock yourself in a room when you try to create a game. They built a Unity User Group in Norway and know the benefits of having an invested developer community that is “in the know” while working on your own game.

Might & Delight – Johannes Wadin, Peter Stråhle and Anders Westin – Created by the developers behind Bionic Commando Rearmed, Pid is Might & Delight’s take on retro platform adventure gaming. It’s also one of the first Unity-powered cross platform PS3/PC/XBLA games. Pid’s makers will spell out their game development philosophy.

Rovio – Jaakko Haapasalo and Mauricio Hollando – The creators of Angry Birds will share the story behind Bad Piggies. The talk will take a close look at how Unity enables rapid iteration to discover interesting emergent gameplay where freedom and constraint are balanced.

Full Control – Thomas Lund – A old timer of the Unity Community and Studio CEO, producer and game developer, Full Control recently secured the IP to legendary Games Workshop board game Space Hulk. The talk will discuss how the small team has set about converting a beloved and iconic board game into a computer game.

Red Thread Games – Ragnar Tornquist – In the space of six months, Dreamfall Chapters—the sequel to The Longest Journey (1999) and Dreamfall: The Longest Journey (2006)—evolved from a crazy idea to a successful Kickstarter to an actual game, all with the help of Unity. Ragnar Tornquist will tell the story of how it happened.

BetaDwarf – Beta Dwarf will talk about their entrepreneurial venture and their Kickstarter success with Forced, a brand new gladiator combat-game, based on tactical cooperative 2-4 player gameplay either locally or online.

2D Panel Discussion – Måns Olson, game developer from Mojang and Magnus ‘Gordon’ Gardebäck from local studio Simogo as well as a member of the Unity team will discuss their approach to designing 2D games in Unity.

From Unity’s own engineers – Unity developers will provide insider tips on getting the most out of Unity’s technology, including sessions on Linux development, key sound design concepts, creating your own editor tools and the do’s and don’ts of cross-platform development.

Come to Malmo, Sweden and meet many of the incredible European game development community that are helping to shape the industry and making amazing games with Unity.

I’ll see you there,

David

As of today, we will stop selling Flash deployment licenses.  We will continue to support our existing Flash customers throughout the 4.x cycle.

When we started working on a Flash deployment add-on some 18 months ago we had high hopes for the future of Flash as a gaming platform. The performance of early builds was promising, and Adobe seemed to be dedicated to making it a success. Since then much has changed.

1. We don’t see Adobe being firmly committed to the future development of Flash. This is evidenced by the cancellation of Flash Player Next, the instability of recent Flash Player versions and by Adobe’s workforce moving on to work on other projects.
2. By introducing, and then abandoning, a revenue sharing model, Adobe eroded developers’ (and our) trust in Flash as a dependable, continuously improving platform.
3. Developers are moving away from Flash, and while Flash publishing has gotten little traction, our own Unity Web Player has seen unprecedented growth in recent months (now installed on over 200M computers and already installed by 1/3 of all Facebook gamers).

We know that some of you have, like us, invested heavily in targeting Flash. We will do all we can to support you. We will keep the current Flash deployment feature set functioning throughout the Unity 4.x cycle, and will include bug fixes made in upcoming Unity 4.x iterations. We do not plan, however, to make further significant investments in deployment to the platform.

We encourage license holders who have questions or concerns about Flash deployment to contact us directly at support@unity3d.com or contact their account manager.

Getting your Unity content on the Web: What the future holds

Though we are phasing out Flash deployment, Unity will continue to break new ground when it comes to bringing high-end content to the Web.

Uptake of the Unity Web Player is growing exponentially, and, given its increasing popularity amongst Facebook gamers and new Facebook-friendly features, we expect this trend to continue over the coming year. All Unity users can publish content to the Web Player.

Work is also underway behind the scenes on an exciting new Unity web publishing initiative that we can’t wait to tell you about. We’ll be providing more details of this soon.

Update: if you have a project where you need the Unity for Flash tools, please contact our sales department.

We’re very happy to be bringing our over 1.8 million users another awesome platform for Unity games and interactive content. You’ll soon be able to create new content for BlackBerry 10 with the same amazing tools and intuitive workflows you use today to port your games to iOS and Android. And, you’ll be able to take your already existing mobile content and seamlessly publish it to this exciting new platform.

As many of you know Unity has supported BlackBerry via Union for a while. There are over 30 Unity-authored games for the BlackBerry Playbook, and many of these games are now being migrated to BlackBerry 10. Additionally we have had a number of games published in BlackBerry App World during the Alpha including:

Shadowgun, Crevures, Wizard Ops Chapter 1, Astroslugs, The Metal Adventures of Sam, Qbism, Hungry MonstR, Double Bubble Trouble, My Horse, Hairy Tales, Sneaky Duck Lite, City of Ages DELUXE, MonsterThon, Karkov Circus, Dog Puppies Puzzle, Kitten Slider Puzzle, My Horse, Pony Puzzle, Knights of Voden and Defence of Ouril

Play with the latest tech from Unity and BlackBerry

We are calling on intermediate and advanced Unity users to pre-register in the BlackBerry add-on open beta. This is your chance to have an influence on software still under development. Some features are not yet fully supported, and others are still being optimized. You’ll get to test our new platform, report bugs and provide relevant feedback that will help Unity create a great product and jump start your BlackBerry plans.

You can pre-register here. Note that depending on the number of people who pre- register for the program it could take time for us to process the requests and send you the link to the beta site.

Just as with our other open betas for upcoming new platforms, there are important points to note before your sign up:

The hardware

You will be able to publish games to all BlackBerry 10 devices including the Z10 and the Q10 along with future devices. Once BlackBerry releases BlackBerry 10 for Playbook you will also be able to bring games to the tablet as well.

Publishing to BlackBerry AppWorld

You will be able to port your existing games to the BlackBerry 10 platform using the Unity 4.2 alpha/beta builds. We will provide a two month trial license key for all registered beta participants that will unlock BlackBerry platform support in the Unity toolset.

Please note that any project deployed with a trial license will be watermarked and not for commercial release. Developers who wish to publish their games on BlackBerry App World using our alpha/beta builds should contact the Unity Sales Department.

Be cautious about signing up if you’re on a tight deadline

It’s not ideal to become a beta-tester if you have any time sensitive dependencies to release your Unity product in BlackBerry App World. This Unity Beta product will not be fully functional nor contain a full commercial feature locked set of tools. New users to Unity should wait to develop in Unity for BlackBerry until after the public commercial release.

We’re excited to include our incredible community of users in the progress this product!

Some interesting bits:

Operating systems

iOS uptake is crazy high: 98% of the market has iOS version that’s not much older than one year (iOS 5.1 was released in 2012 March). You’d be quite okay targetting just 5.1 and up!

Android uptake is… slightly different. 25% of the market is still on Android 2.3, which is almost two and a half years old (2010 December). Note that for all practical reasons Android 3.x does not exist.

Windows XP in the Web Player is making a comeback at 48% of the market. Most likely explained by “Asia”, see geography below.

• Windows Vista could be soon dropped, almost no one is using it anymore. XP… not dropping that just yet.
• 64 bit Windows is still not the norm.

Geography

Android is big in United States (18%), China (13%), Korea (12%), Japan (6%), Russia (4%), Taiwan (4%) – mostly Asia.

iOS is big in United States (30%), United Kingdom (10%), China (7%), Russia (4%), Canada (4%), Germany (4%) – mostly “western world”.

Looking at Web Player, China is 28% while US is only 12%!

GPU

GPU makers on Android: Qualcomm 37%, ARM 32%, Imagination 22%, NVIDIA 6%.

• You wouldn’t guess NVIDIA is in the distant 4th place, would you?
• ARM share is almost entirely Mali 400. Strangely enough, almost no latest generation (Mali T6xx) devices.
• OpenGL ES 3.0 capable devices are 4% right now, almost exclusively pulled forward by Qualcomm Adreno 320.
• On iOS, Imagination is 100% of course…

No big changes on the PC:

• Intel slowly rising, NVIDIA & AMD flat, others that used to exist (S3 & SIS) don’t exist anymore.
• GPU capabilities increasing, though shader model 5.0 uptake seems slower than SM4.0 was.
• Due to rise of Windows XP, “can actually use DX10+” is decreasing…

Devices

On Android, Samsung is king with 55% of the market. No wonder it takes majority of the Android profits I guess. The rest is split by umpteen vendors (Sony, LG, HTC, Amazon etc.).

Most popular devices are various Galaxy models. Out of non-Samsung ones, Kindle Fire (4.3%), Nexus 7 (1.5%) and then it goes into “WAT? I guess Asia” territory with Xiaomi MI-One (1.2%) and so on.

On iOS, Apple has 100% share (shocking right?). There’s no clear leader in device model; iPhone 4S (18%), iPhone 5 (16%), iPad 2 (16%), iPhone 4 (14%), iPod Touch 4 (10%).

Interesting that first iPad can be pretty much ignored now (1.5%), whereas iPad 2 is still more popular than any of the later iPad models.

CPU

Single core CPUs are about 27% on both Android & iOS. The rest on iOS is all dual-core CPUs, whereas almost a quarter of Androids have four cores!

On PC, the “lots and lots of cores!” future did not happen - majority are dual core, and 4 core CPU growth seemingly stopped at 23% (though again, maybe explained by rise of Asia?).

FAQ

How big is this data set exactly?

Millions and millions. We track the data at quarterly granularity, and in the last quarter mobile has been about 200 million devices (yes really!); whereas web player has been 36 million machines.

Why no “All” section in mobile pages, with both Android & iOS?

We’ve added hardware stats tracking on Android earlier, so there are more Unity games made with it out there. Would be totally unfair “market share” – right now, 250 million Android devices and “only” 4 million iOS devices are represented in the stats. As more developers move to more recent Unity versions, the market share will level out and then we’ll add “All” section.

How often is stats.unity3d.com page updated?

Roughly once a month.

I’m very proud to announce the launch of the Unity 4 open beta for Windows Phone 8 apps! We welcome any experienced Unity developer to enroll in this latest open beta. It’s a chance to preview Unity 4 for the Windows Phone 8 platform and get a foothold in an all-new marketplace that is looking for great games. As a beta participant, you’ll test new technology, report bugs and help us to make it better.

If you enroll in both the Unity 4 Windows Store apps and Windows Phone 8 apps beta programs, you can develop games for the entire Windows ecosystem. People around the world can play your games on computers running Windows XP/7/8, Windows RT tablets and Windows Phone 8 mobiles.

How can my team get access to beta builds ?

In order to participate in this beta program, you need to register here. The open beta consists of two parts:

• Participants can discuss issues, ask questions, give feedback to Unity engineers  and report bugs via the mailing list. Please note that this can result in significant email traffic.

• Windows Phone 8 beta builds, info on how to get started and all other relevant information is hosted on the beta site.

In 24 hours after your registration you will receive a welcome email with instructions on how to proceed.

What is the state of technology ?

Unity 4 Windows Phone 8 support has not yet reached maturity: we are still working on performance optimizations.  There are also bugs and some features missing. However, we feel experienced developers can take advantage of this early technology and already ship games on Windows Phone 8. In fact, we have a few games published on Windows Phone Store:

Drift Mania Championship 2  Fling Theory  Orcs Must Survive

At this point we really need feedback from you, the game creators working on real games. By joining our beta testing program, you can help us accelerate development to ensure this is a great product for all Unity customers.

How can I publish my games to Windows Phone Store ?

You will be able to port your existing games to the Windows Phone 8 apps platform using the Unity alpha/beta builds.  We will provide a two month trial license key for all registered beta participants that will unlock Windows Phone 8 app platform support in the Unity toolset.  Please note that any project deployed with a trial license will be watermarked and not for commercial release. Developers who wish to publish their games on Windows Phone Store using our alpha/beta builds should contact the Unity Sales Department.

The Unity 4 Windows Store add-on is a requirement in order to publish your Windows 8 x86, Windows RT, or WP8 project to the Windows Store or Windows Phone Store.  This licensing option comes in the same two flavors you all know and love:  Basic and Pro. However, if you simply want to deploy your game to the Windows desktop without going through the store, then there are no additional licenses for you to purchase. Regular desktop application development for Windows was, is and will be a part of the existing Unity product.

When will Windows Phone 8 apps support be released?

Windows Phone 8 apps support in Unity 4 is going to be released after 4.2 is shipped. We are working very hard to make this another top-quality Unity feature. We will take the time necessary to polish it. Still, this does not prevent you from making awesome games with our beta builds !

Please note that Unity 4 Windows Store apps and Unity 4 Windows Phone 8 apps beta builds are incompatible at this point, so users are advised to have parallel installations of beta software bundles: Unity 4 editor and platform plugin.

PLEASE BE AWARE

Please do not enter this open beta program if you have any time sensitive dependencies to release your Unity product in the Windows Phone Store. This Unity Beta product will not be fully functional nor contain a full commercial feature locked set of tools. New users to Unity should wait to develop in Unity for Windows Phone Store until after the public commercial release. We appreciate you carefully understanding what your expectations are and not depending on this Beta Product for any of your deadlines. We’re excited to progress this product with the help of you, your team, and our incredible user community. Depending on the number of people who register for the program, it could take time for us to process the requests and send you the link to the beta site. Thanks for your help and patience in advance.

After a road trip so epic that we’re optioning the story to Hollywood, the result was a Facebook Unity package (coming soon to an Asset Store near you) and Unity 4.1.2, with two major improvements already completed. Both of these projects simplify the development and deployment of Unity games to Facebook, while also making it easier for your players to game on Facebook.

Whenever a gamer wants to play a Unity game, they have to download and install the Web Player. We’re committed to making it easier and faster for anyone to download and play Unity games. Facebook is currently deploying a new Web Player install flow to help ease new players to Unity games through the download and install process, and we’re happy to report that this has significantly boosted the number of users installing the Web Player and enjoying Unity games on Facebook.

To simplify the lives of game developers, Unity and Facebook jointly studied the development of immersive, high-quality games and collaborated on improving the Unity workflow. As a result, Facebook will soon release a new, free package to the Unity Asset Store, which wraps the Facebook API into a nice, easy-to-use C# SDK.

Using the new Facebook Unity package not only makes development easier, but it also allows your games to integrate much more deeply into Facebook’s user experience. Many Facebook prompts will now be displayed directly within Unity, allowing your players to post high scores, invite friends, and brag about their accomplishments without ever having to drop out of full-screen. Even better, on any platforms that don’t yet support these new Unity-native dialogs, the SDK will gracefully fall back to the old Javascript methods. In the future, we will expand the number of dialogs available natively inside of Unity, as well as add support for additional platforms beyond the Web Player.

Friend Smash, a test game where you smash your Facebook friends

In order to deliver this enhanced Facebook integration, we also developed some tools that will be useful for everyone, whether you’re writing a Facebook game or not. These will be available in the 4.1.2 release of Unity.

First, we added a new type of UI, a Modal Window. Modal Windows always appear on top of all other content. This allows you to make sure that the user doesn’t miss any critical information or UX flows. Another key feature of these new windows are that any input to them is only captured by the modal window. This makes them a secure way for plugin developers to capture input from the player without having to expose potentially sensitive data to a 3rd party.

Unity 4.1.2 also features the Chain of Trust. This new system allows a hosting web page to send a secret key to the Unity Web Player which will only be readable by a specific assembly. In order to access this secured information, assemblies must be signed. Only signed, authentic assemblies whose credentials match those specified by the hosting webpage are permitted to read the secret key, allowing the hosting site to securely extend its trust into the Unity run time. You can find more information on the Chain of Trust system here.

So what does all this new stuff used in the new Facebook Unity package mean to you? It means that you can integrate Facebook’s awesome social experience into your game easier. It also means that you can keep your players immersed in your game while you do it. If a player is running your game in full screen mode, the native Facebook UI allows you to keep them full screen so they don’t feel like they are leaving the game.

We’ll have more information soon, so stay posted here and on Unity’s Facebook page.

Dear Unity developers, community, friends.

In our tireless march towards world domination (okay, perhaps merely game industry domination), we’re proud to announce that we’ve just entered into a strategic partnership with Sony Computer Entertainment to bring out tools for development for every single of SCE’s PlayStation platforms! Of course, we already offer PS3 support and will continue to do so through Unity’s updates. But now we’ll be working with SCE to build out tools for PS4, PS Vita, PSM, and SCE’s upcoming cloud gaming service.

Work is still in early stages so it will be more than a couple of months before we have something for you all to play with, but we’re hitting the ground running in the efforts to give you all more options to publish your awesome games. We’re looking to begin rolling these tools out this fall, though it’s good to keep in mind that the different tools will have different schedules.

Sony Computer Entertainment is really committed to making their platforms approachable to all kinds of developers, so this partnership is going to make a lot of sense for both companies… and a lot of sense for the Unity community! They’re really focused on bringing the most creative studios, with an emphasis on independent developers, on board their platforms and we are leading the charge to make development awesome for studios of all sizes.

Game Developer’s Conference is starting Monday, and we’re all dug in planning our huge presence there, so I’ll keep this short and sweet. But expect more communications about this along the way (this, and all the other stuff we got in the works!)

Lots of love,

David Helgason

Back then, we imagined an Island Facility called Unity Labs, a remote research base where Unity engineers create game scenarios and test new technologies. We set about creating this world and are shipping the first environment from this world – the Robot Lab, as part of Phase I of the Tutorials site.

The Unity Lab environments host all of our modular content, as you’ll see from this introductory video –

Another part of Unity labs is the Simulation zone, a top secret lab that can simulate any kind of game. Our first simulation is Stealth – accidentally triggered by Ethan, a teenager who strayed from the tour of our facility – you must build the tutorial and help him escape!

This is just the beginning, as you’ll see, we have a great framework here, and I’m excited at the kind of unique resource we can offer to help people get into game and content development. We warmly welcome your comments, so have at it!

UPDATE:

Some of you are experiencing a lack of a fullscreen button on your video player, we have a fix for this we’ll be pushing tomorrow or Friday, in the meantime, as far as we know, Chrome does have this feature visible by default, so if in doubt, use it!

UPDATE 2:

We have now switched to Youtube as our video provider, this should mean better bandwidth and device support. We are also working on subtitles and translations, keep your eyes on the blog for more details!

Of course, things weren’t always like this here at Unity. We’ve come a long way since we first exhibited 7 years ago. Back in 2007, we had a tiny corner at the Nordic Games pavilion with barely enough room for one overworked demo machine. In 2008 we got our own 10 x 10 foot booth on the expo floor. Our small group of developers multi-tasked like mad to manage the the GDC releases, the booth traffic and the parties! At GDC 2009, we were totally unprepared for the huge interest generated by our newly announced support for iOS and Windows. In that sense, 2009 was a major eye opener for all of us.

In 2010 the Unity booth featured Unity partners for the first time; in that same year, and in 2011 we announced support for more platforms. At last year’s event we launched 3.5 and previewed the new animation functions that were to become Mecanim.

Our GDC 2013 program is awesome. This year we’ll be showing our new high-end mobile demo The Chase and giving away Unity Pro Licenses, NVIDIA Graphics Cards, Windows 8 Nokia Lumia 825 and 920 developer edition phones and BlackBerry Z10 devices.

We’ve got a truly amazing collection of tech and titles on display this year. Games like The Drowning, Dead on Arrival 2, HAROLD, Oliver & Spike: Dimension Jumpers, Lovers in a Dangerous Spacetime, and Make showcase that imagination is the only limitation when developing games using Unity. We’ll also have some Offensive Combat and Robot Rising running on the Unity Web Player within Facebook and a demonstration of the excellent Zspace 3D display that can be used in exceptionally creative ways.

As per tradition, we are hosting a Unity Dev Day with a ton of Unity specific information and sessions. We also have a packed schedule of in-booth sessions and our own talented developers will be on hand to answer your questions.  We always do our best to provide a qualified answer – even if it involves finding the guy who wrote the code in question!

And then there are the announcements, all the great news we can’t wait to tell you. We hope to see many of you  next week in San Francisco!

I just thought I would take a few minutes to explain some of the new graphics features they we have going into Unity 4.1 so that you can have a real play with them.

Get the project for the things I talk about here. Note: After importing this package change the player settings to render in linear mode, as that was how the lightmaps were baked and it will look a bit weird otherwise.

Lit Shader Replace

So up to and including Unity 4.0 you have been able to do some pretty cool post processing and other things with shader replacement, but it’s always been a bit limiting, you could not have your whole scene be rendered with a different set of shaders and also include lighting. In Unity 4.1 we have made changes to how this works. Now when you use shader replacement lighting will also be calculated (if the shader you are providing supports lighting). The render path for the camera you are using for the rendering of the shader replacement will be selected (so you can use forward / deferred or vertex lit).

Using lit shader replace you can write some pretty nifty effects and tools. To show an example of what can be achieved I decided to implement a view mode in the editor that shows ‘lighting only’ this is a pretty handy tool for lighting artists to debug their scene lighting and lightmaps.

Original Scene

Lighting Only

So how does it work?

If you check out the Editor Script in the LightingOnly folder you will see that there is a new menu “LightingOnly” with two options. When this is called we render scene view with a replacement shader. The shader was written pretty quickly and does not cover every rendering eventuality (i.e. does not do trees & grass / if you have your own rendertype tags in the shader you will need to write a lighting only shader for them). But it gives an idea of the kind of things you can do. You can use lit shader replace to show a lot of cool things in the scene view.

In addition to the scene view script there is another script ‘LightingOnlyCamera’. If you put this on the camera then it will use shader replace to render the game view. You could do many interesting effects with this.

Custom Material Inspectors / Per Shader Keywords

For a long time you have been able to specify shader keywords using the ‘Shader.EnableKeyword’ and ‘Shader.DisableKeyword’ this worked on a global level and would set keywords for all shaders. This isn’t really what you want all the time though. In Unity 4.1 we have added per material keywords. What this means is that you can specify keywords on a per material level. So you can have one shader that uses one or two textures and select the combination you want from a material inspector (or from scripting)!

To do this you will need to extend the material inspector. If you open the shader ‘MyShader’ in the example project you will see there is a new field ‘CustomEditor’ this has the name of a C# class that will be used for the inspector. If you open up this class you will see that it extends from MaterialEditor. On the material you can simply set the keywords by passing them as a string array to the shaderKeywords property of the material. At some stage in the future we think it makes sense to convert Unity’s built in materials to be more like this so we don’t have a large number of shaders on the back end, but instead have some nice defines for enabling normal mapping and the like and a sexy inspector for them. Not sure when we will get around to this though.

One shader with defines for Texture1 And Texture2

I hope you enjoy the new features and have some time to experiment with them.

Answers to some questions from the comments:

But how do these keywords work? Are shaders recompiled to several version depending on the keyword combinations?In the background this is how they work, we compile a shader for each valid combination. This means that shader compilation will take longer, but it also means less shaders to maintain. Kuba and I talk about how it works in this presentation we gave last year (as well as lots of other things): https://www.dropbox.com/s/1akw1kv0sby1let/Unite12_UnityRenderingPipeline.zip

yeah same question as VALENTIN, does the shader perform the same with 1 or 2 textures ( we pay for 2 even if we chose 1 ), is it as expensive as a conditional ?We currently have a known bug with the shader compiler where doing texture sampling in conditionals is a bit funky, we will fix this. When it’s fixed it will perform better with one sample then two.

DocumentationThe shader replacement behaves as the existing shader replacement and there is only minimal documentation changes which can be seen here: http://docs.unity3d.com/Documentation/Components/SL-ShaderReplacement.html. The new custom material editor feature is documented in these locations: http://docs.unity3d.com/Documentation/Components/SL-CustomMaterialEditors.html and http://docs.unity3d.com/Documentation/ScriptReference/MaterialEditor.html

With the new tool, it’s much easier for developers to tackle the leaks that inevitably arise during development and that Unity’s garbage collection can’t pick up on because they relate to referenced game elements.

Gathering more detailed information

The estimate performed by the original Memory Profiler provided a good approximation of memory usage by tracking selected asset types. In the new version of the Memory Profiler however, all game objects and asset types are tracked along with several internal Unity structures. In this way, the new tool provides much more precise information about how much memory is allocated to various areas.

To provide just one example, the old tool estimated how much memory an animation used based on the various animation tracks. The problem is that such an estimate quickly becomes outdated and needs to be kept in sync. with development. In the new Memory Profiler, every allocation related to the animation is linked automatically, and the numbers shown reflect real-time memory usage on the platform.

Providing a detailed breakdown

As well as making data more accurate, tracking more memory also allows the new Memory Profiler to provide much more detailed information to the developer about how memory is used. The new tool lists each asset and its memory consumption individually allowing the user to check which ones are using more memory than they really should.

Plus, the updated Memory Profiler also provides a better system-level breakdown. Unity has a number of internal systems that use a lot of memory: for example the Shader Lab and internal file caches. Developers can now see how these internal systems affect memory usage when their game is running on the Editor, and how they use less memory or are stripped out completely when the game plays on a device.

A major ongoing project

The new Memory Profiler has been under development for some time, and a lot of preparation has gone into it as it’s something that touches on all Unity systems – everything uses memory.

For us as a company, the new Memory Profiler also provides useful information about the way that Unity uses memory which we’ve used to tweak and trim the engine in various places.

In future, we hope to further develop the tool, and our ultimate aim is to provide total transparency about where every single byte in Unity goes.

The Problem

In the previous 2 releases, 4.0 and 3.5, we had a very, very long release cycle. 4.0 work was started in January 2012 for some people and everyone in the department shifted to it in early March. We released it in November, giving us 11 months of coding and grinding without actually giving the world any value in that period.

The second part of the problem was the way we were dealing with making features and stabilizing them. Developers would frantically make features ready for “Feature Complete”, at which time QA would dive in and find a bazillion bugs. This then quickly diverged into a war of bugs, where developers would be trenched in bug fixing for months. Literally from July to November, bugs were the primary thing everyone looked at, which turns a release into a death march.

We wanted to get out of this vicious cycle and at the same time improve the quality of the product.

Enter Short Cycles

Our solution to the problem was to push our entire cycle down to 2 months. 2 months from the first alpha to the final release. In reality the cycle is longer, since the features are obviously being built before the first alpha, but those 2 months is the rough timeframe we have between releases. There’s a whole range of consequences of this approach:

• We don’t know what is in each release. If stuff is ready for an alpha, it comes in, otherwise it goes to next release.
• We have overlapping cycles. Development of 4.2 has been ongoing for a long time while we are stabilizing 4.1.
• We get features out to users much more frequently than before. This gives us better feedback on the individual feature, thus better test coverage.
• Our betas are 100% feature complete. It is absolutely out of the question to introduce feature once in beta. This was not the case before when a release could be 4 months away.
• Our beta testers experience a better stability, thus are more willing to convert, thus better coverage.

Another benefit we reaped from this is that QA are now having their hands on features ahead of the alpha release. Previously we simply weren’t staffed for it, but this has changed and we are now having time to weed out the worst bugs before the alpha crew gets them. Our internal demands for getting stuff into trunk is simply higher than previously.

Numbers

First I’d like to show you a “burnup” chart of the effort on 4.1. As you see the work started a long time ago and the bug fixing naturally takes off for real when we start the alpha cycle and slows down when we reach release candidates and raise the bar massively for what can enter. About 330 bugs have been fixed during 4.1

A lot of our test coverage comes from our fabulous community and we take them very seriously. As you see in the below chart, we have handled 97% of all reported incidents, this number will be 100 very soon. We have recieved 231 incidents in total, converted 181 to be reproducible bugs and 69.4% of those are either still active or have been resolved as fixed. As a bonus info I can say that our communities account for 36% of all the active/fixed bugs found in 4.1, thank you very much for that!

Enter the burnup for 4.2. This cycle is more representative of how it will go in the future, since 4.1 was our very first and lots of changes had to happen.

It’s interesting to notice that we released 4.2 alpha 1 a few days ago and we already have 200(!) bugs fixed in this release. Before even getting the first user on it, we have shaved a massive pile of technical debt away. This is exactly what we wanted to achieve!

More to come…

As you can tell from the above, we’re full speed ahead on version 4.2, which will include more good features for everyone and the astute reader will probably figure out that we are also having lots going on already for 4.3 and 4.4. This is going to be an exciting year. My personal goal is that we deliver the highest quality game engine you will find on the market and the quest for that continues ever onwards.

If you feel brave enough to be an early adopter and play with technology still in development, then enroll in our Windows Store apps early access program. If you are an intermediate or advanced Unity user, WE WANT YOU! As a participant of our beta, you get to test our new platform, report bugs and provide relevant feedback that will help Unity create a great product and jump start your Windows Store plans. We do ask for your patience though; depending on the number of people who register for the program it could take time for us to process the requests and send you the link to the beta site.

Is it ready for my team?

We’ve been working on the support of Windows Store apps for a while now. The below Unity-authored games have already been published in the Windows Store:

Orcs Must Survive,  Drift Mania Championship 2,  Pettson’s Inventions,  Gunpowder,  Rumpelstiltskin 3D,  Snow White Prequel,  Razor Salvation,  Siegecraft,  Qbism,  Hungry MonstR,  Fling Theory,  Experiment HD,  Big Buck Hunter,  Living Stories: Das Verlorene Herz.

Unity 4 Windows Store apps support is still in development. It is not feature complete nor fully optimized so there may be some bugs lurking. By joining our beta testing program you can help us accelerate development, ensuring this is a great product for all of our developers.

What hardware is supported?

With Unity 4.2 you will be able to publish games as Windows Store apps targeting x86 and ARM systems. The minimum DirectX version supported is DirectX 11 Feature level 9.1, so your games will run on almost any PC and tablet that is running on Windows 8 or Windows RT.

How can I publish my games to Windows Store?

You will be able to port your existing games to the Windows Store apps platform using the Unity 4.2 alpha/beta builds. We will provide a two month trial license key for all registered beta participants that will unlock Windows Store app platform support in the Unity toolset.

Please note that any project deployed with a trial license will be watermarked and not for commercial release. Developers who wish to publish their games on Windows Store using our alpha/beta builds should contact the Unity Sales Department.

PLEASE BE AWARE

Please do not enter this early access program if you have any time sensitive dependencies to release your Unity product in the Windows Store. This Unity Beta product will not be fully functional nor contain a full commercial feature locked set of tools. New users to Unity should wait to develop in Unity for Windows Store until after the public commercial release.

We appreciate you carefully understanding what your expectations are and not depending on this Beta Product for any of your deadlines. We’re excited to progress this product with the help of you, your team, and our incredible Pro user community. Depending on the number of people who register for the program, it could take time for us to process the requests and send you the link to the beta site. Thanks for your help and patience in advance.

*Regular desktop application development for Windows was, is and will be a part of existing Unity product. The ability to develop a new Windows Store app based on Windows Runtime will be introduced in 4.2.

Unity may mostly be known for the focus on “fun and games.” But over the years the use of the platform has truly matured in the development of industry-defining game changers (pun intended) for serious games and virtual environments, from the military to education to medical.

We actively work to always ensure Unity is ready and primed for government applications, and were recently reissued certifications by both the US Army and US Air Force. And, in just the past year, NASA’s Mars Rover, NASA Jet Propulsion and the National Oceanic and Atmospheric Administration (NOAA) all took advantage of Unity for a variety of projects.

For example, NOAA leverages the power of Unity to create powerful data visualizations of their big data for science analysis, education and outreach. One of their products named TerraViz is a multi-platform interactive visualization tool that accepts information in formats like KML or data provided through web map services (WMS) and displays the results in a 3D environment. They can seamlessly display millions of points of information at game-level frame rates, as NOAA produces thousands of gigabytes of information every day.

Serious games projects made with Unity also swept the majority of the category awards at the recent Serious Games Showcase and Challenge at the recent Interservice/Industry Training, Simulation and Education Conference (I/ITSEC). Four of the six category winners were made with Unity and approximately 40 percent of both the overall submissions and finalists for SGS&C were Unity projects. The judging included more than 100 people from academia, government and industries around the globe for the official awards of the I/ITSEC conference that attracts 20,000 attendees each year. The top, award-winning projects using Unity technology were:

• Government: Cross-Competency Cultural Trainer by JKO-J7
• Student: Machineers by IT University of Copenhagen
• Mobile: DragonBox+ by WeWantToKnow AS
• People’s Choice: C-ID Combat Vehicle Detection & Identification by AEgis Technologies

We’re most proud of the fact that Unity’s accessibility and our business model has truly enabled the growth in opportunities — for both small businesses and large companies — with serious games. Organizations including Booz Hamilton Allen, CliniSpace, Daden for BAE Systems, Designing Digitally Inc., E-Semble, Heartwood, Real Visual, Serious Games, Vienna University, VIZERRA, and more, have chosen and implemented incredible new experiences, simulations, and 3D content and serious games with Unity. We believe anyone should have the ability to create interactive, real-world applications outside of the traditional games realm, and we will continue to innovate and deliver the cutting-edge features that makes Unity stand out in the interactive applications fields.

To see non-game examples, in action, where Unity has been used with great success, please make sure to check out Unity’s serious games demo reel and visit our dedicated serious games mini-site at www.unity3d.com/sim.

Last week I finished reading the book ‘Exploratory Software Testing’ by James Whittaker. Not coincidentally at the same time we concluded the first round of exploratory testing (E.T.) sessions that I have been a part of here at Unity. I thought I would share my thoughts on the book as well as our current and future use of the E.T. *Spoiler Alert* … We have not seen the last of E.T. at Unity.

If you are interested in software testing and haven’t read the book, I encourage you to do so. It’s a relatively quick and easy read and even though the chapters vary greatly in usefulness, it’s never less than interesting.

The first two chapters – ‘The Magic of Software’ and ‘The Case for Manual Testing’ seem to be aimed at either novice testers getting into the craft or developers who believe that processes, engineering practices, defect prevention and automated testing (while all excellent) have or will make manual testing obsolete. James presents at least one damning evidence to the contrary – Windows Vista – and the fact that he worked at Microsoft during the development of Vista leads credence to his case.

The next four chapters are the core of the book. Chapters 3 and 4 are concerned with “testing in the small” and “testing in the large” respectively.

The former – testing in the small – is about the actual nuts and bolts of testing. Hands on keyboard and eyes on screen. It does not contain actual test techniques as such. It is more about useful ways to think about software and testing. There are lots of good terms and concepts. A select few:

• Atomic vs. abstract input (specific input vs. groups of similar inputs)
• Significance of input order and input combinations
• Legal vs. illegal inputs (analogous to confirmatory vs. destructive mindsets)
• A good definition of the concept of state (“A state of software is a coordinate in state space that contains exactly one value for every internal data structure”)
• The importance of realistic user data and environment

None of this is revolutionary but useful for explaining the problems that James is trying to address in the book. However, as a source for concrete advice and test techniques, James’ own book ‘How to Break Software: A Practical Guide to Testing’, is much better.

Chapter 4 – ‘Exploratory Testing In the Large’ – is where the concept of exploratory testing “tours” is presented. James’ idea is to take different tourist metaphors and apply them to exploratory testing. For instance, the “guidebook tour” is about following the manual, a tour through the “historical district” examines legacy code and features and the “taxicab tour” explores all routes to a specific location or state. The concept of tours is the book’s main contribution to the world of software testing. The metaphor of software testing as exploration or travelling through terra incognita has often been used, not least in the “American” context-driven school of software testing. The tourist metaphor complements this view well. It is an easily grokkable way of framing and guiding the test activity.

Chapter 5 is an elaboration on some of the tours and chapter 6 presents some real-world examples of the tours in use. Both are required reading to understand the concept.

Even though the actual tours are presented in the preceding three chapters, chapter 7 – ‘The Five Pain Points of Software Testing’ – is perhaps my favourite. It is one of the best summations of the fundamental challenges of software testing that I have seen:

• Aimlessness: Testing without a goal. Testing for the sake of testing. In my experience this is the most widespread problem I have encountered in the field of software testing. Not properly defining what needs to be tested, when to test, as well as how to test. What are the questions that you seek to answer with your testing?
• Repetitiveness: How do we make sure we inject enough variation into our testing so we don’t run into the pesticide paradox? How do we maintain our manual regression test suites.
• Transiency: How do we make sure that our testing is representative of real-world usage of the software?
• Monotony: The fact that testing can be mind-numbingly, life-drainingly boring (he actually means “checking” – the difference between “testing” and “checking” is topic for another blog-post)
• Memorylessness: For testing in the small, how can we persist and relate what actually happened during a test-session so that we can use that info at a later point? For testing in the large it has to do with the concept of coverage – how can we tell what we have tested and how do we get access to historical data about this so we can track trends over time?

The last three chapters can easily be skipped. Chapter 8 is musings about the future of software test, none of which seem particular insightful or relevant to me. He spends a lot of time talking about reusability of test-cases. The space and importance he allocates to this seems a little at odds with his points in the early chapters about the importance of manual testing with sentient testers. The last two chapters are collections of James’ blogposts. Good reads – James’ colourful style and affection for British pubs really come through here. But many of the points presented are covered elsewhere in the book.

Exploratory testing tours are not a free lunch. I had actually encountered the concept of Whittaker’s tours before I started at Unity. First impression: “not impressed”. To me they seemed a little superficial and cute. We had tried running a couple of tours. Some of the obvious ones – supermodel, crime-spree, collectors etc. That was fine, but we didn’t find much that we wouldn’t have found using our normal methods. So we kind of moved on.

Because the concept of testing tours is so immediately graspable (which is good), it’s easy to fall into the trap of simply running the most basic and vanilla versions of the tours. But if your preparation consists of nothing but “inspect and interact with all UI-elements” (for the supermodel tour), then the results will reflect that. If the tours you pick exercise the same parts of the application that you would have tested anyway – well – your results will reflect that.

The sad truth is that the more you prepare for a test session, tour or not, the more you will get out of it (to a point, of course). This also seemed to be one of the general takeaways from our internal evaluation of the E.T. sessions last week. To me, this is perhaps best illustrated by five minutes of James’ talk on testing tours (from 37 to 41 minutes in). It shows some of the work James’ team at Google did as preparation for test of the Chrome OS back in 2009. They didn’t just flip out the Landmark Tour and went to town. Instead they broke down the software into attributes, components and capabilities (ACC-breakdown). They filled out spreadsheets, talked to developers and hosted risk sessions. And THEN they decided on the tools they needed to test this – some of it automated testing, some of it carefully chosen E.T. tours.

If, for whatever reason, you have no preparation, the tours in their basic form can be used to good effect. Certainly they are much better than complete ad-hoc testing. But they are not a silver bullet which was the impression I got from how they were initially presented to me.

The way I see it, exploratory testing tours are a great tool for overcoming the five pain points of testing outlined in James Whittaker’s book:

• Aimlessness because it frames the test activity and gives it a purpose
• Repetitiveness because different tours are different lenses that examines the software in different ways. And because by the nature of exploratory testing, no two sessions are ever exactly the same
• Transiency can be addressed by choosing tours that emulate real-world usage and because tours combine well with use cases/user scenarios
• Monotony because exploratory testing is a challenging mental activity that requires human thought and reasoning
• Memorylessness because the concept of tours provide a vocabulary to talk about test sessions which can otherwise be an elusive activity. And because the output of different tours can be tracked and compared to previous and other sessions

My goal is to integrate exploratory testing more with the way we work. Not big bang overnight but rather slowly and surely. For starters, I am sure we could benefit from having one or more tours as part of at least full test pass for each area. There is some work to do before this can happen. We need to do our homework and figure out our concepts for describing coverage. And then we need to just start doing it. Trying out different tours and see what gives results and what doesn’t. Maybe eventually even come up with some tours of our own.

I also see uses of exploratory testing that do not necessarily fit into the tours concept. This could be exploratory testing used as part of early feedback on new features pre-alpha. One thing is certain – we have not seen the last of exploratory testing at Unity.

Dear friends,

I’ve spent 10 years of my life on Unity – from writing the first version of ShaderLab (our shader compiler – yeah, you can blame the convoluted syntax on me), to my main focus of designing the Unity Editor (yup, every missing button is probably my fault as well), to working with our wonderful team on the Asset Store (where I don’t think I did too much damage).

It has been an awesome ride.

Over the years it has been amazing to watch Unity getting better and better at such a crazy speed. Lately I have been incredibly inspired by what you guys have been creating and have been experimenting more and more with my own ideas. It’s made me realize that I have games I want, no need, to make!

As great as it has been building Unity, I have come to feel that actually using it is what really scratches my itch. On days where I can just get into the zone and fidget around with some shaders, gamecode, a custom editor tool or whatnot, I feel really fulfilled. And at the end of the day, that’s what it boils down to (for me, at least)

So I will be leaving Unity in order to join your ranks and dedicate myself to creating games. This has not been an easy choice – in fact, it has been one of the hardest ones in my life. I am infinitely proud of everything I’ve been part of building, proud of the team, and proud of having a tiny part of me in all your games. So proud that I can’t wait to experience Unity from the other side of the fence.

I’ve given to Unity all I had to give, and now I gotta go do what I gotta go do.

Wish me luck!

Nicholas Francis

Unity co-founder

Right now, Unity is the world’s No.1 engine when it comes to mobile games. According to a 2012 Game Developer survey, Unity is far and away the most popular engine amongst mobile game developers, and they use it to make huge numbers of critically-acclaimed, innovative, mega-grossing games. In fact, no less than seventeen Unity-made games and apps featured in Apple’s AppStore USA Best of 2012 list.

The seventeen Unity games were recognized across 10 categories including:

iPad Game of the Year: The Room by Fireproof Games

Top Grossing iPhone App of the Year: Kingdoms of Camelot: Battle for the North by Kabam

Best Casual Games:  Mini Motor Racing by The Binary Mill (iPhone and iPad) and Bad Piggies by Rovio (iPhone)

Best New Ways to Play: Slingshot Racing by Snowbolt Interactive (iPhone), Total War Battles by The Creative Assembly (iPhone), Splice: Tree of Life by Cipher Prime (iPad), Tentacles: Enter the Dolphin by Press Play (iPad) and Beat Sneak Bandit by Simogo (iPad).

Best Showpiece Games: ORC: Vengeance by Big Cave Games (iPhone), Dead Trigger by Madfinger Games (iPhone and iPad) and Air Mail by N-Fusion Interactive (iPhone)

See the full list of Unity games featured on the AppStore USA Best of 2012 list here.

Innovate at speed

Independent studios like Best New Ways to Play winner Cipher Prime are using Unity to push the boundaries of touchscreen content and create trailblazing games fast. Game play in Splice: Tree of Life revolves around reprogramming the DNA of an ever-shifting pool of organisms that tilts with the player’s iPad, contributing to the immersive feel of this stylish like-no-other puzzler.

Cipher Prime built Splice: Tree of Life in an astonishing six weeks. “Since switching to Unity, our production time has pretty much halved on each new project, and Splice has been our fastest build yet,” says Creative Director Will Stallwood. Read more about Cipher Prime’s experiences in creating their latest hit here.

Small is beautiful…and successful

Like many of the games featured on the Best of List, The Room, a gorgeous 3D puzzler, was made by a small team of highly talented developers. Remarkably it was also Fireproof Games’ first production and cost just $90,000.

“We wanted to make something that was among the best-looking games on the platform, but didn’t have the resources to build characters or large environments,” says Mark Hamilton, the game’s artist and designer.

“With that in mind, I came up with the idea of a Chinese puzzle box. Interacting with the panels, sliding them around… seemed like a good fit for the touch interface, and focusing on one object built of various woods would allow us to show off our art expertise.”

And, at Big Cave games, cofounder Ryan Rutherford says, “with a small team, everyone can adjust quickly and still be on the same page with one another. This was crucial in the development (of Best Showpiece Game Winner ORC: Vengeance), and is what led to us making a high-quality product. Two guys and a game engine like Unity can still create a good game that’s available to millions of people on the App Store.”

How can we help you get your talent out there?

We’re really proud that so many people are choosing Unity to build great mobile games. But to readers new to both Unity and game development, the task of mapping out a plan for building, publishing and promoting an awesome mobile game might seem daunting. Where do you start? If you’re a mobile developer with a suggestion for content that you would find helpful, leave us a comment to let us know.

Here at Unity, since last August we’ve been pushing ahead with our plan to create a totally new learning area on the site, and as a larger concept – a new focus on the web for people young and old who are new to game development, and want to get started. Naturally we want to serve our existing users too, and as this new area develops, we hope there will be something for everyone to inspire fresh ideas, and ultimately, awesome games and interactive content.

If you’ve missed the previous updates on this project, I recommend you read up on where we’ve come from so far in these previous blog posts -

http://blogs.unity3d.com/2012/08/29/learn-unity-coming-soon/

http://blogs.unity3d.com/2012/09/11/learn-unity-update-1/

http://blogs.unity3d.com/2012/12/13/learn-unity-update-2/

At this stage, we’re still on target to launch the first iteration of the project in late March, and you’ll see a lot of beginner content arrive around then. We’ll also be bringing this content to GDC to chat to anyone who wants to stop by the Unity booth and talk about game development.

What to expect in Phase. I

As stated previously, we don’t want to wait until everything is recorded to get you started using this new learning area, so we plan to ship phase one with a lot of the basics of game development in Unity available for beginners to get started. Then over time we’ll be adding more content, covering more topics, and making good on our promise of democratizing game development, by giving you as much knowledge on the topic as we possibly can. In the first phase we plan to ship -

• The Robot Lab environment
• Beginner Scripting lessons
• Beginner Editor
• Beginner Physics Lessons
• Beginner Graphics Lessons
• Beginner Audio Lessons
• Beginner Physics Assignments
• ‘Stealth’ – a larger game level tutorial

What’s the latest?

Grab the Lab!

At the time of writing, we have our first tutorial environment ready to ship – The Robot Lab, with all manner of crazy props from a giant robot arm, to a sci fi battering ram! This has taken time as we are producing the level to the highest standards of detail, to try and inspire you to experiment, learn and have fun with these assets. We’ll be using this environment to deliver the bulk of the learning content that you’ll see in phase one, aside from the larger level project ‘Stealth’.

To make sure this environment is up to your standards, today we’re pushing this project to the Asset Store to let you get your hands on it, and let you start experimenting with the props we’ve created. As a former tutor I know how valuable it can be to have cool assets to inspire your students so I wanted to get this content out to you as soon as we were happy with it.

We’d also like feedback on any bugs you find so please write a comment on this post or email me directly on will [at] unity3d dot com during this testing period. We’ll be adding more scripts, a few collision meshes and more sound effects but for now our only known bug is a lightmapping issue when opening on mac. So what are you waiting for? grab the project now and have a play with the lab!

Tutorial Content

In terms of video tutorial content, we have our Beginner Editor, Physics and Scripting Lessons produced and on our staging site which is also currently mid-production. The Stealth game is our first larger ‘Project’ (as opposed to Lesson or Assignment, our smaller pieces of content), and is currently being pieced together by the team, ready to be recorded as video steps in the coming weeks.The game level is designed to teach you how to put together a game level in Unity, comprising a metal gear solid style ‘sneak em up’ with security cameras, guards, keycards and a battle bus! This project will help you learn about Character animation for player and enemies, Raycasting, Collision, Game logic and various other tips and tricks! We’ll have more to show of this soon, but for now here’s a sneaky peek at our main character.

We are also continuing to prototype other ways of teaching game development with Unity, and we’ll have more news on a piece of new tech we’re developing with schools in mind, towards Q2 of this year.

For now, if you are a teacher at any level, we’d like to hear from you, and get your feedback on how we can better support you – drop me a line on will [at] unity3d dot com and we’ll add you to our database of tutors we’re compiling.

Fortunately, for the majority of models this otherwise lengthy setup process is completely automatic. Let’s have a look at how that works…

What Avatar Mapping Involves

Setting up a humanoid Avatar in Unity involves matching every “human bone” to one of the transforms in the model. It’s possible to do this manually in Unity by clicking Configure… under the Rig tab of the Model Importer. Without fingers there’s up to 24 bones to map – and 30 more if you have finger bones too. For every one of those you have to drag the transform into the corresponding slot in the GUI when you use the manual method.

When I first joined the effort to improve the interface for Mecanim, that was the only way to setup characters. For anyone who wanted to experience the Mecanim awesomeness with their own characters, there was first these 24-54 bones to drag in with the mouse, one by one. Things like that don’t leave an exciting first impression.

So I began looking into how to do that automatically.

Hints to Go By

How do you make a computer figure out what transforms correspond to which human bones? There is more than one way to go about it…

Names of Bones

One seemingly straightforward option is to use the names of the transforms. But unfortunately, some of the most commonly used terms are actually used to describe different bones in different models.

• “Hip” can mean the center bone that’s parent to both legs, or it can mean the left or right hip.
• “Leg” can mean upper or lower leg.
• “Shoulder” can mean either the bone for the upper arm or, if present, the collar bone that’s the parent to the upper arm bone.
• “Arm” can mean upper or lower arm.

Naming for bones in the spine is often a total anarchy since the number of bones is completely variable, and sometimes a bone called “neck” even has the left and right shoulder as children (due to a flaw in a popular software used for rigging), meaning the mapping have to assign it as the chest bone despite its name.

Furthermore, finger bones are often simply named “finger_0″ to “finger_14″ or similar, with no convention of which numbers mean what. And bones for eyeballs and jaw have a ridiculous amount of variation for what they’re called, including helpful things like “nurbsToPoly2″.

So while names of bones often give us certain useful hints, they don’t contain sufficient information on their own to cover a wide variety of models.

Side Keywords

Just determining if a bone is for the left or right side is a mini challenge by itself. Obviously if the word “left” or “right” is included in the name it’s a given, but a lot of the time only the letter “l” or “r” is used. However, those letters can also be part of a word, so I only regard them as side keywords if they stand by themselves, separated from the rest of the string by spaces, punctuation, or similar.

Bone Directions

Some information can be inferred by looking at the direction of a bone. While there’s no guarantee about the pose of the character at the time when the auto-mapping happens, it’s generally more likely that bones in the right side point towards +x and that bones in the spine point towards +y while bones in the legs point towards -y etc. For each human bone we have specified a “correct” direction. Direction matches of different child transforms are computed using dot products of the normalized transform direction compared to a target human bone direction, and a score is awarded accordingly. Where the bone direction information really shines is in figuring out the mapping for the fingers, where there is often nothing else to go by.

Bone Length Ratios

While proportions of different models differ, there are usually some aspects of the proportions that are consistent for most models. For example, the upper leg and lower leg usually have roughly the same length, while the length of the foot is typically much shorter. The length of the upper arm bone is usually about twice as long as the length of the collar bone, when present.

The length ratios contribute a lot to ensuring sensible mappings. Imagine for example a model that has no collar bone, and the upper arm bone is called “shoulder”. The upper arm also has a bone in between the shoulder joint and elbow joint used for twisting of the upper arm (but nothing in the name necessarily indicates this). Looking at the names of the bones alone, the computer would be inclined to map the bone called “shoulder” to the human collar bone and map the upper arm twist bone to the upper arm human bone. This would be completely wrong. But thanks to the length ratios, this scenario is almost always avoided and the bones are mapped correctly.

Another place where the length ratios shine is for the bones in the spine. The spine in a model can consist of any number of bones, but they have to be mapped in a sensible way to just the following human bones: Hips, spine, chest (optional), neck (optional), and head. If you have, say, 8 transforms in the spine, how should they be mapped? The names are no use, and the bone directions are all the same. Just attempting an even distribution gives terrible results. Instead we strive towards these length ratios: spine-chest should be 1.4 times as long as hip-spine. Chest-neck should be 1.8 times as long as spine-chest. Neck-head should be 0.3 times as long as chest-neck. (Humanoids generally bend mostly in the area below the chest since the chest itself is more rigid.) The result is a mapping that produces bending in the spine that looks natural within the confines of the bones in the model.

The algorithm chooses bone assignments that matches the desired length ratio as closely as possible. Calculating “closeness” in this case requires converting both the actual ratio and the desired ratio to a logarithmic scale and measuring the difference of those. The logarithmic scale ensures than a length that’s twice as longs as it’s supposed to be is penalized by the same amount as a length that’s half as long as it’s supposed to.

Topology

Last but not least, the “topology” of the bones play a major role. For example, the neck and the left and right arm must all be children of the chest, so a mapping where one bone is mapped to the neck, but children of that bone are mapped to the left and right shoulder is not an option. Contrary to the other factors described above, the topology requirements work as a hard constraint. The requirements are specified in the form like this

• The RightShoulder human bone must be a child to the Chest human bone, placed 1-3 levels further down the hierarchy. (1 level would be a child; 2 levels would be a child of a child etc.)
• The RightUpperArm human bone must be a child to the RightShoulder human bone, placed 0-2 levels further down. (A level of 0 means they are the same bone. This is permitted when one of the bones are optional, like the Shoulder ones are.)
• The RightLowerArm human bone must be a child to the RightUpperArm human bone, placed 1-2 levels further down.

Most bones allows for a range of levels in between the mapping of itself and its parent. This is because different models have different amounts of transforms in between the principal human bones. For example there might or might not be a twist bone in between an upper arm bone and an elbow bone. The range also function as an optimization, since transforms that are further down the bone hierarchy than the number of levels allowed do not need to be considered as potential matches.

Optimal Mapping as a Search Problem

We’ve looked at various hints that can be used as part of the mapping algorithm, but how is it all combined? The solution I arrived at is to treat the mapping as a search problem.

Consider the function EvaluateBoneMatch which evaluates a match between a human bone (for example Chest) and a transform (for example “MyModel_Chest”). This function evaluates the match itself according to the keyword, direction, and length ratio hints described above. The result is a score that indicates how good this match is.

But the EvaluateBoneMatch function goes further than that. It iterates through all the child human bones. (For the Chest human bone, the children would be LeftShoulder, RightShoulder, and Neck.) For each of those it gathers all the transforms that are potential matches according to the topology requirements, i.e. all transforms n levels down the hierarchy, where n depends on which human bone is being mapped. And for each of those pairs of a child human bone and a transform it calls EvaluateBoneMatch. Since the function calls itself, this is called a recursive function. Each of those calls return a score value that determines how good the match is.

Now the function determines the best match for each of the child human bones (LeftShoulder, RightShoulder, and Neck). This is based mostly on the scores, but it can’t simply choose the top ranking choice for each of them, since multiple child bones sometimes pick the same transform as their top choice! More on that later. Anyway, the score for each of the picked child human bone matches is added to the score of the current bone match itself, and the result is what the EvaluateBoneMatch function returns.

Confused? It is common for it to take a little while and some effort to wrap one’s head around a recursive function and it sure did for me as I implemented the algorithm. Having many different inter-related hierarchical structures in parallel didn’t make it easier (the human bone hierarchy, the transform hierarchy, and the search graph hierarchy). But the gist of it is that the EvaluateBoneMatch function returns a score that represents not just how good that specific match is in itself, but including the entire child hierarchy of best matches.

This in effect means that every bone mapping gets chosen not just based on how good that match is by itself, seen in isolation, but also based on how well it fits as a piece in the entire mapping.

Remember how I mentioned that a lot of models incorrectly have the arms as children of a bone called “neck”? Imagine this conversation:

Ah, so this is the Neck bone! It’s called “neck” and points upwards and has a good length ratio, so it seems to match. The neck should only have the Head as a child, but there’s some other transform children as well that don’t seem to match any bones in the head. Oh well.

… later …

Hmm, alternatively we can try to map the bone called “neck” as the Chest bone. This doesn’t score well in terms of keyword matches but let’s try it anyway. This Chest has child transforms that seem to match the LeftShoulder and RightShoulder as well as the Neck. And those left and right shoulders have children that matches the various bones in the arms, and so on. All those matches are worth a lot of points so it ends up being better to match the transform “neck” to the Chest than to the Neck, based on the points obtained from the hierarchy further down.

With a search based algorithm you get seemingly “smart” considerations like this for free all over the place. It’s very similar to the problem of trying to solve a maze: In order to get to the exit that you know is to the North, you may have to go in the wrong direction some of the way first. Knowing the right direction for even the first step requires knowing the entire solution.

Child Conflict Resolution

Multiple child human bones sometimes pick the same transform as their best matching choice choice. For example the human bone LeftHand have the child human bones ThumbProximal, IndexProximal, MiddleProximal, RingProximal, and LittleProximal. And maybe both RingProximal and LittleProximal picked the transform called “Finger_2″ as the first choice. Now what to do? The same finger can’t be both the ring finger and the little finger!

For each of the human bones we keep not just the first choice, but a ranked list of choices. To make sure that each transform is only mapped to one human bone, and that the transforms are assigned to the human bones in the best possible way, a function called GetBestChildMatchChoices is called. First we make a list that contains the current choice for each human bone. Initially they’re all set to 0 (the first choice) even if that means there are potential conflicts. We pass that list of current choices to the function, and the function then goes through these steps:

1. Check if any of the current choices have conflicting transform. If not, we are done and can return the current choices!
2. Make a list of all the human bones that are part of the conflict.
3. For each of those human bones, try out an alternative list of current choices where this human bone retains its current choice and all the other human bones in the conflict have to use their next choice on their priority lists. For each of those alternative lists of current choices, call the GetBestChildMatchChoices function. (Yes it’s a recursive function again.)
4. Each call of GetBestChildMatchChoices returns a new current choices list and a score value that is simply the summed scores of all the matches corresponding to the current choices.
5. Choose the current choices list with the best score and return that list along with its score.

This procedure basically tests all permutations and chooses the best scoring one.

Before I came up with this approach I had initially just implemented an approach where the human bone with the best scoring match got its first choice, the human bone with the next best scoring match would get its first choice excluding the already picked, and so on. This was faster computationally and easier to understand, but unfortunately it often resulted in incorrect results. The illustration below demonstrates the difference between picking the best individual match versus the best overall match for all siblings.

Optimizations

Since the search evaluates many hundreds of possible mappings for a typical avatar, the auto-mapping started to get a bit slow at some point. A lot of the time was spent with string handling related to trying to match keywords, but other parts of the evaluations also took up significant time.

I realized that the same pair of human bone and transform was being evaluated many times as part of different possible mappings. The biggest optimization was achieved by caching the results of such an evaluation and simply use the cached result the next time the same pair needed to be evaluated. Different parts of the cached data needed to be cached differently because they had different amounts of needed context. A keyword evaluation only needs the human bone and transform themselves, but the evaluation of bone length ratios need the parent match and grandparent match as well, since they are used for calculating the lengths.

In the end I used a design where I cache the result of an entire EvaluateBoneMatch call based on a pair and the parent and grandparent pairs. If a potential pair needs to be evaluated and the cache already has an existing evaluation for the same pair with the same parent and grandparent, that result is used and the call to EvaluateBoneMatch is skipped altogether for that pair. If it doesn’t exist, EvaluateBoneMatch is called to do the evaluation, but some of the sub-routines that evaluate keywords etc. use their own caching that requires less context and hence is more likely to have already been evaluated before. Using these cached result sped up the evaluation times by a factor of 8. After that, it was fast enough that the entire Auto-Setup process was no longer a bottleneck. (It usually takes less than a second which is a fraction of what the model import process takes.) Doing high-level optimization like this is often very satisfying since it can change the fundamental time complexity of an algorithm which can often result in very big improvements.

Special Handling

The Auto-Mapping algorithm was designed for to be primarily data-driven. I wanted to avoid a solution that had all kinds of hard-coded rules for different parts of the body, since code like that is often brittle and error-prone, and doesn’t lend itself to the kind of search-based solution I could see would be necessary for good results. Nevertheless, some compromises ended up being necessary.

One compromise is that the search for the body mapping stops at the hands rather than including all the fingers. The fingers include more bones than the entire rest of the body, and excluding all that from the body mapping search reduced the search time significantly. Instead, the fingers are mapped by themselves starting from the hand bones found in the body mapping search.

Another thing that’s handled in a special way is the assumption about body orientation. As mentioned earlier, the search algorithm takes hints from the directions of the various bones. However, sometimes a model is imported in Unity with a completely arbitrary rotation and all the assumptions about bone orientations are wrong. The remaining hints are usually enough to map some parts of the body well enough, but the fingers, if present, are often mapped completely wrong in those cases. To counter this we check the positions of left and right hip and shoulder after a mapping is completed, and derive the body orientation from those positions. If the body orientation is significantly different than the assumed one where +z is forward and +y is up, then we redo the entire mapping based on the now known actual orientation. In this second pass the bones are usually mapped with much higher rate of correctness.

Testing Framework

While implementing the automatic setup I also created a function for automatically testing and validating the automatic setup for a model. Every time we have come across a model where the auto-setup fails, we have added it to the testing framework, provided a sensible setup is possible to do manually in the first place. (Some models don’t have a proper skeletal hierarchy at all. Those are not compatible with Mecanim humanoid animation, so obviously auto-mapping won’t work for those.) At this time we have around 30 models in the framework, which include a lots of humans with different proportions as well as some fantasy and toon characters with completely different proportions and a few robots. Among them the models have wildly varying rigs.

While the auto-mapping is based on a solid algorithm, there is a lot of tweaking involved in determining which hints should contribute how much in the scoring. Having the testing framework has been essential to being able to tweak those parameters and be able to immediately test that it fixes the intended edge cases without causing regressions for other characters. If you have any characters that you CAN do a manual setup for, but which the automatic setup did not handle satisfactory, you are welcome to send the models in question in a bug report. Include the words “avatar auto-mapping” in the first line of the description. We can’t guarantee that we’ll be able to make the auto-setup handle every single model correctly, but being aware of problematic cases provides us with a better basis for attempting it.

Conclusion

I’ve covered the primary functionality of the Auto-Mapping for humanoid characters in Unity. The Auto-Setup includes other functions as well, such as getting the character into T-pose, but those are outside of the scope for this post, and not quite as interesting and challenging anyway. The Auto-Mapping is an interesting feature in that it contains quite advanced functionality yet is practically invisible to the user. It’s very purpose is to be something you don’t have to think about at all. Of course it doesn’t always work out that way in all cases – for some models here and there the automatic mapping fails and then you’re suddenly painfully aware of it. But for the majority of cases, the Humanoid Animation Type is just a setting you can enable, and then not have to think about. Instead you can get on with the real fun of animating your characters.

We had a great turnout of submissions which made judging one tough cookie, so as well as presenting the Grand Prize Winner and runners up, we have a little showcase of everything that made us giddy. A massive THANK YOU to everyone who entered, we hope you all had fun and learned something new.

So without further ado, I present to you, the Winner, Runners Up and Honorable Mentions.

Check out official page with more judges notes here!

WINNER! The Museum of the Microstar.

RUST LTD and co did a marvelous job of putting together this interactive demo, it not only showcases impressive technical ability and great visuals, it also encompses a narrative, making it an all round great project. Check out more of their stuff at http://www.rustltd.com/

The Team.

RUST LTD: Anton Hand‐ Game Direction, 3D Art, Visual Effects, Adam Liszkiewicz ‐ Narrative Design, Writing, Lucas Miller ‐ Graphic Design, Writing, Luke Noonan ‐ Development, Sound Design, Writing, Narration RUST AFFILIATE: Joshua Ols ‐ Shader Development TINYCUBE STUDIO: Arthur Brussee ‐ Particle System Development

1st Runner Up – Voxel Cone Tracing.

Kurt Loeffer

2nd Runner Up – DirectX 11 Demo

Davit Naskidashvili

Honorable Mentions.

And now for a showcase of great projects that were entered.

Light submitted by Sergey Noscow

Deserted building scene. Really great environment modeling, lighting and use of HDR rendering with postprocessing effects.

Sail Ship submitted by George Notyag

The most tessellated ropes and guns you’ve ever seen on a ship! But seriously this looks great.

Happiness submitted by Maciej Gornicki

A sweet and artistically driven demo about happiness.

Interactive Water Simulation submitted by Laurens Mathot

Nice use of compute shaders for simulating water flow and buoyancy for objects.