Unity going free?
The big news this week is that Unity, the “introductory” version at least, has gone free.
From my perspective, that’s both good and bad:
- Good, because I was planning on buying the Blackberry version once it becomes available
- Bad, because I purchased an iOS license for $400, a couple of days before Unity went free
Lucky for me I asked for a refund an hour after I purchased it, because I’d ended up with two separate Unity licenses, one for Android, one iOS, that couldn’t be used at the same time.
I contacted support and they cancelled the iOS license, the Account Executive approved the refund, and at the time of the announcement, the refund request had apparently been lodged with the accounts department.
It’s been nearly a week now, and I’m still waiting for my refund. Unity have said that they’d compensate anyone that purchased a license 30 days prior to it becoming free, but as I had an authorised refund pending, and I didn’t have an iOS license at the time that Unity became free, I’m expecting to get my money back without a fuss, despite the fact that I was intending to re-purchase Unity iOS once the money had appeared back in my account.
My Android license, on the other had, doesn’t qualify for compensation because I purchased a little over 30 days ago.
It would really suck if I’d purchased a Shiva license before the secret that they’d gone out of business had leaked. I’d be starting to feel like a serial victim…
Rewriting the user interface
Despite not wanting to continually rework everything as I go, I ended up rewriting the GUI tools I’d developed for my project.
I did this because I have finally adjusted to Unity’s object oriented design approach, versus the way that Shiva did it. It became apparent that it would be far more efficient (from a development point of view) to create a few small scripts and attach them directly to the menus, rather than try to handle all the menus from one shared script.
I worked through the scripts I’d written making all the variables static so that the code that accesses them would be more readable, and then I created a default Menu class which handles basics such as showing and hiding a menu, and translating the controls on it. Each menu in the project has a derived version of this class attached which handles the stuff that’s specific to that particular menu.
The end result is something that’s very easy to use and makes it quick setup a new menu.
While working on these changes, I encountered a couple of other issues:
- While the NGUI table/grid can use prefabs for row/cell items, the layout gets incredibly flaky if you try to create a prefab from a row that you’ve constructed in your scene. The problem is that when the row object is turned into a prefab, Unity inserts a UIPanel into it, which causes the grid/table to throw a fit. I kept getting caught out by this because the symptoms aren’t consistent and can include any or all of these: tweens not working properly, grid rows remaining invisible despite being active and the grid not sorting. I gave up on using a tween in the grid, it’s just not worth the trouble of manually creating all the objects in code.
- The disabled property on the NGUI UIButton component doesn’t work property if the pressed colour has the same value as the hover colour. It’s behaving like the button’s code is using the colour to detect the button status.
Currently I’m at the stage of linking the level manager to the level editor I had previously written. Once that’s done, it’ll be time to develop some levels and see how the whole thing hangs together.
The brown cube icons on image are placeholders for a edit and delete icons, when I get time to add them.