TL;DR 概览

第二章剧情细节、激励点设计、谜题设计都完成了，理论上绝大部分内容都可以复用现有逻辑完成，只需要让脚本执行机制更自由些

本期目标

• 细化第二章剧本，使其足以确认我需要实现哪些机制
• 思考当前界面如何进行优化

进展速记（Changelog）

本期假设 / 预期

我当时以为世界是怎样的？ 这个预期中，哪一条被证伪 / 被削弱 / 被确认？

• 我应该可以很容易地把之前在PureWriter里写的故事稿转化成剧本
  • 实际上其颇为自嗨，需要做很多润色来插入激励点，并让整体风格、设定一致
• 我可以模仿win11搞UI
  • 实际上因为编程内容需要使用外部编辑器，这个游戏需要使用窗口化执行，而这个和类win11的UI是有很大冲突的，我可能需要重做UI设计

本期确定性变化

哪些东西现在「更确定」或「被明确否定」了？ “确认 X 不可行” “删掉 Y 抽象” “意识到 Z 是伪问题”

新增：

• 第二章剧本

变更：

• 调整先前的故事脉络，使其激励点布局更合理
• 调整部分故事内容，使其更加真实也更加符合世界观

修复：

删除：

• 当前的UI确实不能接受，接下来两期需要想一个方案出来

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

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

大部分剧情初稿都有重做

先前第二章的剧情是

• 玩家因为神秘人的帮助修好了ProxyOS
• 神秘人建议玩家去论坛找更靠谱的防护套件
• 玩家在论坛找到了玄云观的招新信息
• 玩家通过测试开始作为外包人员接玄云观派的活，在这个过程中训练编程技能并逐渐与这个世界产生联系
• 玩家发现了轻聊，并按照其文档实现了一个消息处理器，得以看到已死用户与其好友看似正常的聊天中的隐藏信息，进而卷入纷争中，进入第三章

这个剧情我写得很嗨，但是实际上其几乎把能踩的坑全踩了一遍

TL;DR 概览

正式接入了ANORA，完成了第一章的所有机制，同时完成了其内容草稿。

本期目标

• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

进展速记（Changelog）

本期假设 / 预期

我当时以为世界是怎样的？ 这个预期中，哪一条被证伪 / 被削弱 / 被确认？

• 我应该可以通过ANORA上预留的IPC和godot-wry的IPC机制对接
  • 实际上其遇到了单页面应用不兼容、IPC协议不兼容的问题需要解决
• 脚本机制已经完善了，只需要填内容
  • 实际上交互机制实际试玩了才会发现根本一坨，于是重构了

本期确定性变化

哪些东西现在「更确定」或「被明确否定」了？ “确认 X 不可行” “删掉 Y 抽象” “意识到 Z 是伪问题”

新增：

变更：

• 优化1-3关关卡脚本，尝试加强剧情张力
• 调整IPC传输的数据模型，使其更加符合一般习惯

修复：

• 脚本完成后因为midware不对导致任务没有正常完成
• ANORA的IPC初始化始终未执行
• ANORA的IPC不兼容godot-wry

删除：

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

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

调整第一章的Typewriter模式

先前使用如下输出循环

• 逐字输出一句话
• 指定延迟多久后继续执行

而这个方案存在明显问题：有时候同一个角色的一次发言需要分多行，这种情况下多行之间是不应该有延迟的

于是我尝试了使用一个状态机来维护什么时候有延迟、什么时候忽略。并将默认延迟根据平均阅读速度按字数计算，以自适应延迟

TL;DR 概览

状态不太好，本期咕了一半，下一期咕了。

本期目标

• 优化1-3关关卡脚本
• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

进展速记（Changelog）

新增：

变更：

• 优化1-3关关卡脚本，尝试加强剧情张力

修复：

• 脚本完成后因为midware不对导致任务没有正常完成

主要进展内容

本期4天实际上有效工作时间只有1天，感觉状态不太对劲，我需要歇一期

倒也不是说进入瓶颈、遇到啥难以解决的问题导致做不下去，只是单纯的突然觉得有些累需要休息下

原本设计上我应该先搞定第一章再歇的，但今天起床难度都和上班差不多了，所以我觉得最好还是别撑，先调整下

瓶颈与问题清单

• 暂无

下(下)期计划（Next）

• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

试玩版

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

TL;DR 概览

ANORA初步集成进了Godot，但是并没有搞定所有的适配问题。游戏的演出内容仍需优化

本期目标

• 增强ANORA录制
  • 精简回放界面
  • 使用IPC指定初始化时加载文件
  • 让外部程序可以用IPC控制播放（继续下一个关键帧.etc）
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

进展速记（Changelog）

新增：

• ANORA 回放模式的IPC
• ProxyOS 集成 ANORA

变更：

• 优化了第一关的文本，使其更加符合世界观设定，逻辑上更加通顺
• 优化了逻辑图参考，现在不用逻辑图的时候它可以自动收起来，用的时候再展开

修复：

主要进展内容

ANORA已集成进Godot，但由于逻辑图第三关才用到，而第一关的文本就很糟糕，所以花了不少时间优化第一关的文本。

不过整体进度还算符合预期，上一期重构的ANORA架构让IPC十分好做，所以本期基础目标仍然按时达成了

瓶颈与问题清单

• 暂无

下期计划（Next）

• 优化1-3关关卡脚本
• 适配相关关卡脚本
  • python脚本输出特定指令控制GDScript控制逻辑图

试玩版

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

TL;DR 概览

ANORA的回放功能（无UI模式）将将完成，但还需要适配

本期目标

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

进展速记（Changelog）

新增：

• ANORA 录制模式

变更：

• 使用状态机增强了执行器的运行逻辑，现在支持单步执行
• 优化了节点显示，现在执行状态的显示不会再导致节点抖动

修复：

主要进展内容

ANORA的逻辑图执行的录制回放已完成，速度低于预期，导致没来得及集成进Godot。

进度状态不佳的主要原因

• 最初我把录制回放视为单独的模块了，但是实际上录制回放本质上应该是侦听执行器事件、模仿执行器发事件。这个实现思路差异在前两天导致了大量的状态不一致的debug和返工
• 设计时没有明确各个vue模块、composition的边界，导致回放和主图的加载分别实现了两套反序列化逻辑
• 最初想简单了，想要按事件设Carousel，但是忘了port值变更、节点状态变更、边传值都是高频发生且强绑定的，导致实际易用性糟糕不得不重构

下次需要更正的地方

• 实现任意模块前先思考下其和现有模块的关系，然后尽量复用、增强现有模块，避免出现一个功能多个实现
• 需要预估数据量和分布，然后选择恰当的交互模块

瓶颈与问题清单

• 暂无

下期计划（Next）

• 增强ANORA录制
  • 精简回放界面
  • 使用URL指定初始化时加载文件（或者其他方式？）
  • 让外部程序可以用IPC控制播放（继续下一个关键帧.etc）
• （有时间的话）适配相关关卡脚本
  • （有时间的话）python脚本输出特定指令控制GDScript控制逻辑图

试玩版

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

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）

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

试玩版

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