Proxyos Weekly 045

Laurence-042

- 5 minutes read - 909 words

TL;DR 概览

好兄弟来帮忙做了 alpha 测试，没好兄弟的话我就凉了

当前很多设计存在问题（不只是上期提到的游戏核心任务循环），很多地方需要重新调整

第一章需要重做，但方案尚未确定

本期目标

  • 确定游戏核心任务循环的优化方案
  • 根据玩家反馈修 bug、优化 ux
    • 把 ProxyOS 打成 Proxy OS 造成了预料之外的换行
    • 最小化后无法恢复
    • 序章
      • 玩家一开始得到的信息太少，以至于缺乏目标和对世界观的了解。工作手册又因为其形式难以让玩家代入，导致玩家不清楚自己在做什么，即使发现用户死亡也困惑大于惊讶
        • 考虑让玩家短暂扮演那格式化前的上一任节点（和 ghostine、何澈的短暂交流，随后被格式化），而非一开始就让玩家两眼一抹黑当格式化后的节点
      • 到第一章过渡比较生硬（一个待确认对话框，先前被认为有助于渲染突然、无措的情绪，但当前氛围感不足以支持），考虑增加演出
        • BGM？
        • TypeWriter？
        • 在这之前营造更多氛围感？
          • 要给真实编辑器让路，不像 类 owell 那样可以使用很多美术资源堆氛围感
          • 音效的支持比较有限
          • 叙事部分在序章和第一章也都非常受限，这个我没有很好的方案来解决
      • 初始化任务
        • 工作手册太繁琐，把 界面组件 和 核心工作流程 两段合并，核心工作流程每一步都象当前一样指向对应区域。演示图用符合当前情况的，并省略具体名称。其余提及 POCKET、ARCHIVE、SPIDER 的任务资源也需要对应修改
      • 摄像头任务
        • 说删除 class=“blocked-overlay” 的时候，用户容易误解成样式筛选器里的".blocked-overlay"，优化相关描述，使用完整 element html，并移除 ctrl+f 的相关描述（一般只要用户用 检查 打开 devtool，不太可能找不到 blocked-overlay，但 ctrl+f 后反而可能被聚焦后显示的额外信息干扰）
        • 需要提醒用户在编辑 style 后按下 enter 以确认修改
        • 我得在数据段的部分提下图片也可以点，并在任务描述里也写下，避免用户在第一章末尾看到图片不知道怎么操作
        • 有时候用户的 devtool 打开后控制台没有正常显示在最下方，需要点上面的 tab，这可能对第二章产生影响
    • 第一章
      • 系统恢复操作指南 的认知负担太重，直接去掉整个 系统恢复操作指南，然后使用一个独立的、默认启动的程序来带着玩家敲一遍，完事之后再让玩家用 diagnose 和 manual fix。
      • 要在玩家以自己的意愿想做某件事但因为经验不足不知道如何行动时，提供教学来让玩家解决困难，并让玩家在跟随教学的过程中获得经验，同时避免灌输的感觉
        • 当前叙事存在很大问题，需要调整。当前的每个模块的演出基本是 介绍背景-介绍技术-插科打诨-玩家操作。介绍背景的文案很疏离，而技术部分又偏干，以至于玩家无法在插科打诨部分代入，以至于出现了“用不耐烦的心态看质量有限的剧情对话”的情况，而且操作部分变数太大，玩家很容易想多导致做出预期之外的行为，并导致卡关
        • 考虑调整背景，让安全内核当导师而非工友，让它给玩家讲自己为什么要写这些代码，并通过对话选项来应对玩家的各种问题，而不是让玩家在缺少补全功能、缺少即时错误校验、对编程不是很了解、报错可能超出作者预期的情况下写大段代码？
      • 我没考虑到终端被垂直放大的情况下，float_input 的显示行计数会出问题，导致它没显示在本该在的地方，必须滚动到最下面才能重新出现
        • 临时修复，根因需要动 xterm
      • xterm 的 col 似乎计算不太对劲，有时候一行末尾的字只显示了一半，需要看下 xterm 实现，必要的话进行修复
      • xterm 的 cursor_pos 在 cursor 不在视野内时返回末行 pos 是个 bug，而且在外面基本没法绕，只能修 xterm
      • 我应该还需要在恢复演出脚本里额外加个变量存在性检查，在玩家输错的情况下帮助快速定位问题
      • 需要添加 exception 转译，把异常翻译成人话，避免 indent 和 not defined 之类的搞晕玩家（而且说实话它们确实对初学者不友好）
      • PythonExecutor 的 path 没写对，没包含游戏本体里的 ipc
      • EA
        • 优化非法代码输入的更正引导（至少 a=1 呢）
        • 难度下调，让玩家只输入 username=“xxx"也能过，但是输全了给个彩蛋啥的
      • MC
        • 对于表达式的描述可以精简一些
        • 漏了比较表达式
      • CD
        • 第一章我应该直接把宽度固定 20%，高度固定 100%，整页一个终端，然后在需要流程图的时候打开个宽度 80%的新窗口拼在页面右边。以此避免玩家调整布局导致看不到流程图
        • 流程图需要给每个节点写个中文名，并在导出时设置 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
        • 细化 elif 描述
      • DS
        • 玩家没能理解 todo_list[1] 为什么能获取到 todo_2，需要使用 main_todo 之类的不容易产生误解的变量名
        • 玩家没能理解实际使用时执行的语句，需要提供完整代码段，而不是把两句代码分散在文字中
        • 玩家认为使用原始数据而非将其整合也没啥原始的，需要补充相关描述
      • LP
        • 没用提及 len 的含义，导致玩家无法理解各个方案的实际含义
        • while 和 for 对于非英语母语者来说含义并不直观，需要明确点出各个方案的实际语义
        • LP 应该以脚本演出为主，这样我能塞下更多示例，也能让玩家更好的理解。否则即便我使用“口述遍历 todo_list 中的所有元素，并打印每个元素。使用 print(todo) 可以打印变量 todo 的值两句逻辑，让玩家对照着写两行”都可能出现如下各种潜在异常
          • 玩家自己写了 todo_list 的初始化导致覆盖了原先的
          • 玩家没理解 print(todo) 的用途，而是参照之前的示例写了 # 检查 todo 并通知延期风险的流程
      • FN
        • 重新设计

          • 玩家反馈

            • 这个函数
