北京
对话翻译跑通了。脚本提取、翻译、重建，一气呵成，角色终于在原版主机上开口说英文了。这是整个项目最重要的里程碑。
但当我真正拿起手柄想玩的时候，一切都还泡在日文里。菜单、地点名、角色资料卡、存档界面——所有告诉你“现在该按哪个键、要去哪儿”的界面，一个字都没变。
对话脚本住在一处专门为对话设计的地方，路径清晰。UI 文本却完全是另一回事。它们不是躺在某份可编辑的脚本文件里，而是作为原始字符串硬编码在游戏的可执行文件中，一个紧挨一个，没有弹性空间。日文版 UI 围绕着固定宽度的日语标签搭建完成，从未给另一种语言更长或更短的单词预留哪怕一个字节。当“アルバイト”被替换成“Part-time Job”时，多出来的字母直接溢出，叠进了下一个字符串的领地。画面直接崩成一片混乱：本该只显示一行字的地方，开始同时绘出好几样东西，彼此交叠压在一起。
但紧接着我就发现了一件怪事——有些英文标签看起来异常友好。对话渲染器曾因为把所有字符都当成等宽处理而需要打补丁，UI 却不一样。同一屏上，有的标签字体被拉得开开的，“P L A N S”几个大字松快地占满了宽间距；旁边的日期“3/20/Th 18h”又挤得紧紧的。两种字符宽度，在同一张画面上相安无事。
答案藏在字体里。这款游戏竟然内置了两套字体：一套是 24 像素宽的日文字体，另一套是 16 像素宽的窄字体，后者覆盖了除汉字之外的所有字符，包括完整的拉丁字母表。渲染器会根据正在绘制的字符自动在宽窄之间切换。这是 1998 年的原始开发者就已经解决了的机制。他们搭建了一个可以把日文和英文字符混排的界面系统，即便当时英文根本不是游戏的主要语言。挖到这个设计的那一刻，我只想说一句：真是撞大运了。
但好运只管到英文单词变长之前。当真正把长单词丢进去，藏在水面下的老假设就浮了上来。游戏里有一个菜单靠一套简单的算式来居中文本：x = (96 - advance * length) / 2 + 4;。96 像素可用宽度，减去文本占据的宽度后平分余量，再整体向右推 4 像素。逻辑完全合理。可一旦塞给它一个 7 个字母的英文单词，一切就翻了车。比如“PROFILE”，7 个字符每个按 24 像素计，总宽就是 168 像素。算式变成 x = (96 - 168) / 2 + 4;，计算结果直接掉到负 32。程序里没有任何安全检查，坐标就这么乖巧地指向了屏幕以外。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
