Posts Tagged ‘iOS’

An introduction to Unity3D for Android

We’re going to take a short break from the Seven Languages updates to talk about Unity 3D, as I’m working on a short demo project and would like to chronicle some of the early highlights as well as bumps in the road.

Unity 3D is an incredible tool geared solidly towards making 3D game content. For years Unity lived in obscurity, targeting its output strictly to the largely unheard of Unity Web player, a competitor to Flash that never really took off. Unity has always been interesting, but its reach was never truly compelling until recently. What’s changed? Unity now has the ability to compile projects to native applications that target iOS and Android in much the same way as Adobe’s CS5 can create native applications for iOS and Android that run swfs using the AIR packager.

Most of what I’ve done with Unity involves mashing together various different tutorials and making them behave in new and interesting ways. This is surprisingly easy to do. What’s slightly harder is making sure it all works when you’re ready to publish to an APK file. I’ll break this down a bit and highlight some of the things that can go wrong.

Certain standard library code won’t compile on Android. This is typically going to be code in JavaScript files, as JS allows and encourages dynamic object referencing while Android an iOS does not allow it in any form no matter the language you choose. For this reason alone I’d suggest to never use JS if developing for iOS or Android. Code that doesn’t generate any immediate errors as you’re writing it may be non-compilable. One such error was easy to find and fix:

Assets/Standard Assets/Scripts/DragRigidbody.js(31,22): BCE0019: ‘isKinematic’ is not a member of ‘UnityEngine.Component’. (Filename: Assets/Standard Assets/Scripts/DragRigidbody.js Line: 31)

I found the solution to the issue here

Other errors were more insidious. One in particular was evident in the Detonator demo buried in the example project on this page.

BCE0019: ‘size’ is not a member of ‘UnityEngine.Component’.
BCE0019: ‘detail’ is not a member of ‘UnityEngine.Component’.

If you look at the relevant code in light of the restriction against dynamic coding the problem is obvious.

var offsetSize = currentDetonator.GetComponent("Detonator").size / 3;
var hitPoint = hit.point + ((Vector3.Scale(hit.normal, Vector3(offsetSize,offsetSize,offsetSize))));
var exp : GameObject = Instantiate (currentDetonator, hitPoint, Quaternion.identity);
exp.GetComponent("Detonator").detail = detailLevel;
// currentDetonator.GetComponent returns GameObject.  
// GameObject does not have a .size or a .detailLevel.
// variable.

So you’d think this could be solved by just casting the return value of GetComponent into Detonator and we’ll be fine. Unfortunately there’s an entirely different problem when you do that…

BCE0018: The name “Detonator does not denote a valid type”

But why is this? Why would it suddenly be invalid on Android but not when compiling for the web player? That has to do with the order in which scripts are compiled. This link details some of the pitfalls that can be related to script compilation order. This particular issue was a result of the fact that the JS file was compiled *before* the Detonator and had no reference to the Detonator scripts. I could solve this by re-arranging the locations of the script files, or by re-writing the JS to be C#. I opted for the latter. This solved my problems.

Another issue I ran into, that was harder to diagnose, is that in one of my scenes I’d created a terrain, as I wanted to play with the terrain painting tools. Unfortunately, every time I tried to load the scene that had the terrain my apk would crash. This is because Terrains are unsupported on Android. This means that you won’t be using any of the pretty terrain painting tools if you’re targeting mobile.

Don’t let any of these things stop you from exploring Unity, however. These have been fairly minor setbacks, and the results of a successful compile are nothing short of incredible. Unity’s particular deal with the Devil is that it gains incredible ease of content creation for performance, but depending on how you look at it Unity might just have gotten one over on Lucifer. Performance may not be up to the level of C++ but it is definitely respectable, and the tools for creating and managing projects are truly amazing.

I’ll be sure to keep you posted as this progresses.

Tags: , , ,