讲到这的时候有个问题了
因为函数部分本身比较难
既提到 proxyos 又提到 python
虽然能增加代入感
但是让人应接不暇
这一大堆文本下来
我已经陷入过载了
这根本不是二十分钟的问题
而一旦人脑过载
就完全不会觉得这是个游戏
更是会让代入感消失的

          • 这个问题的根因是

            • 函数本身对初学者是个理解难点，即使是很多偏硬核编程游戏都会尽量避免出现函数内容。
所以为了解决这个难点，我必须把它放在仍可以用大段文本交互来介绍的第一章，如果放到第二章，玩家将不得不在需要理解任务需求的前提下学函数，这反而会让理解难度更高。
但即使在第一章，为了讲清楚函数本身的特性、优势，大段的文本仍会显得像是说教。
所以我尝试添加背景是 proxy，但实际上完全为函数本身服务的相关逻辑图，以此来冲淡说教感。
但看起来效果不佳

          • 其可行解决方案之一是

            • 十分有价值的反馈！

实际上这和我的设计预期产生了很大差异，
我本认为必要的娱乐性需要由剧情补充，但你给出了一个观点：
教学内容做顺畅+关键交互点让玩家处理 同样可以提供娱乐性。

这是我没想到，而且确实合理的。

另外，其实我一开始以为 2-5 没任何难点，只有 1 的拼接和 6 的 if 存在困难，而 6 的困难大于 1，结果实际玩家能顺利完成 6 但却在 1-5 上遇到了很多问题。
这些问题很多是因为叙事部分对思路的干扰和没先验知识的前提下对代码的误解，这应该可以通过缩减叙事、优化代码展示/解释的表现方式、更合理地安排玩家介入的点来解决
    • 第二章
      • 将编程手册提前到第二章开始，而不是第一个任务完成后

进展速记

本期假设 / 预期

预期：

准备本期开个 itch，好兄弟来帮忙测试了，他应该会提出不少问题，优化后就能上 itch 了

结果：

卧槽这么多 ux 问题，好兄弟不愧是好兄弟，

虽说准备本期开个 itch，但是帮忙测试 demo 的好兄弟发现了很多 ux 问题，这样发肯定是不行的

