有 AI，不代表它已经是一款游戏

在参赛作品列表里看到自己的游戏

提交完成后，我重新打开 AI Browser Game Jam 4 的参赛作品列表，在一排排游戏封面中看到了《Memory Fragments》。它没有因此获得任何额外结论：比赛尚未结束，我也不知道其他玩家会怎样评价它。但那一刻仍然很具体——此前只存在于本地页面、代码和待办清单里的东西，第一次变成了别人可以打开的公开作品。

这也是我第一次完整走过浏览器游戏从概念、原型、反复修改到 itch.io 提交的过程。回头看，真正困难的部分并不是让 AI 生成更多内容，而是把不断扩张的想法压回一条玩家能够理解、操作并完成的路径。

为什么制作关于记忆的游戏

最初的灵感来自我此前做过的长期记忆机制。很多叙事作品会用失忆、线索和回忆推动角色寻找过去，但我不想只把它写成一段线性剧情。我希望玩家通过操作参与“恢复记忆”，并在过程中意识到：被恢复的内容不一定等于未经改变的真相。

于是，游戏被收束为一座损坏的记忆终端。玩家在废弃档案馆中寻找碎片，阅读照片、值班表和员工卡等记录，再决定如何把它们注入 AI 角色 NORA。记忆可以被拆成明确的探索目标，恢复进度可以成为持续反馈，而相互矛盾的碎片又能让“是否相信”成为选择，而不是单纯的收集。

这个设定最终留下了一个贯穿游戏的问题：一个由记忆构成人格的角色，究竟是在恢复过去，还是在接受玩家重新拼接出来的自己？它既是叙事主题，也必须通过玩家行为成立。

原本以为 AI 会是游戏中心

开始开发时，我设想过自由对话、动态剧情、多角色记忆冲突，甚至实时生成音效。因为比赛名称里有 AI，我很自然地把“加入更多 AI 能力”当成作品向前推进的方向。

我先让 ChatGPT 辅助拆解科幻终端、AI 角色和叙事探索的方案，再由我复核、删改并整理成页面结构、状态规则和交互要求，交给 Codex 辅助代码实现。最终的选择、整合、测试与提交仍由我完成。这个过程很快，但也很快暴露出另一个事实：如果需求里没有清楚的玩家目标、状态变化和失败边界，生成速度只会让不确定的方向更快变复杂。

第一版已经能探索档案、读取文字和触发对话，却像一个装着很多信息的网页。开场解释过长，玩家仍不知道第一步做什么；碎片只是可点击条目，找到它们也缺少足够明确的结果。那时我才把核心循环写成一句简单的话：找到碎片，作出选择，获得反馈，继续推进，最后触发结局。

关键流程交给状态机

真正进入制作后，我没有让大模型控制整个游戏。碎片收集、场景解锁、核心充能、信任变化、关键选择和结局触发都交给确定性的状态机。NORA 根据当前阶段显示对应的回应和视觉状态，关键剧情与通关路径不依赖随机输出。

这不是为了把 AI 藏起来，而是为了保证玩家的行为有可复现的结果。玩家注入一段记忆后，系统必须知道发生了什么、下一处入口是否解锁、角色现在处于哪个阶段，以及两条结局是否满足触发条件。如果这些关系本身含糊，再自然的即时对话也无法替代游戏规则。

AI 在这次制作里更多承担方案分析、文本试写和代码实现的辅助工作；运行中的核心流程则保持可检查、可测试。对第一次参赛而言，这种划分让我可以先保证游戏能够被理解和完成，再讨论实时生成是否真的增加体验价值。

视觉和交互反馈的迭代

早期版本收集碎片后，界面主要显示数值变化。逻辑虽然正确，但“人格完整度上升”更像后台记录，玩家很难从中感到 NORA 正在恢复。后续版本加入半透明人物轮廓和损坏的面部投影，并让角色形象、场景亮度与粒子状态随进度变化。

我也补上了终端启动、碎片粒子、光线、脉冲、降噪和关键画面变化。它们没有改变底层玩法，却把一次点击变成可被感知的结果：玩家不必反复读取数字，也能看出刚才的选择改变了角色和世界。

