Archive for the ‘Android Development’ Category
One of the attendees was so kind as to grab the apk that very night and show me how it runs on some other devices. He demoed it running on the Samsung Galaxy Tab, and the Motorola Xoom. The excellent news is that the UI repositions as I’d expected. This was possibly the thing that worried me most, and I was gratified to see it went according to plan. The even better news is that the Galaxy Tab ran the demo so very incredibly smoothly. The animations were smooth as butter, and the controls were very responsive. The framerate felt almost as nice as the web player version. Furthermore, the larger screen size made the whole control scheme feel very nice and open. On my phone it can feel a little cramped, but not so on the larger screen. Performance on the Xoom seemed subjectively to be about 2/3 that of the Galaxy Tab, which is surprising given its raw statistics.
I’d like to thank Mike for letting me see the demo running on another device in-person, and if anyone else (whether you attended the meetup or not) has anything to report on how the demo runs on a device, please let me know.
I’ve had quite a busy week digging deeper into Unity 3D. As such there’s a newly updated version available here (as a web player) and here as an APK that you can install on your Android device. The updated version of the web player may not look very different apart from the inclusion of a title screen and some extra GUI text at the top, but it will definitely sound different. The outside scene is a new model set, but aside from wandering about there’s nothing to do other than admire the scenery.
The real point of differentiation here is that the same codebase that compiled the web player also compiled the APK, and the APK has an onscreen gui control system that is completely absent on the web player. Yes, the Android version has a joystick, and A/B buttons onscreen.
So given what you see in this update, you might wonder where the time has gone in this. I’ll try to break it down as best I can:
~60% of my time has been devoted to learning the various ways to make and use GUIs
~20% of my time has been spent converting unsuitable JS code into C#
~20% of my time was everything else, including working with music and sound, experimenting with different ways to access and work with data in Unity’s ecosystem, and tweaking the control scheme from one that works well only on keyboards to one that is good both on a keyboard and on a touchscreen.
Why did the GUI explorations take up so much time, you might wonder? The main reason is because laying out a 2D GUI display using a tool that is geared exclusively for 3D content presents more challenges than you might first expect. There are several built-in solutions that may or may not satisfy your needs, depending on what they are. There are solutions kindly provided by the Unity community as a whole that also may or may not meet your needs precisely. There are also plugins and extensions to choose from such as EZ GUI. So which do you choose? And why? It’s a large topic. Here are just a few of the questions you have to ask yourself:
- Will one of the standard tools be “good enough” here or do I need special functionality?
- What’s the “safe zone?” in terms of screen resolution? Can I arrange my GUI elements to occupy only that space?
- Should my GUI elements dynamically “float” to the sides of the screen if the resolution allows for it?
- Are there special performance considerations? Will the OnGUI native methods be too costly and inflexible?
Ultimately, I think my current solution could be better. I’m not accounting for screen width on my mobile version just yet, and personally don’t have a tablet on which to test at the moment. I suspect that the A and B buttons will not be positioned correctly on devices with wildly different pixel densities than my own, and the title screen will likely be too small on a tablet. As I said, currently no attempt is made to correct for screen resolutions. This is one thing I hope to account for soon.
At this point I’d like to implement some pickups and perhaps an enemy or two as well.
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.
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.