The localization of Nocturnarya took exactly one month. It was a complex project, with numerous dialogue lines and a few challenging sections, as discussed in a previous post. Some terms posed difficulties during translation, such as Blood Cartridge, Fang Sword, Bloody Spirit, Diabolical Nurse, and others. We included the option to switch between vampiress and vampire identities for narrative purposes, without any impact on gameplay (our tests confirmed that there were no bugs resulting from this feature).
Raphaela speaking in French
Submissions of the localized versions of Nocturnarya (German, French, Spanish, Dutch, Italian and Portuguese) are already underway, to our regular publishers. These localized versions will be available for Windows only, and there are no plans for a Steam release. All in all, considering both the time spent on localization and the development of the original English game, Nocturnarya stands as our largest project to date. Since Spooky Dwellers 2 was already localized in September, we can now shift our focus towards developing a new game.
Regarding this new project, we’re still discussing a few ideas. One of our goals for 2024 is creating at least one Match 3 game, that’s for sure. However, we’d like to explore other genres, if time and budget permit. We’ll likely write a post when we have clearer ideas about our next title. Stay tuned! 🙂
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.
I can’t even pinpoint what a 16 bits COM Oddity really means, but I think the idea is therein, somehow. Previously, I explained how to code a simple a “hello, world” program using the DEBUG tool that was shipped with DOS. Revisiting this obsolete knowledge was unexpectedly fun. We’ll retrieve the hexadecimal version of “hello, world” (well, “hello, world!!”) from that post:
That’s all we need for our “hello, world!!” binary. 32 bytes exactly. We can create that file bit by bit but that’d be too excessive, I think. Let’s use the echo command instead. This is the full command I entered in my Windows 10 cmd.exe prompt:
After that you’ll get a 16-bit COM, hello.com, that will display the “hello, world!!” message. Funny 🙂
What are those weird characters?
First a little explanation. We want our hello.com file to be, byte after byte, an exact representation of the hexadecimal sequence above presented. We’ll use cmd.exe commands to dump characters into the file and, if we choose our characters carefully in order to match the target hexadecimal values, we’ll end up with the exact representation we’re looking for. For instance, the first 2 bytes block, EB 13, is the “jmp 115” instruction. Then comes the newline (0D 0A), and so on. If we convert our hexadecimal to decimal, we get:
The first byte in hello.com must be EB, or 235 in decimal. In order to dump our characters from the command line, we’ll convert that decimal value to a character. I’m trying this on a Windows 10 (64-bits) machine, with cmd.exe using Code page 850 Multilingual Latin 1. In such code page, character 235 is Ù. And 19 is ‼. And, luckily, 13 is ♪ and 10 is ◙. Those two characters are especially important because they represent the carriage return and the line feed, respectively, and some shells won’t convert them to characters. However, happily, cmd.exe with my default code page will handle them as we need. To input those characters you can type the usual ALT + decimal value.
Coding “Hello world” with DEBUG will be a blunt exercise on programming futility. Or an exercise on retro, old-school coding. More than two decades ago I used to code in x86 (Intel) assembly, almost daily. I remember the masochist approach to learning the opcodes and the hardware architecture. The famous RBIL (Ralf Brown’s Interrupt List) was, back then, my favorite “reference”. First painful steps were taken and first crashes happily followed. I remember trying to code, as expected, the traditional “hello, world!”, using a strange tool included in DOS, DEBUG.COM. I wrote a post about this “hello, world” with DEBUG.COM elsewhere, and yesterday I found the time to reread it: I verified, first with awe, then with horror, and finally, with relief, that I had almost completely forgotten how to code in assembly. So I’ll revisit this here, mostly as a self-imposed disciplinary measure, an exercise on programming, specifically, an exercise on programming futility. Heck, DEBUG isn’t even available on the Windows 10 machine I’m typing this on. However, DEBUG looked pretty cool back then: it could assemble, disassemble and dump hexadecimal output. You could create little programs, or inspect programs and peek memory areas.
Specifically what I want is to build a minimal “hello, world!” program using DEBUG.COM. I don’t have any use for this, but it comes as a “relaxing” post after several weeks focused on the release of “DragonScales 3: Eternal Prophecy of Darkness” on Steam and the localization of “DragonScales 5: The Frozen Tomb”. After we execute DEBUG.COM we’ll meet a prompt with a “-” symbol. Now we can input our commands. I want to assemble, i.e., I want to type assembly language instructions. The command for that is “a”, which might be optionally followed by a memory address. By default, instructions will be placed starting from CS:0100, so I’ll use that address. Equivalently, I could type “a 0100” or “a 100” to achieve the same result.
-a
Now we have to place the data in memory. For this little program I only need the characters for “hello, world!!”. Notice I want two “!!” at the end. That’s because I want the final program to occupy exactly 32 bytes; we’ll see the reason for this later on. I’ll use the pseudo-instruction “DB” to define our string. With DB I can neatly provide the string using ASCII values, like this:
db "hello, world!!"
Those are 14 bytes. However, I want a prettier output, with a newline character before and after our string. A newline is in fact two characters: a carriage return (CR is ASCII 13) and a line feed (LF is ASCII 10). In hexadecimal, CR is 0Dh, and LF is 0Ah. OK. Now our DB would be modified to look like this:
db 0d,0a,"hello, world",0d,0a
Those are 18 bytes. We are not done yet with our data. In order to effectively print the message to the standard output I’ll recur to the function 09h of INT 21h. Check RBIL D-2109. In short, I have to place the value 09h in register AH, and DS:DX should point to the beginning of our string. The function will print every character until finding a “$” character (i.e., “$” acts as the “zero” in null-terminated C strings). ASCII value of “$” is 36, or 24 in hexadecimal. Therefore, we modify our DB instruction again:
What is Inversion of Control in Software Engineering?
Inversion of Control in Software Engineering (IoC) is essentially a strategy for decoupling software components. Basically, the purpose of IoC is to remove unnecessary dependencies (couplings) which might reduce flexibility and elegance of a system’s design. The term Inversion of Control in Software Engineering might sometimes appear applied to different design contexts. It is a term that comes from the 70s, when bottom-up parsing was considered an inversion of top-down parsing. It has roughly continued to be applied in multiple contexts. Some people think Inversion of Control in Software Engineering is a design strategy. For others, it’s a design pattern. After some articles dealing with OpenGL, in this post we will briefly discuss this topic of Software Engineering.
This post will discuss how to render a triangle with OpenGL. In the following, renderization of a triangle assumes modern OpenGL, i.e., the old, fixed-function pipeline is of no concern for us in this post, as we’ll be using OpenGL buffer objects and shaders.
A Simple Triangle
By following the tutorials in the previous posts (Setting up Eclipse CDT for OpenGL and the GLFW Example) we were able to create a minimal program displaying an empty window. Now we want to draw something with OpenGL on that window, specifically, a triangle. Why a triangle? Well, the geometric shape more frequently used to approximate surfaces is the triangle. Approximation of 3D surfaces in real-time graphics by means of simpler shapes is known as tessellation. For our tutorial purposes, a single triangle will suffice.
GPU Power
Modern GPUs are quite fast and can also have a considerable amount of dedicated memory. When rendering, we’d like for as much rendering data as possible to be read by the GPU directly from its local memory. In order to render a triangle with OpenGL we’ll need, obviously, to transfer the 3 vertices of the triangle to the GPU’s memory. However, we do NOT want our rendering to go like this:
read a vertex from our computer RAM
copy it to the GPU memory
let the GPU process that single vertex
and then repeat this whole process for the next vertex of the triangle.
Ideally, what we want is to transfer a batch of data to the GPU’s memory, copying all the triangle vertices, and then letting the GPU operate with this data directly from its local memory. In OpenGL we have the concept of Vertex Buffer Object (VBO) to represent these data placed on GPU’s memory.
The data to render the triangle in OpenGL
Normally, we think of a vertex as a point, which in 3D space leads to a representation with 3 coordinates, commonly designated by x, y and z. However, in this case I’d like to think of a vertex as a more abstract concept: a minimal data structure required to define a shape. Given a vertex, we can “link” attributes to it to further define our shape. Thereby, one of such attributes of a vertex can be its position (the “x, y, z values”.) Other attribute might be the vertex’s color. And so on. In this tutorial we will “link” two attributes to our vertices: position and color. For position we will have three coordinates, each a floating point value. If a float takes 4 bytes, then our position attribute would require 3 x 4 = 12 bytes. For the color attribute, we’d have 3 extra components, following the RGB model. Each color component would then take 4 bytes, and the color attribute would also require 12 bytes. In total, each vertex would take 24 bytes, 12 for its position attribute, and 12 for its color attribute.
Now we have to specify how to process these vertices.
Here I’ll briefly discuss a tiny GLFW example. Previously, I explained how to setup Eclipse CDT to work with OpenGL, using GLFW and GLAD. However, I instructed to copy-paste the example code on GLFW Documentation page, without providing any details. In the following I’ll present some code that you can add to the little project of our setup post, and will include GLAD initialization too.
OpenGL is an API to render 2D and 3D graphics. Remember that an API (Application Programming Interface) is an interface for interaction between components of a system. Typically, an API defines a set of functions, protocols and/or tools. I’ll skip the details about the client-server model, but OpenGL allows a client program to communicate with GPUs (Graphic Processing Units, e.g., your videocard) to achieve faster, hardware-accelerated rendering. That’s why OpenGL is a common topic in the game development scene.
OpenGL is focused on just rendering. It’s an API to write and read data from a framebuffer, and that’s it. It won’t handle user input, or sound playback, or loading a PNG image. It does not even have functions to create or close a window. We’ll need auxiliar libraries for all of that.
A minimal OpenGL window
So we want to build a minimal OpenGL application on Windows. We’ll create an empty window with an OpenGL context, using the GLFW and GLAD libraries. In the following, I assume we’re using a 64 bits version of Windows. I’ll also be relying on mingw-w64. In summary, these are our assumptions:
Windows operating system (64 bits.) Things will be a tad different for macOS and Linux users.
Eclipse CDT.
mingw-w64 to build GLFW from sources. Besides, our Eclipse CDT project will be compiled with the gcc version of mingw-w64.
GLFW and GLAD libraries.
What’s GLFW?
As told, OpenGL does not provide any facility to create a window, retrieve user input, create the OpenGL context, etc. These functionalities depend on the operating system. GLFW is a C library which provides a neat abstraction layer to handle all of this on several platforms. Notice that GLFW is focused on management of windows, OpenGL contexts, user input and time. It will not play sounds, or load images, etc.
When localizing DragonScales 3 we experienced a baffling issue with an internal tool whose purpose is simply to replace text in a group of files. Those UTF-8 encoded files contain messages loaded by the game from the very beginning. However, after running the tool, the game started crashing when reading such files. By using an old buddy, fc /B, we found out that our tool was “injecting” a few extra bytes at the start of the file: EF BB BF. In short, the tool was altering the encoding of files from UTF-8 to UTF-8 with BOM. That was the cause for the crashing, as our game expects the files to be UTF-8 encoded without BOM.
What’s this BOM, anyway? Simply put, it’s just a sequence of bytes (EF BB BF) used to signal readers about the file being UTF-8 encoded. It seems such mark might be useful in some specific contexts, with some specific programs. Not our case, so we had to remove the BOM with a little batch script like this:
for /r ".\DE\scenes" %%i in (*.*) do (
copy %%i .\tmp.txt /Y
sed -i '1s/^\xEF\xBB\xBF//' .\tmp.txt
attrib -R .\tmp.txt
move /Y .\tmp.txt %%i
)
In this snippet we remove the BOM via sed. Files are those under a fictitious directory, .\DE\scenes. Those copies and attribs help to circumvent some problems with permissions of files created by our sed version on Windows.
