Alien Apartment Update

This is possibly the last chance I’ll have to work on the Unity 3D demo for a while, so I decided I’d make this update a good one. Here is the web playable version and here is the apk. You’ll notice a few things different between the web playable version and the APK even though they are compiled from the same source. Not all these differences are intentional. Here’s a breakdown of the differences you’l see:

  • Intentional: The apk has onscreen controls for the character
  • Unintentional: The web version shows both a health meter and a rage meter. The apk only shows health
  • Unintentional: The robot enemies in the courtyard have a solid purple helmet in the apk. In the web version you can see that the helmets are clear glass.
  • Unintentional: The player’s character in the web version has a different jump height outdoors than indoors. This was the intended effect. In the apk, the player’s jump height is locked to the very first value known. Since you start in the apartment, the jump height will be very small.

I suspect that the rage meter problem has something to do with the fact that the health / rage meters make use of the native GUI elements (which means that under the hood they’re using OnGUI, which is a shame). As of now I can’t quite explain why the robot’s helmet has lost its texture in the apk. The texture existed until Unity crashed on me and I had to restart it. After the crash, the helmet texture disappeared from the apk and the preview editor. As you can see though, it continues to exist in the web player.

As I mentioned in my previous post, there were a number of code optimizations I implemented, which gained me about 5fps on-average. If I had to take a stab at what causes most of the slowdowns it would have to be that these particular scenes are somewhat heavy in terms of mesh construction and lighting. It’s no problem at all for a desktop (at least a Windows desktop) or a modern laptop, but mobile requires a lighter touch with its models. It doesn’t help that the cameras render a great deal of the field as well.

For more information on using Unity for mobile devices, check out this presentation which shows some additional best practices as well as a particularly impressive example of how an intelligent approach to laying out a scene allows you to squeeze maximum performance out of a Unity mobile project. Do not miss the part of the video where the representative of Crecent Moon Games presents Aralon: Sword and Shadow, which showcases the incredible potential of Unity.

As for myself, I’m suitably impressed by the Unity tool. It renders the code aspect quite easy to work with, as you can program at a much higher level of abstraction than using OpenGL directly, and while the drag-and-drop relationships of the code with the on-screen assets can seem muddy if you come from a strict OOP background it’s possible to create a well-designed structure regardless. The biggest hurdle with Unity, and the one that there is no truly easy solution for, is that 3D assets such as models, animations, and textures are incredibly labor intensive to create. It’s a much bigger field with many more areas of specialization than 2D art. You may or may not have noticed, but almost all the art assets from this project are either from Unity’s own site or otherwise royalty-free. The time investment for 3D assets is the biggest reason why. This example, which constitutes my first forray into simply learning my way around the Unity tool took approximately three weeks of my time, where the only art assets I generated were the A/B buttons in the APK and the titlescreen. Were I to create my own 3D assets, this demo would not even exist in the span of three weeks.

No Comments


Unity 3D Code optimization tips

I’ve been holding off on attempting to write more optimized code in Unity 3D until I have a basic grasp on putting a project together, but I’ve had a nagging suspicion that there’s plenty of poorly optimized code floating around in the examples I’ve learned from.

Fortunately, many of the lessons learned from optimizing ActionScript 3 apply just as well to Unity. If you’re a regular reader here you’ve likely heard me harp on similar topics in the Flash world. Here are some of the most important things I’ve uncovered over the course of the day:

  • You should cache references to components whenever possible. Never call GameObject.Find() or gameObject.GetComponent() inside of an Update() method. These are very slow methods that get slower as the number of objects in your scene grows. Grab all the references you need in Start(), or add to them dynamically as you need them. This is one of the most frequently abused and broken rules in the Unity demo code, and stripping it out gave me an extra precious 5fps on my Android device.
  • The native OnGUI method may be a very convenient way to lay out a gui, but during gameplay should be avoided like the plague. It’s fine for static title screens, or scenes with little action, but even an empty OnGUI call is a nightmare for your framerate. For a detailed overview, check this link.
  • Provoking a garbage collection cycle is a kiss of death for your framerate. Try never to instantiate inside of an Update() method. Create as much as you can upfront and recycle what is practical. Object pools, and cached instances once again come to the rescue here.

No Comments


Alien Apartment Demo updates

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.

No Comments