Introductory tutorial for Chinese games

Simply put, the work of Chinese translation is to replace all the text in the game with Chinese. In a mobile game, there are probably three forms of modified text:

picture words. It refers to all text that exists in the form of pictures, such as game splash, text background or special effects, etc. The replacement method is very simple, find an artist to make the drawing, and then directly replace the original picture. Many games in the past put these pictures into jars without any processing or only removed the extensions. It is very simple to replace them. However, in order to reduce the size, many games now pack n pictures into one file. It is a bit troublesome to replace these files accurately.

First we need to figure out the storage format of the file. According to the drawing method of the program, it can be roughly divided into two forms: drawImage and drawRGB.
drawImage directly packages the image without destroying the format of any image, while drawRGB saves the pixel information of the image in RGB format. The former is easier. In addition to PNG, some mobile phones also support GIF, JPG and other formats. Just make sure the image format is correct. The latter is a little more troublesome, because the array of RGB pixel information formed is very large, and some of it is compressed, so accurate replacement will be more difficult.


String written in the program. The processing method is also very simple. Just decompile the source file and replace the corresponding string. Don't ask me what decompilation is, I won't talk about the principles of compilation in this post. To elaborate further, there are two ways. The first is to directly modify the class file. If you write Chinese characters directly in the source program, the Chinese character strings in the generated class file should be standard UTF8 encoding. A simple way is to compile a java file with Chinese strings written yourself, and then copy the corresponding bytes in the generated class file to the original class file. The second is the Java file generated after decompilation. Due to scrambling, there are places where it cannot be compiled. This is usually because there is a problem with the file generated after decompilation. Due to different scrambling tools, the existing problems are also different. In some places, decompilation was not successful, in other places pseudo-assembly instructions (such as goto, etc.) were used, and the names of some constructors were hidden. . Wait, some scrambling tools will also deliberately add unreasonable code to set traps for decompilation -__-|| Therefore, very troublesome modifications must be made. . . Of course, there are only a few mistakes to make when correcting them, which is very troublesome. Scrambling and decompilation techniques work together, and there is no one-size-fits-all solution. In short, this method is not recommended when the interference of scrambling codes has not been completely eliminated.


String written in external data. If the program structure of this game is good, all strings should be placed in an external file. If you don't know which file it is, just open all the files with a text editor and view it to find the file that stores the string. Many games use the general function readUTF() to read data from files. Therefore, make sure that the new strings used are UTF-8 encoded. Since there is no original xml file to regenerate this data file, you may need to replace the hexadecimal encoding of the string to correctly replace the original string. Generally speaking, each character of uft-8 is one byte larger than Unicode, so the replaced string file may be a little larger than the original. If it is not in UTF8 format, it may be in Unicode or other formats. However, if the program itself does not take into account the reading of multi-byte text, it cannot be solved unless the source code is modified.


This is basically done. The changes in jar size and game runtime memory caused by replacing these strings are negligible. The last step is to confirm that the mobile phone you want to run this program supports Chinese:)

In short, it is really a joy to not have a built-in font library. When you get a GBA rom, the first thing you need to do is to crack it, but what about getting a mobile game? Just unzip it and view each file.Haha, to make a GBA Chinese version, you need at least cracking, translation, and art, but to make a mobile phone Chinese version, the amount of text is not large, there are not many pictures, and one person is enough. And the most important point is that there is no GBA game production company in China. If you want to play Chinese games, you can only rely on fans to do it yourself. But for mobile games, it is the opposite. There are many domestic production companies. But despite this, most Chinese games are still pure garbage, and they really don't compare to the games produced by big-name foreign companies. Interested students can try it themselves, so I think the significance of this article is not meaningless at all.