[转载]游戏汉化教程1-汉化流程 – sweetwxh – 博客园.
游戏汉化流程
游戏汉化是非常具有挑战和成就感的,挑战在于和游戏开发商斗智斗勇,想尽一切办法层层拨开文件,得到最后需要汉化的资源,其过程不亚于一段推理。成就感就不用说了,和开发程序一样的,谁不愿意看到自己的作品被很多人使用呢?
实际上,游戏的汉化流程非常简单,如下图所示:
其中,黄色的表示要根据实际情况进行处理,大部分游戏是需要处理字库和编码(字库和编码的处理属于汉化中难度比较大的一个技术环节,后面的教程 会详细说明)的,不过如果运气好遇到一些比较厚道的厂商(比如我们汉化的托托莉的工作室,采用Unicode编码,TrueType字库,那就可以直接利 用ttf字库,而不需要重新生成字库了),那么这个环节就简单多了。
OK,我们还是按照流程来说,上图整个左边就是汉化组中,程序需要做的工作。看起来几个简单的步骤,实际上每一步都还可以拆分的更细,每一步要做的工作也不会很少。
首先是要多整个游戏的文件资源进行分析,一般来说,游戏的资源都不是我们平时在Windows或者Linux下常见的文件类型,而是一些游戏厂 商利用第三方工具处理或者自己开发的文件格式。例如PS3的psarc格式(playstation archive),CRIWare的cpk等等。这些文件都是对游戏资源的一个压缩打包,作用是减小游戏的体积并且减少零碎文件的存在,以提升游戏的运行 效率。这些文件有些可以直接利用现成的工具解包,有些则需要分析封包数据来自己编写解包程序。
游戏资源解包以后,就要开始寻找文本了,寻找文本以前,首先要搞清楚游戏文本所用的编码方式,一般来说,PS3上的日文游戏采用的是UTF8、 ShiftJIS等编码,也有游戏使用的自定义编码(自定义编码处理起来稍微麻烦一些,不过到目前为止,还没有在PS3上遇到过自定义编码的,PSP上倒 是有)。找编码的方式有几种,一是先找到字库(大部分游戏是自制字库,整个字库就是一张图片,整图或者Tile图片),通过字库可以观察出游戏的文本编 码。二是对文件进行16进制搜索,先在游戏中找到一段对话,然后利用工具在资源中选择不同的编码方式进行搜索,对于非自定义编码,第二种方式比较简单,对 于自定义编码,可以采用相对搜索方式(或者叫差值搜索),这种方式就需要结合字库来进行。寻找字库和编码常用的工具有CrystalTile2(天使汉化 组的一款功能比较强大的工具),还有一个是我近期才编写的16进制搜索工具(源代码在这里),我在网上找的16进制搜索工具都不太好用,不太适合汉化。
文本搞定以后,就需要处理游戏图片了,一般游戏图片上也包含了需要汉化的内容(比如封面之类的),游戏的图片常见格式为PNG或者DDS(当然 还有其他格式)。但是这些图片一般都不是直接就乖乖的躺在资源文件里面,而是用一种厂商自定义的格式来封装了一下(也就是加了些文件头信息和控制数据,但 是图片内容数据本身就是位图),所以只需要去掉这些自定义的文件头信息,换成BMP或者DDS的文件头即可用常用图片阅览器打开。
文本和图片搞定以后,要做的就是编写一个程序来导出文本和图片(最好是批量工具,能整体处理某一个文件夹下的所有文件)。图片还好,一般包装的 文件格式都比较简单,文本就不一样了,千差万别。所以,为了导出文本,还需要读懂文本包装文件的数据。比如一个文本包装文件,包含头信息,里面告诉了你这 个文件包含多少句文本,同时,每一句文本前还有控制数据,告诉你这句文本总共包含了多少字节的数据(但一般都直接利用一个特殊字节来做为每一句的结束,例 如0x00)。所以,我们需要读懂这些数据来编写导入导出程序。
上面的工作完成后,汉化就基本完成一半了,这个时候,还不要急着把文本和图片丢给翻译,一个拥有良好习惯的程序员总是要自测一下自己的程序的。 我们需要将解包的资源封包,放回游戏,看看有没有问题,如果没有问题,则将导出的文本随便修改一些,再导入放回游戏,看看在游戏里面是否有效果等等。完成 一系列的测试后,再交给翻译人员,不要等翻译完了,才发现,不能封包什么的,那就亏大了。
翻译完成后,程序要做的事情实际上就是翻译前的一个逆向过程了,就像上山总要下山一样。不过一般的汉化组的程序会在编写导出程序的同时,就完成 了导入程序的开发,并且,按照我的习惯,会利用我的程序来将导出的资源导入回去,与原始文件做一次MD5校验,必须保证完全一致,才能确保在游戏中不出问 题。
以上就是整个汉化的大致流程,比较粗,实际上整个汉化过程会非常繁琐,而且有时候一个很小的细节,就会导致游戏出现各种问题。我会在后面的文章中,把每一个步骤都细分,然后结合实例来编写这部汉化教程。教程中所有涉及到的源代码,我会在Github上共享。