开发者日志 06：把自己放到队伍末尾，先做一次 PC 体验验收

5 小时前1 浏览综合

大家好，上一篇结尾我说，下一步要把食堂切片交给 PC 试玩。真正开始这一步之前，我先做了一轮“第一次打开游戏的人会看到什么”的体验验收。这个阶段依然是我一个人完成：我写规则、改界面、做美术、跑测试，也负责把每一个不舒服的地方记下来。

这篇记录的是 10 月 13 日到 15 日之间的本地 PC 版本整理。它已经比食堂四关多了很多内容，但我会把自动化和原生窗口检查的结果写在它们能证明的范围内。真人玩家还没有给出反馈，候选版也还没有公开发布，这两个空白我会留在最后。

从四关食堂，走到四个场景的十六关

食堂切片证明了餐票、窗口容量和换档可以组成一组关卡。接下来我把它扩展成正式入口：食堂、火车站、景区和夜市，每个场景四关，一共十六关。人物还是自动行动，玩家仍然只旋转路牌；改变的是每个场景让队伍等待的理由。

食堂教玩家看票和窗口，火车站加入周期性的检票窗口，景区让停留、合流和缓冲位置互相影响，夜市则把补货预告和绕路放进同一张地图。场景物件不再只是背景线稿，它们对应真实的可走格、服务格、闸口或暂时关闭的通道。这样我才能继续确认最初的想法：人物只遵守几条简单规则，整体却会因为环境变化表现出自己的脾气。

我还在第 4、8、12、16 关各放了一个章末挑战。挑战复用主线地图，但会换票序、入场批次、服务节奏或通道开放时间，另外给出两个可以自己追的目标：完成得更快，或者让队伍少一点非自愿的堵塞等待。它们是重玩目标，不是通关门槛，也不能替主线盖章。

目前四个挑战都有可复现的公共操作解。比如第 4 关挑战用时 56.25 秒、最长受阻等待 0 秒；第 8 关是 30 秒和 6.75 秒；第 12 关是 48 秒和 7.5 秒；第 16 关是 45.75 秒和 6 秒。这些数字说明规则和目标能够对上，不能说明它们已经是最优解，也不能代替第一次试玩的感受。

先让犯错以后还有机会看清楚

以前一局路牌转错以后，通常只能按重开。站在制作者的位置，我知道哪一块牌错了；站在玩家的位置，队伍可能只是突然停下来，过了几秒才发现自己已经没有回头路。

所以这次加了回退。按 Z 可以撤回最近四轮，最多保留一局里的 160 轮状态，人物、票种、窗口服务、入口批次、牌面和计时都会一起恢复。已经拿到的关卡进度和历史纪录不会被回滚，回退以后会回到手动暂停，给玩家重新看一眼局面再决定怎么转牌。

我也加了 F 键切换 1 倍和 2 倍速度。遇到窗口换档、闸口变化或危险堵塞时，游戏会回到 1 倍，避免玩家为了少等几秒而错过真正需要观察的变化。速度只改变观察节奏，不改变模拟轮次和成绩。

底部的回退、倍速、暂停、重开、帮助和声音按钮，都要跟着当前状态改变。帮助和旅程册打开时，路牌不能偷偷接受输入；窗口失焦时，按住鼠标再回来也不能补算一串旧操作。对我来说，这些细节比再加一张地图更接近“可以交给别人玩”。

让等待说出自己的原因

体验验收时，我把顶部信息重新整理了一遍。现在画面会告诉玩家当前关卡、已经送出的人数、时间、入口接下来会进什么票、窗口现在接什么票以及下一次换档大概什么时候发生。悬停人物时可以看到票种和一小段实际路线，路线遇到墙、占位、关闭通道或不匹配窗口就会停下来。

第一关还加入了分步提示：先转牌，再开始，再看第一个人完成服务。提示不会替玩家自动转牌，也不会挡住整张地图。诊断文字会区分正常服务、暂时停留、错票、容量不足和队伍互相阻挡。这样玩家看到“等了一轮”时，至少能知道这是窗口正在处理，还是自己把人送到了错误的地方。

真实原生窗口截图：1024×600，食堂第 4 关暂停在规划阶段。顶部显示入口票序和窗口换档，中央提示可以调牌，底部的旅程册、声音、回退、倍速、继续、重开和帮助按钮保持在窗口内。

我还做了旅程册。它会记录正式主线的最近位置、十六关的通行情况、四个章印和挑战目标纪录。原来的主线进度文件继续保留，挑战和最佳时间使用独立记录；测试入口全部开放也不等于玩家已经通关。这个区分看起来像保存格式的事情，实际是在保护“我真的走过这里”这件事。

章末不再只弹出一句完成

正式关卡走到第 4、8、12、16 关时，会出现一段很短的纸片小景：食堂收盘、车站发车、景区合影和夜市收摊。它们只负责给这一章一个停顿，不锁住下一关，也不凭空增加章印。圆圆会在四个场景里各说一句话，人物的能力和规则都不会因为这句话改变。

