Fieldmade:靠画像素画加 AI 来做 RPG 合成的游戏
文章摘要
Fieldmade 是工作室 Chroma Golem 发在 itch.io 上的一款 HTML5 网页游戏(状态标为 Prototype,发布 5 天、更新 2 天前,标签包括 Aseprite、Cozy、Crafting、Farming、Life Simulation、Pixel Art、单人;AI 披露项标注为 AI Assisted,涵盖代码、图形、音效和文本)。核心卖点一句话就能说完:你画什么,它就变成真的。开场设定是你的货车在乡间小路上抛锚,兜里除了一本速写本什么都没有,镇上的人没有赶你走,而是给你机会自己挣出修车钱。于是你只能用你唯一会的方式干活——画锄头就能锄地,画斧头、洒水壶、鱼竿,它们就变成真的、带真实数值的工具。没有配方表要解锁,也没有科技树要爬,只有你、一块田,和你能想出来的任何东西。你可以画一盏灯、一把摇椅、一串风铃、一个歪歪扭扭的稻草人来装饰农场,而这些家具「在别处都不存在,因为没有别人画过」。颜色系统与农业系统挂钩:金盏花、菘蓝、茜草等共 11 种作物需要自己种、收、磨成颜料,再在染料台调出需要的颜色。NPC 会逐渐来找你下单(铁匠要一把正经的斧头、邻居要个挂窗户的东西),付你钱、人情,以及你自己做不到的东西,镇上的人各有难处,你的速写本成了打开他们心事的一把奇怪钥匙。
作者 ChromaGolem 在 HN 评论区放了一篇极长的技术自述,是本条目最有价值的部分。AI 参与度非常高:「游戏代码接近 100% 由 Opus 5、Fable 和 Gemini 3.7 Flash 组合写成。」分工是——Fable 负责高层架构和项目搭建,包括规划新功能以及它们如何与其他系统交互;Gemini 负责一切视觉相关的部分(HUD/UI、动画、粒子系统),作者说它在这方面「似乎特别擅长」;Opus 5 负责苦力活,在设计方案和实现细节定稿后写代码。除角色以外的所有静态精灵图都在 Unity 里用 Gemini 2.5 Flash Image 生成(便宜、快、一致)。而所有带动画的精灵(包括角色)实际上是由 Gemini 生成的代码画出来的,而不是生成图片:作者解释,图像模型吐出的像素往往是模糊的,再经过缩放/风格化管线就更糟,要生成像素级精确且 PPU(每单位像素数)一致的 spritesheet 非常难。绕过这个限制的办法是,把角色的所有部件(头发、眼睛、胡子、手臂、腿等)都用代码生成,保证每一个像素都是硬边像素,并且让动画由数据而非图片驱动(这样重做角色风格的可维护性大幅提升),角色则被定义为「部件的集合」,包括这些部件各自同样方式生成的动画。
游戏里有两套合成体系。第一套是「你画的是不是这个东西」:NPC 通常会指定要你画某个具体物品;团队用 Gemini 批量为每个物品生成了「提示」模板,告诉你该怎么画(想要提示的话可以看);你画完后只做一个基础的相似度检查——「你和模板差了多少个像素」。足够接近就直接发物品,跳过所有 AI 环节,既省等待时间和 token 开销,也避免「玩家照着模板画了却被告知画的不对」这种恶劣体验。如果你彻底放飞、画了自己的理解,才把画布转成图片交给 Gemini 2.5 Flash 问「这是不是 XYZ 的图」,用 AI 判定目标是否达成,达成则给和标准模板同样的物品。
第二套是「画任意物品」:合成台上有一整块自由画布。提交后系统把画布转成图片交给 Gemini 2.5 Flash Image,问「这画的是什么」,得到答案(比如茶壶)后,再把结果交回 Gemini 2.5 Flash,附上「我们世界里所有可组合系统对物品如何运作的描述」,请它生成一个能用的茶壶的物品数据;与此并行(为了压缩等待时间)再让 Gemini 2.5 Flash Image 按游戏物品的美术风格画一个茶壶。两者都回来后写入物品数据库、在游戏里铸造出这个新物品,作为玩家刚刚合成的可用道具发给他。作者强调,真正承载能力的是游戏里已有的系统:生成的茶壶可能从基础的洒水壶那里拿到功能所以能浇地;「Mega Torch」可能有基础火把的功能但亮度值更高;「Glowing Teapot」可能既能浇作物又给你一圈微光,还能摆在农场里当永久光源。作者补了个有趣的耦合:种田产出的染料决定了你能用哪些颜色作画,而颜色又影响 AI 如何解读你的画——「祝你在没有蓝色颜料的情况下画出什么湿的东西」。
第三套是开放式采集(用工具作用于游戏内物体)。每次你用任何工具作用于任何物体,系统先查配方数据库看有没有已知结果:有就直接给(快);没有就进入多步生成流程——先问 Gemini 2.5 Flash「用 [工具] 作用于 [物体] 会发生什么」,归类为修改物体、修改工具、采集资源、触发其他游戏内效果这几种交互;再据此让 Gemini 2.5 Flash 基于已有的预编码系统生成该交互的数据。作者举的例子链条很能说明设计意图:用自制的 Superfiery Tinderbox 点树,树可能着火变成 Burning Tree(大概会加一圈强光),而这是个新物体,于是又有了新配方可发现——对它用斧头可能得到 Burning Wood,用洒水壶可能把它变回普通树;又比如用铲子挖树可能采到蚯蚓,蚯蚓用在泥土上把土变成沃土,再用铲子挖沃土得到肥料。最后,每对工具-物体组合生成出的配方都会被保存下来,此后这个交互在游戏里就是瞬时的。
HN 评论精华
这条帖子的社区讨论几乎不存在:只有 9 分,评论区仅 1 条发言,而且是作者本人写的技术长文。也就是说没有任何第三方的赞同、质疑或批评可供转述,因此这里不虚构任何用户名或观点,只如实呈现作者自述中最值得注意的几点。
- ChromaGolem(作者,也是本帖唯一发言者)开场就说:「给任何对这背后技术细节感兴趣的人,一大堵文字墙来了 :)」随后披露游戏代码「接近 100% 由 Opus 5、Fable 和 Gemini 3.7 Flash 组合写成」,并给出了三个模型的明确分工:Fable 做高层架构与新功能规划、Gemini 做视觉相关(HUD/UI、动画、粒子)、Opus 5 在设计定稿后做写代码的苦力活。
- 作者最有工程价值的一段是放弃用图像模型生成动画精灵:图像模型吐出的像素本身是模糊的,再经过缩放/风格化管线更难保证像素级精确和 PPU 一致,所以改让 Gemini 生成「画角色部件的代码」,保证每个像素都是硬边,动画由数据而非图片驱动,重做角色风格时的可维护性大幅提升。静态精灵(角色以外)则仍用 Gemini 2.5 Flash Image 在 Unity 里生成,理由是「便宜、快、一致」。
- 另一段很务实的取舍是尽量绕开 AI:对「画指定物品」的判定,先用像素差异的基础相似度检查匹配预生成模板,够接近就直接发物品。作者列出的三条理由——省等待时间、省 token 开销,以及避免「玩家照模板画了却被 AI 判定画错」这种最伤玩家的失败模式——是这类 AI 游戏里少见的清醒设计。
- 关于生成物品为什么不会失控,作者的答案是已有系统承载能力:生成的物品只是从预先编码好的可组合系统里取功能和数值(茶壶继承洒水壶、Mega Torch 继承火把但亮度更高、Glowing Teapot 同时具备浇水与发光),AI 生成的是「物品数据」而不是新逻辑。同理,工具与物体的开放式交互先由 AI 归类为修改物体/修改工具/采集资源/触发效果几类,再在既有系统框架内生成数据,且每次生成的配方都写回数据库,之后这个交互就是瞬时的——这是一个会随玩家游玩而逐渐「固化」、AI 调用越来越少的设计。
- 最讨人喜欢的一处系统耦合:农业产出决定颜料,颜料决定可用颜色,颜色又影响 AI 对你画作的解读。作者的原话是「祝你在没有蓝色颜料的情况下画出什么湿的东西」。