用 AI 做了一个暗黑肉鸽小游戏
最近用 AI 做了一个暗黑像素风的肉鸽小游戏,名字暂时叫「暗黑罗格」。
试玩地址:
https://m-finder.github.io/roguelike-demo/
源码暂时不开源,主要是一个使用 Cocos Creator 3.8.8 + TypeScript 做的单场景地牢生存原型。
玩法比较简单:角色在地牢里移动,自动攻击最近的敌人,打怪升级,选择强化,尽可能活得久一点。
一开始我只是想试试:现在的 AI 到底能不能把一个「脑子里有画面」的小游戏做出来?
事实证明,可以,而且比我预期中更快。
但 AI 并不是输入一句「帮我做一个吸血鬼幸存者」就可以直接交付成品。
真正有价值的地方,是把一个大需求拆成很多小而明确的需求,让 AI 持续实现、修复和验证。
目前实现了什么
目前这个小游戏已经不只是一个角色在屏幕中间发射子弹了。
- 三张地图:遗忘地窖、霜封回廊、余烬熔室
- 全屏拖动虚拟摇杆,网页端同时支持
WASD和方向键 - 自动锁定最近敌人并攻击
- 六种武器:木杖、寒霜刃、余烬法器、骨矛、影灯、雷符
- 白、绿、蓝、紫、金五档品质
- 同品质武器三合一升阶
- 经验球、升级三选一、精英怪掉落
- 随存活时间增加怪物种类、数量和精英比例
- 局外天赋、皮肤、碎片解锁和地图战绩
- 暂时还没实现的看广告复活
- Web 试玩版自动发布到 GitHub Pages
现在看来,可玩性比我的预期要高出很多,唯一的缺点可能也就是现在的贴图有点丑萌,但是看多了觉得也挺可爱。
技术选型
项目使用的是 Cocos Creator 3.8.8,逻辑使用 TypeScript 编写。
我没有一开始就做服务端、排行榜、登录系统这些东西,而是先把核心循环跑通:
1 | 移动 -> 自动攻击 -> 击败敌人 -> 掉落经验 -> 升级强化 -> 敌人变强 -> 死亡重开 |
肉鸽游戏最重要的不是菜单有多漂亮,而是这个循环是否能让人继续玩下去。
项目的核心逻辑主要在:
1 | assets/scripts/RogueGame.ts |
这个文件负责游戏生命周期、敌人生成、武器攻击、掉落、升级、暂停、死亡和 UI。
后面随着功能变多,也逐步把一些适合独立测试的逻辑拆出来了:
1 | assets/scripts/ArenaLayout.ts |
例如 ArenaLayout.ts 专门处理地图边界、镜头、HUD 缩放和屏幕外刷怪点。这样在适配宽屏浏览器和手机竖屏时,不需要把所有逻辑都塞进游戏主类。
AI 最适合做什么
这次做下来,我觉得 AI 最适合做的不是「替你完成整个项目」,而是下面这些事情。
1. 快速搭建第一版
从角色移动、敌人追踪、自动攻击,到经验球吸附、升级弹窗,这些都是很适合让 AI 先搭第一版的内容。
因为这类功能规则清晰,输入输出也明确。
例如我会把需求写得尽量具体:
1 | 敌人必须从玩家视野外出生; |
需求越具体,AI 给出的代码越接近可用状态。
2. 把模糊的玩法变成参数
游戏平衡不是一句「怪物越来越强」就结束了。
例如经验升级需求,现在采用的是:
1 | 首次升级需要 36 点经验; |
所以升级经验会是:
1 | 36、56、83、121、173…… |
武器、敌人、升级和掉落也都需要明确参数。
AI 可以帮助整理这些规则、补齐边界情况和持续调整数值,但最终决定「好不好玩」的人还是自己。
3. 处理重复劳动
像素风资源也是一个很适合半自动化处理的部分。
项目里有 Python 脚本来生成和维护英雄皮肤、武器、敌人的精灵图和行走帧。这样新增一个武器品质或者一套皮肤时,不需要手动复制很多资源文件。
这里的感受很明显:AI 生成代码的价值,不只是少写几行逻辑,而是帮我把重复的工作变成工具。
不要只看「能不能跑」
AI 生成的第一版代码,大部分时候能跑。
但「能跑」和「能玩」差别很大。
例如这个项目里后来补了不少看起来很细碎的问题:
- 键盘移动和触摸移动不能互相干扰
- 斜向移动不能比直线移动更快
- 敌人必须从屏幕外进入,而不是突然出现在脸上
- 暂停、升级、死亡、切后台时都要冻结冷却时间
- 广告回调只能结算一次,不能重复复活
- 手机竖屏和桌面超宽屏的 HUD 不能被拉得很奇怪
- 武器合成、碎片解锁、局外成长都要兼容旧存档
这些问题很多不是「主功能」报错,而是玩家玩十分钟后才会遇到的问题。
所以项目里目前有 18 组行为测试,主要使用 Node 的断言和 Cocos 对象 mock 来验证玩法逻辑,例如:
- 武器掉落、装备和三合一
- 地图和镜头边界
- 横竖屏 HUD 布局
- 虚拟摇杆和键盘移动
- 敌人行走动画
- 皮肤、天赋和局外成长
- 广告完成、跳过、失败和并发请求
AI 很适合帮忙补测试,但前提是先告诉它「什么行为绝对不能坏」。
Web 发布
为了方便试玩,项目构建成 Web Mobile 版本后,会通过脚本同步到独立的公开演示仓库。
流程大概是:
1 | Cocos Creator 构建 Web Mobile |
这样源码和试玩版本可以分开:
- 私有项目仓库保留 Cocos 工程、资源和工具脚本
- 公开仓库只保留 Web 构建产物
- GitHub Pages 只负责托管静态页面
试玩地址就是:
https://m-finder.github.io/roguelike-demo/
这次最大的心得
以前我觉得做小游戏最难的是写代码。
现在感觉,写代码可能只是最容易的一部分。
真正困难的是:
- 先确定最小可玩的版本
- 不断告诉 AI 哪些功能不要乱改
- 把模糊想法变成具体规则
- 每次加功能后都验证旧功能
- 克制住「再加一个功能」的冲动
AI 让一个人做小游戏的门槛低了很多,但它没有替代产品设计、玩法判断和测试。
它更像一个不会累的开发搭档。
你可以让它写移动逻辑、补武器系统、生成资源脚本、修复边界问题、补测试,但你还是要知道自己想做什么,知道什么该加,什么不该加。
目前这个小游戏还只是一个原型。
后面如果有时间,可能会继续补 Boss、更多地图、成就、音效和正式的微信小游戏发布。
先这样,能活多久就看你的走位了。
评论