这么发了之后恐怕是直接进 itch 的垃圾分区了

我得解决这些问题才行——但有些问题我一时间想不到解法

本期确定性变化

新增：

变更：

  • 本期目标 中已标记的

修复：

  • 本期目标 中已标记的
  • SimpleChat 插件工作不正常，但之前因为一个预期之外的绝对路径配置使其没有表现出问题
  • 窗口默认比例用了 screen_size 而不是 screen_usabel_size 导致被任务栏遮盖
  • 重新加载插件前，应该_ensure_plugin_environment 一次，避免用户修改 beautiful_filter 内容

删除：

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

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

游戏循环优化方案

当前逻辑：

  • A 任务完成
  • ChapterEvent 系统+来自任务系统的任务完成信号：
    • NPC 回应消息排入时间轴
      • 通常基于 A 完成时间 + 至少半小时
  • 时间系统+用户主动触发：通过“结束当前循环”推进到下一天
  • 任务系统+循环步进回调：依赖 A 的 B 任务静默解锁并显示给玩家
  • ChapterEvent 系统+来自任务系统的任务解锁信号：
    • B 任务 NPC 任务发放通知消息排入时间轴
      • 通常基于 A 完成时间 + 至少 1 小时，会通过 ChapterEvent 事件编排使其和前置任务回应消息间隔至少 1 小时
    • 显示来自控制节点的任务详情通知
  • 消息系统+循环步进回调：将时间轴上早于当前时间的消息发送到 SimpleChat
  • SimpleChat+用户主动打开：消息按时间轴出现

这就导致玩家总是先于消息看到任务和控制节点的任务详情通知，这十分致命

新逻辑：

  • A 任务完成
  • ChapterEvent 系统+来自任务系统的任务完成信号：
    • NPC 回应消息排入时间轴
      • 通常基于 A 完成时间 + 至少半小时
    • 在最后一条消息的时候编排一个“在指定时间插入唤醒点”的 action（通常比最后一条消息晚 10 分钟）
  • 任务系统+任务 A 完成的回调：依赖 A 的 B 任务静默解锁（当前状态下玩家不可见）
  • ChapterEvent 系统+来自任务系统的任务解锁信号：
    • B 任务 NPC 任务发放通知消息排入时间轴
      • 通常基于 A 完成时间 + 至少 1 小时，会通过 ChapterEvent 事件编排使其和前置任务回应消息间隔至少 1 小时
      • 需要注意 A 的完成信号和 B 的解锁信号会导致几乎同时触发两次 ChapterEvent 系统，需要在 ChapterEvent 系统编排好事件
    • 在最后一条消息的时候编排一个“在指定时间插入唤醒点”的 action（通常比最后一条消息晚 10 分钟）
      • 如果新的唤醒点比某个旧的唤醒点时间晚，而且间隔不超过 10 分钟，移除那个旧的
  • 时间系统+用户主动触发：通过休眠维护推进时间，推进到第一个唤醒点
  • 消息系统+时间前进事件：将时间轴上早于当前时间的消息发送到 SimpleChat
  • SimpleChat+用户主动打开：消息按时间轴出现
  • SimpleChat+用户主动滚动：玩家滚动到 B 任务通知消息
    • 动效高亮 + 自动弹出"已总结为任务"通知
    • B 任务在 POCKET 中变为可见
    • 发送任务发放信号
  • 任务系统+任务发放信号：发放任务 B
  • ChapterEvent 系统+来自任务系统的任务发放信号：显示来自控制节点的任务详情通知

也就是说任务的生命周期有 4 个状态：

  • 未解锁（前置要求未完成）
  • 未发放（不可见）
  • 进行中（可见）
  • 已完成

实际上，这本质上是

事件 → 推进世界状态 → 派生消息 / 任务

这种以事件为底层逻辑、任务和消息为表现层的一种子集模式

我这个方案本质上是复用了任务“可隐藏，彼此之间有前后顺序，但具体间隔时间不一定”的特性，将其当作事件 DAG 使用了，然后通过可隐藏 TaskRequirement 做任务内的进度控制。

让任务承载世界状态、将任务发放与完成作为核心事件的这种方式有优点也有缺点。

