Unity Spark 正式发布：浏览器里直接用 AI 做游戏

Behaviour
295 阅读8分钟

10 月 7 日，Unity 在官方博客发了一篇《Why we built Unity Spark》。标题很直白，产品也很直白：打开浏览器，用自然语言加素材拼游戏，不用装 Unity 编辑器，不用碰 C#。

这东西最近的讨论度不低，但它被误读得也厉害。中文圈里常见的转述是「Unity 也做了一句话生成游戏」，而 Unity 官方博客里第一件想澄清的恰恰就是这件事。

在这里插入图片描述

一、官方先把「一句话生成」这条线划掉了

Unity CEO Matt Bromberg 在博客里写得很直接：Spark 不是关于「one-shotting」（一次性生成）游戏。 在这里插入图片描述

图：Unity Spark 官方发布主视觉：深色背景上带 Unity 立方体标志与「Unity Spark」字样的产品标识图（1920x1080）。（图源：Unity 官方博客 Why we built Unity Spark cdn.sanity.io/images/fuvb…

他给了一个比喻，我觉得是全文最值得抄下来的一句：让 AI 去复刻一款已经存在的游戏，「不会让你成为下一个小岛秀夫，就像在文字处理器里重打一遍《战争与和平》第一段不会让你成为托尔斯泰」。

所以 Spark 的目标不是 prompt 进去、成品出来，而是让创作者做出「值得被加工、打磨和分享」的独特互动体验。说白了，AI 负责把门槛降到脚踝以下，剩下的活还得人干。这个定位决定了后面所有产品设计——它不是生成器，是一个带生成能力的编辑器。

支撑这个定位的是一组数字。Bromberg 给的对比是：约 30 亿人每个月都在玩用 Unity 制作的游戏，但其中几乎没有人自己做过一款。

他把电子游戏称为「最后一种几乎人人都在消费、却几乎无人创作的主流娱乐形式」。影视有人拍 vlog，音乐有人玩 GarageBand，代码有人写脚本，游戏这一块，消费端和创作端几乎完全断裂。Spark 就是往这道缝里塞东西。

二、目标人群不是开发者

Spark 面向三类人，Bromberg 点名了：gamers（玩家）、graphic artists who can't code（不会编程的图形美术师）、modders（模组作者）。据 80.lv 的报道，这三类是官方明确框定的对象。

这里就解释了一个看上去有点反常识的设计：Spark 要接 Unity Asset Store。既然 AI 能生成美术资源，为什么还要用专业美术师手里那批现成素材？

因为目标用户里有一批美术师。他们能画、能做模型，唯独卡在代码上。让他们从零学 Unity 的组件系统、Prefab 嵌套、MonoBehaviour 生命周期，成本太高；但让他们在一个浏览器编辑器里把 Asset Store 的资源和 AI 生成物拼起来，是能力范围内的事。

对已经在写 Unity 的人来说，这意味着 Spark 现在不是你的竞品，也不是你的新工具。它是把「有想法但不会写代码」的人往 Unity 生态里拉的漏斗入口。

三、技术上它到底是什么

几个容易混淆的点先理清。

Spark 不是一个独立产品，而是 Google 那个实验性平台 Playground 上的「扩展创作体验」。Google 先发了 Playground（playground.google.com，目前仅限美国 18 岁以上用户），据 Video Games Chronicle 报道，Spark 会作为 Playground 上的一层创作能力出现，计划在今年晚些时候进入 closed beta。

技术层面，Spark 会用多种生成式 AI 模型，并且不绑定 Google 独家模型。这条信息挺关键：合作是战略级的，但技术路线是多模型，不是把身家押在一家身上。

编辑器本身只支持桌面浏览器，但做出来的游戏可以在桌面和移动浏览器上被玩。协作方式是多用户共享一个链接、同时编辑同一个项目，成品发布到 Google Playground。Google 后续还计划把 Google Play Games 的资料页、排行榜、多人匹配这些社区功能接进去。

至于终局，Bromberg 在 CNBC 采访里说希望平台最终能上主机——先 web，再移动，再覆盖「所有平台」，靠的是 Unity 那句老 slogan「build once, distribute everywhere」。这个野心大小，读者自己判断。

在这里插入图片描述

四、发布时的硬边界

这部分是转发里最常被漏掉的。

据多家报道，Spark 发布初期有几条硬限制：项目不能下载，也不能导出到完整的桌面版 Unity 编辑器；用 Spark 做的游戏不能用于商业售卖。

不能导出到桌面版 Unity，也不能商业售卖。 这两条摆在一起，Spark 现在的形态就清楚了——它是「创作 + 分享」的闭环，不是通往正经商业发行的路径。做得再好玩，也只是网页里一个能发给朋友点的东西。

