We haven’t done a lot of UI work in a while, but now that shops can finally be selected it seemed like a good time to start with the shop info window.

What we have here so far is the product settings tab, listing all the products and their required ingredients (which need to be delivered to the shop). For some ingredients you can tweak how much of it goes into the product, so you have a bit of an influence on how many delivery crates need to be hauled around and the production costs. Guests might not be willing to pay as much/are less satisfied with lower quality products though.
Most ingredients have a status effect on the consumer (for example, coffee reduces tiredness a bit), so you might not want to be too stingy with those.
Adjusting the ingredient amounts should not really be required in the end as that could easily become tedious, but it’s something you can do if you want to.

The costs in the screenshot above are placeholders. We’ll have to do a big balancing pass someday and assign some proper values.

The tunnels from last week received their art and work for other coasters now too:

They’re just simple concrete tubes, but that’s what a lot of real coasters use. We might add other types of tunnels later - for now though I’m pretty satisfied with these.

Working on the coasters wasn’t really planned for this month, but after the work on tunnels I felt like it and the result is that corkscrews can be built diagonally now:

Same for regular hills:

Naturally, diagonal elements are a bit longer and thus have a slightly different shape, but that’s the trade-off for keeping everything properly aligned.

Here’s a comparison showing the shape difference of diagonal hills (orange) and regular ones (blue):

I was told that it would be a good idea to allow building brakes on flat slopes, so that’s possible now:

I think it’s mostly useful for accelerating a train out of a block brake a little bit quicker.
The drive tires and brakes received some simple animations.

We’ve added a follow camera mode for guests:

More things than usual that we did this week were possible to show on a screenshot/gif and interesting enough to show here, so this got a bit longer :)
Too bad not every week is like this!

We quickly noticed a problem with the text boxes from last weeks activity logs - if you had many activities close to each other or zoomed out the boxes would overlap and you couldn’t read a thing.

It seemed like a good idea to automatically space them out to not overlap anymore, so we tried a couple different methods…

…but that didn’t work too well. And even if it did work all these boxes would really block your view.

In the end, the most simple solution worked the best:

As you already know from the previous blog entry and can see here we also worked on adding support for different languages :)
It’s pointless to actually translate things before they’re final but since there’s slowly more text being added to the game it’s good to have this working. One thing less to worry about!

People received names this week. We’re using these lists from the US Census Bureau that handily also contain data on how frequently the names occur. We’re using the peoples names as seed for their appearance and characteristics, so “John Smith” will always look and behave the same. It’s a bit silly and probably nothing you’d have noticed, but I like the thought that these people are all unique somehow.
Speaking of translations, I guess we’ll have to get similar lists for other countries.

You guys convinced Garret to create a raptor entertainer during this weeks stream, and here he is:

He still needs animations before we can properly implement him though.

Here’s a timelapse of the livestream:

March

Unity 5 is getting close to release. It’s a huge update of the engine we’re using with many exciting new features that should make some things easier for us. We planned to switch to Unity 5 from the very beginning and think the time has finally come to do so next month! It should go fairly smooth but we’ll see.

February was tech-focused, so for March we mostly want to take care of polishing and tying up some loose ends.

Unity provides you with pretty much all the tools you need for creating a game - one really handy feature that’s unfortunately missing though is inbuilt support for doing translations into different languages.

It wasn’t too complicated to add it myself in the end, but since I couldn’t really find any articles on this topic I thought I’d do a quick write-up of how I approached it in case it’s helpful for anyone :)

So, if you want to add translation support to software you’ll have to ask yourself how and where to store your text strings and their translated versions, and how to load them into your program. Especially the latter was really important to me - I wanted to have a system that requires minimal code changes and requires the least possible amount of work when adding new strings that needed translations. What I especially did not want was having to manually manage a database of all strings in the game with cryptic lookup keys like ID_UI_INGAME_WINDOW_BUILDER_TITLE that some systems use, because having to maintain that database would be super uncomfortable and I’d rather not have to copy these keys around where after a couple weeks I don’t know anymore which text exactly is hidden away behind them.

When researching translation systems you’ll quickly stumble over gettext (up-to-date Windows binaries can be found here), and it satisfies the above requirements perfectly.
All you have to do is to wrap your strings that need translations into some function, so for example this:

string text = “Some text”;

becomes this:

string text = I18N.GetString(“Some text”);

You then run a command line program named “xgettext” that’s part of the gettext system over your source code. It looks for appearances of your wrapper function and extracts their string argument into a separate .pot file. Using “msginit” you then take this .pot file and create individual .po files for each language you want to support. The .po is a simple plaintext file containing both your original language strings and their translations.
Here’s an example of what that .po file looks like for German:

msgid “Some text”
    msgstr “Irgendein Text”

    msgid “Another text”
    msgstr “Ein weiterer Text”

You then parse this file and put its contents into a hashtable, using the msgid as key and msgstr as value. Your GetString()-wrapper method from the example above then simply looks up and returns the proper value for the given key (or returns the key if it doesn’t exist in your hashtable, so if some strings are missing translations they’ll at least show up in English).
There’s a source code example of how to do this here that should get you started.

If you’re like me and try to use the Windows command line only if you really have to you can make it even less of a hassle by creating a couple of batch files that do all the gettext stuff and a Unity editor window that executes them. Now you can run the string extraction with a single click, without having to leave the Unity Editor!

Another benefit of using gettext is that it’s a pretty common translation system, so there are plenty of tools already supporting it. For example there’s poEdit, a GUI application for editing the .po files, which makes life easier for your translators. And if you’re neither into command line programs nor Unity editor scripting it can do the string extraction for you as well.

Making it work with Unitys UI system

So, this system is great for text that you’re directly assigning from within your code - but what about the Text components in Unitys UI system? I certainly didn’t want to set all the Text component values from code and wanted to keep being able to visually create my UI in the Unity editor.

My solution is to do the same thing as for the code basically. I “tag” the Text components that need to be translated by adding another special component to them (named “I18NText”):

It does nothing more than take the text value and run it through the wrapper function:

public class I18NText : MonoBehaviour {
     void Awake() {
        Text textComponent = GetComponent<Text>();
        textComponent.text = I18N.GetString(textComponent.text);
    }
}

Of course it’s also necessary to extract these UI strings into the .po file, so I wrote a small editor script that loops over my UI assets, gets their Text components and writes them into a .pot. The .pot containing the UI strings and the .pot containing the source strings are merged into a single .pot (using the gettext tool “msgcat”), that is then used for creating the .po files.

Phew! :)
This sounds like a lot, but once it’s set up all you really have to do in the end is to wrap your strings into the lookup function, mark your UI texts with the additional component, and run the gettext tools before doing a build. That’s it!