最近大概是7月左右涌现出了一大批的使用agent进行翻译的补丁,再加上B站上的一些up的视频大多数人都应该有了一定的了解,下面说说我个人的看法与些许建议,纯主观
在具体开始之前我说说自己对于ai迅速发展带来了什么吧,我觉得最大影响的一部分就是在coding上,现在对于自身写代码的要求大大的降低了,但是这能帮助一个什么都不懂的人去做好gal程序吗,我个人算是不看好的,或者说现在agent的能力还不至于完美的处理好这部分,ai相当于是一个知识面足够全面的coding手,但是他做不到在某一个专项内达到顶尖的程度,如果使用者自己都不知道应该分析什么、验证什么,那agent很多时候也只能根据有限的信息不断猜测,这一部分相当需要使用者的指引,如果使用者能明确的告诉ai该做什么,该分析什么,该怎么操作怎么处理一部分的操作,不至于让ai像无头苍蝇一样的胡乱猜测,那么相信最后能达到一个事半功倍的效果大概也是写这篇文章的目的
流程其实比较固定解包,提文本,回注,有字库的多处理一个字库没字库的想改gbk的改gbk,想做日繁的做日繁,只重点讲文本的预处理上
首先我不提倡所有的直接把文本丢给ai让他直接翻译的行为,进制类bin文件可能还好,最忌讳的就是把明文直接丢给ai翻译,ai不知道到底哪些地方是需要翻译,哪些地方不用翻译,包括译后的一些处理,全角化这些小地方的讲究非常多
大概能用上的工具winhex,vscode,ida/ghidra这些的逆向软件
写到这里的时候其实才突然意识到,所有的操作似乎到这里就已经结束了,用ida导出反汇编,然后丢给ai写提取注入然后再结束了
那就说点别的东西吧,krkr一整个dataxp3包的一般都有补丁包逻辑,还有一些引擎也是单独一个大包,在做之前优先检查有没有免封包/补丁包逻辑,BGI/FFA等等的都有
提取的话建议让ai提成name--message json或者txt格式然后用**SExtractor** 进行二次提取,正则就
05_search="name": "(?P<name>.+)"
30_search="message": "(.+)"
翻译还是更推荐用**GalTransl** GalTranslPP 这类的翻译器,就目前而言还是不推荐直接在codex等agent软件里面进行翻译
全角化,有些引擎并不支持半角字符,建议在完整翻译进去之前先测试下半角字符的兼容性,有些会导致后续同句内容错乱,有的会导致报错,nscript这引擎就这样的
字典,翻译之前可以用codex此类agent软件跑一个项目字典,避免人名译成千奇古怪的东西
agent到底带来了什么呢,带来的实际上是对于陌生引擎的分析成本,过去更多就是garbro先拆,然后去github上找有没有对应引擎的工具,有的话那就直接用,没有的话那基本就歇逼了,只有少数的人掌握技术去生产工具,agent带来的就是工业浪潮,就好像第一次工业革命给人类带来了工业化生产,如今agent的到来也给想要自己做翻译的游戏带来了工具,发出指令的人就是boss,而agent成为了工人(笑),但我依然不认为就可以丧失寻找工具,检索的能力,毕竟省下来的token可以用来做更多没人做的引擎



2 条回复