Archive for January, 2011

Things not to do in Unity Android

Today marks my 6th day deving with Unity Android Pro, and I’m not going to lie… it’s been a very frustrating week.  I’ve got enough material to fuel four or five posts, but I’ll try to keep this one brief and hopefully help some people out.

Firstly, let me remind everyone that I was a Flash dev for the better part of a decade, and unfortunately this has permanently damaged my programming mindset. In Flash you find yourself moving objects around the stage in incremental steps… something along the lines of:

player.x += 1;

In flash this is fine.. and if you’re going to move things in Unity this kind of method works too… But that’s Unity for PC or Web… Now we’re working with Unity Android…

If you take anything away from this post, please take this. Android only cares about one thing. CPU Cycles. If you have an update loop and you’re moving something with += 1, you’re going to hate yourself.  Things will run very choppy, laggy, and freezy (depending on your phone). The most frustrating thing is when you’re testing this on your PC or Mac, it’ll work just fine! That’s because your PC and Mac process things completely differently than Android.

The tools you’ll use in Unity to save you from all this is Lerp, Slerp, and Translate. Also Mathf.Clamp, Floor, and Ceil are super important because Android will not calculate math quickly enough to keep up with your loop.  For example, say you want to rotate an object 90 degrees… well you better write that 90 degrees like Mathf.Ceil(90) otherwise your object will miss the 90 mark completely and keep spinning.

So remember kids, Lerp, Slerp, Translate and use your Mathf or you’ll be sorry…

Advertisements

Developing Unity for Android

EDIT: This article is out-dated and reflects Unity Android when it was first available in Beta. There have been vast improvements since the time of this writing.

I swear I have 10 articles in the blog saved to the “drafts folder” that I’ll end up finishing soon.  In the meantime, I’ll go ahead and post about my most recent development work: Unity on Android.

First off, this is a considerable investment and shouldn’t be taken lightly. First you have to purchase Unity 3.1 Pro: $1500. Then you have to purchase Unity Android: $1500. Then you have to pay Google to become an authorized Android Developer: $25. For those of you keeping track, I ended up spending $3025 pretty much blindly… Well, to be completely honest only the Android parts are blind… as I’m already a seasoned Unity dev on PC and Web, so I know exactly what I’m getting out of the “Pro” purchase.

I’ve been using Unity for quite some time now, and I’ve collected/written several helpful tools and what not that speed up my dev time considerably. I also love to write useful reusable physics functions (like magnets, explosions, etc) which I can then quickly put into any game I’m writing. Why am I mentioning all of this? That’s because almost all of these tools are now worthless in Android.

1. Terrain = fail.

I have a bunch of games that I think would port perfectly to Android. The first thing I did after setting up my environment (Sprint EVO 4G which took 7 hours to get working properly… but that’s for another post) was open up a Helicopter game I’ve been working on. I tried to build the game for Android and immediately I’m confronted with the error:

TerrainData’ is not supported when publishing to mobile devices.assets/new terrain.asset

A quick look in the Unity3d forums and I find that Android just can’t handle Terrain Data. My only option for creating terrain now is to build it externally and import it as a mesh… So the Terrain Toolkit I’ve been using is now worthless, which is disappointing because it’s a great tool.

2. Explosions = fail.

There’s a great tool called “Detonator” that was built for unity. It let’s you quickly and easily create awesome explosions. I had to re-write the force physics behind it because it was a bit dodgy, but out of the box it’s still a great tool. I loaded up Blast Lab and tried to build an Android version and it compiled successfully. Great! I transferred the .apk to my EVO and fired it up… only to find that the explosions absolutely kill the frame rate… I spent the next few hours dumbing down the explosions to be just a concussion wave with no glow or sparks or anything… rebuilt… same problem. As soon as I instantiate the explosion the frame rate is destroyed… back to the drawing board on explosions…

3. Controls = fail.

Unity has a really great Input manager that makes scripting controls a dream. When you’re writing your own control scripts you can just point to Input.GetAxis(“Horizontal”) and this will immediately recognize what they’re using for Left and Right. (Joystick, Keyboard arrows, A and D key, etc).  I figured that Android would function in a similar way, but alas no.  Any control scripts you’ve already written will now have to be completely re-imagined and use the Input.Touch features.  For simple things you can still do things like Input.GetMouseButtonDown(0) and it will record if they touched the screen anywhere… but that’s limited.

The worst thing about the touch controls is that there is NO WAY TO TEST THESE IN THE UNITY EDITOR! This is super frustrating. What this means is that I have to write my controls, save the project, build the project, transfer the .apk file that’s created to my EVO, install that APK via my EVO’s interface, run the game and then see if it works as expected.

So… that’s my experience with Unity Android so far. I’ve got a lot to learn, and I’m pretty invested at this point to get some games out there to try and recoup my $3025.