TL;DR 概览

ANORA的前端核心逻辑已经完成，初步调试无误，也具备了通过 wry 节点与 gdscript 交互的能力

本期目标

• 完成逻辑图系统，考虑用TypeScript+Vue/React之类的搞一个ANORA原型，然后通过wry集成进游戏，通过wry的事件系统进行操作
  • Node框架
  • 分层Port
  • Connection折叠/展开
  • 逻辑图计算
  • 简而言之就是之前的AWW的所有除了定制节点之外的基础计算和显示逻辑，时间有点紧，毕竟这些东西当时我用了好几个月内的工作间隙。但我觉得有善用claude应该能及时完成——Again
  • 集成进游戏
    • 无UI模式（纯逻辑图，游戏内通过GDScript控制）
    • 适配相关关卡脚本

进展速记（Changelog）

新增：

• ANORA 核心实现
  • 虽然看起来只有一条，但改的是真的多啊
• ANORA 扩展 mod 加载

变更：

修复：

主要进展内容

NORA的前端核心逻辑已经完成。将上周遗留的设计问题收尾后，本期对ANORA进行了实现。

相较于其前身 AAW 的核心升级

• 更灵活的节点执行控制
• 更高效的计算
• 可扩展的Node、Port甚至Executor
  • 实际上核心的定义哦都是通过扩展机制加进来的
  • 所以说Rimworld的那个名为Core的mod真是个天才的构想

距离接入 ProxyOS 仍需完成的内容

• 无UI模式(纯逻辑图，游戏内通过GDScript控制)
  • 初始化图
  • 控制按步执行
  • 一些为了通用的动画演示准备的画面效果
• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

瓶颈与问题清单

• 暂无

下期计划（Next）

• 无UI模式(纯逻辑图，游戏内通过GDScript控制)
  • 初始化图
  • 控制按步执行
  • 一些为了通用的动画演示准备的画面效果
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

ANORA的设计花费了比预期更多的时间，目前还未达到目标

本期目标

• 完成逻辑图系统，考虑用TypeScript+Vue/React之类的搞一个ANORA原型，然后通过wry集成进游戏，通过wry的事件系统进行操作
  • Node框架
  • 分层Port
  • Connection折叠/展开
  • 逻辑图计算
  • 设计

进展速记（Changelog）

新增：

变更：

修复：

主要进展内容

ANORA的设计难题

虽然四天前我说“毕竟这些东西当时我用了好几个月内的工作间隙。但我觉得有善用claude应该能及时完成”，但实际上比我想象得更难，仅仅是设计就几乎花掉了这一期所有时间

设计文档中的致命问题

我第一天写了ANORA的设计文档。我以为已经很全面了，毕竟我是基于之前已经实现的AAW的经验，覆盖了各种实体的定义、执行逻辑、功能细节、项目结构等等

但是当我用claude检查的时候，我发现了很多致命问题

问题1：推还是拉？

在ANORA的前身AAW里，逻辑图里的顺序是“拉”的，即执行器只记录节点间的依赖关系，当某个节点所依赖的节点都执行完成后，就把数据从其依赖的节点的出Port上拉到这个节点的入Port上供这个节点使用

ANORA为了给节点更多的自由度，使节点可以根据当前入Port输入状态决定自己是否可以执行（为了提供现代编程语言的可选参数特性），这就必须使用“推”的，即一个节点执行完成后会把它出Port上的数据推到下一个节点的入Port上，然后节点才能做出判断

但这产生了一个问题：ANORA需要和AAW一样支持Port的嵌套。AAW在拉的模式下可以先拉外层Port再拉里层Port来保证里层Port的数据优先级最高，以此支持入Port数据模板之类的写法。但ANORA的推的模式就无法支持这个特性了

问题2：要不要支持Port的嵌套？

遇到上述问题后，我首先想的就是“问题的前提条件是否是无法改变的”，也就是是否一定要支持Port的嵌套。直接用get/set节点行不行

思考后我觉得是必须要支持的。因为我设计时就想好了这个项目的演示用后端——API录制回放。是的，还是AAW。但不是因为有个垃圾底层系统需要我包装，而是因为这个任务同时涉及了强时序、复杂数据流、异步调用这三个节点编程系统能发挥最大作用但又最难同时满足的场景，它会成为ANORA的试金石