删除自由对话与复杂功能

第一次做游戏时，最容易产生的冲动是继续添加功能。自由对话、更大的探索地图、多角色冲突、复杂情绪数值和更多分支听起来都能让作品更像一款“完整的 AI 游戏”，但它们也会同时增加内容、一致性、服务依赖和测试成本。

我最终删掉完全自由的实时对话，也没有继续扩展多角色和大量结局。原因不只是时间有限，更重要的是这些功能会分散尚未被证明的核心体验：玩家是否愿意寻找碎片，是否理解注入记忆的后果，又是否能感受到 NORA 的变化。

自由对话可能让角色越过剧情边界，也会让主流程依赖模型服务；扩大地图会增加移动距离，却不一定让探索目标更清楚；复杂数值在缺少玩家验证时，很容易制造一种看似丰富的假深度。删除它们之后，剩下的内容反而更接近一条能够从头走到尾的游戏流程。

两个结局

最终版本保留了两个可以独立触发的结局。THE ARCHIVE REMEMBERS 选择为 NORA 充能过去，让档案馆继续保存已经找回的记忆；THE DOOR OPENS 则选择充能未来，让她不再被全部旧记录定义。

两条路径使用同一批探索结果，却在最后一步给出不同方向。它们没有试图证明哪种选择更正确，而是让开头的问题真正落到玩家手上：恢复全部过去是否一定等于恢复自己？如果不再保留完整记忆，新的选择又是否仍属于同一个人？

itch.io 提交与移动端问题

临近提交时，最棘手的问题已经和 AI 无关，而是外层滚动、响应式布局、结局页面截断，以及游戏嵌入 itch.io 后的显示方式。桌面浏览器中可以完成的流程，到了较窄的屏幕上可能因为容器高度和页面滚动互相影响，让玩家看不到操作区域。

我反复从头检查探索、注入和两条结局，调整移动端文字密度、滚动范围与结局页布局，再确认公开页面能够进入游戏。它们没有增加新的模型能力，却直接决定作品是不是“真的能玩完”。

按照我当时对比赛规则的理解，我在提交页说明了使用的 AI 工具与人工复核边界：ChatGPT 和 Codex 辅助分析、叙事、代码实现与测试计划，图像生成用于 NORA 的概念视觉；所有输出仍由我选择、编辑、整合和测试。公开提交迫使我把这些边界写清楚，也让项目离开了只对作者本人有效的开发环境。

这次比赛留下的三个判断

先让玩家知道下一步做什么

AI 能生成角色台词、界面和代码，但它不会自动产生游戏目标。玩家为什么探索、一次行动改变了什么、离完成还差多远，这些问题必须被明确设计。没有目标和反馈，再丰富的生成内容也只是一组可以浏览的素材。

把不确定性放在系统能够承受的位置

关键流程交给状态机，并不意味着拒绝 AI，而是先区分哪些环节必须稳定。通关、存档、解锁和结局需要可复现；角色表达和方案探索可以保留更大的变化空间。只有先划清边界，AI 的不确定性才不会成为玩家无法完成游戏的原因。

完成来自取舍，而不是功能数量

这次真正推动作品提交的，不是把最初清单全部做完，而是连续删除与核心循环无关的功能，并把时间留给反馈、移动端和公开页面。一个规模较小但能从头玩到尾的版本，比一组彼此没有闭合的复杂系统更接近游戏。

首先学习如何做一款游戏

我原本以为，这次比赛会主要教我怎样把 AI 放进游戏。做完后才发现，它更像一次基础课：怎样把概念变成规则，怎样把规则变成玩家可见的反馈，怎样在功能扩张时守住核心循环，又怎样把本地原型交付成别人可以打开的作品。

《Memory Fragments》仍有许多没有验证的地方。我没有进行系统的玩家研究，也不能仅凭完成提交判断它是否足够有趣。但它让我确认了一条更朴素的顺序：先学习如何做一款目标清楚、反馈明确、能够完成的游戏，再判断 AI 应该进入哪里。