Our current project is the localization of Nocturnarya Collector’s Edition. As usual, our target languages are: German, French, Dutch, Spanish, Portuguese and Italian. It’ll be a Windows-only release. This localization is a daunting task, which comprises a few intricate parts:
The Story: Nocturnarya’s story is a bit long, as the game builds a particular vampire lore, with adventure, scheming, military invaders, treasons and loyalty. The game portrays several characters of which the most important is you, the player. At its core, it’s a battle between you and Grysmore, the boss of the human invaders.
The vampire and the vampiress: In the original English game, you can choose how you want to be referred to as the story progresses: as a vampire, a vampiress, or a rockstar renegade. Localizing this is tricky, because of articles and genre-specific details in all the target languages. We’ll be removing the rockstar renegade option, and will do our best to keep the vampire and vampiress options. However, if it proves to be too error-prone we’ll just scrap this option altogether.
The Village: The game has a section that allows you to build a 3D village for your vampire tribe. However, the help window and the tutorials amount to a lot of text to translate.
The Match 3 levels: This includes all the help texts, instructions and user interface of the Match 3 levels.
Collector’s Edition goodies: Last but not least, we’ll have to translate the extra stories and minigames offered as Collector’s Edition exclusive bonuses.
If everything goes smoothly, this localization should be completed by the end of this month.
Localization in Unity with No Such Localization is easy and truly convenient. We used that package to localize our game 10th Corpse into several languages, and it was a straightforward process. When the time came to localize our game, we evaluated the localization options available for Unity. The canon choice, so to speak, is Unity’s own Localization package which, however, required us to update our project and also, at that time, did not have an expedited installation (it had to be installed manually.) In the long run, Unity’s Localization package is likely to become the standard and the first choice of Unity developers, but for now it’s still at the preview stage.
For 10th Corpse, however, No Such Localization was a wise choice. In fact, No Such Localization offers much more than what we really needed to localize our game, which only required localization of strings. No images and no audio had to be localized in 10th Corpse, but if your project needs that, No Such Localization easily allows for it.
What is No Such Localization?
It’s a localization package for Unity, and it comes in 2 versions: Lite and Pro. Both versions are available in the Unity Asset Store. The Pro version (paid) offers even more features, such as support for Right-To-Left (RTL) languages (Hebrew, etc.), automatic variable replacement, and translation source classes for JSON and CSV files (more about this in a while.) Even the Lite version is awesome and, as told above, it offers much more than what our game’s localization required. No Such Localization integrates naturally with the Unity editor, and requires no coding unless you want to extend its functionality. And that’s the beauty of the package: its architecture, which makes it a breeze understanding and extending its functionality.
How to work with No Such Localization?
Let’s first understand the architecture of No Such Localization. The official documentantion is here and is very good. You’ll work with 3 classes of components. The most important of these components is the LocalizationService. It’s the core of your localization, and you should have a single instance in your scenes (ideally, use DontDestroyOnLoad to have single, persistent LocalizationService object if your project comprises multiple scenes.) Just create an empty object and append a LocalizationService component. Now, in the Locales list, add the languages you want to support, e.g., English and German. There are a few attributes, but you’ll be mostly changing Current Locale. Once you complete the localization process, modifying this Current Locale will immediately switch your project’s content to the localized strings and assets corresponding to such language.
So, main component: LocalizationService. We have yet to work with other two components: ComponentLocalizer and BaseTranslationSource. LocalizationService is our core, our hub, the ruler of all the localization of your game. However, it needs to know what scene’s objects (strictly speaking, components) it has to localize, and it also needs to know where it’s going to find the content with which it will localize those objects. For instance, let’s suppose you have a Text object (again, strictly speaking, an object with a Text component) displaying a “Welcome” string. The LocalizationService can automatically localize that object, but it needs to know that such object has to be localized (that’s the responsibility of ComponentLocalizer), and it needs to know what content it will use to localize the object (that’s the responsibility of BaseTranslationSource.) You can subclass both ComponentLocalizer and BaseTranslationSource to adapt them to the requirements of your project, but No Such Localization comes with classes that will suffice for basic requirements. For instance, the package includes a TextLocalizer component.
In continuation of our example, let’s add a TextLocalizer to our Text object having the “Welcome” string. You’ll notice that the TextLocalizer component has a Phrase attribute. When localizing, you’ll have to remove string literals (e.g., “Welcome”) from your components and replace them with unique IDs. The localization components will used those unique IDs to identify the content. Place unique IDs in that Phrase attribute, e.g., welcome_text. Now we need a Translation Source with an entry for that unique ID, welcome_text. The package comes with a very basic translation source, StandaloneTranslationSource which we can recur to for a simple use case like this. Create another object, add a StandaloneTranslationSource component, and edit its Translation List attribute to add welcome_text as an entry of such list, with translations for Locale English and Locale German.
Translation List of a Standalone Translation Source
That’s all. All the components of No Such Localization will connect among them automatically, and if you go back to your LocalizationService component and change the Current Locale you’ll see your text component modifying its content accordingly. It’s like magic!
Of course, if your project is medium or large sized, working with the StandaloneTranslationSource can be tiresome and error-prone. You might want to read your content from a file (the Pro version of this component comes with translation sources for JSON and CSV files.) The wonderful thing about architecture of No Such Localization is that you can extend it as you wish (we created our own Translation Source class for 10th Corpse.) And you can also create your own ComponentLocalizer for your specialized widgets, for example. You can localize text, images, sound, etc. Further information in the official documentation. An excellent tool for localizing your Unity project!
I’m using the fantastic DOTween engine for creating and managing tweens on Unity, but the latest version cannot handle a specific case: how to append a tween to a sequence which is already playing? First a bit of background. After completing DragonScales 6, we’re focusing on a new game, a casual Match 3 with a traditional tile swapping gameplay. Our DragonScales games are created with Java and LibGDX. However, this new project will be built on Unity with C#, and we make intensive use of tweens.
In particular, we want the players to be able to keep playing and swapping tiles even if the game is simultaneously processing matches in other areas of the board. When a match is detected, tiles above those matched tiles will fall. We’re implementing this falling path with position tweens, via DOTween. However, new matches in other areas might alter the path of tiles which are already falling. In order to handle such cases we’ll be appending new tweens to the tweens which are already executing. The problem is that sequences in the current version of DOTween must be entirelly defined beforehand, which clearly does not suit our requirements.
public class TweenChain
{
public Queue<Sequence> SequenceQueue = new Queue<Sequence>();
public TweenChain()
{
// empty
}
public void AddAndPlay(Tween tween)
{
// Create a paused DOTween sequence to "wrap" our tween
var sequence = DG.Tweening.DOTween.Sequence();
sequence.Pause();
// "Wrap" the tween
sequence.Append(tween);
// Add tween to queue
SequenceQueue.Enqueue(sequence);
// If this is the only tween in queue, play it immediately
if (SequenceQueue.Count == 1)
{
SequenceQueue.Peek().Play();
}
// When the tween finishes, we'll evaluate the queue
sequence.OnComplete(OnComplete);
}
private void OnComplete()
{
// Tween completed. Remove it.
SequenceQueue.Dequeue();
// Other tweens awaiting?
if (SequenceQueue.Count > 0)
{
// Play next tween in queue
SequenceQueue.Peek().Play();
}
}
public bool IsRunning()
{
// Are tweens being processed?
return (SequenceQueue.Count() > 0);
}
public void Destroy()
{
// Goodbye. Thanks for your hard work.
foreach (var sequence in SequenceQueue)
{
sequence.Kill();
}
SequenceQueue.Clear();
}
}
Hopefully future versions of DOTween will handle this use case in a straightforward fashion. We needed to append a tween to a sequence in execution and, for the time being, this class solves our requirement.
