“My Opportunity To Transform From A Localization Engineer Into A Unity Developer” – Yaroslav Rudenko’s experience at Plarium

This text is a translation of an article originally published on GameDev DOU.

My name is Yaroslav, and I’ve been a Unity Developer at Plarium for the past two and a half years. But my journey here started back in 2016, when I joined as a Localization Specialist.

In this article, I’ll share my story of how I switched to a technical specialization; how I made decisions, what other options I considered, what steps I took, and what difficulties I overcame. I believe my experience will be of interest to anyone in Unity development, but especially useful for those who want to move into the field like I did, as well as to those who are starting out in their careers as developers.

My background in Plarium’s Localization Department

I am a translator by training. The languages I learnt are English and French. By my third year at university, I had already started working in the field, and over the course of 12 years of professional activity I worked in various roles: copywriter, translator, editor, and localization specialist. I also have a small amount of experience working as an interpreter. My portfolio is quite diverse, and I specialized in game and technology content, as well as game localization. Outside of Plarium, I found time to translate several mobile games, and worked on the localization of the Ukrainian version of the App Store. Before joining Plarium, I worked for several years as a project manager in various outsourcing companies, and also tried my hand as an English teacher.

At Plarium I started as a freelancer, translating articles about game design and development that the company published on social networks. When I joined the staff, I also started working with internal documentation and game texts. For the five years I was in the Localization Department, I was lucky enough to participate in translating most of the games made by our Ukrainian studios - at least 11 titles. I also translated game-related content: news, articles, posts on social networks, promotional materials, and video subtitles. Sometimes I helped prepare texts for dubbing. In addition to that, I was engaged in writing documentation for the department, and helped a little with the onboarding of newcomers. Sometimes I tested and managed localization. During my last few years in the department, I mainly worked on RAID: Shadow Legends and Mech Arena, both flagship titles for the company.

Plarium has a rather atypical approach to working with texts and localization, even for a product company. First of all, we have a small staff of native English-speaking writers. Before the transition to remote work in 2020, they all went to the office every day. Secondly, we localize part of the languages with the help of full-time employees, and give the majority to freelancers, with whom we work directly, and not through intermediaries. This approach guarantees better quality control, allows you to process larger volumes of text, and is sometimes more flexible.

An unexpected side effect of our process is that we have a considerable concentration of talented and intelligent people, writers, translators, and editors, who are in direct contact every day and create an atmosphere where you want to grow and develop. My colleagues and I read books, played games, took courses, participated in online and offline translation conferences, and had many discussions about texts. I still like to reminisce about those times, because everyone in the team was really into their work.

“I’ve been curious about different aspects of gamedev since the moment I started working in the company”

As a freelance and later full-time translator, I took on articles about 2D and 3D art, programming, game design, level design, sound design, and more. I had no prior knowledge of any of these fields. Therefore, it was necessary to understand as much as possible.

It is typical for translators to master unfamiliar topics and concepts. At university, in the Department of Translation Theory and Practice, we were trained to work with "inconvenient" texts such as instructions, recipes, legal documents, and so on. I assume that those who have completed at least four years of study and eventually embark on the professional path of a translator, have a tendency to be interested in a wider range of topics than average, and have a knack for understanding them with a sense of satisfaction.

That's why when I started working at Plarium, not only did I dive into every topic I wrote about, I did it with great enthusiasm. I read articles, watched videos, consulted company specialists, and sometimes asked someone to proofread and comment on certain translations. For me, as a mediocre player of games and a non-technical specialist, I saw gamedev from a different perspective. It turned out to be a complex and interesting field, and just like every other industry, it’s a rabbit hole into which you can fall for decades. I wanted to dive into some topics even more deeply than my duties as a translator required, and I hoped that one day such an opportunity would arise.

