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.