Proxyos Weekly 064

Laurence-042

June 3, 2026 - 2 minutes read - 245 words

TL;DR 概览
把 godot-xterm 换成了 xterm.js，以此解决了先前 terminal 的 bug。至此 alpha 测试的所有问题都进行了优化，接下来进入 beta 发布前打磨

本期目标

把 demo 从 alpha 打磨到 beta
- 完成测试
  - 第一章
    - 【低优先级】xterm 存在一些 bug，可能需要看下其实现并修复，麻烦的话自己实现一个 xterm
      - ~~[ ] col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复~~
      - ~~[ ] cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm。这个 bug 不修会导致无法在向上滚动时正确隐藏输入区~~
    - 从 godot_xterm 方案切到 xterm.js 方案
beta 打磨完成后
- 开个 itch
- 琢磨下宣传

进展速记

本期假设 / 预期

预期：

godot_xterm 的这个问题我不确定其根因，具体根因需要检查其仓库源码

如果修起来太麻烦，我可能需要换个方案，甚至直接自己实现

结果：

godot_xterm 坑了，换成了 xterm.js 方案

本期确定性变化

新增：

webview 层现在支持navigator.clipboard了——是的，之前不支持，我也刚知道

变更：

优化上一期赶进度没有仔细审核的 sb 代码
将 godot_xterm 方案替换为 xterm.js 方案

修复：

任务结束动画不知道啥时候丢了，已补充，并使用更好的架构实现，以及改善视觉效果
修复了调试面板回退任务完成状态后立刻再次完成的 bug

删除：

主要进展内容/本期关键判断点

我做出了哪些「如果错了也要付代价」的判断？

将 godot_xterm 方案替换为 xterm.js 方案

被放弃的命令行后端

当时这个游戏的设计还是围绕着命令行展开的，玩家需要在命令行里做各种操作，甚至整个第一章就是纯命令行。我还准备在其中集成一个真实 pty，以此彻底 meta，并允许用户使用各种诸如管道的高级特性

但是 alpha 测试暴露出这个设计存在致命问题，玩家对命令行并不一定感兴趣，即便存在叙事、各个 python 特性都用不同的交互进行教学、显式进度，阅读大段命令行纯文本仍会让用户觉得自己在上课（甚至不是觉得寓教于乐，而是单纯的上课）。而管道……说实话一些在互联网公司工作的人都不一定清楚，很难保证没有代码思维的初学者能理解其作用。而如果初学者不能很好使用命令行，那命令行就是给纯粹的“要求我打字”的负反馈，他们会宁愿按按钮。

然后我尝试从成功同行那里取经，发现 Hacknet 也是重复打各种相同的命令。这让我思考 Hacknet 是怎么让打字变得有趣的。

我认为 Hacknet 也没有让打字有趣。实际上打字只是玩家操作的一种风格化表现，玩家实际上是在思考解谜。而且打字部分都控制得非常短，让玩家可以条件反射地操作。最后，玩家会重复输入的命令完成后都有很好的视听觉反馈（播放入侵 bgm、入侵进度条上涨等等），并且缺乏视听觉的命令，Hacknet 都提供了替代性操作（比如 ls、cd 可以直接用鼠标点击旁边提供的文件管理器面板的方式发送对应命令）。

回看我的游戏，考虑到命令行不是主要内容，编程才是。所以我不准备继续以其为核心构建游戏，也就是说视听觉反馈没有制作价值，至少在现阶段没有。而解谜部分的话，“使用 help、cd、ls、cat 找到恢复说明文件”这个操作虽然也许有解谜玩法，但我不确定玩家是否都能接受。

因此在当前的 beta 版本施工中，就单纯在第一章使用了命令行，而且其完全是作为启动内部编辑器的启动器，只是让玩家浅尝辄止地输俩命令甚至可以直接点提示按钮，并在内部编辑器里提供有丰富反馈的图形和现代代码编辑器功能。至于 pty？我没信心能让玩家学会管道的同时让他们觉得这好玩，所以自然不再需要了。

xterm 的风险

而同样在 alpha 测试中暴露出的问题还有在计划里挂了俩月的那俩 bug

原本寻思等都做完了就修一下 godot_xterm，结果一看好家伙，上次 commit 4 个月前

xterm.js 的集成

然后我就寻思有没有替代方案，这时候我想起了之前选型时因为没有后端而被我排除的 xterm.js

当时是因为 godot_xterm 提供了后端、而 xterm.js 又需要基于当时我还没搞定的 webview 通讯，所以我才选前者的，但既然现在我已经确定了不再需要后端，那么我自然没有排除 xterm.js 的理由，于是我再次将其集成了进来

集成一天就搞定了，主要是之前我有好好控制代码风格，保证各个模块各司其职，xterm 的修改也是局限在 xterm 层，没有影响 terminal 层。以至于我只要复用已经在 anora 上完成了验证的 ipc 系统，把 xterm.js 包装成兼容这个项目 ipc 的形式，并在 godot 侧补全必要后端功能就行。

至于之前为了 xterm 做的各种诸如 utf8 编解码、浮动光标输入之类的适配，全都直接移除了。

xterm.js 的问题

godot-wry 不支持navigator.clipboard，具体来说，是 tauri-wry 就不支持

因为各个平台对此的实现不同，所以 tauri 为了屏蔽这一差异，没有把它做在 tauri-wry 层，而是做在了 tauri-app 层，也就是说需要在 rust 后端里使用 tauri 的对应平台的剪贴板支持插件

而 godot-wry 是基于 tauri-wry 做的，这就尴尬了……

结果自然是只能让 webview 侧和 godot 侧通讯，让后者读写系统剪贴板了

我也想过要不要干脆把它做到 godot-wry 里，但想了想还是算了，tauri-wry 不做内置支持是有理由的，做了支持反而容易引发其他未知问题，毕竟 godot-wry 并没有 tauri-wry 那么强的技术后备，所以还是保险起见别瞎搞比较好

但在我这个项目里风险可控，所以我可以直接用注入 polyfill 的方式来补上navigator.clipboard，让我项目里的 webview 侧应用无感使用这一 api