Three years had passed since I joined Plarium. It was 2020 and the whole world was plunged into quarantine. For the first six months, like many, I played games, watched TV shows, and read books. At some point I came across “Blood, Sweat, and Pixels” by Jason Schreier. After reading it, I remembered how interesting it was when I started working at Plarium to translate stuff about the technical side of game development, and I felt inspired to take courses. It turned out that I was interested in many topics, from 2D art and 3D sculpting to sound and game design. What can I say, even programming. I wanted to understand how games are created. Maybe even try to do something myself. First, I took a relatively long course in game design, then devoted several months to 2D art. After that, a big "course" in programming began, which, instead of six months (as I originally planned), is still going strong.

“It’s better to start from C# and devote a couple of months to it, or as I call it, ‘touching base with Unity’”

The vast majority of non-programmers who work in IT contemplate, in one way or another, taking on the role of programmer. Before I eventually found the inspiration to follow that path, I also had thought about it, but I did not find the motivation required to overcome all the difficulties of becoming one. At first, I signed up for a course on Android development, but dropped out in the third class. It was difficult and uninteresting. A few years later, I took several online courses on HTML and CSS website design. I tried to learn JavaScript, but it didn't work either.

Curiosity arose a little later, when I read the book “Code: The Hidden Language of Computer Hardware and Software” by Charles Petzold. It was then that I first understood how and why digital data was converted into zeros and ones, what the first programming languages ​​were, how they worked, and much more. Even then, it wasn’t until my third attempt at programming that it seemed like things would work out. And, well, my third time did indeed come.

This time, the course I chose primarily taught me how to work in Unity. Students were expected to either already know C# or learn it in parallel. I will say right away that this was a bad idea.

It's better to start with C#, spend a few months on it, then move on to Unity. Otherwise, it will be the same as it was for me at first: chaotic and unclear.

Nonetheless, I was able to settle in. There was no need to code the first few classes, we just dealt with the capabilities of the engine, and looked at some educational projects from Unity. I naively assumed that I would not be intimidated by complex software, because I knew a little about Photoshop, Illustrator, FL Studio, etc. Of course, game engines are a separate category of programs.

One of my first Unity tasks: to create a scene with a skybox, terrain, trees, and water

One of my first Unity tasks: to create a scene with a skybox, terrain, and buildings of your choice

The course I took consisted of 20 lessons and lasted approximately 10 weeks. At the end, each student was expected to have at least three projects in their portfolio: a 3D shooter, a 2D platformer, and a puzzle game built purely on UI. We consistently worked on projects, improving them as we learnt certain topics. We studied physics and colliders and added them to the project. Then we learned animation, and also added it. In each lesson, students were given a bit of written code and asked to finish it according to the topic. This is a cool approach, because it's easier for beginners - who don't know code conventions or how to solve basic problems - to work with something than to write from scratch.

Here’s what my first projects - the 3D shooter and 2D platformer - looked like

I paid a lot of attention to the visual part of the game: fonts, color schemes, effects, animations, sprites, and other assets. For the most part, the resources for the shooter were free, but I made dozens (maybe even hundreds) of visual fixes so that everything was pleasing to me, first and foremost. It was never tiring. In the case of the platformer, I spared no expense and bought a set of assets from the Unity Asset Store to build the level, as well as sets of sprites for the champion and enemies, and even a parallax background. I spent a long time adjusting animations, in particular for game windows. I drew some sprites myself.

Why? Well, first, a visually attractive game is more pleasant to work with. Secondly, I knew that someday I would like to show the game publicly. It needed to be presentable and minimally complete. And while the total cost of assets did not exceed $30, I’m convinced that the effect I achieved was worth much more, and it did not go unnoticed in subsequent interviews. Here's a comparison of my game before and after buying assets:

How you do educational projects may well indicate to an employer your general approach to work. Therefore, I do not advise taking them lightly.

In general, studying was interesting but didn’t come without its challenges. The course took up a lot of free time, but still I needed more. I didn't complete it the first time around and joined the next group. I didn't finish with them either. The main reason for my slow progress compared to others was that they already had fundamental programming knowledge that I had to catch up on. Of course, I did catch up.

