个人游戏开发者失败案例：反复换引擎让项目停在起点

写在前面：工具选择可以重要，但不能永远重要

陆沉想做一款 3D 探索游戏。

玩家在一座废弃天文台里修复观测设备，通过星图解开不同房间的机关。项目不大，重点是空间谜题和氛围。

他最初用 Unity。
两个月后换到 Godot。
又过三个月，他开始研究 Unreal。

一年过去，游戏没有 Demo。
但他对三个引擎的优缺点都很熟。

这不是学习失败。
这是项目失败。

一、每次换引擎都有合理理由

第一次换引擎，是因为他担心 Unity 授权和生态变化。
第二次犹豫 Godot，是因为 3D 光照和插件让他不放心。
研究 Unreal，则是因为它的画面效果明显更好。

这些理由都不是胡扯。

问题是，他每次都在项目还没验证核心玩法前，就把长期技术风险放到最前面。

他还不知道玩家是否喜欢“星图机关”。
却已经在比较渲染管线、资源导入和动画蓝图。

二、技术迁移制造了虚假进展

换引擎时，陆沉总觉得自己在重新开始得更正确。

他会重新搭项目结构，重新实现角色控制，重新导入模型，重新写交互系统。
这些工作都很具体，也很忙。

但它们没有让游戏更接近验证。

玩家仍然没有玩到谜题。
商店页仍然没有开。
核心循环仍然没有外部反馈。

技术迁移给了他一种“这次会更稳”的感觉，却不断把真实风险往后推。

三、他用未来问题阻止当前发布

陆沉经常担心：

• 以后性能不够怎么办
• 以后要上主机怎么办
• 以后资产量大了怎么办
• 以后多人协作怎么办

这些问题未来可能存在。
但当项目还只有一个人、一张地图、三个机关时，它们不是最紧急风险。

真正紧急的是：
这个游戏有没有人在 15 分钟内觉得有意思？

他没有回答这个问题。

四、失败发生在没有玩家之前

项目暂停时，陆沉并不是不会开发。
相反，他学到了很多。

但游戏本身没有形成。

他后来用两周时间在 Godot 里做了一个极小谜题原型，发给朋友试玩。反馈很普通：氛围可以，但谜题不够特别。

这本该是一年前就知道的事。

复盘：个人开发者要把工具选择压缩到可行动范围

这个案例的教训是：

• 引擎选择要服务当前验证，不是服务所有未来可能
• 不要在核心玩法未验证前反复重建技术栈
• 迁移工作很忙，但不等于项目推进
• 先做 15 分钟可玩版本，再讨论长期架构

个人开发者当然要关心工具。
但工具不能成为避免面对玩家反馈的安全区。

当你第三次重写角色控制器时，可能真正需要的不是新引擎，而是一个外部玩家。