优点主要是十分方便，省去了很多“任务 A 完成的事件触发状态变更，使 B 可以被发放，然后玩家做了什么操作导致 B 被发放”的样板代码，全都统合到了任务系统内部。而且结合隐藏任务，也可以当真正的事件用。

缺点是有一些理解成本，而且有时候必须使用隐藏任务来做触发，反而更加复杂。

但我目前认为其优点明显大于缺点

为了处理上述调整，系统需要做以下变更

项目当前修改后
TaskManager在“结束循环”时激活并发放任务在前置任务完成时激活任务但不发放
ChapterEvent/添加新的 action，这个 action 用于添加唤醒点
时间系统/添加唤醒点管理
添加事件前进事件
SendMessageAction使用 delay+baseTimeType+realDelay+taskId（仅在基于任务延迟时起效）+cap将偏移抽取为单独的 Resource 类型，使用 baseTimeType+delay+isRealTime+taskId（仅在基于任务延迟时起效）+dawnCap/nightCap（用于避免 npc 在半夜发消息，默认是循环开始后 8 小时和循环结束前 0 小时，需要在计算时注意每个循环长度不一定一样）+dawnJit/nightJit（用于避免 npc 总是在固定时间发消息），添加唤醒点的 action 也会使用响应的延迟配置 Resource
TaskManager任务状态为 未解锁、进行中、已完成任务状态为 未解锁、未发放、进行中、已完成
游戏时间推进系统“结束当前循环”是主动推进大量时间到下一循环，
“休眠维护”是保存并退出游戏+被动推进少量时间（取决于离线时间）		“睡眠直到被唤醒”是主动推进大量时间到唤醒点，
“休眠维护”是保存并退出游戏+被动推进少量时间（取决于离线时间）
SimpleChat单纯处理消息并显示消息显示时发 simple_chat_message_viewed 信号，触发 ChapterEvent 的对应 trigger，trigger 包含发放任务的 action
SimpleChat由 GameProgressManager 的调用发放消息虽然时间线上的消息还是存在中央存档而非应用存档，但是 SimpleChat 会侦听时间推进事件来从中央存档取消息
SimpleChat玩家打开一次后就会消去“新消息”红点只要有一条消息未读，SImpleChat 本身和对应联系人上都会有红点

好兄弟 alpha 测试出来的问题

完整问题直接更新进开头的目标了……

这里只按照章节顺序提最关键的一些变更计划

缺乏引入

玩家一开始得到的信息太少，以至于缺乏目标和对世界观的了解。工作手册又因为其形式难以让玩家代入，导致玩家不清楚自己在做什么，即使发现用户死亡也困惑大于惊讶

“直接把玩家扔进游戏然后不管”的前提是游戏是重探索、知识扁平、操作本身游戏性强的，而这个游戏也就探索有戏，其他俩完全没戏，所以必须要添加引入剧情

考虑让玩家短暂扮演那格式化前的上一任节点（和 ghostine、何澈的短暂交流，随后被格式化），而非一开始就让玩家两眼一抹黑当格式化后的节点

这样当玩家在序章就能带着为什么被格式化的好奇进行探索，并在第一章结尾看到 ghostine 死亡时就会有先验知识而惊讶

不过我需要明确，这个引入的目的是“在玩家心里埋一个问题，通过悬念让玩家有目标”，而不是和 ghostine 建立情感链接（那样反而会在第一章和第二章的快速游戏模式变换下产生负面影响）。因此很短的一段就足够了。

设定太多/认知负载大

让愿意读的玩家有东西读——但不能太难找

让不愿意读的玩家不用读——但要把必要信息喂到嘴里

