游戏制作计划

开头#

我觉得也需要先解释一下，为什么是做游戏。

说实话，并没有什么特别宏大的理由。用 AI 更快写代码这件事已经很常见了，我想很多人也已经亲身体会到了这种变化。游戏开发，正是从一个多少有点奢侈的问题开始的：到底有什么东西，可以被我真正做成一个可发布的产品？

放在以前，哪怕只看开发和运营资源，这也是一个很难轻易踏进去的领域。可现在看起来，时代已经变成了一个可以不用想太多就先开始的阶段。再加上，做一些我自己也能享受、而且比起工作更接近兴趣的开发，本身也多少带着一点浪漫色彩。

前言说得有点长了。这篇文章里，我想整理一下我打算推进的游戏类型，以及我为什么会选择这条路线。

实现顺序

为什么第一个类型是故事问答#

我最先选择的类型是故事问答。它是一种视觉小说式的结构，故事会不断推进，而玩家会在中途或最后通过解谜推理来获得经验值。之所以先做这个类型，原因很简单。乐趣的中心显然是故事和推理，但运维负担却可以相对压低。

在这里，AI 并不需要进入所有环节。我反而认为这一点非常重要。在故事问答里，我希望 AI 更接近 评分 和 制作辅助，而真正的游玩体验则建立在人设计的规则和演出之上。这样一来，运维不至于失控，同时也可以实验一种让作者直接出版自己作品的模型。

虽然现在还处在早期阶段，但实现方向已经基本朝着那里去了。它不是把原稿直接塞进数据库，而是通过 Markdown 原稿 → 解析 → 剧本强化 → 提示词生成 → 翻译 → import 这样的制作管线，去让 AI 更贴合故事制作。

source.md
-> parse-episode.py
-> script-doctor.py
-> prompt-gen.py
-> translate-story.py
-> /bo/story-quiz/games/import

故事问答目前实现到了什么程度#

以当前仓库为 기준，故事问答已经比单纯的想法阶段更往前走了一步。面向玩家的一侧，已经有游戏列表与详情、会话创建、继续游玩、答案提交、尾声查询等 API；在后台侧，也已经有管理游戏、角色、阶段、区块、题目和背景资源的结构。再加上整套游戏数据可以通过 JSON 进行 import, export，它开始被当作一种可出版的内容格式来对待，而不只是单个游戏。

更重要的是，这个类型正在以 内容数据 和 游玩会话 分离的方式成长。一个游戏会被拆成角色、阶段、区块、题目和背景资源，而在会话里，又会单独管理当前阶段、当前题目、已使用的提示、分数和进度状态。也就是说，作者修改作品的流和玩家消费作品的流，已经被拆到了不同的层上。

评分也遵循同样的哲学。客观题是即时评分，主观题则被拆成 KEYWORD_ONLY, LLM_ONLY, HYBRID, MANUAL 之类的策略，以及后台审核流。对我来说，重要的不是 AI 永远正确，而是只把适合交给 AI 的问题交给 AI，剩下的内容则保留在人可以复核的结构里。

为了实验作品出版，交付层也在单独整理。封面图和卡面图通过 public source path 和基于 preset 的 thumbnail 进行分发，Asset Studio 也已经能把 Story Quiz 和 Mystery 的角色与背景资源一起管理。最终，故事问答既是一个游戏，也是 作品制作、校验与出版管线 的第一个实验场。

为什么下一步是推理游戏#

如果说故事问答更接近 作者设计好的结构化体验，那么推理游戏就是一个更活的类型。玩家不会只停留在阅读线索，而是会扮演角色、进行对话、彼此怀疑，并不断更新局面。它确实是一个比较小众的类型，但一旦做得好，用户参与度很可能会更深。

而也正是在这里，AI 的占比会明显上升。故事问答里，AI 可以用得比较克制；但到了推理游戏，NPC 反应、审问、提示辅助、剧本补强这些环节，都已经离核心体验非常近了。我把这个类型看成是 AI 正式进入游玩体验内部的第二阶段。

推理游戏目前到了什么程度#