而为了适配复杂数据流，“从默认数据模板中改一个数据”的操作必须要足够简便，最多只能用独立的参数节点提供默认数据模板，不能通过额外的节点数据合并。毕竟合并数据如果不使用嵌套Port，就必须通过某种更程序员的方式指定属性路径了，这显然和ANORA的设计目的相悖。

所以问题1必须要解决。但在思考解决方案的时候，我遇到了另一个更严重的问题

问题3：同步还是异步？

在ANORA的前身AAW里，逻辑图的执行是全顺序的，即使在一个批次里，节点的执行也是顺序的。当时这个设计是因为我没有很多时间实现一个复杂高效的系统，所以当时我就想只要在性能可以接受的情况下debug尽可能方便就行。但是ANORA自然不能这样，所以在我最初的设计中执行是全异步的。这使效率最大化，而且不管是用在什么任务中都足以胜任。

只能说理想是美好的。在全异步的模式下，我想不到一个可以同时满足易用、直观、可维护的循环逻辑执行方案。我参考了UE、ComfyUI等流行的节点编程系统，但它们要么就是直接封装编程语言里的while为节点，要么就是根本不支持流程控制。

问题4：要不要null？

这反而是最小的问题了，这玩意又不是给经验丰富开发者用的，拒绝null那就得引入更多保护措施，反而导致其上手门槛更多。一番折腾后我才明白了这个道理，然后释然地添加了null

解决方案？

显然，问题2和问题4都解决了，关键是1和3。

最后，我想到了这么一个设计：让流程控制节点可以一次激活多次执行

而这个方案不仅解决了两个问题，还让ANORA彻底甩开了AAW到达了全新层面。

ANORA的思想

更复杂的节点

之前我一直把节点当成函数调用的抽象，这使我陷入了误区——调用函数的语句天生就没有分支！

虽然在AAW里通过“以数据为核心，节点只有其需求的数据都输入后才能运行，运行后可以选择性地在特定出边输出数据”的方式实现了比UE更易用分支写法，但是其循环逻辑仍然十分粗糙、难以编写——它产生了环

而有环的图天生就是不直观的

但当我不再把节点当成一个函数，而是以更自然的方式进行比喻时，一切迎刃而解了

TL;DR 概览

Terminal总算是搞定了！fastai确实咕了，爽玩ComfyUI

本期目标

• 修好Terminal

进展速记（Changelog）

新增：

变更：

• 从之前的ConPTY方案改成了自己做PTY，结合BetterProcess来做异步程序调用与交互

修复：

• Terminal修好了

主要进展内容

Terminal修复完成

之前我说“目前我在使用“gd命令每发一行，同步给pty发一行以#开头的命令，并在回显中过滤掉#命令及其回显”的思路，不过它的状态转移我还没想清楚，直接扔给claude只会得到水多加面面多加水的结果，所以我得好好想想再继续”，但是实际思考后发现由于PTY本身的复杂性，根本不可能以可维护的方式将其实现

我写了篇长文边写边理思路，然后提出了几个方案又一一否决

方案1-拦截

通过在PTY里执行#__PROXYOS_SYNC__#这种注释来在标记行的同时让PTY光标进入下一行。同时拦截包含这种标记的行，避免其被显示到XTerm上。以此在不影响Xterm输出的情况下把PTY的光标同步到GDScript命令回显的下一行。#__PROXYOS_SYNC__#不可在 GDScript 输出中使用。

• 优势
  • 完整支持命令行为，对于那些在输出中主动设置颜色、换行之类的命令支持良好
• 劣势
  • GDScript命令输出存在单行长度限制，这会降低可维护性
  • PTY 行为并非稳定规范，后续变更可能导致完全乱套（比如移除了多行输入的>>行为）
  • GDScript命令输出较长时可能耗时过长，且每次都整页刷新的PTY输出可能会导致性能问题（类似top命令那样的）

方案2-单纯把PTY当异步os.execute

不再使用完整PTY，而是由自己维护XTerm，只在用户按下enter发送命令时，判断是不是GDScript命令。

