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: 61% [?]

How can a small developer produce enough content to keep a massively multiplayer game interesting?

Fun is not a full time job

More and more browser games want to be World of Warcraft, which, in practice, usually means that they try to suck you into spending your whole day grinding. Our game is designed to be played for about fifteen minutes per day. Why? Mostly because we expect that our players will have lives outside the game, and we don’t want to ruin them. The side benefit is that we don’t need to produce content as quickly, since players can’t burn through everything in a single insomniac sitting.

Rough Sea needs you

The MMOG content problem arises because there are more players than developers. So why not allow players to make their own content? Everyone wins: creator players get in-game rewards and the pleasure of seeing their work in the game world; consumer players get more copious and varied content.  Of course, vetting submissions is a lot of work, but we may be able to use voting, etc., to get the players partially to supervise themselves! Many web sites (eBay, flickr, facebook) and computer games (Sims, Spore, Little Big Planet) are either founded on or enriched by “user created content”, but browser games haven’t twigged yet.

Use your words

The convential wisdom is that people hate having to read while playing a computer game — it’s a visual medium, like film — and that “reading” on the web consists of skipping as much text as possible. Our game, while primarily graphical, uses text to describe special events that occur in the course of play. Are we crazy? Possibly — and if playtesting shows that reading sucks, we’ll scrap it and redesign. But since players will only see a couple of text-based events per day (and since we hope to attract literate players, not twitch monsters), we hope that these will be seen as welcome variety, not as a chore.

And what are the advantages of text?

• it’s faster to write an atmospheric text than to create the same mood with art or sound. That means we can deliver more content.
• writing requires no special software or equipment, which makes it especially suited to user created content as described above.

Left to Chance

Computer games discovered early that a computer, given the right formulae, can create a huge, complex world much faster than a human can. The procedurally generated approach isn’t suited to text, nor to our style of graphics, but it is excellent for creating spaces for people to explore.

Popularity: 6% [?]

Game design distinguishes between mechanics — the rules of the game — and content — the stuff in the game, like art, music and story. Good mechanics tend to be fairly simple, so that players can understand them, but provide enough flexibility for expressive play (consider chess and go). This often makes them cheap to implement: a clear, simple set of rules is a programmer’s dream. Good content, on the other hand, tends towards the elaborate and expensive: if you want your game to contain a city teeming with life, you’d ideally want every one of its thousands of citizens to look different, and possibly even behave uniquely. Big budget titles like content, because if you have money, it’s the safer bet: it’s hard to come up with good new mechanics, and even if you do, gamers may reject them. Content allows you to distinguish yourselves from the competition without that risk, and you can produce it pretty reliably (of course, there are brilliant and incompetent digital artists and authors, but for an average team, more time & money => cooler content).  On the other hand, Indie games tend to emphasize clever mechanics because that’s all they can afford. Also, games intended for brief play sessions, like arcade or casual games, simply don’t have enough time to show off much content, so they can and do skimp.

But there’s the rub: people associate content-light with short! If someone sends you a link to a browser game with little content, then you will almost certainly play it for only a few minutes, regardless of how brilliant its mechanic may be. If it were boxed for retail sale, you wouldn’t play it at all. There are too many games available to expect people to have the patience to let a mechanic unfold unless they are seduced by content. If chess were invented today, it would fail. A few people would play it, sure, but if only a few people played chess, it would never have reached the depth it has; the scholar’s mate might still be state of the art (unless it got nerfed in a patch).

We here at Rough Sea are making a game that is not short. It’s intended to be played in brief daily sessions, but the world and characters are persistent, so each session contributes towards larger goals. Therefore, we need content. But how will we keep up with the consuming hunger of our hoped-for hordes of fans? That’s a subject for another post.

Popularity: 7% [?]