个人游戏开发者失败案例：那个不断加功能的像素 RPG

写在前面：这个项目不是突然死掉的

阿澈最初想做的，只是一款很小的像素 RPG。

游戏设定很简单：
一个年轻药剂师回到故乡，发现村子周围的森林被一种奇怪的雾气吞没。玩家需要白天采集材料，晚上制作药剂，逐步探索森林深处。

听起来并不夸张。

第一版计划只有：

• 1 个村庄
• 1 片森林
• 3 种药剂
• 5 种怪物
• 2 小时流程
• 一个开放式结局

阿澈给自己定了 4 个月时间。
他是后端程序员，业余时间做游戏。像素素材从商店买，音乐用授权素材，剧情自己写。他觉得这事很稳。

第一个月，他做出了能走动、采集、战斗和合成药剂的原型。
朋友试玩后说：“挺有味道的，要是后面能有职业成长就更好了。”

这句话后来变成了整个项目的第一个裂口。

一、第一次加功能：职业系统

阿澈原本只打算让主角使用药剂战斗。
但朋友提到职业后，他开始想：

既然是 RPG，没有职业是不是太单薄了？

于是他加了三个职业方向：

• 药剂师：强化制作和治疗
• 猎人：强化远程攻击
• 守林人：强化陷阱和探索

这看起来只是一个小扩展，但它立刻带来了连锁反应：

• 每个职业需要技能
• 技能需要 UI
• 技能需要数值平衡
• 敌人需要能应对不同职业
• 装备也要区分职业
• 剧情对白要承认职业选择

原本的药剂系统不再是核心，而变成了三个职业中的一个方向。
项目的重心开始移动。

阿澈没有意识到，第一次加功能时，他已经把游戏从“一个短篇药剂冒险”改成了“一个职业制 RPG”。

二、第二次加功能：装备和掉落

职业系统做了一半，阿澈又遇到一个问题：
如果有职业，就应该有装备。

于是他加入：

• 武器
• 护甲
• 饰品
• 稀有度
• 随机词条
• 怪物掉落

起初他只想做 20 件装备。
两周后表格里已经有 73 件。

装备系统让战斗变得更复杂，但也让内容生产变得更重。
他需要为每件装备写名称、描述、数值、图标和掉落来源。为了让装备不只是加数值，他又加了特殊效果：

• 暴击后回血
• 药剂效果延长
• 陷阱触发两次
• 低血量增伤
• 采集额外获得材料

这些效果看起来都很有趣，但每一个都需要测试。
更糟糕的是，它们开始影响药剂、职业和怪物设计。

项目从“可完成”变成了“每个系统都在等另一个系统补齐”。

三、第三次加功能：村民支线

阿澈很喜欢叙事游戏。
当村庄地图做好后，他觉得 NPC 只是站在那里太浪费，于是给每个村民写了支线。

铁匠有女儿失踪的故事。
旅店老板年轻时去过森林。
村长隐瞒了雾气的真相。
一个小孩每天在井边等不会回来的父亲。

这些内容写出来时很动人。
阿澈甚至有几次写到凌晨，觉得自己终于做出了“有灵魂”的东西。

但问题很快出现：

• 支线需要任务系统
• 任务系统需要追踪 UI
• NPC 对话需要状态分支
• 支线奖励要接入装备和药剂
• 支线进度要进存档
• 玩家错过支线时要有处理逻辑

他原本只是想让村庄更真实，结果又引入了一整套叙事管理系统。

到第 7 个月，游戏仍然只有第一片森林能玩。
但设计文档已经写到第 8 章。

四、真正的问题：每次加功能都有理由

这个案例最值得警惕的地方是：
阿澈并不是乱加功能。

每一次扩展都看起来合理：

• RPG 有职业，很合理
• 有职业就有装备，很合理
• 有村庄就有支线，很合理
• 有森林就有更多区域，很合理
• 有材料就有家园种植，也很合理

范围失控最可怕的地方，不是功能没有理由，而是每个功能都有理由。

真正的问题是：
这些理由没有服务于最初的项目边界。

阿澈没有问：

• 这个功能是否必须存在？
• 不做它，游戏是否仍然成立？
• 做它后，项目会增加多少内容债？
• 它是否会改变游戏类型？
• 它是否让 4 个月项目变成 18 个月项目？

他只问了一个问题：
“这个功能会不会让游戏更好？”

这个问题太危险。
因为答案几乎永远是“会”。

五、第 12 个月：项目开始变重

到了第 12 个月，阿澈打开工程时已经不再兴奋。

他有一个 Trello 看板，里面有 168 张卡片。
其中很多卡片只是为了让旧功能不崩：

• 修复职业切换后药剂加成丢失
• 装备词条在读档后重复生效
• 任务 NPC 晚上不出现导致支线卡死
• 森林第二层怪物掉落表为空
• 背包满时采集材料消失
• 技能说明和实际效果不一致

这些问题都不大，但它们密密麻麻地堆在一起。

阿澈每周只能抽 10 到 15 个小时。
他原本以为自己在做游戏，现在感觉自己像在维护一个没有用户的老系统。

更糟糕的是，他已经不敢轻易改设计。
因为每一次改动都会牵动职业、装备、任务、存档和 UI。

项目还没发布，却已经有了遗留系统的疲惫感。

六、第 18 个月：停滞不是放弃，而是不再打开

阿澈没有正式宣布项目失败。

他只是越来越少打开工程。

一开始是一周没动。
后来是一个月。
再后来，他买了一个新的像素素材包，想着“等周末重新整理一下”。
但周末到了，他只是打开项目，看了十分钟，又关掉。

失败有时不是一个明确事件。
不是删库，不是公告，不是退款，也不是痛哭。

失败有时只是：

你知道还有很多事要做，但已经没有力气重新进入那个世界。

阿澈最后把项目压缩备份，放进硬盘。
文件夹名字叫 forest_rpg_final_rebuild_3_backup。

这是很多个人游戏项目真实的墓碑。

七、这个项目本可以怎样活下来

如果回到第一天，这个项目并不是没有机会。

它真正可行的版本应该是：

• 保留药剂师单一身份
• 删除职业系统
• 删除随机装备
• 村民支线只保留 2 条
• 森林只做 3 个区域
• 流程控制在 90 分钟
• 核心卖点集中在“采集、制作、探索雾林”

也就是说，它应该是一款短篇体验，而不是中型 RPG。

更重要的是，阿澈应该在每次加功能前写下代价：

只要把隐藏成本写出来，很多“顺手加一下”就不会再顺手。

八、复盘：范围控制不是少做，而是保护核心

这个案例的教训不是“不要做 RPG”，也不是“不要加功能”。

真正的教训是：

• 每个功能都应该为核心体验服务
• 第一款游戏不应该靠内容量证明价值
• 系统越多，完成概率越低
• 业余时间项目尤其需要硬边界
• 没有砍功能机制的项目，最终会被功能淹没

范围控制不是保守。
范围控制是让游戏有机会完成。

阿澈失败的原因不是不努力。
恰恰相反，他太认真地回应了每一个“这样会不会更好”的想法。

个人游戏开发者要学会问另一个更冷的问题：

这个功能不做，游戏还能不能成立？

如果答案是能，那它大概率不应该进入第一版。