写在前面：有些失败不是项目崩了，而是人先撑不住了
闻川没有辞职做游戏。
他在一家互联网公司做客户端开发，白天写业务代码，晚上回家做自己的游戏。
他的计划很理性：
- 不冒现金流风险
- 先兼职做出 Demo
- 有收入或发行机会后再考虑全职
游戏是一款横版动作平台跳跃。
主角可以在墙面和天花板之间切换重力，通过不同方向的重力变化解谜和战斗。
原型很好玩。
第一次在开发者群里发视频时，很多人都说“这个机制可以”。
于是闻川开始做。
两年后，游戏没有发布。
工程还在，关卡也有十几个，但他已经不想打开。
这不是一个戏剧性失败。
没有投资人撤资，没有平台封禁，没有重大技术事故。
它只是一个人慢慢被耗空的故事。
一、兼职开发最开始总是看起来可行
第一阶段，闻川状态很好。
他给自己定了节奏：
- 工作日晚上 2 小时
- 周六半天
- 周日休息
前 3 个月，他进展很快：
- 主角控制完成
- 重力切换完成
- 基础敌人完成
- 5 个测试关卡完成
- 简单 UI 完成
他甚至做了一个开发日志，记录每周进度。
那段时间，做游戏像是在给生活开一扇窗。
白天的工作越琐碎，晚上打开自己的工程就越有意义。
但问题也从这里开始。
游戏项目带来的正反馈，让他开始不断压缩休息时间。
原本周日休息，后来变成“周日只做一点点”。
原本晚上 2 小时，后来变成“今天状态好，多做一会儿”。
兼职开发最危险的不是一开始太慢。
而是一开始太顺。
二、他没有给项目设置“休息预算”
闻川做过功能计划、关卡计划、素材计划。
唯独没有做精力计划。
他默认自己可以长期维持：
- 白天 8 到 10 小时工作
- 晚上 2 到 4 小时开发
- 周末继续补进度
- 偶尔熬夜赶版本
短期可以。
长期不行。
半年后，变化开始出现：
- 工作日晚上效率下降
- 周末起床越来越晚
- 看到 bug 列表会烦躁
- 不再愿意写开发日志
- 社交邀请开始变成负担
- 休息时也觉得自己在拖延
项目还在推进，但代价变高了。
闻川没有把这些当成风险信号。
他只是觉得自己最近不够自律。
这是很多兼职开发者都会犯的错误：
把精力耗尽误判成意志力不足。
三、工作压力会污染个人项目
第 9 个月，公司项目进入紧急迭代。
闻川白天开始频繁加班。
需求改来改去，测试不断提 bug，线上问题也多。
他原本想暂停个人游戏两周。
但又担心断掉节奏，就每天晚上“至少打开工程看一下”。
结果是，他既没有真正休息，也没有真正推进。
有几天，他只是打开关卡编辑器，看着未完成的地图发呆。
他知道应该修一个跳跃判定 bug，但脑子不愿意进入状态。
白天的工作压力开始污染晚上。
当一个人白天已经在解决技术问题，晚上再继续解决技术问题，区别只剩下“这个项目属于我”。
归属感能提供动力，但不能无限抵消疲劳。
四、最消耗人的不是大任务，而是无数小尾巴
闻川原本以为，项目最难的是核心机制。
后来他发现，真正磨人的是那些永远处理不完的小尾巴：
- 某个关卡边缘会卡住
- 某个动画切换不自然
- 手柄菜单焦点偶尔丢失
- 存档后重开位置不对
- 教程提示出现太早
- 敌人掉下平台后不销毁
- 音效在暂停后继续播放
- 打包版本和编辑器表现不一致
这些问题单独看都不难。
但它们会不断打断成就感。
你花一晚上修完三个 bug，游戏看起来和昨天几乎一样。
没有新关卡，没有新技能，没有新画面。只是少了几个别人可能看不见的问题。
商业项目有团队、流程和工资来支撑这些琐碎工作。
个人兼职项目只能靠开发者自己的热情消化。
当热情下降后，这些小尾巴会变得非常重。
五、他不敢缩小项目，因为已经投入太多
第 14 个月，闻川其实已经知道项目太大了。
原计划：
- 5 个章节
- 40 个关卡
- 6 种敌人
- 3 个 boss
- 2 小时流程
当时完成情况：
- 2 个章节
- 13 个关卡
- 4 种敌人
- 0 个完整 boss
- 教程还没定稿
他考虑过砍内容。
但每次想砍，都会舍不得：
- 第 3 章的重力水流机制已经写了原型
- 第 4 章的美术素材已经买了
- 最终 boss 的设定很喜欢
- 商店页描述里写了多章节冒险
沉没成本让他无法收缩。
于是项目进入一种危险状态：
明知道做不完，但仍然按原计划背着走。
这比直接失败更折磨。
六、第 20 个月：他开始害怕玩家反馈
闻川曾经很期待试玩。
但到第 20 个月，他开始不想让人玩了。
原因不是游戏太差，而是他太累了。
每一条反馈在他眼里都不再是机会，而是新的任务。
玩家说：
“第三关节奏有点拖。”
他听到的是：
我要重做第三关。
玩家说：
“跳跃手感有时不稳定。”
他听到的是：
核心控制还没过关。
玩家说：
“这个机制很有潜力。”
他听到的是：
还要继续做很多内容才能配得上潜力。
当反馈不再带来方向，而只带来负担时，项目已经进入危险区。
七、最后一次打开工程
最后一次认真打开工程，是一个周六下午。
闻川本来想修 boss 房间的镜头问题。
他泡了咖啡，打开编辑器，工程加载了很久。
进入场景后，他发现有几个脚本报错。
原因是前一周升级插件后，部分 API 变了。
这不是大问题。
半小时能修。
但他突然没有力气了。
他看着控制台里的红色错误，想到后面还有 boss、关卡、教程、音效、商店页、手柄适配、成就、Demo、宣传视频。
然后他关掉了编辑器。
不是愤怒。
不是崩溃。
只是很安静地关掉。
之后他再也没有真正回到这个项目。
八、这个项目本可以怎样避免耗尽
闻川的问题不是不努力，而是没有为长期兼职开发设计结构。
更健康的做法可能是：
1. 把第一版砍成 30 分钟体验
不是 5 个章节，而是：
- 1 个章节
- 8 到 10 个关卡
- 1 个 boss
- 完整开头和结尾
- 可发布短篇
先完成，再决定是否扩展。
2. 规定每周休息时间不可挪用
休息不是奖励，而是开发资源的一部分。
例如：
- 每周至少 2 晚不碰项目
- 每月至少 1 个完整周末休息
- 工作高压期允许项目暂停
暂停不是失败。
长期项目需要呼吸。
3. 每 3 个月重新评估范围
固定问：
- 当前速度是否支持原计划？
- 哪些内容必须砍？
- 是否还能在 6 个月内发布？
- 我是否仍然愿意继续？
如果答案越来越差，就要主动收缩，而不是硬撑。
4. 把反馈分级
不是所有反馈都要处理。
可以分成：
- 阻断体验：必须修
- 影响理解：优先修
- 改善体验：排期
- 个人偏好：记录
- 扩展建议：第一版不做
否则每次试玩都会变成新的债务。
九、复盘：个人开发者也需要保护自己
独立游戏社区很喜欢讲坚持。
坚持当然重要。
但如果只讲坚持，不讲恢复、边界和缩小范围，就会把很多人推向耗尽。
闻川的失败不是因为他不热爱游戏。
正因为热爱，他才愿意长期牺牲夜晚和周末。
但热爱不能替代项目管理。
热爱也不能替代睡眠、社交、运动和空白时间。
个人游戏开发者最重要的资产不是代码，不是素材，也不是创意。
是还能继续创作的人。
如果一个项目必须持续消耗你的生活才能推进，那么它迟早会吞掉你继续做下一款游戏的能力。
这个案例的教训很简单，也很难执行：
不要为了完成一款游戏，把自己变成无法继续做游戏的人。
对个人开发者来说，失败并不总是项目没有发布。
有时更严重的失败，是项目还在，但你已经被它耗空。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。