Game Development Reference
In-Depth Information
while anautomated system will convert these strings totheir respective numeric identifiers
with the goal that during the game's execution no string comparisons are performed.
Therearedifferentmethodsthatmaybeusedtostorethelocalizationdata.Itisimportantto
understand the implications of the method you choose. While one approach is to use XML
to store the raw localization data, this can have performance issues, higher than necessary
memory use or even logistical complications.
<id>1</id>
<en>Hello World!</en>
<fr>Bonjour tout le monde!</fr>
<sp>Hola todo el mundo!</sp>
Depending on the game and the amount of localized text, this approach can quickly take
up a lot of memory and we would incur the processing cost of parsing this XML data. The
XMLdatashouldonlybeusedasanintermediate format,thedatashouldbeconvertedtoa
binary format during the build or packaging process. One logistical issue that may arise is
at the time of delivering data to be localized. If all the data is stored in a single, very large
XML file, it may become difficult to send out this data to multiple localization agencies or
tomultipletranslators,havethemapplytheirtranslationsandthenshipthefilebacktoyou.
You may find yourself having to merge multiple revisions of the file as work is delivered.
A more flexible approach is to create a simple file format using UTF-8 files, one file per
localization string. The format of the file may look something like this:
1
en: Hello World!
fr: Bonjour tout le monde!
sp: Hola todo el mundo!
jp: こんにちはこの世 !
This file may follow a naming convention to make it easy to know what the files are,
1_helloworld.loc. Now,thesefilescanbeeasilyshippedtothedifferenttranslatorsoragen-
cies, they may be passed around and if ever a file needs to be merged for some reason, it
is a lot simpler to do so. During build packaging we can collect all these files and create a
binary database per language. As we discussed earlier, having one database per language
will allow us to only ever load the active locale's text and nothing more.
The database should be loaded into a hash table. We have designed the system so that each
entry has a unique key thus we do not have to worry about key collisions, in other words,
our hash table has a perfect hash function and no collision resolution needs to be imple-
mented. Given a key, we can query our database in constant time, O(1).
Search WWH ::




Custom Search