写在前面：爆火有时比冷启动更危险
顾然做了一款第一人称恐怖游戏 Demo。
场景是一栋废弃公寓。玩家要在暴雨夜里寻找妹妹留下的录音带，楼道灯忽明忽暗，墙上的住户门牌会随进度变化。
Demo 很短，20 分钟左右。
但它有一个非常有效的惊吓段落：玩家以为电梯门打开后会出现怪物，结果什么都没有。等玩家松一口气，转身时才发现走廊尽头多了一扇原本不存在的门。
一个主播试玩后，视频播放量很快破了 80 万。
几天内，顾然的 Steam 愿望单涨到 1.6 万。
他本该高兴。
但真正的问题也从这时开始。
一、Demo 是为短体验设计的，不是完整游戏骨架
这个 Demo 的强项是氛围和一次漂亮反转。
弱项也很明显：它没有足够系统支撑长流程。
玩家在 Demo 里做的事主要是：
- 找钥匙
- 听录音
- 走到新区域
- 触发事件
20 分钟内，这些动作不显得重复。
如果扩展到 4 小时，就会很单薄。
顾然早期没有意识到这一点。
他把 Demo 爆火理解成“游戏方向已经成立”，于是直接开始扩写正式版。
他新增了地下室、医院回忆、邻居支线、多个结局，还设计了一只会追逐玩家的怪物。
但这些内容不是从核心系统自然长出来的，而是为了让游戏“看起来够长”。
二、玩家期待被主播视频放大了
Demo 爆火后，玩家期待变得很具体。
有人希望正式版保持克制心理恐怖；有人希望加入更多追逐；有人分析录音带里的隐藏剧情；有人猜妹妹其实不存在。
顾然每天都看评论。
他本来有自己的故事大纲，但看多了玩家猜测后，开始觉得原来的结局“不够震撼”。
他重写了三次剧本。
第一次加入精神疾病反转。
第二次改成家庭悲剧。
第三次又加了邪教线索。
每次改动都影响关卡、文本、道具和演出触发。
项目像一栋不断加层的旧楼，外面看起来更大，内部结构却越来越不稳。
三、恐怖感被制作量稀释
恐怖游戏很依赖节奏。
玩家什么时候紧张，什么时候放松，什么时候以为安全，什么时候发现自己错了，都需要精确控制。
顾然在 Demo 里做到了这一点。
但正式版内容变多后，他开始用更多惊吓填充流程。
问题是，惊吓次数越多，边际效果越低。
玩家很快学会“这里大概会吓我一下”。
为了维持强度，他又加入追逐和躲藏。可追逐系统需要路径、AI、音效、失败反馈和检查点支持。任何一个环节粗糙，恐怖就会变成烦躁。
测试玩家反馈：
- “前半小时很吓人，后面像在跑任务”
- “怪物卡门的时候有点出戏”
- “故事线索太多，反而不知道重点”
这些反馈让顾然很受挫。
因为它们不是说他不努力，而是说努力没有集中到正确地方。
四、他不敢缩回 Demo 的尺度
最合理的选择其实是做一款 90 分钟左右的短篇恐怖游戏。
保留公寓、录音带、妹妹失踪这条主线，把体验做扎实。
但顾然不敢。
愿望单已经很高，玩家期待已经很大，媒体邮件也来了。他觉得如果正式版太短，会被认为“骗愿望单”。
于是他继续扩写，直到自己耗尽。
项目暂停时，正式版已经做了 14 个月，但只有前 40 分钟质量接近 Demo。后面的内容不断返工，越做越没有信心。
复盘：Demo 爆火后，第一件事是重新定义规模
这个案例最重要的教训是：Demo 成功只证明 Demo 成功。
它不自动证明：
- 完整游戏长度合理
- 核心系统可扩展
- 故事能支撑更大体量
- 玩家期待应该全部满足
个人开发者遇到 Demo 爆火，最需要做的不是立刻加内容，而是冷静回答：
- 正式版最短可以多短
- 哪些内容必须保留
- 哪些期待不能接
- 项目能否在 6 到 9 个月内完成
热度是资源，也是压力。
如果没有明确边界，它会把一个本来能完成的小作品推成无法完成的大项目。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。