As Okhlos enters the last stages of development, we have to do more than finishing all the game’s content, we also have to work on some features that may not be as fun or glamorous, but are important nonetheless. And at the top of that list was something we have been postponing for quite a while. Something that many devs have described as “an unfathomable development nightmare which will haunt us until the end of our lives”[citation needed]. Something called localization.

Most people think that localizing a game is just swapping strings in one language to another. And they are right. That’s all there is to is. So we swapped some strings. It was very easy. We won and now everyone is happy. End of post. Or maybe not. Replacing text is just the start. One of the most important ones, yes, but sadly not the only one and not that simple either.

The good news is that, since we are working with Unity, we didn’t have to start from scratch. What we wanted was very simple, something that takes a spreadsheet, parse it, create a dictionary and display texts based on that dictionary. Making this ourselves wouldn’t take much time but getting an existing solution would save us not only a few hours of  development time but a lot of testing too. So we looked into a couple of localization plugins in the asset store, but soon we found out that NGUI, the UI plugin we had been using all along already a neat little localization system in place.

csv

This is how NGUI’s localization rolls.

NGUI system is nice and simple. It has a parser that reads localization keys from a comma separated file, which means you can use a google spreadsheet to store the texts in different languages. Then, it creates a dictionary that can be linked to any NGUI label or be accessed anywhere via code. Just what we needed!

Soon we started working our first officially supported language: Spanish. As you may know (or figure out by reading the horrendous word crimes we commit when Pablo isn’t around to fix them) English is not our native language, Spanish is. This meant that we could translate every text we had into Spanish with ease. We will still have to check a lot of things to make sure it comes across right in every different Spanish-speaking country (which is not an easy task by any means) but  we can do most of the work ourselves.

So texts got translated, spreadsheets were spread, CSVs were parsed and, lo and behold, we now have translated ingame texts!

What kind of sorcery is this !?

 But, as I said before. This was just the start of the ride. A long journey was ahead, with many an obstacle to face. What were those dangers we encountered, you say? Here is a list conveniently summing them up for you!

  • Really Long Words (we are looking at you, German). Another typical localization problem. A button or a text box may have enough room for any of the words the game uses for a given language, but switch to another one and it is spill-out madness. Being aware of this beforehand, we made all buttons and labels in Okhlos scalable, so if a word gets too long we can easily adjusted them.
  • Character Codes. While you are programming, living inside the dictatorial world of the compiler, it is easy to forget that there are more characters than those in the ASCII code, and many languages. Even the extended ASCII, which adds support for most romance languages, can fall short. So it is always best to use Unicode encoding when dealing with strings. And so we did
  • Fonts. So your game supports UTF encoding, with a potential for thousands of characters. But what good is all that if you can only show them in plain, old and boring Arial font? This is something we have yet to deal with. Okhlos uses mainly a pixelated font called Dalek (insert Doctor Who joke here), which is pretty neat and fits the game’s theme very well, but only supports ASCII characters. So we will have to decide whether to find a new pixelated font that has all the characters we need, or modify the current font to add the necessary characters.
  • Procedurally Generated Texts. Texts that are generated on fly can be next to impossible to translate, and we have a couple of them in the game. However, one of them is the name generator, which generates a unique name for each non-hero unit, and since all those names are in ancient Greek(ish) they don’t need to be translated. The other is the useless skill generator, which during the implementation phase was trimmed down to more of a randomizer than a generator, so all we had to do was translate each item individually and voilà.
  • Graphic Texts. We always knew we had to keep them to a minimum but there are still a few instances in which we use texts that are not rendered dynamically. Because of this, we had to make a custom script (but still using the NGUI system) to replace the images when the language changes. We still need to make a different image per language but since we have so few of them is not really an issue.
  • Lip Syncing.  Most voice effects in the game are just gibberish. And most characters don’t have mouths. So we dodged that bullet.
ImageSign

Begone, vile text , we banish thee!

This is by no means the end of it, we will have to deal with a lot more stuff once we add more languages but for the moment we say ciao!