是的话命令输出直接输到XTerm里

不是的话暂停侦听PTY，在PTY里使用三次Ctrl+C清除当前命令、潜在执行中的程序、兜底一次来获取单纯的输入提示符格式，再次启动侦听后发送命令。从PTY响应中过滤掉命令输入行、过滤掉设置光标的CSI、识别并替换输入提示符为自定义的输入提示符

• 优势
  • 兼容性良好，实现简单
• 劣势
  • PTY的输入提示符在不同系统上五花八门，即使是同一个系统不同版本的PTY程序都有些许不同，适配较为困难
  • 无法支持类似npm那种会在输出中使用CSI来实现转圈的\|/-的行为，反而会输出一堆这种序列
  • 三次Ctrl+C可能仍有不兼容情况

方案3-直接自己搞个有cd、ls的极简console

之前一直折腾PTY主要是因为OS.execute阻塞，而OS.create_process又没法拿到stdout输出

但现在发现了BetterPorcess，这就好办了

• 优势
  • 兼容性极佳
• 劣势
  • 难以处理方向键
  • 本质上需要自己实现一个PTY

最终方案：基于方案3，尽量实现相关特性

目前支持的特性如下

• 右键复制/粘贴
• Ctrl+Shift+C粘贴
• Tab补全
• 自定义命令
• 自定义python脚本调用
• 自定义中间件来处理特殊输出

爽玩ComfyUI

哎，ComfyUI真不错。我发现我以前收藏的不少图实际上就是ComfyUI出来的

所以我更新了我的图片下载器，它可以识别到新老图片里的ComfyUI特征，然后重命名时给后缀名前面加个.comfy来备注

爽玩各种工作流和prompt，还找到个不错的模型/lora网站

瓶颈与问题清单

• 暂无

下期计划（Next）

• 完成逻辑图系统，考虑用TypeScript+Vue/React之类的搞一个ANORA原型，然后通过wry集成进游戏，通过wry的事件系统进行操作
  • Node框架
  • 分层Port
  • Connection折叠/展开
  • 逻辑图计算
  • 简而言之就是之前的AWW的所有除了定制节点之外的基础计算和显示逻辑，时间有点紧，毕竟这些东西当时我用了好几个月内的工作间隙。但我觉得有善用claude应该能及时完成

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

问题远比预想的多，一直在调Terminal和修改架构

本期目标

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

进展速记（Changelog）

新增：

• 一个仍有很大问题的，在修复阶段用于辅助说明的逻辑图系统（也是为ANORA进行技术试水，其前身AAW的架构可能有些过度设计，这次借着这个机会试试其他架构）

变更：

• 自删除动画从python改成gdscript，以此绕过pty光标位置和xterm对不上的问题

修复：

• 尝试修复gdscript命令执行后导致光标偏移的bug，但没修好

主要进展内容

基本没进展，一直在和命令行死磕，而且完善Rimworld小工具所需的时间远比预期的多，其发挥的价值远比预期的少，说实话心态有点崩。下期我准备缓缓，暂停fastai学习，只追求在心态不崩的状态下把Terminal修好

Terminal

本质上这是我给自己挖的坑。当时测功能的时候没多试几个命令，结果现在才发现gd命令会出问题

其核心问题是，gd命令只会影响xterm状态，但pty却以为自己还和xterm同步仍在给xterm发光标位置信息，双方的状态不一致导致了显示灾难

目前我在使用“gd命令每发一行，同步给pty发一行以#开头的命令，并在回显中过滤掉#命令及其回显”的思路，不过它的状态转移我还没想清楚，直接扔给claude只会得到水多加面面多加水的结果，所以我得好好想想再继续

沉迷开发Rimworld小工具

rimworld-ordinatus-calculi Demo

实际上这一期又画了一半时间完善这个

然后投了一篇宣传到Reddit的Rimworld板块，一篇到Rimworld的Steam社区指南

结果前者被删帖，后者没人看……

不过我确实在实现这个的过程中学到不少东西，比如怎么描述需求更加合适、demo迭代式开发试水、plotly、界面布局设计等等，也算是不虚此行