Nonetheless, learning C# alongside Unity meant having to juggle two areas of study at the same time. This was tough, especially at that time when there was no ChatGPT to turn to for help, and, given the specific nature of the course, I couldn’t simply use Google to search for answers in online forums.

At times I have to admit I felt demotivated, but my natural curiosity and interest in the subject carried me through. Ultimately, I spent 250 hours on the course and completed a number of projects, all of which was to stand me in good stead for moving forward with my career transition.

I also made some pleasant, unexpected discoveries during this period. I realized that there is a lot more creativity in writing code than it might seem at first - and that was very gratifying.

“Writing code is in many ways similar to writing texts. As one idea can be expressed in a hundred ways in writing, the same logic can be applied to code in many ways: more or less compact, more or less clear, more or less elegant.”

Unity Developer Internship at Plarium

Soon after I started out on the course, I realized that being a developer is more complex than I had thought. I suppose all the promises one sees in ads of becoming "a programmer in three months" crept into my subconscious. According to my original plan, six months should have been enough to grasp the basics and, for example, participate in Game Jams or work on simple pet projects.

In fact, after six months, I still felt far away from my goals. I remembered my foreign language training and how It felt similar to that: you know some words and rules, but you can’t connect them into a simple text. Still, I was giving it my all by spending extra time after work and at weekends reading books and watching YouTube videos on top of studying the course materials.

At the same time, I learned that Plarium was announcing an internship for a C# developer, and I realized this was my big opportunity. Until then I had been doing the course for my own interest, but now I saw that it could lead to a new career. I felt excitement and curiosity to delve deeper into the topic. I figured that I had nothing to lose, and put in an application.

Although the internship was designed for external candidates, Plarium was supportive of my aspirations, and invited me to an interview. I had a hard time with the technical questions, but the projects I had worked on during the course came in handy. I showed both of my games, and then some code. I answered a few questions about some parts of the code and features of configuring projects in Unity. Since I didn't write the code in full, I was honest about that.

Although it was clear that I had made a positive impression, I wasn’t chosen for the internship on that occasion. But the company encouraged me to keep going, and provided lots of constructive feedback including some recommended reading, namely, “CLR via C#” by Richter, “Pro C# 5.0 and the .NET 4.5 Framework” by Troelsen, as well as some Microsoft documentation. I did the work, came back for another interview two weeks later, and was hired.

The internship lasted approximately 8 weeks and took place online. Together with other interns, I attended lectures and completed tasks that ranged from programming problems like "implement a snake traversal of a 2D array" or "write your own implementation of a singly linked list" to small game projects like tic-tac-toe.

There were a little more than a dozen people in the group. Most were university students in the latter years of programs in technical specializations. For them, such tasks were nothing unusual, and they would have done them before during tests as part of their study courses. But for me they were totally new experiences, and I often wasn’t familiar with concepts until they appeared in a task.

Even with the knowledge I had gained on the course I took prior to the internship, I had a lot to learn, so I gave it my all. In total, we learned about twenty topics and completed approximately the same number of tasks of varying complexity. Throughout the internship, we took tests regularly, once every one or two weeks. September, which was the peak of internship activity, turned out to be the most difficult time for me. In total, I spent no less than 250 hours working and studying on the internship, my all-time record. This resulted in the final test showing that I had the most progress out of all the interns, relative to my initial level of knowledge.

Then interviews with the teams at Plarium began. Theoretically, work could be offered to all interns, because at that time the demand for developers was high. We were recruited in three departments, by which I mean, the most promising of us had a chance to get to three interviews.

I wasn't too worried, because if I wasn’t offered a role, I would simply continue to work in the Localization Department. That was something else I valued a lot from Plarium: their support in my ambitions as a developer, but with the security of knowing I could continue in my current position if things didn’t work out.

