The big win for this week was definitely the localization (language support/translation) effort. I knew that the sooner I got localization done, the less work it would be, because there would be less text just floating around in UI properties, in code, and in game definition files.
I hear a lot of complaints about how hard it is to do localization. For me, it seemed pretty easy, though I didn’t have concerns about localizing textures and voiceovers and other expensive assets, only text.
The basic gist of text localization is that whenever you want to show text to the player, instead of showing it directly, you look the text up in a language file using a key. The difficulty in localizing existing code comes from finding all of the places that text is presented to the user. Also, you have to make sure all text gets re-rendered in the correct language if the player switches languages in the middle of the game (or be slop about it and force the player to restart, but that’s not as nice).
Once you are looking up all of your text from a language file, then supporting new languages becomes as easy as adding a new language file to the project. To help with this process, I built a utility, cheekily named Hoshi after a linguistic specialist in the Star Trek universe. This utility keeps track of what has and has not been translated into each supported language and what needs to be re-translated based on changes. Even cooler, it can call out directly to Microsoft Translator to get a basic (though probably dodgy) translation. This at least gets a stake in the ground for each language I want to support, and hopefully I can find some real linguists to help improve these base translations. Probably a lot of the current translations are unintentionally humorous.
I’d like to eventually support all languages available in the Steam client, plus Klingon.
Unity’s font fallback support even makes supporting the native Klingon alphabet easy, as can be seen in the screenshot.
Oh, and the UI is looking a little more spiffy now. Most things have now been re-implemented in the new 4.6 UI system. (I wish they’d give that subsystem a proper name, it would make it so much easier to find info on it without tripping over info on the old UI systems.) Saving and loading of games is now working, too, and the Autosave feature represents my second foray into the black art of multithreading within Unity, employed to eliminate frame stutter when the autosave occurs. This is where my decision to have a Domain Model for all persistent game state really pays off: I can just deep-copy the game model, and threadsafely send that copy to the Autosave. Remember, multithreading in Unity is possible, you just cannot access ANY of the Unity API beyond basic structs like Vector3.
In other progress, the cockroaches have finally returned! And they brought along some friends! Right now I have cockroaches and houseflies implemented, and I plan to add mice, mosquitoes, rats, and probably one more undetermined outdoor vermin. I’m able to do much more with vermin than I had with the purely “decorative” cockroaches in Dehoarder 1. I’m actually able to turn them into a proper gameplay mechanic.
The amount of vermin in a particular room or area is determined by how messy the area has been. Vermin can only be reduced by eliminating them through a couple different means, though if the area is still messy, new vermin will appear to replace their fallen comrades. The only way to permanently eliminate vermin is to clean up as you hunt the varmints down.
Eliminating vermin can be done through a few tools. For insects, a can of insect spray will do the trick. Flies and mosquitos can be taken out with a flyswatter, and roaches, mice, and rats can be caught with specific traps. Eliminating vermin will improve the living conditions of the house, and will probably eventually contribute to some in-game events occurring.
Every day, I am finding myself more driven to deliver this game, as well as make a transition to full-time indie game development. Time will tell.