搞定Lucifen,再次体会到rUGP有多难

7月底,暂离汉化一周年,忽然动了翻俺翼的念头,于是开始搞俺翼R的程序。出乎意料的是,只花了二十多天的业余时间,就把从解包到剧本封包的主要问题都解决了。跟当年搞君望LE的程序一比,天上地下——解决君望LE的解包和初步封包前后花了大半年。单纯以花费的时间衡量的话,君望LE大约比俺翼R难十倍到二十倍。即使考虑自身水平提高、改用Python开发、资料更丰富等因素,也无法忽视两种引擎复杂度的巨大差别。

首先是封包格式和对象种类。俺翼R等Lucifen引擎的游戏有多个LPK包,分别存放脚本、背景、立绘、语音等内容,每个包开头的前缀树和索引数组里记录着包内所有对象的文件名和位置大小。Crass早已提供了前缀树和索引数组的解码算法,只需要跟程序抓一下密钥就能用了……即使不会解析其中某些对象,至少能拆开LPK包。相比之下,君望LE的rio文件没有全局索引,而是把所有对象存成树形。一个对象如何连接到子对象与它的类型、内容有关,只有正确解析了一个对象,才能确认它的子对象存在哪儿、有多大。把rio文件中的所有对象取出来,几乎等于解析所有对象。这是一个可怕的工作:君望LE中已经确认的对象类型不少于88种,而且都是需要进一步解析的二进制数据。相比之下,俺翼R的LPK包解开后,需要进一步解析的基本只有elg、sob、tob三种对象。

图片解析方面差别不大。君望LE这边,westside的四个函数可以合并成一个;俺翼R这边,Crass的四个函数可以合并成两个。当然,原来的算法都是有效的;不过既然做静态替换,需要写逆算法的函数自然是越少越好。两边的难度都在算法清理和合并,写逆算法并不难。

脚本的情况和外层封包类似,虽然都是二进制脚本,但是俺翼R有全局索引信息和强特征,君望LE没有。俺翼R的tob脚本开头有记录命令组分割点的数组,而且命令组中除可自由调整的剧本正文外,每条命令开头都有特定标记。于是,很容易分割命令和提取文本,封包也不用顾忌正文长度的改变。君望LE的脚本复杂得多,11种脚本对象的解析依赖于更深一层约300种命令对象的解析,而且缺少共通的结构。我在RioX中采用的方法是,对假设树剪枝以定位每个对象开头的标记双字。虽然这个双字没有强特征,但是相邻对象标记双字的差和对象长度之间存在弱对应关系。一般情况下扫完整个脚本,假设树中就只剩一个假设了。封包时,对象长度有限制,标记双字也需要调整。

解决了解包封包,处理中文显示就有套路了:先改取字体的API,再改双字节字符判断。然后,就可以开始翻译了。