Four days down and I’m making some good progress with Unity.
I decided the best way to tackle learning Unity was to build a complete game from scratch, starting with the UI, and incorporating the plugins I purchased as I went along, to minimise the amount of work I’d have to do.
Starting on day one, I created a new project, added NGUI to it and dragged a few buttons into the scene to act as a main menu. To keep things simple, I wanted to avoid creating a different scene for each menu, and instead created all the menu panels in the one scene.
This presented a challenge because of the way Unity handles inactive objects. Once an object is disabled, it can no longer be found using Unity’s search functions. The developer has to store a pointer to the object in order to find it again, or it can’t be reactivated.
Based on my Googling, Unity developers have been complaining about this problem for many years. As I understand it, the built in functions for locating objects are considered to be very slow, so it’s recommended not to use them anyway. The workaround was to create a singleton class (also frowned upon by some, but it works) that held pointers to all of the important objects in the menu system, such as the menus themselves and specific controls on the menus.
With my global class in place, it was very easy to extend it to include user preferences such as sound or music volume settings, using the Easy Save 2 plugin.
I wanted to build localisation in from day one, so the next step was to add a language selection page to the menu and add Localizer Package. This is quite a clever solution as it uses Google Docs to store a spreadsheet that uses Google Translate to provide translations for key/value pairs in the first two columns on the sheet. Obviously, since it’s machine translation, the result aren’t always the best, but it’s better than nothing.
The easy languages to translate are Spanish, German, French, Italian and English, because they largely use the same character set. To this I added Portugese which is quite a common language online and fairly similar to the others in structure. Russian is also popular, so I created a new version of my font to include the Cyrillic character set.
Beyond these European languages, things start to get a bit more difficult. Arabic and Indian both have a basic alphabet, so they aren’t too different to the others to work with, but finding a suitable font with the characters can be difficult.
The other major online languages, Korean, Chinese and Japanese are composed of thousands of characters, and because Unity stores characters as bitmaps on mobile devices, it’s nearly impossible to translate on the fly. The recommended solution is to “bake” phrases into bitmaps and use those, instead of text. For now, I’m just going to stick with simpler languages because I don’t want to have to limit the amount of text I have in my app.
At this point, I have to say that things are going quite well. I now undersand Unity’s internal structure, I’ve successfully implemented PlayMaker, Localizer Package, Easy Save 2 and NGUI into the application, and it’s definitely saved me time. I’ve even managed to build an Android version of the app and try it out on my tablet, and it works just like it does on my Mac.
The next step is to create the actual game part of the project, which is probably going to take another five to seven days, just to get it to the functional prototype stage.
Meanwhile, Stonetrip are still keeping secrets about what’s going on with Shiva. Presumably, they are working behind the scenes to emerge from receivership and open shop in Estonia, but who knows? Unfortunately, none of the users do, and it’s all too little, too late for me. I’ve already made the switch to Unity, and there’s no looking back now.
The hard part for new ShiVa developers is getting familiar with the tool. It's very flexible and full-featured, but unless you come from a 3D programming or modelling background, its got a very steep learning curve because you may not know what to expect from it.