瓶颈与问题清单

• Terminal的显示和pty内部状态的同步
• 剧本完成后，我意识到设计当初根据大纲写的恢复程序框架有点死板了，下一期我得花大力气搞定这些交互式演出的Python脚本，其中一些还得用eval来保证玩家体验

下期计划（Next）

• 修好Terminal

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

这一期咕了

本期目标

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

进展速记（Changelog）

新增：

• 第一节脚本
• 第二节脚本

变更：

• 无

修复：

• 无

主要进展内容

这一期基本咕了，倒不是遇到啥难题，就是单纯的麻烦，然后失去了动力效率偏低。

感觉很不爽，于是去继续搞fastai，结果被kaggle一套组合拳下来彻底干不下去了

kaggle的组合拳

当时我在看这个fastai的官方教程 https://colab.research.google.com/github/fastai/fastbook/blob/master/09_tabular.ipynb

里面需要使用kaggle的数据，而且后面的内容都是依赖这个数据的 注册kaggle，填一堆信息，获取token，执行 kaggle 401，查了下发现是kaggle把colab给ban了 发现kaggle也提供了在线notebook执行器，但因为这个ipynb文件超过1MB不让导入 手动裁掉了文件中比较大的图片，重新导入执行 发现kaggle的环境装不了第三方依赖库，而且也不给GPU资源 只能本地搭环境，结果因为fastai和pytorch的安装顺序搞反了，导致装上了CPU版的pytorch，GPU的没装上 删除venv重新装依赖 装完依赖执行ipynb，结果发现里面使用了没列在requirements里的依赖 补装后再次执行 kaggle 403，查了下发现是kaggle要求用户签署对应比赛的同意书才能下数据 找半天没找到同意按钮，结果找了一圈后发现kaggle已经不提供加入老比赛下载老比赛数据的方式了 走投无路问ChatGPT，她说fastai的sample里可能有给了我个URL，404 再次问ChatGPT，她说github里可能有给了我个URL，404 血压拉满再次要求ChatGPT核查，她说她可以把她那里的数据给我，但需要我等下 饱含怀疑地要了数据，结果她给我发了个ChatGPT的聊天URL——还正是我问这个问题的聊天URL

血压爆了

沉迷开发Rimworld小工具

心态崩了之后，自然就得找发泄渠道。于是我去玩了半天Rimworld，然后发现其中两个武器我很难抉择，它们造价相差无几，但穿甲、伤害、不同距离的精度都相差很大，我没法很简单地算出哪个更适用于我的游玩风格。于是……

我去做了个Rimworld计算器

一开始只是准备给定命中率、穿甲、理论最大DPS，画敌人护甲和实际DPS的关系曲线的，结果后来越做越投入，连曲面和多层护甲都整出来了……

就这么做了两天，一看时间——哦豁，ProxyOS咕了

不过今天顺利的话我应该能把它的链接放下面

rimworld-ordinatus-calculi Demo

瓶颈与问题清单

• 剧本完成后，我意识到设计当初根据大纲写的恢复程序框架有点死板了，下一期我得花大力气搞定这些交互式演出的Python脚本，其中一些还得用eval来保证玩家体验
  • 我确实可以去戳copilot claude，但是之前他没能很好地实现第一章的开始动画演出，而且第一节写得也有不少问题，扯皮两三轮后还是手改了一堆

下期计划（Next）

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

第 1 章剧本终于全部写完了。 花了远比预期更多的时间。 但系统与玩家交互的逻辑终于成型。

本期目标

• 完成第一章游玩内容
  • 拖了整整 3 期，这期怎么说也得搞定了

进展速记（Changelog）

新增：

• 第一章的游玩剧本
• 第一章的游玩框架

变更：

• 无

修复：

• 无

主要进展内容

这一期花费的时间仍然比预期的长，我在平衡可玩性、剧情合理性、难度、教育能力上花了不小力气。

难点：六节结构带来的设计压力

这第一章总共6节，我每次写完一节都会缺乏灵感不知道怎么设计新的游玩内容。

毕竟一招用一整局那是官方教程会干的事，这个终归是个是个游戏，然后才是个教程——但它毕竟也是个教程。

