不论你是否有才华，或者是否有想做游戏的冲动，齐备的物质条件都在说明一件事：今天，任何人都可以很快地做出一款，甚至多款电子游戏。
在我的传统认知里，想要做出一款游戏，怎么说都要花上几天构建关卡，还要花心思打磨，统筹美术资源和音乐，怎么说好像都不是完全没接触过游戏开发的人能上手的东西。
但很明显，我弄错了做游戏的方法。
产品研发中有一个术语叫MVP（Minimum Viable Product），翻译成中文是“最小可行性产品”，不是那个什么NBA球场上的MVP（Most Valuable People，最有价值球员）。在绝大多数情况下，很多游戏就是从一个堪堪能玩的小Demo逐步开发成成品的。尽管游戏非常关注“打磨”，但这个“从零到一”的启动步骤也是至关重要的。
而人工智能大模型的出现，让完全没有游戏开发经验的人，在面对“从零到一”的起步阶段时，从”难于登天“变成“唾手可得”。
我其实只用了几个瞬间就明白了这个道理。只不过由于后天养成的性格，使我在这几个月来明明已经看到了有各种好用的工具时，面对它们却完全无动于衷。
让我突破这层桎梏的，是我在网上看到的一个利用ChatGPT开发的，极其简陋的，指挥蚊子咬人的HTML游戏。
北方夏天的蚊子非常猖獗，夜深人静时，一些被放进家里的蚊子就会围绕在耳边嗡嗡作响。一方面很烦，另一方面也确实很忌惮蚊子对我的皮肤发动偷袭。
每次打蚊子的时候，我都会想起《游戏风云》栏目中介绍的，PlayStation 2主机上的游戏《蚊》（Mister Mosquito）。玩家操控一只蚊子，骚扰山田一家人。
相比之下，那个HTML游戏则极为粗糙：没有复杂的3D场景，人类没有对应的反应机制，操作的方式也极为简单：拖动鼠标即可。
这时候我才猛然意识到，好像在制作一个小Demo的时候，暂时没必要考虑这个那个的。先做出来可能比什么都重要。
所以，我便开始构思第一款游戏Demo。
飞卡
我一开始就将游戏规模定锁定在了“简单操作+HTML编写”的范围，并围绕这层限制确定游戏的玩法。
我很快确定了利用鼠标“点击+拖拽”的操作逻辑，因此玩法层面也是很快的联想到了Rovio的《愤怒的小鸟》（Angry Bird）。
很明显，我在构思时还不认为大模型配合HTML文本能快速实现《愤怒的小鸟》这种规模的物理特性和关卡安排，但“点击+拖拽”一个物体之后产生的惯性似乎可以用很简单的方法实现。所以我就把这种操作逻辑敲定为游戏最核心的操作方法。
接着就是配合一套自洽的，简单的玩法。既然是“点按+拖拽”出现带惯性的飞行效果，那么似乎轻一点的物体可以更好地展现这套逻辑。
我想到了我小时候常玩的“打面包”。玩家用纸折好的“面包”，摔击场地上对手的“面包”，利用物理特性将其掀翻。我认为这一层物理在HTML层并不容易实现，而且需要制作额外的动画效果，因此希望简化这一逻辑。
我想到了另一个常玩的游戏：飞卡。这个游戏的玩法比打面包更直白：场地上的先手玩家，将自己手上的牌抛掷到距离对方卡牌一掌以内，就能吃掉对方的牌，赢得胜利。
这在现实生活中比较好实现，但在可视空间有限的电脑或者手机屏幕上，这种玩法的局限就比较大了。所以我试着融合了打面包的规则，让先手玩家的牌覆盖在对手卡牌上，覆盖超过一定面积就能获胜。
这些构思是我在晚上睡觉之前和在公共交通上完成的。到家之后，我就开始让大模型帮我生成开发文档。文档对于项目开发至关重要，而对于游戏开发而言，编写文档则是任何项目开始动手之前几乎是最重要的必要工作。
我没有特别在意Demo的名字，只是因为叫着顺口，就将Demo的名字定为了：《飞卡》（Flycard）。
我利用免费版的ChatGPT对话窗口帮我设计了几版开发文档。我的要求是：每做一版开发文档，就找出文档中不确定和设计上相互冲突的部分，列出来并向我提问。
在解决了模糊和设计冲突的问题，迭代了三版文档之后。ChatGPT的免费额度刚好用完。我把完善过的文档，以及第一版游戏的bug代码都扔给了腾讯元宝，让它正式进行游戏的开发工作。
游戏一共迭代了四版，第一版完善了物理规则的细节和手感，后面三版则是在不断测试AI的难度、胜利目标和增加英语。现在你看到的，就是这个游戏迭代第四版之后的样子，也是我当前已经正式发布的版本：
（背景音乐是我本地播放器的音乐，ChiliChill的专辑，不是游戏自带的(´_ゝ`)此外，若无法观看视频请开启全局代理。）
尽管我后来重新调整了一下手感和物理效果，但实际上，这个小Demo并没有我想象中的“那么有趣”。尽管这个想法在我大脑中的时候还算可以接受，但在实际游玩的过程中，这款小Demo并没有我想象中的，特别能激发玩家的求胜心——当然，也有一些可能过去没有经历过那个年代的小伙伴，在第一次玩到这个游戏的时候，或许会获得一点点乐趣。
总体执行下来，我还意识了另外一个问题，就是当今游戏从业者经常遇到的“卡发布”。游戏在临近发布，或者发布流程中总是会出现各种各样意想不到的状况，使得发布本身也成为了游戏制作中的重点关注环节。好在现在有了AI大模型，“卡发布”的问题并没有困扰我太长时间，加上游戏规模很小很小，AI几分钟就解决了问题。
为了让游戏“玩的愉快”，我几乎马不停蹄地开始了第二款游戏的构思。
不可能的贪吃龙
在我二十多年的玩游戏的生涯中，我了解到：一款游戏想要好玩，最重要的事情，除了做减法之外，就是打磨：打磨游戏的手感、动画动作帧数、打磨数值，打磨游戏中所有看得见和看不见的部分。
《飞卡》带给我的信心是：大模型配合HTML文本，可以轻易地实现一些非常简单的物理特性。既然这条路走得通，加上我这次的目标，并非针对操作方式和关卡设计进行迭代改进，那么我就可以先继续采用HTML，维持项目规模，专注于优化玩法体验。
这次我需要验证的则是：若将玩法集中在更简单的“滑动”上，我可以以多快的速度构建一款玩起来手感还不错，只需简单的手工打磨，或大模型帮我打磨，就能带来一点点刺激感，并能在一分钟内玩完一局的游戏。
我第一时间想到的就是大名鼎鼎的《贪吃蛇》；但贪吃蛇这种游戏几乎是所有AI游戏开发教程的第一课，想要做出有趣的Demo，仍需增加一些不一样的元素进去。
我想到了那个简陋到不行的“拖动蚊子emoji咬人”的HTML游戏。和之前提到的《蚊》不一样的是，这个小Demo多了一点点额外的机制：每咬到一次人，那个蚊子的emoji就会变大一点。
如果你经常混互联网和独立游戏圈子，应该一眼就能看出来这是Agar.io的机制。如果你不知道这个曾经火遍整个互联网的小项目，容我在这里稍微介绍一下：它是《贪吃蛇》的“网络对战版”，每一个玩家各自指挥一个“吃掉比自己小的泡泡就会变大的泡泡”，在一个无边际的竞技场中生存并赢得胜利。
这款游戏在国内也有一个长期运营的版本，叫《球球大作战》。
Agar.io带来的策略性和刺激感依赖的是PVP，也就是玩家之间策略和走位博弈，单纯依赖AI暂时还做不了网络部分的设计，因此，想要让一个“开箱即用”的Demo里体现这种“微微紧张”的质感，就需要给这个能无限膨胀的球体加上一点点有随机性的限制。
由于我不打算让AI生成任何独立的美术资产，所以将游戏的美术设计放在了emoji上。
而emoji中天然有一个适合当作提升游戏策略性的图案：炸弹💣。
我想到了一个点子：如果在玩家操作的“贪吃蛇”或其他东西在“进食”的时候碰到炸弹，会产生什么样的后果。
当确定了这些思路之后，我再次打开腾讯元宝，并开启专家模式帮我梳理开发文档，并要求大模型依照文档开发游戏。
之所以继续采用腾讯元宝，除了经济问题，另一个方面其实是我后知后觉的：腾讯旗下有数支国际顶级游戏开发团队，并且微信小程序上的游戏也是数不胜数。自然地，腾讯云的游戏开发基建也几乎可以肯定是全球最好的。这么说我认为一点都不为过。
在开发这款《不可能的贪吃龙》（Impossible Dragon）Demo的时候，似乎也印证了我的感慨。
我在把我的想法整理成大纲时，我希望的是让大模型先生成游戏文档，再根据游戏文档进行开发。但实际上，在我有意识地观察了元宝的思考过程时才发现：大模型在后台跑的时候，就直接开始开发MVP并进行测试了。
也就是说，虽然我的要求是先完善游戏开发文档再进入正式开发，但实际上大模型的方法是“一边写文档一边构建Demo进行测试”。尤其是当一个项目非常精简，整个HTML文本只有几十KB的时候。当然，这也让我有所顾虑：是不是已经有其他人开发过这样的玩法，而大模型已经完全跑通了这个模式，因此才会直接进入构建状态，再用完成或半完成的build来辅助文档的编写。
不仅如此：腾讯的大模型在后台工作的时候还加入了许多我不曾想到过的细节，包括emoji生成频率的变化曲线、动画特效、无敌帧、WebAudio合成音效、滑动逻辑的打磨、惩罚特性随进度变化等元素，都是大模型帮我想好的。尽管这些细节没有特别让游戏变得更好玩或者更不好玩（毕竟不是影响游戏的核心玩法元素），但至少能让游戏看上去有清晰地“打磨过”的痕迹。
我和大模型之间的拉扯只有5轮，解决了前期模糊不清的构思，同时否决了两个大模型自以为不错的设计，并且修掉了两个bug之后，就把Demo上传到了Gtihub。成品如下：
（注1：若无法观看视频请开启全局代理。）
（注2：在Windows 10系统下玩这个Demo，一些emoji由于没有更新所以显示不出来，如果你的电脑是最新的操作系统是不会出现这种bug的！）
这个Demo最让我震惊的一点是，通过大模型自主增加了不少细节之后，这个游戏“带有一点点刺激感”的质感被放大了非常多，但它仍旧带来的是主观上的“刺激感”，并非游戏设计上的难度堆砌。我在亲自跑测试的时候甚至不由自主的多玩了好几轮，并且每轮游戏时长确确实实都不超过50秒——实际上，在很多时候判断一款游戏好不好玩的标准就是：第一次上手之后会不会不由自主玩很久。策略类如《席德·梅尔的文明》（Sid Meier's Civilization）系列，ARPG类如《暗黑破坏神》（Diablo）系列，皆是如此。
今年夏天，国内独立游戏玩家社区里火过一款一人开发的Roguelite游戏《群侠传：幸存者》。这款游戏从美术、音乐到数值、机制均由AI打造，但我在没有看过开发人员专访直接去玩的时候，就能明显感知到游戏在AI的外表之下，有着非常非常重度的人工打磨痕迹，不论是动画帧数还是数值设计，人工介入的质感极为明显。当时我就意识到：一款游戏是否能让玩家上头，目前靠的依旧是“人”这一环——而这也是我在设计《不可能的贪吃龙》这个项目时最想验证的地方。
我得到结论是：如果游戏规模控制在《不可能的贪吃龙》这种小Demo时，现有的大模型产品完全能够自主打磨并带来远比原始Demo更优质的体验（不论是开发过程还是游玩过程）；而一旦将规模提升到《群侠传：幸存者》这种涉及技能提升、玩法区分，长线玩法的难度梯度设计，以及美术和音乐的全方位制作时，依赖人类进行的反馈和迭代仍然是不可或缺的环节。
小结
从《飞卡》的构思正式落地到上线最新的迭代版本，由于用的是零碎时间，但全部时长也只用了不到五个小时，其中真正工作的时间可能只有不到90分钟；而《不可能的贪吃龙》由于需要更细致的想法落地和打磨，因此我坐在电脑前跟大模型协同，但其实花了也不到120分钟，就将游戏部署上线了。
当然，这里的“上线”指的是将游戏上传到代码托管平台；真正的游戏发行业务，暂时还不是现在的我能接触到的。不过在大模型的帮助以及我观察到的案例已能充分说明：开展这些后续的发行工作也并非难事。
但这并不意味着开发游戏就一帆风顺了。目前，利用大模型做游戏，仍然要克服至少三件事情：
- 迈出第一步，将想法落地：有时候可能是想法很多，但更很多时候可能确实是没有想法。比如我一开始完全没有思路，直到看到了某一款个游戏Demo之后，我才有了“我上我也行”的心态，并开始动手；
- 打磨至关重要：不论是大模型来打磨，还是人工介入打磨，都是非常非常关键的。游戏只有打磨过，那些数值上体现不出来的，无法量化的，真正让人上头的东西，才能真正透过玩法和机制体现出来，让游戏体验更上一层楼；
- 发行之后，还有宣传与销售：这是对于绝大多数游戏开发者和制作人们最难克服的障碍。大模型能帮你开发，能帮你跑测试，能帮你修bug和打磨，但它们不能帮你获客，没法帮你建立私域，初期也不可能帮你宣发和销售。这在目前仍然是大量依赖人力完成的工作——毕竟，你的游戏也不是给机器玩的，对吧？
电子游戏不论对于当代人类有多刚需，本质上仍旧是极端“务虚”的产品类型。这类小游戏所面向的玩家群体和社区，目前主要仍是玩游戏且经常玩电子游戏，同时不太在乎自己玩的是不是AAA游戏的那群人。
已经被验证过的宣发模式包括QQ/微信群，明星制作人号召，平台投流等方式。但随着游戏越来越多，玩家注意力越来越分散，不论私域还是投流，都正在朝着军备竞赛的方向发展。尽管不是所有的独立游戏开发者都砸不起这一笔费用，第三方发行商的介入也在从商业角度尝试解决这种问题，但它仍旧是中国独立游戏人面对的最大难题。