Intelligent Refactoring

Hey, everyone! For this update, I thought it would be good to start talking about some of the specific things that we are doing to try and make To The Rescue! a great game. We’ve already mentioned (at least I’m pretty sure) that we are doing a whole lot of refactoring and reimagining of existing systems withing the game that we thought could use some improvement. Since TTR! is our first big project, a lot of the early implementations of mechanics and features were done with the mindset of “get it done, in whatever way you come up with first and address any problems when they happen.” Which in retrospect, was a terrible plan!

We’ve learned a lot about design, programming, and our engine along the way, which is great. But it also means that we know that in order to add the new features we want, there is a whole lot of revision to be done.

In particular I’ve been working on a few things, including entity generation and game event management (which I may write more specific future dev diaries on!). But for now, I’m going to talk about localization, and why it’s important to think about it early and often.

Now, Not Later

We always knew we wanted to translate TTR! into other languages. Of course we wanted to! It’s just an easy thing we can add on real quick to make the game more accessible to a wider audience, right? Well, as I’m sure you probably already know, as naive first-time developers we were definitely WRONG. Localizing a game is not as easy as popping terms into Google Translate.

In this game, and in a lot of games, text and symbols are used in a lot of different ways. For us it’s in menus, it describes dogs, it informs players what to do next, it alerts players to the current game state, it provides personality to the world and the characters, and more. Because of how extensive language is used in games, it would be disastrous to wait until last-minute to try and add variants because of how interconnected those things are to other game systems, for one.

Why? Well, every single item that needs to be localized to the player’s language needs to know what that language is as well as what version of text corresponds to that language. There’s a lot that needs to be handled preemptively for that to work. And that’s not to mention any little bits of code that may accidentally be language reliant, such as hard-coded strings (oof) and other procedural-generated information. So, we realized that we had to re-vamp the way we treated text everywhere that it is used in the game, which meant rebuilding several forms of data processing from the ground up.

The Right Tools for the Job

Luckily, we are far from the only ones to have this problem to solve. There are as many ways to approach this problem as there are projects trying to address it. For our workflow, we decided to look for a tool to help ease the process, and we found one! After doing a lot of tests and research, we are using a handy-dandy Unity tool called I2 Localization to make the process a bit easier.

With I2 Localization, we’re able to set up every piece of text in the game in regards to “Terms,” rather than text. Simply put, the I2 Localization tool utilizes a dictionary of “Terms,” which are keyed values containing the translation of a word, phrase, sprite, or audio clip. Instead of manually setting the strings of text to appear in each place they are relevant, Unity objects instead have a reference to this Term which can then dynamically determine which language-specific value to use!

Since we are in the midst of completely revising systems rather than making incremental changes them as needed, we were able to set up a localization workflow that looks a little something like this:

1. Enter text data in a spreadsheet with a column for each language to translate to.
2. Export spreadsheets to CSV format.
3. Import the spreadsheets into the Term Dictionary using the I2 Localization tool within Unity.
4. Ensure that text or image elements have a reference to the proper term. (For game event generation, for example, there are scriptable objects with a field for the term key that is used to change the in-game UI element with a Localize component at runtime).
5. Give player a way to set the language using in-game settings.
6. Done!

This tool has allowed us to have a streamlined process for adding new content to the game (including things like events and dog info), and importantly it also will make it simple for localizers to translate in-game elements in an easy-to-access way (it’s all on a spreadsheet! Wowza!), and adding new languages will (HOPEFULLY) be as simple as adding a new column to each spreadsheet, then re-importing them.

There are still a few in-game elements that are slightly more complex to translate than others, such as how to dynamically conjugate verbs in a sentence with different trait types. For example, we want to say a dog “has” the flu, not “is” the flu, and across languages it won’t always be as simple as replacing the term in the same place in the sentence. But this structure still gives us a great place to start from with room to handle exceptions.

Takeaways

So, the takeaways for this dev diary may seem obvious, but we really want to be honest about our process and the things we are learning, so that maybe someone in our shoes might be able to avoid having some issues.

I really don’t like the phrase “work smarter, not harder,” but you know what? I think it might apply here. If we had thought about localization much earlier in the development process, we definitely would have saved a lot of time. But, since these revisions are happening at the same time as some other major data structure changes, it all came together really nicely for a streamlined process. Planning for localization doesn’t just make localization easier but helps everything it touches work better, too! If you’re designing text entry to be easy to localize, chances are it will be easier for you to use down the line, too. At least, that’s exactly what our experience seemed to suggest!

Secondly, don’t be afraid to use existing tools and strategies for solving problems like these. I2 Localization has made what originally seemed like a daunting problem into a breeze. Might it have been more kosher to build our own localization tool? Maybe. Did it save us a boatload of time? Definitely. And right now, that makes it totally worth it.

This diary was a bit of a technical one, but hopefully someone finds it valuable to see a little bit of what we are thinking about behind the scenes while making this game. If you have any questions, or want to tell us everything we’re doing wrong (eep!), feel free to let us know. We’ll have another diary in a few weeks!

NOTE: we are not sponsored by I2 Localize, we’ve just really enjoyed using the tool and it was extremely relevant to discussing this specific game revision.

– Olivia