跳到正文

如果AI能写得比我还好,我为什么还要自己写代码?

这个想法在我脑海中盘旋了很久。

作为一个独立开发者,我曾经以为必须精通代码才能做游戏——让角色动起来、让物理系统工作、让画面呈现在屏幕上。我花了无数个夜晚研究GDScript,调试碰撞检测,优化渲染性能。

但就在最近几个月,我意识到一件事:AI写代码的能力已经超越了我。

不是夸张。我测试过——给AI一个清晰的需求,它写出来的代码结构更清晰、bug更少、注释更规范。而我花两小时写的功能,它十分钟就能完成。

那我还有什么优势?

我想了很久,答案是这个:我知道游戏应该是什么样子的。

AI能写代码,但它不知道玩家按下跳跃键时期待什么样的反馈。它能生成关卡数据,但它不理解什么是”恰到好处的难度”。它能优化性能,但它感受不到”手感”。

所以,我决定转变角色——我不做程序员了,我要当老板。

AI是我的员工,负责执行。我负责设计、决策、把关质量。这才是人机协作的正确打开方式。

这就是这个项目的起点。


我想做一款什么样的游戏#

简单说,是一款每次玩都不一样的平台跳跃游戏。

但”随机生成”这四个字在游戏圈里名声不太好。太多游戏打着”随机”的旗号,实则塞进一堆毫无章法的关卡,玩家死了都不知道该怪自己还是怪设计。

所以这个项目有三个必须坚持的原则:

第一,关卡要”每次都不同,但质量稳定”。 AI生成的不是混乱,而是在规则内的变化。就像一副扑克牌,每次洗牌顺序不同,但每张牌都是标准的。

第二,难度要”跟着玩家走”。 如果你玩得好,下一关会悄悄变难一点;如果你刚死了一次,系统会温和一些。但这种调整必须是隐形的——玩家不该感觉到系统在”刻意刁难”或”可怜你”。

第三,手感永远是第一位的。 无论关卡怎么变,跳跃、落地、冲刺、攻击这些基础操作必须扎实。玩家是因为操控爽快而继续玩,不是因为关卡新奇。


团队配置:我 + AI#

我的”团队”只有两个人:我和AI。

我的职责:

AI的职责:

我选择的工具是 Claude + Godot 4.5

为什么是Claude?因为它在代码理解和长上下文方面表现出色。我可以丢给它整个项目的代码,让它理解上下文后进行重构或新增功能。

为什么是Godot?轻量、免费、2D支持完善,而且GDScript对AI很友好——语法简洁,结构清晰,AI生成的代码质量很高。


从”我自己写”到”我指挥AI写”#

这个过程的转变比想象中深刻。

以前我的流程是:

  1. 想到一个功能
  2. 查文档、研究实现方案
  3. 自己写代码
  4. 调试、修bug
  5. 测试效果

现在我的流程是:

  1. 想到一个功能
  2. 想清楚这个功能的”体验目标”(玩家应该感受到什么)
  3. 用自然语言向AI描述需求,包括上下文和约束
  4. AI生成代码
  5. 我测试效果,给出反馈
  6. AI根据反馈修改

关键区别在哪?

以前我的精力分散在”想做什么”和”怎么做”之间。现在我可以100%专注在”想做什么”上。

比如实现跳跃手感。以前我需要自己研究coyote time的实现、跳跃缓冲、变高度跳跃的物理公式。现在我只需要告诉AI:

“我要一个平台跳跃的手感,参考Celeste的标准:离开平台后100毫秒内仍能跳跃,落地前150毫秒按键有效,按住跳得高、短按跳得低。给我完整的实现。”

然后AI会生成结构清晰的代码,包括注释。我只需要测试,然后说:“落地的感觉太滑了,增加一点摩擦力”或者”空中控制再灵敏一点”。

我变成了品控官,而不是工人。


AI是怎么”重构”我的旧代码的#

其实我之前已经写了一个原型,但代码很乱——毕竟是边学边写的。

于是我让AI做了一次彻底的重构。过程很有意思:

第一步:代码审查 我把整个项目丢给AI,让它分析代码结构问题。它列出了十几个问题:职责不清晰的类、硬编码的数值、重复的逻辑、缺少错误处理……

第二步:架构设计 我让AI设计一个新的架构。它建议用组件模式——把玩家能力(跳跃、冲刺、攻击)拆成独立的组件,可以灵活组合。这样一来,后期要新增能力就不需要改动核心代码。

第三步:逐步重构 不是一次性重写,而是分模块进行。先重构玩家控制器,再重构关卡生成,再重构敌人AI。每重构一个模块就测试,确保功能正常。

第四步:文档生成 AI还自动生成了代码文档和架构图。这是我以前从来不会做的事,但AI几秒钟就完成了。

重构后的代码量减少了30%,但功能完全不变,而且更容易扩展了。


关卡是怎么”长”出来的#

