用Codex做了一个暗黑like游戏,然后我把它埋了

独立开发者用AI做暗黑like游戏,因系统膨胀而核心玩法缺失,最终放弃项目。
一位独立开发者借助OpenAI Codex快速搭建暗黑like游戏,系统功能飞速膨胀,但核心玩法循环——选地图、刷装备、变强的欲望闭环——始终未能扎实成立。作者反思:AI消除了实现摩擦,制造了进展的错觉,却无法帮助判断什么才是游戏的核心。最终决定埋掉项目,带着教训重新出发,从更小的原型开始。
一个独立开发者的AI游戏开发实验
暗黑like游戏——刷装备、看词条、凑Build、角色逐步变强——这类游戏有着令人着迷的循环。这一循环的本质是心理学家斯金纳发现的「可变奖励机制」(Variable Reward Schedule):不确定的奖励比固定奖励更能驱动重复行为。装备词条的随机性、Build成型的顿悟感、角色强度的指数级增长,共同构成了玩家「再刷一把」的内在动力——这一设计哲学自1996年暗黑破坏神初代起便确立了整个品类的基因。
对于一个热爱这类游戏的开发者来说,「自己做一个」是藏在心底很久的念头。但一个人做数值型游戏太重了:职业、装备、掉落、词条、技能、怪物、地图、存档、UI……每个模块单独看都不复杂,叠在一起却是一座难以独自搬动的山。
直到Codex出现,这座山看起来突然没那么重了。OpenAI Codex是基于GPT-3架构针对代码生成任务专项训练的大语言模型,也是GitHub Copilot的底层引擎。它在数百亿行公开代码上进行训练,能够理解自然语言描述并生成对应的代码实现,在函数级别的代码补全、模块架构生成、文档转代码等任务上表现尤为突出。它能写代码、拆文档、补架构、生成实现方案。于是,一个被压了很久的项目正式启动了。
AI编程的速度幻觉:起步阶段的兴奋与陷阱
一开始确实很爽。世界观、职业、装备、挂机、大秘境、掉落、词条、技能、佣兵、地图、存档、UI——这些东西都在飞速生长。对一个有软件开发经验的人来说,这种速度极其上头:你说一个系统,它就能展开;你说一个功能,它就能实现。项目每天都在变大,好像每天都有进展。
但这恰恰是AI辅助开发中最危险的地方——速度制造了进展的错觉。
值得警惕的是,Codex本质上是一个「模式匹配与补全系统」,它擅长根据已有上下文推断「下一步应该写什么」,但它没有产品判断力——它无法区分「技术上可以实现」与「对这个游戏真正重要」之间的差异。这正是后来所有问题的技术根源。
系统在膨胀,核心玩法却没站稳
慢慢地,不对劲的感觉开始出现。不是某一个bug,也不是某段代码写错了,而是整个项目的重心在悄悄偏移:
- 页面越来越重,逻辑越来越绕
- 测试数据和正式数据混在一起
- 文档里写着「完成」,工程里却没有真正闭环
- 系统看起来越来越完整,但基础玩法始终没有站稳

最关键的问题是:选择地图→挂机战斗→掉落装备→打开背包→换上装备→下一局变强。这件事听起来很简单,但它没有扎实地成立。做了很多暗黑like「应该有」的东西,却没有先证明玩家为什么还想再刷一把。
这正是游戏设计中「最小可玩原型」(Minimum Playable Prototype)理念所强调的核心:只实现能够验证核心游戏循环的最少功能集合。《以撒的结合》的开发者Edmund McMillen曾公开表示,他的原型只有一个房间、一个角色、一种敌人,但核心的「随机房间+资源取舍」感受已经完整成立。功能完整性是工程目标,而不是游戏设计目标。
核心反思:AI不会帮你判断什么才是核心
后来在别的游戏里看到了自己真正想做的东西——不是多么宏大的系统,可能只是一个装备设计、一个数值节奏、一次掉落后的反馈、一个BD成形时的感觉。那一刻突然意识到:花了大量时间做系统、做架构、做文档、做页面、接数据,但真正想要的,其实是那些很小的瞬间——
- 极品装备爆出来的瞬间
- BD成形的瞬间
- 角色突然变顺的瞬间
以为想做的是一个暗黑like游戏,后来发现,真正想做的是这些瞬间。

这些瞬间在游戏设计理论中有一个精确的描述:心理学家米哈里·契克森米哈伊提出的「心流」(Flow)理论将其具体化为「欲望闭环」——玩家在每次循环结束时,必须获得足够的正反馈,同时产生对下一次循环的期待。这个闭环的成立与否,是游戏能否留住玩家的根本判断标准,而不是系统数量或功能覆盖率。
这是这次最大的教训。AI可以让人更快地开始,但它不会自动帮你判断什么才是核心。甚至算是,它会让人更容易失控——因为它太能产出了。你说要装备系统,它就展开装备系统;你说要地图,它就做地图;你说要挂机、秘境、佣兵、技能、掉落,它都可以继续往下推。
这制造了一种很危险的错觉:项目好像一直在前进。但游戏不是靠系统数量成立的,游戏是靠一个可重复的欲望闭环成立的。
大而全的执念:独立开发者最容易踩的坑

这次犯的错误,是太执着于复刻一个大而全的暗黑like:
- 想要低数值传奇的克制感
- 想要暗黑的装备驱动
- 想要挂机游戏的轻量循环
- 想要BD成型的爽感
- 想要秘境、地图、掉落、成长线
每一个都没错,但放在一起,对一个早期原型来说就太多了。最后它不像一个游戏,更像一个被AI快速催生出来的游戏系统大全。
这在软件工程领域有一个对应的经典警告——Donald Knuth的名言「过早优化是万恶之源」(Premature optimization is the root of all evil)在这里可以被改写为:「过早实现是独立开发的万恶之源」。AI工具消除了实现的摩擦,而传统开发中,实现一个系统的高摩擦性本身会迫使开发者反复确认其必要性。这种摩擦的消失,让「做了再说」的冲动更容易付诸实践,也让方向纠偏的成本随时间指数级增长。
当然也不是完全没有好东西。比如挂机逻辑本身,方向仍然是对的——玩家不用高强度操作,通过一次次挂机、掉落、换装慢慢变强。只是它一开始被设计得太复杂了,复杂到还没来得及变好玩,就已经先变重了。
决定埋掉项目:不是否定,而是重新出发

最终决定把这个项目埋掉。不是因为它一文不值,而是因为它已经不适合作为下一个阶段的起点。不想继续在一个越来越沉的项目里修补,更想带着这次失败,重新做一个更小、更有意思的游戏。
下一次,不再从「我要做一个完整的暗黑like」开始。可
相关推荐
产品体验Qoder vs Cursor实测对比:同样20美金谁更强?
实测对比Qoder和Cursor两款AI IDE,从Agent自主修复能力、人工沟通次数、架构决策等维度评测。Qoder仅需2次沟通完成任务,Cursor需8次。详细分析两者差异,帮你选择最适合的AI编程工具。
产品体验Cursor云Agent演示:打通软件开发全链路瓶颈
深度解析Cursor云Agent最新Demo,展示如何通过云端虚拟机、自动测试产物和全链路控制平面,系统性消除软件开发生命周期中的人类瓶颈,让Agent自主运行、人按需介入。
产品体验Cursor 3.0深度解析:多Agent并行、Design Mode与Best-of-N模型对比
Cursor 3.0正式发布,从AI辅助编程工具进化为Agent舰队指挥中心。本文详解多智能体并行、Design Mode可视化编辑、Best-of-N多模型择优等核心功能,解读AI编程新范式。