|
|
Games are international products. When we start working on a new game, we are expecting it to be released all over the world. We are expecting people of every nationality, race, religion and culture to enjoy it. Since all this is known before a single line of code has been written or the design document has been started, why is it that so many developers don't think about it at all, until after they ship? Even if you are only going to ship your product to English speaking countries, you need to think about it. US English has many different spellings to UK English for example, and each nation has it's own collection of slang and cultural references to trip you up.
If you are really serious about adapting your product to each territory you sell it in then you will probably be looking to make the following changes for each of them.
This list could certainly be a lot longer and as you can see, some of the items could really be described as shipping a completely different game to some territories. The goal should really be to make people of a given territory think that the game was made specifically for them. For example, the French should think they are playing a French game made by French developers. Obviously, all this costs money, and most of us don't really know enough about our foreign friends to really make good decisions about what features to change and how to change them.
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.
When designing the internationalisation support in Cipher I came up with a list of requirements.
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.
There are a number of ways of encoding text that are commonly used on computers. They are...
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.
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.
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.
User Contributed Comments