项目问题应对措施
工作手册设定名词和编程专有名词太多不再显式提及 POCKET、ARCHIVE、SPIDER 等名词，让玩家在理解系统操作后，通过游戏里的论坛之类的渠道零碎地了解相关设定
工作手册玩家可能会忽略 warn 之类的段落，导致其无法将 pocket 之类的名词和界面对应上同上。同时合并 界面组件 和 核心工作流程，核心工作流程每一步都象当前一样指向对应区域。演示图用符合当前情况的
系统恢复操作指南知识点太多，导致玩家一次记不下
而非编程从业者似乎并没有边看手册边尝试操作的习惯		去掉整个 系统恢复操作指南，然后使用一个独立的、默认启动的控制台引导程序来带着玩家敲一遍，尝试调用 diagnose 和 manualfix 查看示例输出。完事之后再让玩家正式用 diagnose 和 manualfix。
系统恢复操作指南玩家忽略/没能理解“Python 被视为一个 ProxyOS 到 windows 的兼容层，为了修好 ProxyOS，玩家需要在 windows 里用 python 实现对应的计算模块，来让部分逻辑在 windows 上执行，以此恢复 ProxyOS 核心功能”这个关系让引导程序使用诊断信息来描述“Python 被视为一个 ProxyOS 到 windows 的兼容层”，用方案制定来描述“为了修好 ProxyOS，玩家需要在 windows 里用 python 实现对应的计算模块，来让部分逻辑在 windows 上执行，以此恢复 ProxyOS 核心功能”，并在引导程序内调用 diagnose 和 manualfix 时显示“windows 并非 ProxyOS 客户端默认支持的运行环境，实际输出可能不一样”之类的
/玩家忘记剧情/没用正确理解剧情在 header 上加个备忘，通过 ChapterEvent 添加描述

序章过渡生硬

  • 在发现用户死亡，开始自删除的时候，加一段演出
    • 锁定主窗口
    • 播放伤感的 bgm
    • 打开单独 window
    • type writer 写一个感人的讣告，并表现出“想说啥但啥用户信息都不知道，想删啥但啥用户文件都没有”的荒诞感
    • 随着讣告突然报错、重启、报错、重启，bgm 撕裂终止
    • 显示侦测到外部侵入，紧急关机，客户端连接丢失
    • 重启游戏，进度第一章

第一章难度需要下调

先前的谜题

阶段 1：

被提示

minimal_positive_integer=1
system_state="recovering"

可以被“优化”成

minimal_positive_integer=1; system_state="recovering"

阶段 2：

输入错误/无关语句，被提示

minimal_positive_integer=1; system_state="recovering"

阶段 3：

输入

minimal_positive_integer=1; system_state="recovering"

后会提示 username 还是之前的值无法通过检查

阶段 4：

输入需要username="xxx"后被告知缺少system_state

阶段 5：

输入以下内容完成关卡

minimal_positive_integer=1; system_state="recovering";username="xxx"

设计目的

从教学角度来说，这是为了让玩家十分熟悉变量赋值，因为这是编程中初学者很难第一时间意识到的模式（等号是赋值、数字和字符串的差异），所以需要通过谜题让玩家多次操作

从可玩性角度来说，玩家刚进入第一章，需要趁着玩家对终端还没失去兴趣，让玩家做个不算太难的谜题来得到成就感，以免在后续的内容中觉得无聊

结果

但结果是玩家停在了阶段 4，没能没能在被告知缺少system_state后意识到整合两者

也许我应该简化下，让玩家只输入 username=“xxx"也能过，但是输全了给个彩蛋啥的

但考虑到第一章的叙事整体节奏存在问题，所以目前是临时修补，具体方案需要等我想明白第一章应该改成什么样的才行

实际上，第一章需要重写

当前叙事存在很大问题，需要调整。

当前的每个模块的演出基本是

  • 介绍背景
  • 介绍 Python 知识，并对照流程图（以对照 ProxyOS 计算方式的名义）
  • 插科打诨
  • 玩家操作，主要是重写前面出现的 Python 代码，但需要做一些变更

我本以为这是一个有趣度为 3 2 4 5 的递增编排，可以让玩家体验顺畅，但实际上：

  • 介绍背景的文案很疏离
  • 技术部分又偏干
  • 玩家无法在插科打诨部分代入，出现了“用不耐烦的心态看质量有限的剧情对话”的情况
  • 操作部分变数太大，玩家很容易想多导致做出预期之外的行为，并导致卡关

这导致我同样犯了那个我深恶痛绝的错误——剧情像自嗨+玩法单薄+引导不足+体验不顺畅

考虑到第一章本质上就是 Python 基础教程，其解法也许是

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

但我暂时不确定应该怎么做。

对于“第一章应该怎么改”，我问了自己很多问题，但是我没一个能信心十足地做出解答。

