So what can we do to make our games more appealing in foreign markets? The most obvious changes to make are to translate all the text and dialog in the game and make sure all the text fits on the screen correctly. This is really pretty easy to handle if you think about it before you start. Obviously if you leave it until the English version is out, then creating the Japanese version might cause you a lot of pain.

Support in Cipher

When designing the internationalisation support in Cipher I came up with a list of requirements.

• Cipher needed to be able to load in all text from external resource files.
• It had to be possible to ship text resources for new languages after a game had shipped.
• It had to be possible to switch languages on the fly.
• All languages should be supported via a single executable.
• When the source code referred to text, it had to be possible to tell what the text might be about. (eg PrintText(42) is no good)

This list of requirements eventually turned into the feature set that Cipher now supports. A single version of the game can support the English, French, German, Spanish, Japanese and Chinese versions. It is also possible for game developers to add code to their user interfaces to allow the players to switch between the supported languages while the game is running.

Character Sets

There are a number of ways of encoding text that are commonly used on computers. They are...

• Byte per character. Each byte represents one of 256 different characters. The 256 characters are defined up front. A common format using this method is ASCII which includes characters for English and some European languages.
• Multi-Byte Character Sets. Some characters are represented by a single byte, but some are represented using 2 or more bytes. Multi-byte character sets are able to support most written languages but are complex to process (as you have to walk a string to determine where each character starts). The main advantage of MBCS is that it is memory efficient, taking up the same amount of memory as ASCII for English text for example.
• Unicode. Uses 16 bits per character, offering 65536 unique characters. This is enough to represent the full character sets for most written languages (all European languages, Japanese, Chinese, Hebrew etc). It is simple to process but uses up more memory that necessary when dealing with English. A list of all the characters supported in Unicode can be found here.

Cipher uses Unicode because it is simple to work with, supports all languages and is supported directly by most debuggers and operating systems. Cipher actually uses Unicode for all text, even the stuff that is not presented to users, like filenames and script parsing, as using it for only the text that the user sees means you have to spend a lot of time converting between ASCII and Unicode.

Using Unicode means that only one version of Cipher is needed to support all languages. I don't need to do a special Japanese build or maintain different code bases for different territories.

Keeping Text Out of the Code

This is pretty obvious, but if you are expecting to translate the text in your game, it is important it is all in one place, and that place is not the source code for your game. When you hire someone to translate everything, it will cost you a fortune if you have to send them all the source code for your game and get them to go through it translating any likely looking bits of text they find.

Put all the text in a resource file, and get the game to read it in. Cipher uses simple files that allows all the text to be stored externally and referred to by name. For example..

// Text for the main menu
playgame=Play Game
playhelp=Start the game using the current settings.

The translator can now get sent a single file and can be told to translate it. Additionally, because each bit of text is identified with a descriptive name, instead of a number, you can see what is what in your source code. So, what have I got against using numbers to identify strings? Integers are simple to handle and cheap to process, but they also need meaningful constants defined so the source code makes some sense. Typically this is with a load of #defines that need to be included in most source files, which adds a strong dependency between the source code and the text resources. These dependencies can mean full rebuilds of the game code each time a text resource is changed, and I hate anything that causes a full rebuild that isn't absolutely necessary. Using names for the strings removes these dependencies.

Displaying Characters

So you can read in all the text resources used by you game and get them translated quickly and easily. Now all you have to do is draw the text onto the screen. Oh, hang on, that is actually quite hard isn't it?

Drawing text in a game can be quite a problem. If you are developing a game for the PC only, then you could use Windows excellent font drawing capabilities to help you out, but it can be complicated to get Windows to draw into a 3D scene without causing big performance problems. If you aren't targeting the PC, or you want to use a common solution across more than one platform, then you will have to take a different approach.

Cipher includes a special tool for generating fonts that can be rendered in game. It does this by rendering out characters from a font to a number of texture pages (depending on how big you want the characters to be and how many characters you need). It fully supports Unicode and allows anti-aliased, proportional fonts to be quickly and easily created. Cipher's renderer understands how to render text from multiple fonts and is fully compatible with 3D hardware. For those that are interested, it renders a single quad for each character, and textures that quad with the appropriate character.

It is also important to consider the length of text when designing screen layouts. Many developers get themselves in trouble when they design screen layouts to look perfect in English. When they come to translate their game to other languages, they find that the translated text does not fit into the spaces provided. German, for example, can take up to 30% more space than English. Always design layouts with plenty of space for expansion and get translated text into the game as early as you can, to make sure everything works as expected. I used to routinely run the French version of one game I worked on, which flushed out numerous problems with menu screen layouts during the project. I guess the foreign language versions were not getting as much testing as the English version.

Creating products that can be easily translated for other territories does not need to be a painful experience. With a little planning and thought up front, it can be easy to avoid the common pitfalls. Redesigning your levels and characters to meet local requirements is another issue altogether though, and I will leave that up to you to think about.