最近用 AI 做了一个暗黑像素风的肉鸽小游戏，名字暂时叫「暗黑罗格」。

试玩地址：
暗黑罗格

源码暂时不开源，主要是一个使用 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
2
3
assets/scripts/ArenaLayout.ts
assets/scripts/HeroAppearance.ts
assets/scripts/AdService.ts

例如 ArenaLayout.ts 专门处理地图边界、镜头、HUD 缩放和屏幕外刷怪点。这样在适配宽屏浏览器和手机竖屏时，不需要把所有逻辑都塞进游戏主类。

AI 最适合做什么

这次做下来，我觉得 AI 最适合做的不是「替你完成整个项目」，而是下面这些事情。

1. 快速搭建第一版

从角色移动、敌人追踪、自动攻击，到经验球吸附、升级弹窗，这些都是很适合让 AI 先搭第一版的内容。

因为这类功能规则清晰，输入输出也明确。

例如我会把需求写得尽量具体：

1
2
3
4
5
敌人必须从玩家视野外出生；
不能生成在墙外；
超宽屏时地图需要扩展；
死亡后不能立刻清空局内装备；
复活后获得 5 秒无敌。

需求越具体，AI 给出的代码越接近可用状态。

2. 把模糊的玩法变成参数

游戏平衡不是一句「怪物越来越强」就结束了。

例如经验升级需求，现在采用的是：

1
2
3
首次升级需要 36 点经验；
后续需求 = 上一级经验 × 1.38 + 6；
结果四舍五入。

所以升级经验会是：

1
36、56、83、121、173……

武器、敌人、升级和掉落也都需要明确参数。

AI 可以帮助整理这些规则、补齐边界情况和持续调整数值，但最终决定「好不好玩」的人还是自己。

3. 处理重复劳动

像素风资源也是一个很适合半自动化处理的部分。

项目里有 Python 脚本来生成和维护英雄皮肤、武器、敌人的精灵图和行走帧。这样新增一个武器品质或者一套皮肤时，不需要手动复制很多资源文件。

这里的感受很明显：AI 生成代码的价值，不只是少写几行逻辑，而是帮我把重复的工作变成工具。

不要只看「能不能跑」

AI 生成的第一版代码，大部分时候能跑。

但「能跑」和「能玩」差别很大。

例如这个项目里后来补了不少看起来很细碎的问题：

  • 键盘移动和触摸移动不能互相干扰
  • 斜向移动不能比直线移动更快
  • 敌人必须从屏幕外进入，而不是突然出现在脸上
  • 暂停、升级、死亡、切后台时都要冻结冷却时间
  • 广告回调只能结算一次，不能重复复活
  • 手机竖屏和桌面超宽屏的 HUD 不能被拉得很奇怪
  • 武器合成、碎片解锁、局外成长都要兼容旧存档

这些问题很多不是「主功能」报错，而是玩家玩十分钟后才会遇到的问题。

所以项目里目前有 18 组行为测试，主要使用 Node 的断言和 Cocos 对象 mock 来验证玩法逻辑，例如：

  • 武器掉落、装备和三合一
  • 地图和镜头边界
  • 横竖屏 HUD 布局
  • 虚拟摇杆和键盘移动
  • 敌人行走动画
  • 皮肤、天赋和局外成长
  • 广告完成、跳过、失败和并发请求

AI 很适合帮忙补测试，但前提是先告诉它「什么行为绝对不能坏」。

Web 发布

为了方便试玩，项目构建成 Web Mobile 版本后，会通过脚本同步到独立的公开演示仓库。

流程大概是：

1
2
3
4
Cocos Creator 构建 Web Mobile
-> 同步静态产物
-> 推送到 GitHub 仓库
-> GitHub Actions 部署 Pages

这样源码和试玩版本可以分开：

  • 私有项目仓库保留 Cocos 工程、资源和工具脚本
  • 公开仓库只保留 Web 构建产物
  • GitHub Pages 只负责托管静态页面

试玩地址就是：

https://m-finder.github.io/roguelike-demo/

这次最大的心得

以前我觉得做小游戏最难的是写代码。

现在感觉，写代码可能只是最容易的一部分。

真正困难的是：

  • 先确定最小可玩的版本
  • 不断告诉 AI 哪些功能不要乱改
  • 把模糊想法变成具体规则
  • 每次加功能后都验证旧功能
  • 克制住「再加一个功能」的冲动

AI 让一个人做小游戏的门槛低了很多，但它没有替代产品设计、玩法判断和测试。

它更像一个不会累的开发搭档。

你可以让它写移动逻辑、补武器系统、生成资源脚本、修复边界问题、补测试，但你还是要知道自己想做什么，知道什么该加，什么不该加。

目前这个小游戏还只是一个原型。

后面如果有时间，可能会继续补 Boss、更多地图、成就、音效和正式的微信小游戏发布。

先这样，能活多久就看你的走位了。