而“考虑调整背景，让安全内核当导师而非工友，让它给玩家讲自己为什么要写这些代码，并通过对话选项来应对玩家的各种问题，而不是让玩家在缺少补全功能、缺少即时错误校验、对编程不是很了解、报错可能超出作者预期的情况下写大段代码？”实际上十分拍脑袋，没用经过完整论证，只能算头脑风暴的一个片段

所以具体问题暂时留到 瓶颈与问题清单 一节

部分内容信息密度过高导致玩家认知负载超标

函数部分最严重

函数本身对初学者是个理解难点，即使是很多偏硬核编程游戏都会尽量避免出现函数内容。

所以为了解决这个难点，我必须把它放在仍可以用大段文本交互来介绍的第一章，如果放到第二章，玩家将不得不在需要理解任务需求的前提下学函数，这反而会让理解难度更高。

但即使在第一章，为了讲清楚函数本身的特性、优势，大段的文本仍会显得像是说教。

所以我尝试添加背景是 proxy，但实际上完全为函数本身服务的相关逻辑图，以此来冲淡说教感。 但实际效果十分灾难

这个函数 讲到这的时候有个问题了 因为函数部分本身比较难 既提到 proxyos 又提到 python 虽然能增加代入感 但是让人应接不暇 这一大堆文本下来 我已经陷入过载了 这根本不是二十分钟的问题 而一旦人脑过载 就完全不会觉得这是个游戏 更是会让代入感消失的

实际上这和我的设计预期产生了很大差异， 我本认为必要的娱乐性需要由剧情补充，但好兄弟给出了一个观点：

教学内容做顺畅+关键交互点让玩家处理 同样可以提供娱乐性

这是我没想到，而且确实合理的。

我此前的思维范式局限在“通过故事和交互设计，把教程包装成游戏”，而没有意识到“让玩家在游戏中自然学习”这个更好的方针。

这个观点改变了我对第一章的设计思路： 教学本身就应该是玩法，而不是需要剧情来“中和”的内容。

另外，其实我一开始以为模块 2-5 没任何难点，只有 1 的用户名拼接和 6 的 if 认知提升存在困难，而 6 的困难大于 1， 结果实际玩家能顺利完成 6 但却在 1-5 上遇到了很多问题。

这些问题很多是因为叙事部分对思路的干扰和没先验知识的前提下对代码的误解，这应该可以通过缩减叙事、优化代码展示/解释的表现方式、更合理地安排玩家介入的点来解决

……当然，这就是为什么要改第一章

但并不只是因为函数本身最难

我之前以为难度基本是教学后的练习谜题带来的，但玩家实际是用“我需要做多少决策”来衡量认知负载的。

函数那一节，玩家面对的决策可能有：

  • 理解什么是函数
  • 理解为什么要用函数
  • 理解函数的“一次声明，可以单行代码多次调用，可以在不同功能模块重使用”的特性
  • 理解参数
  • 理解返回值
  • 理解 ProxyOS 里函数对应什么
  • 理解流程图
  • 然后写代码

哪怕文本只有三行，只要这些决策点同时存在，就会过载。

解法不是减少文本，而是拉平决策曲线——不要在一个节点上要求玩家同时处理多个新概念。可以先让玩家“调用”一个已经写好的函数（只理解“调用=执行一段打包好的逻辑”），当玩家彻底理解后，再让玩家“修改”函数内部影响多个调用点，再之后才完整“理解”函数特性。

难不难取决于同时引入的新概念数量，而不是这一批概念组成的名为“函数”之类的集合本身的绝对难度。

瓶颈与问题清单

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

  • 第一章应该怎么改
    • 提前解锁完整编程？
    • 玩家在第一章有什么意愿？
    • 玩家在第一章有什么困难？
    • 怎么合理地提供解决这些困难的方式？
    • 如何避免解决困难的方式过于自由以至于玩家做出预期外的行为？
    • 剧情应该以何种方式、以何种程度提供才不至于自嗨也不至于晦涩？
    • 当前只有安全内核和神秘客会不会让剧情单薄？
    • 在当前大纲下这里可以有哪些角色出场？
    • 流程图是弊大于利还是利大于弊？其更接近帮助玩家理解代码还是凭空加了认知负担？
    • 流程图系统我之后准备怎么用？

下期计划

  • 想清楚问题清单里的问题
  • 把 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
    • 琢磨下宣传

试玩版

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