TL;DR 概览

通过头脑风暴应该算是找到了第一章的解，并进行了初步的设计

前一期提到的系统变更已完成，但未测试，准备等这一批待办都完成后统一测试

本期目标

• 想清楚问题清单里的问题
• 搞定 045 期提及的系统变更
• 把 demo 从 alpha 打磨到 beta
  • 把 ProxyOS 打成 Proxy OS 造成了预料之外的换行
  • 序章
    • 玩家一开始得到的信息太少，以至于缺乏目标和对世界观的了解。工作手册又因为其形式难以让玩家代入，导致玩家不清楚自己在做什么，即使发现用户死亡也困惑大于惊讶
      • 考虑让玩家短暂扮演那格式化前的上一任节点（和 ghostine、何澈的短暂交流，随后被格式化），而非一开始就让玩家两眼一抹黑当格式化后的节点
    • 基准测试报告需要更新
    • 【待确认方案】到第一章过渡比较生硬（一个待确认对话框，先前被认为有助于渲染突然、无措的情绪，但当前氛围感不足以支持），考虑增加演出
    • 初始化任务
      • 工作手册太繁琐，把 界面组件 和 核心工作流程 两段合并，核心工作流程每一步都象当前一样指向对应区域。演示图用符合当前情况的，并省略具体名称。其余提及 POCKET、ARCHIVE、SPIDER 的任务资源也需要对应修改
    • 摄像头任务
      • 我得在数据段的部分提下图片也可以点，并在任务描述里也写下，避免用户在第一章末尾看到图片不知道怎么操作
  • 第一章
    • 系统恢复操作指南 的认知负担太重，直接去掉整个 系统恢复操作指南，然后使用一个独立的、默认启动的程序来带着玩家敲一遍，完事之后再让玩家用 diagnose 和 manual fix。
    • xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
    • xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
    • 【待确认方案】要在玩家以自己的意愿想做某件事但因为经验不足不知道如何行动时，提供教学来让玩家解决困难，并让玩家在跟随教学的过程中获得经验，同时避免灌输的感觉
      • 我应该还需要在恢复演出脚本里额外加个变量存在性检查，在玩家输错的情况下帮助快速定位问题
      • 需要添加 exception 转译，把异常翻译成人话，避免 indent 和 not defined 之类的搞晕玩家（而且说实话它们确实对初学者不友好）
      • CD
        • 流程图需要给每个节点写个中文名，并在导出时设置 i18n 使其他部分为中文
        • “if 后面需要有冒号”容易让玩家写出“if:a>1”
        • 有些引导需要加强
          • 用户没赋值，而是直接把“ask_new_plan”当表达式了
          • 需要提及“ask_new_plan”等变量已被赋值为默认值 False，所以只需要设置 True 的，不用自己写设置 False 的
          • 用户写出了如下内容，其疑惑为“那我这个 ask new plan 怎么会也是 True？明明结果是大于零的”，也许我应该描述下”等效“相关的内容

            • make_schedule=True;ask_new_plan=True
              if tomorrow_todo_count>0:
              make_schedule
              else:
              asknew_plan

      • DS
        • 玩家没能理解 todo_list[1] 为什么能获取到 todo_2，需要使用 main_todo 之类的不容易产生误解的变量名
        • 玩家没能理解实际使用时执行的语句，需要提供完整代码段，而不是把两句代码分散在文字中
        • 玩家认为使用原始数据而非将其整合也没啥原始的，需要补充相关描述
      • LP
      • FN
        • 重新设计
  • 第二章
    • 将编程手册提前到第二章开始，而不是第一个任务完成后
• beta 打磨完成后
  • 开个 itch
  • 琢磨下宣传

进展速记

本期假设 / 预期

预期：

我应该想清楚第一章应该是什么样的，这是核心

然后我需要大致给出一个第一章怎么改的方案

结果：

搞定了

本期确定性变化

新增：

变更：

修复：

删除：

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

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

上一期留下的问题清单：第一章应该是什么样的

要在玩家以自己的意愿想做某件事但因为经验不足不知道如何行动时，提供教学来让玩家解决困难，并让玩家在跟随教学的过程中获得经验，同时避免灌输的感觉

教学本身就应该是玩法，而不是需要剧情来“中和”的内容。

这种时候就该头脑风暴了

结论

核心判断：