于是我需要为每一节设计不同的操作逻辑来保证玩家新鲜感、不能让玩家卡关影响其学习积极性、玩家得有参与感不能纯看文本、不能让玩家在这个阶段写太多代码（用Terminal写程序那是上世纪才会干的事）、得让玩家能学到东西。在这些前提下，还得保证世界观自洽、作为引导者的系统既不能太聪明导致玩家全局按yes，也不能太蠢导致尬住、系统必须要在世界观框架下卡在它可能会卡住的地方，而不能硬卡、每次卡的地方需要不一样才能让玩家不至于“啊……又来”

在这种情况下，虽然我大体对这6节要写什么内容、系统大概处于什么阶段有个大概的概念，但是具体细节是写了一节后就不知道下一节还能写啥的状态。

方法：用 ChatGPT 当头脑风暴对象

所以我自然去戳ChatGPT了——逻辑能力比ChatGPT强的Claude只会工程代码，没啥创造性。而创造力比ChatGPT好的又没啥逻辑。

但是吧……虽然ChatGPT都快成白月光了，但是她在创造性上确实还是不太行，记性也不太行。以至于她总是在尝试使用我在前几节已经用过的方案，即使明确了要求，她也总是过度依赖第一节里用的“根据日志修系统”的设定。而对话再长一些，她就又忘了早些时候的要求。（看来我暂时不用担心她抢我工作）

于是整个过程本质上属于是对着小黄鸭头脑风暴，所幸这个小黄鸭能很好地整理我的思路，所以我还是得以吭吃瘪肚地搞定了第一章的内容。

不过在第一章剧本写完后，她在保证角色语气一致、优化玩家细节体验、避免出现章节间割裂、玩家心理落差等方面确实表现极佳——她甚至还看出来了其中一个人名RABOOF的梗！

我想在细化后续内容时，我也能使用这种模式，即将 ChatGPT 作为头脑风暴的小黄鸭，然后在方案定型后再由她规范语气、把控节奏。

瓶颈与问题清单

• 剧本完成后，我意识到设计当初根据大纲写的恢复程序框架有点死板了，下一期我得花大力气搞定这些交互式演出的Python脚本，其中一些还得用eval来保证玩家体验
  • 我确实可以去戳copilot claude，但是之前他没能很好地实现第一章的开始动画演出，而且第一节写得也有不少问题，扯皮两三轮后还是手改了一堆

下期计划（Next）

• 完成第一章
  • 更新当前交互脚本基础框架
  • 实现六节的脚本
• 重新审视目前的章节切换流程，确保其扩展到三章时不出大问题

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

TL;DR 概览

把Terminal的方案退回了真实Terminal，修了些第三方库的bug，然后爆改了第一章

本期目标

• 实现靠谱的Terminal
• 重构第一章游玩结构
• 完成第一章游玩内容

进展速记（Changelog）

新增：

• 无

变更：

• 回退到了真实Terminal方案
• 将最开始的“自动进行下一个教学”改成了“玩家需要手动依次触发相关教学”

修复：

• 修好了GodotXterm里野指针导致的高频偶现问题

主要进展内容

在详细分析后，发现一旦涉及执行外部程序并实时显示stdout，那么自建Terminal的问题就会多到难以置信，而且市面上也缺乏支持良好的——这本质上就是实现正经Terminal了

所以最后还是切回了真实Terminal的方案，并借助Copilot修好了那个间歇性好使间歇性不好使的问题。问题路径是

• 在获取cwd_ 参数时，使用了const char* cwd_ = p_cwd.utf8().get_data();
  • .utf8()创建一个临时的 UTF8 buffer（CharString）
  • .get_data()取出它的内部 char*
  • 临时对象被销毁
  • cwd_ 指向已经释放的内存 → 悬空指针
• 随后又使用std::string helper_path = p_helper_path.utf8().get_data();
  • .utf8()再次分配到了cwd_ 指向的内存上
• 在CreateProcess时引用cwd_ 作为工作目录
  • helper_path 是一个可执行程序，而非目录
• ConPTY进程创建失败

