Enjoy.

==

The main feature will be a finished, integrated resolution messaging system; you will be able to reposition you UI elements with ease!

Stay tuned!

==

I’m very close to version 1.3, and a full release, now as well as an Asset Store submission. If you read the Change Logs you can see many of the roadmap features are already implemented in this release. The next step is beefing up the editor and adding a few more features for doing some more complex UI components.

Give it a try, and report any bugs you find!

==

As for some features:

• Complex UI Components
  • Selection Grid
  • Slider
  • Clock
  • Counter
  • Toolbar
  • Resizable Bar (Health bar, progress, etc.)
  • Radio Buttons
• Additional Primitive UI Components
  • Dynamic Text Button
  • Multi-State Sprite
  • Repeater Button
• Depth-Masked Scroll View Solution
• Multi-touch Support
• Improved Editor
• Ability to generate UI components based on your own classes
• Several bug fixes

There is probably more, but I’d rather spend time working on QuadUI rather than talking about it.

Stay tuned.

==

It was a relatively quiet release, thankfully. The reason I am thankful is mainly due to the fact that Unity 3.2 shipped that day as well, an update that broke 2 of the core features of the extension. Working fast, though, I was able to fix the problems created by Unity 3.2 and later that night version 1.2.1, a hotfix for 3.2 was released.

So where do I go from here?

The release was much more stable than I initially thought it would be (Unity 3.2 aside), as I have continued to develop content with it internally, I have not found myself making changes to the API or the Editor. Aside from a few known, non-fatal issues, I believe the product is close to an Asset Store submission. I would like to add a few more features before I get there, though.

The road map includes adding 2 new modes to the Editor, as well as some feature upgrades and additions to the API. You can expect v1.3 to ship in the very near future.

Thanks again the community again for the support.

Cheers,

==

First and foremost I just wanted to say thanks for all of the encouragement both on the blog and on Twitter, without it this would likely have become vaporware.

Well, after some holiday season radio silence I can proudly say that I will be releasing the tool for public beta early next week under the name QuadUI.

Here’s what you can expect to see:

• Scroll-able & zoom-able (up to 4x) canvas.
• Re-sizable grid with grid snapping.
• Platform-independent, integrated framework.
• Time.timeScale independent animations.

Stay tuned over the next few days as I’ll post some videos and documentation in preparation for the beta release.

Until next time,

==

In the 5 Unity games I have worked on so far, there has consistently been one job that has always been, in a best-case scenario, tedious. What I am talking about is 2D UI. The current implementation in Unity (3.1) is less than efficient when doing the 2D elements of a game. Now, I love the ability to do immediate-mode GUI, but when developing for low-end hardware and mobile that isn’t really an option. So the other out-of-the-box option is to use GUITextures, which are not only bad for memory consumption and bandwidth, but eat up those ever-so-important draw calls on our mobile hardware.

A couple other issues with how things are currently:

• No draw call batching for 2D
• Large memory bandwidth due to several uncompressed textures
• No real editor for 2D built-in.

Now there are some fantastic solutions out there for doing 2D in Unity, some of them free, some not so much. What I have seen (and used) though, are not very artist friendly, or very time-efficient for setup. I found myself punching in way too much data into 3rd party classes, which then generated my UI at runtime (On a mobile device that left me a marginal overhead around Awake and Start).

I was also forced into using programmatic animations and tweening classes (some of which were outdated by the time Unity 3 was released), which the artist half of me is never happy with. To make that side of me happy, I had to write custom adapter classes and hack my way around it just to use Unity’s Animation Tool. There went a few hours on top of all that data I was plugging in.

Also, if you’ve been working on games, you’ll know things change during development… all the time. So when things do, the last thing I want to do is go back and change values that were punched in inside of the Inspector, hit Play to test, then repeat because the numbers I punched in weren’t right. I want to open up the Scene, drag some stuff around, save, and then get on with my life.

The last problem I see is, though they work with Unity 3 just fine, they were designed during the 2.x feature set and take time doing things that 3.0 does automatically to boost performance, like batching.

So with that said, what I wanted was to create something that uses my favorite solutions for these 2D inefficiencies, and make it friendly for artists. What I came up with was a tool which allows the user to generate a 3D quad, textured from a custom imported UI texture atlas and place it directly into the scene to use Unity’s very awesome Editor the way it was intended.

Currently I have a rough feature set implemented and am testing as well as iterating on it inside of my current projects. This process insures that the product is suitable for a production environment because, well, I used it during the production of my games and it worked for me. I’d say in another week or so I should have a base alpha release for anyone wanting to try it out.