因为几个方向是并行推进的，所以推理游戏其实也已经到了肉眼可以看到小型原型的程度。平台 API 里已经接上了场景查询、会话创建与邀请码加入、准备状态、开始、阶段切换、笔记、道具和审问记录。会话是围绕门票、邀请码、玩家列表和状态切换来管理的，起始道具、起始笔记、起始审问这些数据也作为单独结构挂在上面。也就是说，真正能跑完一局的会话模型 已经先立起来了。

制作侧更有意思。推理游戏里有一条叫做 Draft Scenario 的后台流，生成阶段被拆成 CONCEPT → TRUTH → CHARACTERS → TIMELINE → CLUES → ROLEPLAY → WORLD_BUILDING → SYNOPSIS → PROLOGUE → EPILOGUE。这不是简单的文本生成，而是一种把答案、动机、人物关系、不在场证明、线索和角色反应都拆成独立节点的方式。我认为这个结构很重要。因为在推理游戏里，比起漂亮的句子，首先要成立的是 逻辑一致性。

实时对话这一侧也已经有了骨架。游戏会话聊天 API 里已经有角色对话、SSE 流式响应以及 AI 助手聊天，而且所有对话都会被保存到审问历史中。也就是说，它不是一个 AI 只负责扔出回答的结构，而是被设计成会在 会话内部积累记忆。这一块，很可能会成为之后 AI 依赖度提升最快的区域。

为什么把 MMORPG 放在最后#

MMORPG 对我来说，不只是技术上的好奇，也和个人的怀旧直接连在一起。我想测试一下，过去长期玩过的《天堂》那种感觉，在现在的工具和结构下到底能做回多少。要是最终真的能走到商业化，那当然再好不过，但在那之前，更重要的问题还是：像这样重量级的类型，用现在的开发方式，到底能推进到什么程度？

另外，我也认为，在 MMORPG 的实现里，上面提到的很多结构都可以继续被复用或改造成世界观、剧情和 NPC 设定的一部分。

MMORPG 难道不太难做吗#

有些出人意料的是，现在的 mmorpg-service 也已经按规格吐出了相当一部分代码。我甚至可以说，当前代码代理的水平已经超过大多数人的想象。只要很少几轮提示词，实时 MMORPG 的客户端和服务端就都能被生成出来。

游戏本身会朝着我以前常玩的《天堂》那种形态去实现。而在服务端侧，Netty 网关、会话管理器、Redis 会话同步、重复登录处理、世界与 Zone 创建、tick 调度器、地图与寻路、AOI 同步、战斗广播、背包与商店，以及掉落与生成流都已经实现，并且作为独立服务在部署。

再看运行时一侧，GameWorld 会管理多个 Zone，并且把会话索引和世界索引分开来绑定玩家。怪物不再只是简单的生成对象，而是以带有 IDLE, PATROL, CHASE, ATTACK, RETURN, DEAD 等 FSM 状态的运行时实体来管理。触发器系统则会直接执行陷阱伤害、法术、台词和聊天等世界反应。再往上，还有一个单独持续世界时间和天气的 WorldContinuum。

做一架梯子#

故事问答是在较低运维负担下实验 作品出版 的类型。推理游戏是在 AI 进入游玩体验内部时，实验 角色化推理 的类型。MMORPG 则是在最重的实时世界里，测试当前开发方式到底能走到多远的类型。

所以，这三个方向并不是彼此分离的项目，而更像是一架梯子。我想先在最轻的类型里把制作管线和审核结构立起来，再提高 AI 交互的密度，最后一路爬到实时世界。

归根结底，我真正想看到的很简单。不是 AI 是否能让游戏做得更快，而是 AI 应该被放在什么位置，游戏才能依然是一个人可以负责到最后的产品。对现在的我来说，在 Omnilude 里做游戏，就是最严肃地实验这个问题的方式。

结尾#

在前面的文章里，我讲的是编码方式的变化，以及后端结构本身。这篇文章更像是对另一个问题的回答：在那套结构之上，我到底想做什么样的游戏，又准备按什么顺序去做。

下一篇我想再收窄一点范围，更具体地写一写故事问答的出版管线到底是怎么转起来的，或者推理游戏里的 AI 审问结构到底是怎么设计的。