然而上面那个并非唯一问题，因为它没有正确处理pipe，导致同一个PTY对象只能fork一次。虽然每次instantiate也不是不行，但还是借助Copilot+Claude给修了


然后就是剧本和一开始有差异。最开始的设计中，我使用“自动依次执行对应的python教学脚本”的方式。但我试玩了一下发现这样很无聊。所以加了俩自定义命令diagnose和manualfix，来分别展示目前修复进度和调用教学脚本。虽然玩家的游玩路线没有变，而且本质上是增加了麻烦，但是自己执行命令来启动脚本对于新手来说应该还是有些意思的，而且即使对于老手应该也能冲淡一个个教学脚本带来的粘滞感

再之后就是我重写了第一章的前两节，之前的剧本有点太挫了，没有很好地和游戏世界观相融合，所以我正在整个重写

瓶颈与问题清单

下期计划（Next）

• 完成第一章游玩内容
  • 这个真得完成了，都TM拖3期了

试玩版

暂未达到第一个试玩版的发布标准

TL;DR 概览

Fuck Terminal

本期目标

• 修好Terminal输入光标歪的问题

• 修好OSWindow点击时不会移动到最前方的问题

• 搞定第一章的主要游玩内容

• 看情况进行可玩性打磨

进展速记（Changelog）

新增：

• 无

变更：

• 我受够在游戏里集成真实Terminal的幺蛾子了，我要搞虚拟Terminal了

修复：

• OSWindow点击时不会移动到最前方
• 演出脚本有命令输入回显

主要进展内容

之前怎么修都没修好OSWindow点击时不会移动到最前方的问题，主要是思路错了。我之前一直以DOM的那种“捕获从外向里的事件，处理后继续往里传递”的风格写程序，但是GDScript只有从里向外冒泡的阶段，这就导致我怎么打补丁都打不对。

真正靠谱的方案是在WindowManager里在_input时遍历所有窗口，确定点击的是哪个窗口，然后根据这个信息来改变OSWindow的层级，而非让OSWindow自己去处理

然后……没了

这个Terminal切成自己的之后，问题依旧一大堆，主要原因是

• GDScript不像python那样有良好的utf8支持，需要手动处理各种字符问题
• 命令执行需要新的映射方式，且需要调整Terminal的模块架构以适应当前展示、执行、命令翻译分离的状态
• 当前样式不满意，十分不Terminal，我在考虑再检查下市面上的，看看有没有可以参考的实现。
  • 或者我干脆直接用Xterm.js？但这样外部进程通信又是个麻烦……我再看看吧

瓶颈与问题清单

• Terminal实现受阻，但真实Terminal确实是不可行的。因为我解决不了它间歇性好使间歇性不好使的问题。
  • 或者也许我能解决？但我需要先试试自建Terminal，实在不行再去折腾其他人代码仓

下期计划（Next）

• 实现靠谱的Terminal

试玩版

暂未达到第一个试玩版的发布标准

TL;DR 概览

能正常进第一章了，而且脚本框架已经完成，除了一些样式问题之外已经能支持第一章的完整游玩了

本期目标

• 把第一章的剧本搞清楚

  • 共同流程
  • 背景设定
  • 具体剧情

• 把第一章的切换逻辑搞定

进展速记（Changelog）

新增：

• 实现了统一的场景加载器，并将之前的关卡切换和进度管理做了相应的配套

变更：

• 优化通知对话框

修复：

• 任务间过渡逻辑有一堆问题
• OSWindow点击时不会移动到最前方（没完全修好）
• OSWindow的缩放很难点中
• 忘记给第一章的脚本任务加任务要求了，结果一瞬间全完成了
• Terminal无法正常显示中文文本

主要进展内容

大范围重构了场景切换框架，现在可以更灵活地以任务为驱动配置各种场景切换了。

得益于这项重构，先前十分复杂的恢复模式（即第一章玩法）加载与维护变得十分简单。

写好了第一章的剧本框架，其设定是

• ProxyOS自删除失败，进入自恢复模式
• 因为玩家使用的Windows系统不在ProxyOS的适配范围内，自恢复失败
• ProxyOS知道自己需要怎么组合特定的逻辑来重新编译自己，也可以使用玩家系统上的脚本语言解释器生成对应的程序。但是它无法仅仅从日志中拿到的只言片语中推断出其通用语法，因此需要管理员帮助
• ProxyOS要求管理员使用可用的脚本语言解释器编写对应的示例逻辑，以便其重构自身