关卡生成是AI发挥创意的核心环节。

我的需求很明确:AI不直接”画”关卡,而是输出关卡配置——一份结构化的JSON数据,描述这个关卡有什么元素、在哪里、参数如何。

流程是这样的:

  1. 我把设计需求告诉AI:当前难度级别、需要的关卡长度、必须包含的元素类型
  2. AI生成一份JSON配置文件
  3. Godot读取这份JSON,实例化成真正的游戏关卡
  4. 系统验证这个关卡是否真的能通关
  5. 如果验证通过,存入本地缓存;如果失败,让AI重新生成

我为什么不用纯随机生成?

因为随机的关卡几乎肯定不可玩。AI的优势在于它懂”规则”——它知道平台间距不能太远、敌人和陷阱不能堵死必经之路、难度要循序渐进。

这些规则我可以用自然语言描述给AI,它会自动在生成时遵守。


游戏会是什么样#

核心玩法#

节奏是”短、平、快”:进入关卡 → 穿过平台与陷阱 → 到达终点 → 结算 → 下一关。单关控制在60到120秒,死了能快速重来,过关有明确成就感。

操控手感#

平台跳跃的灵魂是手感。我正在和AI一起调试的机制包括:

攻击方式我选了最经典的”踩踏”——从上方落到敌人身上就能消灭它。这既是攻击也是移动,和平台跳跃的核心体验天然契合。

敌人设计#

MVP版本不追求复杂AI,但需要2-3种类型制造变化:

主角与世界观#

主角叫 铁头,一个中世纪王国的新手见习骑士,因一次神秘的盔甲锻造事故获得了不寻常的力量。

这个设定有几个好处:骑士盔甲的模块化结构天然适合”能力解锁”(护手、护胫、胸甲各对应不同能力),头盔面甲的开合可以强化情绪反馈,厚重盔甲让夸张动作不违和。

世界观背景:王国最伟大的炼金术师 梅林 创造了管理领地的魔法系统 Arcana。当Arcana开始按自己的”完美秩序”标准重塑王国时,铁头在一次魔法盔甲试炼中觉醒,进入不断变化的城堡与村庄中探索。

这解释了为什么每次地图都不一样——Arcana在不断重组王国的结构,试图构建它心目中的”理想国度”。

美术风格#

我选现代像素风格——保留像素艺术的魅力,但加入现代技术:16位色深、60 FPS流畅动画、光影叠加、粒子反馈、视差滚动背景。


现在的进度#

项目骨架已经搭起来了:

接下来要填血肉。我的优先级:

  1. 补齐关卡要素 —— 至少加入陷阱或移动平台中的一种
  2. 扩充敌人类型 —— 再实现一种,飞行或远程
  3. 最小UI实现 —— 主菜单、暂停、HUD
  4. 音效与反馈 —— 跳跃、落地、受伤、消灭敌人都要有反馈
  5. AI生成逻辑优化 —— 等基础扎实了再调难度曲线

风险与对策#

风险一:关卡”能跑但不好玩”

这是程序化生成的常见病。对策是缩小生成空间——不让AI有太多自由度,用强约束的模板,明确参数边界。同时用缓存系统沉淀”好关卡种子”。

风险二:AI生成太慢

如果每次生成都要等几秒,玩家会疯。对策是先用快速检查,必要时再用AI生成。还可以异步生成——玩家玩当前关卡时,后台已经在准备下一关了。

风险三:我变得太依赖AI

万一哪天AI服务不可用怎么办?对策是所有AI产出都要可维护——代码要有清晰注释,JSON配置要有文档,我不能完全不懂自己项目的实现。


MVP与路线图#

30天内的MVP目标要克制:

明确不做:复杂剧情分支、关卡编辑器、成就系统、本地多人、实时生成。

发布路线分四阶段:

  1. 技术演示 —— 验证核心假设,产出演示视频
  2. MVP测试版 —— 可循环游玩,小范围测试
  3. 早期访问 —— 持续加内容,Steam/itch.io收集反馈
  4. 1.0正式版 —— 内容完整、稳定达标

写在最后#

这是一个实验性的项目。它的价值不在于最终是否赚钱,而在于探索AI时代独立游戏开发的新范式

我想证明的是:当AI能写好代码时,独立开发者的核心竞争力不再是技术实现能力,而是设计判断力品味

知道什么感觉”对”,知道玩家想要什么体验,知道什么时候该坚持、什么时候该妥协——这些才是人类开发者不可替代的价值。

AI是强大的执行者,但方向盘必须握在人手里。

这个文档会随着项目进展持续更新。每一章都会记录新的发现、新的挑战、新的解决方案。

希望最终能成为一个完整的案例:如何当AI的老板,让它帮你做游戏。


💡 感谢您的阅读!工具在进化,创作的方式在改变,但用心创作的初心永远不变。 本站 RSS地址已更新,麻烦读者朋友们重新订阅一次喔!