Proxyos Weekly 066
Laurence-042
- 2 minutes read - 265 wordsTL;DR 概览
完成了语言设置功能,正在整理翻译基线
本期目标
- 语言设置
- 系统重装选语言?
- ghostine 聊天信息乱码,使用自己的语言回复后 ghsotine 表示“哦对,忘记你的默认语言是{lang}了”?
- 类无人深空的初始化心理测试序列?
- 用英语通玩一遍
- 更多内容
- 支线任务
- 更多任务
- 实用化任务时限
- 命令行内容?(等第三章?是否需要?)
- 远程访问?
- 更精细化管理事件而不是按章组织?
- 开个 itch
- 琢磨下宣传
进展速记
本期假设 / 预期
预期:
接下来的几期将聚焦于 ux 优化以及内容填充,我不确定具体什么样的内容才算够,但我想我应该至少添加 3 个支线
不过那是后几期需要的了,这一期我得专注于把 i18n 测完
结果:
单单一个语言设置对话框属实太挫了,然后就寻思优化一下。想了个天才的主意但是当前的剧本系统能力不足以支持,爆改剧本系统后发现其实没必要爆改……
最后发现翻译过于机翻,需要制定基线后再机翻(是的,还得是机翻,我自己翻译就全是小学生写法了)
本期确定性变化
新增:
- 显式的语言设置
- 总结人物画像草稿,用于避免翻译后语气脱离人物性格
- 制定专有名词翻译基线草稿,用于避免同一个词翻译成多个
- 总结人物-发言对应关系草稿,用于配合人物画像草稿检查语气
变更:
- 升级剧本系统,使其支持以 DAG 的形式管理依赖关系,并创建了编辑界面
修复:
- 修复修改语言后资源没有重载的 bug
删除:
主要进展内容/本期关键判断点
我做出了哪些「如果错了也要付代价」的判断?
语言设置界面
我确实折腾了 Godot 的基于系统语言自动设置语言的机制,但是这样的话在首选语言没对上的话就很难搞了,所以我寻思了寻思,觉得还是得用显式的语言设置,而且还必须在开场之前完成设置(开场就会有大量文本)
但单单一个语言设置对话框属实太挫了,然后就寻思优化一下。
这一期的计划确实列了几个备选,但感觉都有些问题
| 方案 | 优势 | 劣势 |
|---|---|---|
| 展示为系统重装界面,模仿系统安装时的语言选择 | 直观 | 目前基本只有语言值得设置,很容易退化成“选语言的对话框”。 而且设定上玩家用的是一个客户端,系统并没有重装,和设定不是很搭 |
| ghostine 聊天信息乱码,使用自己的语言回复后, ghsotine 表示“哦对,忘记你的默认语言是{lang}了” | 完全嵌入剧情 自然、没有设置感 | 需要无感重载资源,而且需要让玩家可以回复信息。 前者容易处理,但是后者会破坏“玩家使用代码,在安全内核与控制节点的代理下和世界对话”的概念。 而且也会失去让玩家提交文件到任务界面而非轻聊界面的正当性 |
| 类无人深空的初始化心理测试序列 | 酷炫 有悬疑感 | 本质上是给系统重装界面加一堆似是而非的问题,但目前剧本中没有什么可以 callback 这些问题答案的地方,让玩家选择却不给选择结果可是大忌 |
但随后我有了个天才(至少当时我这么觉得)的想法:
设计一句话,将其打断为 3 个词组/字,然后每个部分都用多种语言展示。玩家需要按顺序点击自己期望语言的词组/字来拼成完整的话。语言一致且顺序和预设一致就使用对应语言,否则视为“仿生逻辑未正常工作,内核实例化为计算节点失败,即将重试”然后要求玩家再次尝试
这和系统重装界面一样直观,但没那么无趣,而且还能自然嵌入叙事
升级剧本系统到 DAG 模式,创建编辑插件
旧剧本系统的局限性
起因是我意识到如下事件序列无法正常完成设置
- 事件 A:仅在玩家第一次进入指定阶段时执行
- 事件 B:在事件 A 执行完成后,如果当前玩家处于指定阶段就执行
看起来很简单对吧?但因为 A 和 B 是两个事件,所以 A 和 B 时平级的,如果用“玩家处于指定阶段”的 trigger 就会同时触发两个事件,没法实现“B 仅在 A 执行后才能执行”的目的
当然,也不是没有规避方案,比如 A 完成后将一个隐藏任务 a 完成,然后 B 的条件是隐藏任务 a 完成。但这样本质上是把任务当状态变量用了,属实过于重量级。
这个问题的本质是事件的触发条件粒度太粗了,导致事件 B 的复杂条件无法正常完成编写。但更细的触发粒度无疑会导致 trigger 的设置变得要么极其反直觉要么极其难以维护
以 (A and B) or C 为例,
如果为了可维护性,那就会变成下面的类似物
- OR trigger operator
- AND trigger operator
- A trigger
- B trigger
- C trigger
- AND trigger operator
显然,这玩意本质上是前置逻辑运算符,经典反人类设计
如果为了易用性,那就会变成下面的类似物
at_stage(INTRO)at_stage(INTRO) and is_event_completed(A)
显然,这我就得写个解释器,重构信号绑定机制,而且到处是 id,根本没法追踪变更
新方案
DAG
也就是说,把剧本系统升级成成类似 galgame 的、基于有向无环图的对话路线剧本系统
这看起来似乎是一个对于事件依赖的针对性修改,但实际上其同样可以为更复杂的机制做铺垫,比如引入条件节点、选择节点等等非事件的控制节点,以此实现复杂条件判断的同时保证所有资源都是 tres 强类型、人类可读可维护
更妙的是,这个方案不需要对现有逻辑做太大改动
新的架构只需要新增一个编辑器插件类,在 DataDrivenChapterController 里调整事件执行逻辑,为 ChapterEventConfig 添加存储边的字段。除此之外不需要额外变更,所有 tres 直接向后兼容。具体调整内容如下
- 将 ChapterEventConfig 的当前 Events 视为 Nodes,新增 Edges。默认 Edges 为空(相当于散点),不需要对已有 tres 做迁移
- 新增一个编辑器插件,使其支持编辑以 DAG 的形式编排 ChapterEventConfig(基于 GraphEdit 和 GraphNode)
- 调整 DataDrivenChapterController 执行流程,使 ChapterEventConfig 中只有任意入边相连的前置节点(Event)完成的节点(Event)才会允许激活与执行 Actions。Actions 都执行完后节点 Event 视为完成,其出边连接的任意 Event 都会进入活跃状态允许被激活
结果
十分反高潮的是,最后这个系统没有发挥啥作用
因为实际上之前提的事件实际上是
- 事件 A-显示语言设置窗口:仅在玩家第一次进入指定阶段时执行
- 事件 B-打开轻聊应用:在事件 A 执行完成后,如果当前玩家处于指定阶段就执行
而我测试后意识到语言设置窗口应该在控制面板加载前先加载到主窗口才对,这么做的话其本身也脱离剧本系统了,以至于 DAG 完全没发挥作用……
翻译优化
之前的翻译完全是由 deepseek 直接翻的,这一期还没出序章就发现存在语言风格突变、专有名词翻译不一致、部分字段翻译缺失等问题
于是这一期剩下的时间都用来基线化各种翻译标准了
而且说实话,我还是不太确定“玄云观”这个该怎么翻译,以及是不是应该修改下 cybertaoism 这个二级域名。当时取这个名字的时候是取神秘(玄)、蕴含等待释放的磅礴能量(雷云)、在混乱的世界中突兀而又自洽(轮形空间站上的道士)的意象,但这反而对翻译造成了麻烦
瓶颈与问题清单
哪些问题还没解,但也许我已经知道“它们不是什么”?
到底该怎么翻译“玄云观”?但肯定不能是 Temple 之类的
下期计划
优化英语翻译
- 名词翻译归一
- 人物语气核查
用英语通玩一遍
更多内容
- 支线任务
- 更多任务
- 实用化任务时限
- 命令行内容?(等第三章?是否需要?)
- 远程访问?
- 更精细化管理事件而不是按章组织?
开个 itch
琢磨下宣传
试玩版
暂缓,第一次上传需要做好准备,等进入 beta 阶段再说