通过这种方式，可以合理地向玩家展示如何将自然语言映射为编程语言（ProxyOS要求管理员参考之前的日志编写对应的基础逻辑块），让玩家知道“编程语言只是用于编程的语言，不是什么魔法，也远比英语简单”

目前的玩法已经能支持内容填充了，下期我将主要专注于问题修复和第一章的具体游戏内容

瓶颈与问题清单

• Terminal输入光标歪
• OSWindow点击时不会移动到最前方，做了修复后只有滚轮在外框上操作时能移到最前方

下期计划（Next）

• 修好Terminal输入光标歪的问题
• 修好OSWindow点击时不会移动到最前方的问题
• 搞定第一章的主要游玩内容
• 看情况进行可玩性打磨

试玩版

暂未达到第一个试玩版的发布标准

TL;DR 概览

又停了一天电，还有一天不舒服咕了，进度延迟……主要进展为进行了完整游玩测试，修了一大堆问题，优化了一堆组件

本期目标

• 跑一遍以确保基础的存档功能正常工作
• 把第一章的脚本要写哪些搞清楚
• 把第一章的切换逻辑搞定

进展速记（Changelog）

新增：

• 上期新增的支持数据段和链接的文本组件现在支持Markdown了
• 新增了两个任务之间过渡的动画

变更：

• 优化任务系统，修正了可能导致稳定性下降与性能下降的不一致逻辑
• 优化窗口系统，现在打开窗口时窗口大小取决于屏幕大小，更加自然
• 优化存档系统，需要后台运行的应用现在都使用Manager+Display的模式了，Manager管理存档和数据更新，Display根据更新信号来修改显示
• 优化通知系统，统一了消息对话框样式
• 优化链接处理模块，现在它更好配置了

修复：

• 存档保存异常

• 存档加载异常

• 文本查看器不知道啥时候没法滚动

• 拖动数据段功能在上次更新样式后炸掉了

• 完成任务时出现了如下异常

  • TaskRequirementNode发出data_dropped信号
  • TaskManager进入submit_data_segment_to_requirement方法
  • submit_data_segment_to_requirement中check_and_update_task_status时，解锁了下一个任务，任务解锁时发出了task_updated信号（下一个任务）
  • submit_data_segment_to_requirement中check_and_update_task_status后的下一句又是发送task_updated信号（当前任务被完成）
  • Pocket在接到下一个任务的task_updated时触发了NavigationWindow的内容更新，创建了一个TaskContent，但因为其初始化方法通过call_deferred调用，新的TaskContent还没有初始化，而旧的TaskContent也还没有删除
  • 新老两个TaskContent接到完成任务的task_updated，因为新TaskContent还没初始化，发生了异常

• 进入第一章的对话框文本显示异常

主要进展内容

进行了完整游玩测试，修了一大堆问题，优化了一堆组件

没了

本以为上一期已经把地基打牢了，但是游玩测试中发现了远比单元测试更多的问题，比如

• 任务完成和任务发布之间没有间隔，体验十分怪异
• 默认的窗口大小（800*400）无法正常显示任务要求访问的网页
• 任务里的网页链接写错了
• 有些应用在保存未使用的存档文件，而还有些应用的存档时机不对
• 在任务完成和任务发布的间隔中，存在时序问题导致创建了异常的任务详情节点
• 默认的文本框组件单行文本过长时不会换行

除此之外，我发现一开始我把 Desktop 当成主场景有些欠考虑了，因为第一章的场景并不在Desktop上发生，需要一个新的场景（或者直接用TaskManager加载覆盖Desktop的第一章场景？）

下一期我会优先写好剧本，然后按照剧本进行相关功能的检查与开发，避免再次像本期一样把时间浪费在返工上

瓶颈与问题清单

暂无

下期计划（Next）

• 把第一章的剧本搞清楚
• 把第一章的切换逻辑搞定

试玩版

暂未达到第一个试玩版的发布标准