Game Localization for a Card Strategy Game

My localization practicum project this semester is completed with Easley Dunn Productions, an Indie game studio. My main task is to manage and deliver the localization for two of their most popular games. One game has already been completed and has a rough localization system in place, and the other is a remodel in progress that will require a new localization system and setup. This experience is unique as Easley Dunn Productions is a small video game company, and their employees and interns are primarily active students like me. This creates a two-folded situation, where there are few professionals in the team, but everyone is more open to suggestions. Combined with the fact that almost every other team member is a programmer and engineer, this puts me in a work environment that is different from all previous projects. This paper aims to provide an overview of the way I worked with software engineers and game developers, the challenges I faced and how they were resolved, and what I learned throughout the process.

Spurpunk in-game screenshot

The biggest challenge I encountered that lasted for quite a few months since I joined the project was the need to set up a new system. It was not just that there was no system in place, instead there was one, but one that was relatively inefficient and prone to errors. All text is extracted from the game and placed into an Excel table, where translators for each language would fill out the cells for another column or another worksheet to insert their translations. Afterward the Excel sheet with completed translation tables will be imported back into the game in Unity, where there is code to change all displayed text to the target language. The system is actually very well designed and as quick as possible for a team of software engineering students. However, it does show some weaknesses, especially for linguists. This type of action one at a time will take a long period for translators to finish, and it does not include any form of machine evaluation to eliminate the chances of human mistakes.

Crowdin editor view

I got ready to change the localization system for our game, and already had a tool in mind. I wanted to use Crowdin, as it is easy to understand for beginners, while I can create and set up preliminary machine translations API with DeepL and Microsoft Translator. However, the team was quite concerned about this change. The engineers were not interested in making the migration, and asked me if it is necessary. I discussed this with a couple of the engineers as well as my boss, trying to learn the origin of this reluctance. The conclusive finding was that software engineers are not quite willing to change a piece of existing and functional code or workflow unless there is a significant benefit for justification, as it is involved with software development and any mistake in the changes will lead to bugs and repetitive work. Knowing this, I realized that it was my duty to convince the team by making sure no significant change is needed in the code and showing a better outcome for my system. I worked with Crowdin input and output files to make sure that it is compatible with our excel sheet format, as my goal was to deliver the exact same file back into the game so that engineers would not have to change any code, and only change the workflow for interaction with translators. I then reached out to our Japanese and Russian translators to make a demo for the tool, as these two are our upcoming language addition goals. I asked them to give the Crowdin project a try, and created a guide for the usage and functionalities of the platform. Once they completed most of their translation work, I delivered the resulting Excel sheet identical to what the team originally used, as well as some positive feedback. Eventually, I was able to convince the team to adopt my translation workflow using the standard procedures and tools learned at MIIS. A key takeaway for me here is that software engineers are usually not subjective. Just like the programs they write, it is obvious to know if something works or not based on the evidence and results, and a successful demo is much more valuable and convincing than any words or arguments.

Another challenge that I faced came towards my technical skills. The game is written in Unity with the language C#. There are also a large number of script files controlling the behavior of game items and logic, which I needed to modify when adding my localization products. When importing translated dialogue files back into the game, especially many versions from all our target languages, I need to change some file pathing references in the code. Naturally, the language selection buttons will also need to be updated to include the new languages and change the display text accordingly. This behavior is also controlled by the scripts tied to the buttons. A final piece of code that I needed to change was the file that controlled the properties of text boxes, such as dimensions, alignment, font, text size, and color. Since different languages may differ in length to convey the same meaning in text, some text boxes had to be adjusted to avoid display bugs.

The trouble I had was not having enough context or knowledge about coding. I have never worked with a large project with dozens of code files that reference each other, and it was hard to follow the function calls correctly. It also took me a long time to identify which line of code controls what in the game interface. Since this first game is in maintenance mode, most engineers did not have an up-to-date context on its code, and could not spare too much time to investigate with me either. Fortunately, as I have been quite interested in practicing localization engineering work, I took and paid close attention to most of our available programming classes. The classes were relatively basic, but does provide me a very solid foundation to read and understand code. I slowly got through the code and identified the scripts that I needed to use and change, by exploring the inspector of relevant UI elements and checking for their attachments, and searching for keywords after opening the directory in Visual Studio. Finally, working with an engineer for a brief moment, I successfully added the necessary functionalities and enabled the new localized languages. The pain in this process was the headache and time consumption from struggling with the code, as I still did not have enough technical skills to do it smoothly.

My biggest achievements this semester for localization practicum at Easley Dunn Productions include setting up the Crowdin localization system for the project and convincing the team to use it, performing Japanese and Russian translations of in-game text with the respective translators, and adding the products into the game and making them accessible to players. There are three key ideas that I learned for the most effective cooperation with software engineers: Set up a good system since they are usually not too aware of work from our side; Speak with evidence and a functional prototype; And learn as much programming skills as possible throughout my career to add another available “language” to my pool. For the second half of the practicum in the next semester, I will be continuing to work at Easley Dunn Productions, and my goal is to build a even better localization schema from scratch for our new game Robot Race, and keep delivering successful localization integration.

Our new game: Robot Race