变现方式是 credit 制，跟 AI token 挂钩：给一部分免费额度，用完了可以买更多，但最终定价还没敲定。Unity 的说法是，这套系统的主要目标是让更多人开始做游戏，而不是生成利润。据 GamesIndustry.biz 报道，官方口径就是这样。

对这条口径，我的看法是它只能当作「当下」的定性，不能当承诺。免费额度 + token 计费这个结构，天然会把成本压力传导到用户侧，最终怎么定价，还是看 beta 期的真实使用数据。

五、一条能自己搭的最小回路

既然不能导出，短期内别指望 Spark 吐出一个 .unitypackage 出来。

但如果你想在自建流程里跑一遍同款思路——自然语言起步、素材组装、人在回路打磨——桌面 Unity 里搭个最小回路并不难。以下代码不依赖任何 Spark API，纯粹是把「描述 → 结构化清单 → 编辑器批量生成」这条链路本地化。

先定义一个蓝图资产：

using System;
using UnityEngine;

[CreateAssetMenu(menuName = "Spark/Blueprint")]
public class SparkBlueprint : ScriptableObject
{
    public string prompt;            // 原始自然语言描述
    public string[] assetGuids;      // Asset Store / 本地素材引用
    public SpawnRule[] rules;        // 组装规则，AI 产出的部分
}

[Serializable]
public struct SpawnRule
{
    public string prefabPath;
    public Vector3 position;
    public Vector3 scale;
}

再写一个编辑器脚本，把外部传进来的 JSON manifest 直接烘成场景骨架：

#if UNITY_EDITOR
using System.IO;
using UnityEditor;
using UnityEngine;

public static class BlueprintBaker
{
    [MenuItem("Spark/Bake Blueprint From JSON")]
    static void Bake()
    {
        var path = EditorUtility.OpenFilePanel("选择 manifest", "", "json");
        if (string.IsNullOrEmpty(path)) return;

        var json = File.ReadAllText(path);
        var bp = ScriptableObject.CreateInstance<SparkBlueprint>();
        JsonUtility.FromJsonOverwrite(json, bp);

        var root = new GameObject(string.IsNullOrEmpty(bp.prompt) ? "Blueprint" : bp.prompt);
        foreach (var rule in bp.rules)
        {
            var prefab = AssetDatabase.LoadAssetAtPath<GameObject>(rule.prefabPath);
            if (prefab == null) continue;

            var go = (GameObject)PrefabUtility.InstantiatePrefab(prefab, root.transform);
            go.transform.localPosition = rule.position;
            go.transform.localScale = rule.scale;
        }
        Undo.RegisterCreatedObjectUndo(root, "Bake Blueprint");
    }
}
#endif

prompt 字段现在没什么用，但它是整条链路的锚——等 manifest 那一端换成真的模型输出，改的是数据来源，消费端一行都不用动。

这里的重点不在代码本身，在于它演示了 Spark 式工作流的一个隐含前提：AI 的输出必须是可编辑的中间产物，不能是黑盒成品。这也是官方那句「值得被加工」落到工程上的样子。

六、在生态里它站在哪个位置

和「一句话生成游戏」那类产品比，两边的赌注完全相反。那类产品的卖点是 prompt 进去、能玩的东西出来，赌模型一次做对；Spark 赌的是人，它把生成结果当成草稿而不是成品。Spark 赌的是人，上限由用户手艺定，而不是由模型能力定。

和 Unity 自家产品线比，三条线各管一段。Muse 是给现有开发者的 AI 辅助，在做游戏的过程中提速；Sentis 是把训练好的模型跑进运行时，管的是游戏里怎么用 AI；Spark 是面向非开发者的创作入口，管的是谁能进来做游戏。互相不打架。

往大了说，这是引擎厂商第一次以「零门槛 AI 创作」的形态直接面向 C 端创作者。对 Unity 来说，这既是内容供给的问题，也是变现的问题——30 亿月活玩家，转化出千分之一愿意动手做东西的人，都是个数得过来的量级。

在这里插入图片描述

七、还没答案的几个问题

第一个，「不能导出、不能售卖」这两条会不会放开。放开的话，Asset Store 素材在 Spark 里的授权和分成怎么算？这直接关系到美术资源提供方愿不愿意继续供货。不放开的话，它对 Unity 商业生态的价值就只剩下拉新，天花板肉眼可见。

第二个，多模型路线具体用谁的模型。多模型意味着质量、成本、一致性三件事同时要控制，这在闭源模型 API 的定价体系下不是小事。

第三个，主机那条路怎么走。浏览器端起步、不能导出工程的东西，怎么落回主机，官方只给了方向，没给路径。

Spark 现在最值得看的，其实不是它能生成什么——生成能力这一轮所有人都差不多。真正决定它是不是玩具的，是 Unity 敢不敢把「不能导出」这条限制拿掉。拿掉的那天，它才从一个 demo 站变成一个入口。

参考链接

avatar
文章
阅读
粉丝