• 放弃终端写代码，改用内部编辑器。 内部编辑器绝大部分代码锁定，只留出固定空行供玩家填写，同时提供报错解释面板，避免开放解空间、避免缩进问题，也天然支持语法着色和变量监视
• 安全内核定位重设： 从"一起探索 Python 的同事"变成"底线灵活、系统可用第一的活泼恢复助手”。通过 Ghostine 留下的 SPIDER 定制工具，以"黑客折腾系统"包装教学场景，玩家驱动力源于"想折腾"而非"被要求学"
• “手把手教"与"不被灌输"不矛盾： 只要玩家的 X（折腾系统/当黑客）是真实驱动力，编程就是克服障碍 Y 的自然工具，不会产生被灌输感。关键在于保证 X 足够真实、Y 足够清晰直观
• 编程教学顺序固定： 变量声明/赋值 → 变量参与计算 → 分支 → 数据结构 → 循环 → 函数，每个大概念需拆解子概念，避免认知并发过载
• 流程图第一章不出现，留待玩家理解语法后作为可选新视角引入
• 第一章整体流程： 系统反复崩溃重启 → 恢复模式终端（玩家 diagnose + systemctl start recovery-assistant）→ 安全内核唤醒并与内部编辑器一起出现 → 玩家修改 username 完成注册成为合法用户 → 图形界面恢复但各模块显示未连接 → 循环：安全内核发现问题、调出代码、玩家填写空行、模块逐一恢复正常
• 剧情细节不堆主线，设定、背景放论坛帖子和散装文件，主线保持动力清晰

瓶颈与问题清单

哪些问题还没解，但也许我已经知道“它们不是什么”？

下期计划

• 把 demo 从 alpha 打磨到 beta
  • 序章
    • 玩家一开始得到的信息太少，以至于缺乏目标和对世界观的了解。工作手册又因为其形式难以让玩家代入，导致玩家不清楚自己在做什么，即使发现用户死亡也困惑大于惊讶
      • 考虑让玩家短暂扮演那格式化前的上一任节点（和 ghostine、何澈的短暂交流，随后被格式化），而非一开始就让玩家两眼一抹黑当格式化后的节点
    • 基准测试报告需要更新
    • 【待确认方案】到第一章过渡比较生硬（一个待确认对话框，先前被认为有助于渲染突然、无措的情绪，但当前氛围感不足以支持），考虑增加演出
    • 初始化任务
      • 工作手册太繁琐，把 界面组件 和 核心工作流程 两段合并，核心工作流程每一步都象当前一样指向对应区域。演示图用符合当前情况的，并省略具体名称。其余提及 POCKET、ARCHIVE、SPIDER 的任务资源也需要对应修改
    • 摄像头任务
      • 我得在数据段的部分提下图片也可以点，并在任务描述里也写下，避免用户在第一章末尾看到图片不知道怎么操作
  • 第一章
    • 系统恢复操作指南 的认知负担太重，直接去掉整个 系统恢复操作指南，然后使用一个独立的、默认启动的程序来带着玩家敲一遍，完事之后再让玩家用 diagnose 和 manual fix。
    • xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
    • xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
    • 【待确认方案】要在玩家以自己的意愿想做某件事但因为经验不足不知道如何行动时，提供教学来让玩家解决困难，并让玩家在跟随教学的过程中获得经验，同时避免灌输的感觉
      • 我应该还需要在恢复演出脚本里额外加个变量存在性检查，在玩家输错的情况下帮助快速定位问题
      • 需要添加 exception 转译，把异常翻译成人话，避免 indent 和 not defined 之类的搞晕玩家（而且说实话它们确实对初学者不友好）
      • CD
        • 流程图需要给每个节点写个中文名，并在导出时设置 i18n 使其他部分为中文
        • “if 后面需要有冒号”容易让玩家写出“if:a>1”
        • 有些引导需要加强
          • 用户没赋值，而是直接把“ask_new_plan”当表达式了
          • 需要提及“ask_new_plan”等变量已被赋值为默认值 False，所以只需要设置 True 的，不用自己写设置 False 的
          • 用户写出了如下内容，其疑惑为“那我这个 ask new plan 怎么会也是 True？明明结果是大于零的”，也许我应该描述下”等效“相关的内容

            • make_schedule=True;ask_new_plan=True
              if tomorrow_todo_count>0:
              make_schedule
              else:
              asknew_plan

      • DS
        • 玩家没能理解 todo_list[1] 为什么能获取到 todo_2，需要使用 main_todo 之类的不容易产生误解的变量名
        • 玩家没能理解实际使用时执行的语句，需要提供完整代码段，而不是把两句代码分散在文字中
        • 玩家认为使用原始数据而非将其整合也没啥原始的，需要补充相关描述
      • LP
      • FN
        • 重新设计
  • 第二章
    • 将编程手册提前到第二章开始，而不是第一个任务完成后
• beta 打磨完成后
  • 开个 itch
  • 琢磨下宣传

试玩版

暂缓，第一次上传需要做好准备，等进入 beta 阶段再说

• ProxyOS
• DevLog

• ProxyOS
• 周报
• 独立游戏开发
• 技术日志