文字生成游戏AI平台给你的东西，和它给不了的东西

文字生成游戏AI平台把「一句话」和「能玩的东西」之间的距离压得很短。你写屏幕上发生什么，平台去补规则、画素材、配音效，最后交回一个在浏览器标签页里就能打开的东西。没有场景编辑器，没有脚本文件，也没有素材目录要整理。代价同样实在：你拿到的是一个跑起来的游戏，而不是一行行都能自己掌控的工程，每次改动都要回到那段描述里。

这篇写给没有美术功底、只有想法的人。挑工具之前先摸清工作流的形状，判断会快很多。哪些环节消失了，哪些反而更难，动手之前该验证什么，下面按顺序说。

文字生成游戏AI平台交到手里的，是一个能玩的东西

产出是可玩的成品，不是源码工程。具体来说包括几样：平台推定出来的一套规则、生成的图形、声音，以及让这些东西在网页里跑起来的封装。拿不到的是能手动摆放的场景树、写条件的脚本层、两版之间逐项对比的视图。

这个区别决定了后面所有判断。在引擎里，工程文件是真相，构建结果是副产品。这里描述是真相，其余全是副产品，包括你刚刚玩过的那一版。两个人写同一段描述，做出来的东西都能满足那段话，也会在那段话没写死的地方分岔。

BinkBink 走的就是这条路：写好的描述进，能在浏览器里跑的版本出，用链接分享。真正值得琢磨的不是它能不能跑，而是一段描述要具体到什么程度，产出才值得留下。

从一句话到一局，中间发生了什么

流程里有几个能分辨的阶段，虽然你看不见。平台先读文字，抽出实体：玩家控制什么、什么在挡路、什么算赢、什么算输。接着把它落到一两个操作上，因为浏览器里的短会话教不会五个按钮。然后挑一条难度曲线，生成和描写场景相配的画面，最后打包成浏览器能加载的东西。

由此有两条结论值得先记下。

具体比热情有效得多。「做一个好玩的平台跳跃」把所有决定都留空，平台只能用无趣的默认值去填。「外卖员骑电动车穿过三条施工中的街，每二十秒加速一次，撞一次就结束」，开场、失败、节奏一次定完。后一句更短，干的活更多，因为每加一个限定，就少一个待定项。

第二条是产出不确定。同一段话要两次，两次都满足描述，都不是你脑子里的那张图。这不是要上报的缺陷。它正是要把描述当版本管理、把每次产出当草稿的原因。改动让游戏变好了，描述也该跟着改，否则下一次生成又把改进抹掉。

H5游戏生成器解决的是分发，不是规模

H5 在这里的意思是游戏在浏览器里跑。不装包，不过商店审核，不需要平台批准。手机和笔记本打开同一个链接，做完的版本在浏览器里直接玩，发给别人就能开。真正的收益在分发：一个可玩原型能塞进聊天、帖子、客服回复、文档。门槛比发一个应用低得多，在原型阶段，这就决定了能不能拿到反馈。

成本压在下面。浏览器给的预算固定：逻辑和绘制挤在一个进程里，WebGL 上下文要和页面一起待在内存中，素材必须在第一帧可玩之前到位。中端手机上这份预算很快见底，大场景 3D、密集粒子和同屏多个动画角色都会从各个方向顶到天花板。

题材的匹配是算术题，不是审美题。可见对象少、循环清晰的短会话游戏塞得进去：无尽跑酷、街机生存、简单解谜、合成棋盘、带插画的分支叙事。需要持久世界、需要玩家同步、需要同时跑几百个单位的东西塞不进去，换多少种写法都抬不高这条线。

还有一条安静的边界。浏览器里的成品住在一个网址上。跨设备存档、账号、排行榜，以及清掉缓存之后还能留下的东西，都需要服务端。从描述生成出来的版本不带服务端。

描述在哪儿不再是设计文档

有四样东西一定会从段落里漏掉，早点知道能省几周。

第一是含糊。「好玩」「精致」「有手感」这类词描述的是感受，感受没法被执行。平台只能对可以判定的条件起作用：玩家按了什么、碰到什么会发生什么、什么时候结束、每样东西跑多快。转不成判定的句子，在转换过程中就消失了。

第二是操作精度。逐帧手感、跳跃弧线、受击后的恢复窗口，都要拿着能毫秒级重玩的版本去调数值。AI做游戏在这里只能改句子再重新生成，工具很粗。你能把跳跃从发飘改成发沉，调不出让平台游戏显得公平的那十一帧宽容。

第三是状态复杂度。「如果玩家有钥匙且门是开的」这种规则自己就能写完。「商店第三天补货、价格随声望浮动、稀有物品只在第二个 Boss 之后出现」是一套系统，而系统要显式状态、执行顺序和存储。描述能载得动循环，载不动模拟。

第四是内容量。生成一个画面便宜，生成二十关还不重复，那是产线问题。一旦需要战役，句子就变成目录，你又回到手写加生成辅助的状态。

一晚把第一版放到线上

到「真能动」最快的路，是把范围砍到只剩流程本身这一个变量。一次做完。

1. 在文本文件里写三句：玩家每十秒做什么、什么结束这一局、什么让它越来越难。总共控制在四十字以内。
2. 用这三句生成。别加第四句。
3. 玩五分钟，只挑一个缺陷。挑让你停手的那条，不是截图里最难看的那条。
4. 改掉负责它的那一句，重新生成，再玩。如果缺陷改完还在，说明问题不在那一句，而在循环本身。
5. 把链接发给三个没读过你那三句的人，只问一个：什么时候你不想再玩下去。别问好不好玩。

第四步最容易出错。一次改两三句，版本变好了，但没人知道是哪一处起的作用。一次只改一句，原因和结果还连在一起，一轮也短到一晚能跑五轮。

哪些人不该从这类平台起步

手感本身就是卖点的游戏，从引擎起步更快。那里调参的循环就是产品，描述替代不了盯着结果拖数值。

想法是「一个世界」而不是「一个循环」的人，也该先停一下。设定、人物、地图，光写就能吃掉几个月，可玩的核心一直悬着。平台会生成一个符合设定、却没有任何事值得做第二遍的东西。这是没人提前警告的那种失败。

需要代码归属权的团队是第三种情况。要评审、要对比差异、要别人接手扩展、要维护好几年，成品必须是工程。

要设计账号、经济、联机的人，把这条路当原型阶段就好，别当交付方式。缺的服务端属于结构问题，不是装修问题。

花一个月之前先过四关

动手之前，用已经有的那一版过四道。

核心循环能连着玩三遍不腻吗？这一问考的是循环而不是打磨，也最能预测下个月值不值。

你能说出下一个要改的变量是哪一个吗。答案含糊，说明设计还停在气氛层面，再生成几次也不会变清楚。

别人不用听解释就能打开吗。打不开的版本等于私人实验，私人实验换不来让下一版变好的反馈。

范围还是一屏吗。当诚实的答案变成「一屏加一张地图加一个商店」，把你带到这里的这套流程就不再合适，转去有显式状态的工具，是迟了而不是早了。

那段描述就是设计文档。十秒能读完，具体到陌生人不用问你就能实现，就够了。其余的交给平台去跑。