My managers advised me to apply to work on our flagship dark fantasy RPG game RAID: Shadow Legends. At that time, the game had been in production for several years, the core part of the code had been written, and the team had a lot of experience in onboarding newcomers. In addition, a new team was recently allocated to the project, and a new Team Lead was appointed, who, as it turned out, was full of enthusiasm to mentor me. I asked if my interview to join the team could be delayed so that I would have more time to prepare. Thankfully, the hiring team were happy to accommodate the request, and I was given a few more weeks. In the end, the interview went well and I was invited for a trial period.

“I still remember the first few bugs I got to work on and the joy I felt when I fixed them”

The onboarding plan was thoroughly thought through. It consisted of two parts: a theoretical one, and a practical one. Each part included dozens of items. At first, novices like me had to familiarize themselves with the array of project documents. That could include both general information about the game, and tutorials on deploying the repository and configuring the editor.

Then there was an opportunity to read a series of instructions directly related to adding one functionality or another to the RAID project. After finishing, it was necessary to perform several tasks and commit them to the test branch. My strength was that I knew the functionality of the game very well from the player's side, so I could fully focus on learning the code.

As it turned out, learning C# and Unity is not as difficult as understanding a large project with a complex architecture and a branching class hierarchy. That was news to me. The training projects I'd encountered before were usually limited to a dozen or so scripts. But here, there were thousands of scripts and millions of lines of code. And client-server architecture. And many auxiliary modules and specific tools that were actively used in the work.

Fortunately, my Team Lead was very understanding and patiently answered questions, helped with issues, looked at and commented on my code, and shared tips day after day. When you're new, every small achievement is as motivating as every failure is depressing. That’s why in the first stages it is more important than ever to receive tasks corresponding to your level, but still getting progressively more difficult. That was the case with me, and I am very grateful for that. I still remember the first few bugs I got to work on and the joy I felt when I fixed them.

How it feels to become a junior again

It was a bit challenging to find myself back in the position of someone needing a bit more guidance than usual. This is especially acute if you consider that in my previous position in the Localization Department, that stage had long since passed.

If you, like me in 2021, are trying to make a career transition, I can tell you this: technical skills are definitely most important, but they are not the deciding factor, because in the interview - and later in the trial period - a whole set of things is taken into consideration.

Your motivation and desire to grow play a significant role. And soft skills are also very important: at least the ability to communicate constructively and in a friendly manner, the ability to explain an opinion at different levels of complexity.

This will help communicate ideas to all parties involved in the development, regardless of their technical background. Such skills are especially relevant now that everyone is working remotely and therefore has to rely even more on text as their primary method of communication.

It is also important to be able to use already existing experience in a new job. If you are also someone who switches roles, then you have knowledge from a previous role.

The relevance of previous knowledge will vary of course, but it may well provide some advantage. In my case, it would seem that knowledge of languages ​​and the ability to write texts do not matter much. But together with understanding the project from a localization perspective, and taking into account my newly acquired programming skills, it all helped form the necessary expertise to optimize the localization pipeline a bit. I will provide some detail on this point.

At the company we have our own localization tool that we use with all our games. It covers 100% of our needs, but in some usage scenarios it is limited and poses issues for translators. For example, we want to add a notification to the game that would tell the player that they don’t have enough game resources to perform a particular action. The text can look like this:

You will need {0} more coins to upgrade your weapon

In this case, {0} acts as a variable, in the game it will be replaced with the needed number: 5, 100, 223, etc. The difficulty is that we did not implement a dynamic change in the form of the word that follows the variable (here it is the word "coin"). Accordingly, this line reads properly only with some numbers, and cannot be used correctly with others. Our translators knew this and were forced to adapt by writing something like:

The number of coins necessary to upgrade your weapon is: {0}.