真实原生窗口截图：1280×720，食堂第 4/4 关完成，显示本局用时、效率与从容目标、历史最佳以及“再排一次”和“下一关”。纸片小景和结算文字都在同一个真实运行画面里。

我特意把结算里的两个目标写清楚。高效看模拟完成秒数，从容看最长的非自愿受阻等待；服务本身的停留不被算成堵塞。玩家可以选择更快的路线，也可以选择让队伍少卡一点。两种结果都留下来，比只给一颗星更能说明这一局到底发生了什么。

五种声音，先从很小的反馈开始

这轮还加入了五个原创短音效：转牌、完成服务、窗口或通道即将变化、真实解堵和通关盖章。它们用本地标准库生成，放在项目的音频资源目录里，没有购买素材，也没有加入背景音乐和配音。每一类声音都会节流，暂停、失焦、重开、回退和打开浮层时，旧事件会被清空，避免恢复窗口后突然补播一串已经过期的声音。

这里也有一条必须写清楚的限制：原生验证使用了无声参数，只确认五个 WAV 能被加载、频率是 22050Hz、SoundSource 可以播放和停止，不能证明我在真实设备上听到的音量和音色就是合适的。音频接口通过，不等于听感完成。

这一轮真正修掉的四个问题

做体验层时，我没有只记录最后的漂亮截图。新增的回归先在修复前失败，下面四个问题是我觉得最值得留下来的部分。

第一，诊断曾经把“窗口正在服务”“服务位已经占满”和“票种不匹配”都归成普通等待。它们在规则里完全不是一回事，玩家得到的建议也应该不同。我让诊断重新读取当前窗口的票种、容量和真正的阻挡方向，错票不再被解释成耐心等一等。

第二，人物移动以后，鼠标指针还可能停留在旧位置上，继续显示已经离开的人的信息。现在展示层会在插值移动后重新命中当前身体，人物离开、取消、浮层和失焦都会清掉悬停状态。绘制和命中检测都只读取状态，不推进模拟。

第三，手动暂停时同一帧里刚接受的转牌有时没有声音。原因不是音效文件，而是暂停前的观察基线把这次新输入也当成了旧事件。我把暂停和输入代次分开记录，让暂停前的历史被排空，暂停中真正新转的牌仍然可以反馈一次。

第四，窗口验证器在结束时遇到过 WinError1400。它发生在被测窗口已经销毁的边界，不应该把一次测量失败伪装成有效尺寸，也不应该吞掉其他错误。现在控制器只处理自己启动的 SDL 窗口，只有 1400 被记为不可用观测，其他错误仍然直接失败；缺少必要的实际像素测量时，结果会保持失败。

这些问题都没有改变人物怎么走、路牌怎么转和每轮 0.75 秒的规则，却改变了玩家是否相信自己看到的东西。体验有时就是由这种很小的边界组成的。

我怎样确认它到了“候选版准备”这一步

最终的 27 个 Lua 规格测试分别在独立进程中通过。针对这轮新增的功能，FlowAdviceSpec 有 12 个用例，ExperienceUISpec 有 75 个断言，AudioFeedbackSpec 有 40 个断言；正式十六关和四个章末挑战也都用公开的转牌与推进接口走过。它们证明代码路径、记录隔离和已知解法能工作，不是试玩人数。

我又用本机 UrhoX Windows 运行了两次真实窗口检查。1280×720 和 1024×600 都实际测到目标客户区，DPR 为 1，两个尺寸都是 166/166 断言通过，验证器统计的 Lua、资源和引擎错误为 0。1280 的最大单帧约 94.77 毫秒，1024 的最大单帧约 63.73 毫秒；这里的 1000 毫秒阈值只用于功能截图验收，不能当成长期性能认证。

这仍然不是完整的候选包。高 DPI、更多窗口尺寸、连续缩放、长时间运行、设备实际听感、第一次打开时玩家能不能自然理解提示，以及真人觉得等待是否公平，都还需要真正把版本交给别人。工程里也还保留着引擎和 UI 类型声明带来的 LSP 基线错误，我没有为了写“全绿”去伪造声明或关闭检查。

把自己放到队伍末尾

做到这里，我发现自己问问题的方式变了。食堂切片时，我问的是“这四关能不能通”；现在我会继续问“第一次看到这张票的人，知道自己为什么停下来吗”。前一个问题可以用解法和断言回答，后一个问题必须等真实的人坐到电脑前。

一个人做项目很像自己排队。地图、界面、声音、记录和测试都在队伍里，我不能同时把它们推进到终点，只能先处理最影响前进的那一项，再给下一项留出位置。回退功能也像是在队伍里留了一个回头看的空位：走错以后可以重新确认方向，但最后还是要自己决定往哪边走。

所以这篇日志的结尾不是“游戏已经完成”，而是“版本终于接近可以交给别人”。下一阶段我会进行真正的 PC 真人试玩，记录第一次打开的人在哪里停顿、哪些提示仍然不够清楚，再决定是否进入候选包和发布准备。那时的反馈会来自玩家，而不是来自我替玩家猜出的答案。

#聚光灯GameJam开发者日志

聚光灯游戏创作挑战

9.1

前往论坛