Rough Sea Games

Automatization of repeated work is one of the keys to productive development. Another is abstraction of common problems to allow concentration on project specific work. Localization is one of the problems you have in nearly every project, especially in iPhone projects. The iPhone SDK brings interesting solutions that abstract many parts of the localization process.

The tool ibtool, for example, extracts strings from an interface automatically. The strings are placed in a .strings file, a textfile with key/value pairs. To localize an interface, you have to translate .strings and merge the strings back into the interface again. Because you have individual interfaces for every localization, it’s possible to adjust widgets individually for each one.

genstrings is another tool inside the iPhone SDK. It extracts textIDs from the source code and write them into a .strings file. You may ask how the tool knows which texts need localization and which do not. The solution is the macro NSLocalizedString, which will be replaced by a .strings file lookup method by the preprocessor, but also searched for by the genstrings tool to create the files.

Both tools help you to create a localized application without paying much attention to localization itself. But you cannot expect the localization department to search for .strings files inside your project and create localized versions of them. Of course this would be possible, but not very convenient, because you have to migrate the translated texts back into the interfaces using ibtool. Another reason for us at Rough Sea is that we use a localization interface from our publisher. This interface is well known to the localization department and the content is placed in a centralized database on a server.

So we have the great tools from Apple that help us to separate texts from the project and we have the great tool from our publisher that handles the whole translation and reviewing process. Now we need something to tie those tools together, because we do not want to insert new texts from the .strings file into the publisher’s localization tool manually or vice versa. This glue tool has to execute the Apple tools, extract the texts from the .strings files and insert them into the publisher’s loca tool. On the other hand, it has to check for new localized texts from the publisher’s loca tool, build the required .strings files from the results and merge them back into the interfaces. Sounds quite easy, but of course there are some obstacles to get there. You have to handle other things, like the deletion of a text entry or changes to an already translated interface. So you have to know what has changed since the last update and stuff like that.

It turns out that you only have to integrate this glue tool into the build process of your build server. The tool will update the localization database whenever the code or the interface changes and it will update the localized versions when the database changes. As a coder you only need to remember to use the text macro around your text id. You don’t have to add this text id in a file or anything else. As you commit your changes, the build server will do this for you. As an interface designer it’s the same: just create your interfaces in the primary language and commit it. After the localization department finishes localizing those texts, they will be inserted into the localized versions automatically. Of course you have to make adjustments to the interface if there are loca bugs like labels that are to small to hold the translated text.

As you can see those localization tools are a big black box for coders, interface designers and translators. The coders only have to write code, the interface designers design interfaces and the translators translate texts. At the end there will be a localized product.

Popularity: 66% [?]

Here you can see Stripe from the movie Gremlins. He is the second movie monster based on a suggestion from our blog readers. The original idea came from Benita:By clicking on the image you can see a bigger version with a short Tutorial on how the image was created.

Chris

Popularity: 78% [?]

Most computer game designs of recent years conspicuously neglect level design. A level designer’s job isn’t limited to level architecture and scripting — a game can benefit immensely from consistent atmosphere and psychological steering of the player. Modern level design should also be understood as a reality check for game design ideas.

Instead, many current games have filled this position inadequately or even tried to make it into a (minor) part of the game designer’s role. Ideally, the game and its scenarios should be believable and understandable, and the player’s actions should be cool and fit into the world; instead of adapting real life to achieve this, new games have introduced specialized, more or less awkward mechanisms.

In earlier games, all openable crates looked the same, and any slope that could be climbed had the same vine hanging from it. Such conventions were tolerable in the graphics of the time.

Such repeated elements aren’t welcome in today’s nearly photorealistic games, which makes levels harder to “read”. Thus, the aforementioned new mechanics:

Wolverine offers “smell-o-vision”, which highlights interactive elements and the path onward. However, this only forces us to play much of the game in false colours.

In Watchmen – The End is Nigh, a button press turns the character to face the direction in which he should next go, rather than designing the level so that the player can figure it out, or at least including a compass in the HUD.

The first clips of the new Splinter Cell show a system in which the character is shown as a ghost in the last place he was seen by the guards. Also, we can storm a room in the style of a modern action film, quickly and precisely eliminating multiple opponents that we have previously observed and marked. This will probably push the game toward an arcade feeling, because it doesn’t allow the player to know intuitively where his enemies are hunting him — it just breaks the atmosphere to show him directly. Also, storming rooms won’t feel fast-paced and cool, because it’s achievable only after a planning phase rather than simulating rapid and accurate shooting through e.g. discreet autoaim.

There are, however, counterexamples: while fleeing on the jetski in Half Life 2, for example, the level design uses the size and lighting of areas and scripted events to push us subliminally through the canals, so that we feel as if we were spontaneously choosing the right path from several alternatives. If we examine the map afterwards, though, it turns out that all of those (not so appealing looking) branches are actually dead ends. Skillful placement of eyecatchers makes the rail feel like a huge open space.

Clearly, there is much to do in the discipline of level design if the next generation of games is to offer a play experience as beautiful as its graphics…

Popularity: 69% [?]