This is an example of poorly written text. Back when I was in localization, my colleagues and I discussed this limitation. In my new role, I was able to write a small improvement for the localization tool that allows you to dynamically change the form of words according to the number, taking into account the specifics of each language. For example, in English noun-number agreement changes as shown in the phrases below. The code I wrote automated this process for all the different languages we localized into, some of which have several options when it comes to dealing with plural nouns.

You will need 1 coin to upgrade your weapon.

You will need 22 coins to upgrade your weapon.

You will need 55 coins to upgrade your weapon.

It was an interesting task through which I gained valuable experience, approval from colleagues, and a lot of inspiration for further work. And all because I saw a way to apply previous knowledge in my new line of work. If you look for opportunities, give them an honest try, and systematically make an effort, then progress will definitely come. And sooner or later you'll grow into the title of “senior”.

My plans and dreams for the future. How I’m going to improve my knowledge

Reflecting on the events of the first months, it's hard not to wonder how things turned out. It really happens to me sometimes: at first I just want to take up running, but some time passes and on the wave of excitement I think about running a marathon. Something similar happened with work.

Of course, there were some lucky coincidences, which may not be the case for you.

But in any case, it is important to look for opportunities and not be afraid to ask for what you want: if I had not asked about the internship in the beginning, it is quite likely that none of this would have happened. And, of course, you have to be ready to put in a lot of effort at work.

For comparison, since the beginning of 2021, I have devoted more than 4,000 hours to development in one form or another.

Now, fortunately, I feel confident enough in the role, although the need to expand and deepen my knowledge has not disappeared. I now work on a lot of updates and even more bugs. Several times I have been appointed responsible for the implementation of certain updates (we call this “feature leading”), and each time it was a very valuable experience.

Together with my colleagues, we twice participated in Game Jams held by Plarium, and in both cases we managed to show good results. During the Jam you need to create a game from scratch in two days. The theme for the Jam is announced a few hours before it starts.

Game Jams are a great crash test for professional and personal qualities.

You code a lot and sleep very little. And as a result, you get a ready-made project that would otherwise be impossible to create in such a short period of time. And it's fun.

The game we made at the sixth Plarium Game Jam (2024)

Horizontal development remains part of my future plans, as does taking more courses, and reading more books. I plan to study Unity more thoroughly and improve my knowledge of mathematics. I want to practice by creating more small games. In addition, I would really like to go into higher education in computer science, so I am looking at some master's programs.

What I recommend to those who want to try their hand at Unity

• You need a knowledge base. Choose one programming language and devote at least half a year to it. Take some reputable courses and read at least a few reputable books. Among YouTube channels, I would single out Brackeys, CodeMonkey, Jason Weiman. Speaking of courses, I recommend looking for something highly rated on Udemy, edX, or Coursera.
• Learn other programming languages, preferably low-level ones. After C# I really liked the C language. Working with it, I learned a lot, in particular, about memory management. In this regard, I recommend CS50's Introduction to Computer Science course.
• Don’t spread yourself too thin. There are many educational materials, and it is very easy to get lost. If you have started a course or a book but you feel it’s not working for you, it’s better to stick with it to get whatever closure you can, then leave it and switch to something else.
• You won’t grasp everything at the first try. And that’s ok. If you can't understand something, see explanations in alternative sources. But remember the previous point.
• Too much theory is sometimes harmful. Understanding some theoretical aspects comes only with practice. Take just as much material as you need to get started, and return to theory after you've had plenty of practice.
• You lose knowledge fast, especially at the beginning. Study every day, preferably for at least 1-2 hours.
• Use AI as a mentor, not a cheat sheet. You must be able to code and understand how this or that thing works. Turn to AI to close knowledge gaps. Ask it to explain unclear concepts in simple words or based on analogies. But always remember that it can be wrong.
• Look for internship opportunities. This will help to quickly get into a commercial project, because interns have lower job requirements than juniors.
• Participate in Game Jams. This is a good way to make your own project for your portfolio.

Thank you for your reading - I wish you the best of luck in your studies and work!