For now, here is a teaser video of it in action:

Now that you’ve seen what it is doing, I’ll take a minute to clarify exactly what I am trying to achieve.

What this is:

This is intended to speed up development of 2D UI in Unity’s Editor, without the need for 3rd party 3D Modeling software. It is meant to provide the same solution as other at-runtime orthographic quad solutions, but at authortime where all of Unity’s built-in Editor features can be used as intended.

What this isn’t:

I am not trying to reinvent the wheel. Unity’s Editor is fantastic for fast prototyping and iteration. I don’t want to, and will not build a Flash IDE-like interface when Unity already has all of the tools it needs. For instance, working in an orthographic environment with your Game view as a preview (like you saw in my video) is wysiwyg already. Unity’s Animation Tool, which is much like that of the animation tools in Flash (CS4+) and After Effects, can be easily applied to create fluid and light-weight animations for your UI. Bundle that with the built-in Animation Events and you can create awesome menus quickly and easily.

That being said, here’s some features I’m planning on implementing:

• Rulers
• Zoom (for those big textures)
• Bundled framework for making usable UI fast!
• Built-in support for Time.timeScale independent UI animations. Animate even while paused.
• Create Sprite Animations right from the Editor

As I said before, I have used (parts of) this tool in games I have worked on. As I need to achieve different things, I will undoubtedly add to it to suit my needs.

Once it hits a level of quality I am comfortable with, I will be releasing it on the Unity Asset Store, free of charge of course.

‘Til next time

==

To make the game extremely lite-weight on initial load we decided to bundle the music for each level and each level themselves separately. This resulted in 21 separate asset bundles. (2 bundles per level + the main menu’s bg music)

To make things simple for programming, a basic asset loader component was constructed and placed along side each scene’s main managing script. On initial load of main menu, the music is loaded in. The user will then be able to navigate around the main menu and eventually choose a level. Upon selecting a level, a bundle containing the level that was selected is loaded in and then the Application.LoadLevel(“levelname”) is called. This works, to an extent.

Continuously upon returning to a scene that was already visited once before I received this exception:

The assetbundle ‘file_name_here.unity3d’ can’t be loaded because another asset bundle with the same files are already loaded
UnityEngine.WWW:get_assetBundle()

Okay – so… I can’t load in this bundle because it’s already been loaded. That’s fine, I’ll just check if the bundle has been loaded before I load it. Sounds simple enough. – Famous last words.

It turns out that after scouring the docs, this is no way in the run-time API to check if an assetbundle of a certain type has been loaded already. I decided to take my case to the Unity community posting an inquisition for a solution, as well as notifying the Twitterverse with a link to my forum post. Within just a couple hours my post on the forums shot up to just shy of 80 views with not a single reply. Back to the think-tank I went.

After some thought, I decided to utilize PlayerPrefs to keep track if a bundle had been loaded.

In the real world situation I used a GameData class that serves as a gateway – but essentially the provided code below is the same thing without the filler -

When the loaded scene’s manager script calls Awake() it is logical to assume that the level’s bundle has been loaded. I make this call there:

[chsarp]

PlayerPrefs.SetInt("level"+(int)LEVELID+"loaded",1);

[/csharp]

Now checking is as simple as this:

[csharp]
if(PlayerPrefs.GetInt("level"+(int)LEVELID+"loaded") == 0)
{
DoLoad();
}
else //already downloaded
{
Application.LoadLevel("LevelName");
}

[/csharp]

There’s a final hole to fill here – and it actually is pretty easy to overlook. The thing about PlayerPrefs is that it is persistent data and therefor remains even after the application is closed. Since the asset bundles need to be reloaded each time the application is freshly started, we need to recursively move through and make sure that all the level’s corresponding PlayerPrefs properties are set back to 0 (false).

To do this, I use Time.time and check to make sure that the application is so young that the user couldn’t possibly have ran this same code twice by exiting and returning to the scene. So in the Main Menu’s manager script I used the Awake() method and ran this:

[csharp]
if(Time.time < 1)
{
//recursively set all the appropriate PlayerPrefs to 0
}

[/csharp]

This ensures that it is only going to execute at the very beginning of the application.

In any case, that was my remedy for tackling this problem. Personally I feel that there should be something in the run-time API allowing me to detect this. I can only imagine how much of a headache it would be had I been doing something with more than 10 levels.

’til next time

==