在 Summer Engine 中用 AI 制作多人游戏（2026 年的能力与路线图）

外面流传着一种说法：多人游戏是 AI 工具唯一帮不上忙的部分。这种直觉是有道理的。网络代码比单人游戏有更多失败方式。状态同步不留情面。一个在你机器上看起来没问题的 bug，第二个玩家加入的瞬间就会崩。所以当开发者听说有 AI 智能体能通过对话造游戏时，他们通常会默认多人这部分不在范围内。

实际情况要更复杂。一款用 Summer Engine 做的真实 3D PvP 射击游戏正在 Steam 上线，基于 Steam 的点对点连接、带语音聊天，由一个小团队大约用了十周完成。多人游戏中真正难的部分依然难。但搭脚手架的部分不难，而脚手架占了大部分工作。本文会走一遍：今天到底能做什么、用什么活生生的案例可以证明、技能库在哪里帮到你、什么还是真的很难，以及我们接下来在做什么。

今天能交付的东西

Summer Engine 是一款兼容 Godot 4 的 AI 原生游戏引擎，当你开始考虑网络代码时，这种兼容性的价值最为明显。Godot 4 自带一整套完整的高层网络栈。MultiplayerAPI 处理对等连接。MultiplayerSpawner 复制节点的创建。MultiplayerSynchronizer 按计划复制属性。这些都不是 Summer 自创的，它们是任何标准 Godot 安装中都有的同一套稳健 netcode，这意味着你做的东西在任何能跑 Godot 项目的地方都能跑。

在它之上，两种传输方式几乎覆盖了所有独立多人游戏的场景。UDP 上的 ENet 提供一个快速可靠的直连层。GodotSteam 封装暴露了完整的 Steam 网络 API，你可以通过 Steam Lobbies 主持游戏，并用 sendP2PPacket 和 readP2PPacket 交换数据包。GodotSteam 还暴露了 Steam Voice API，这意味着语音聊天只需要几百行脚本，而不是另接一家供应商。

Summer 在上面加的那块，是多人技能库。当你让智能体搭建一个合作大厅、宿主权威状态或点对点连接逻辑时，它会从一个叫 multiplayer-and-networking 的类别里取，其中包含 peer-to-peer-multiplayer、host-authoritative-state 和 setup-multiplayer 等技能。智能体并不是每次都现场即兴生成架构，而是遵循已经在真实游戏中验证过的模式。技能文件采用 MIT 协议，存放在开源的 Summer CLI 仓库中。

锚定案例：Don't Pray

如果这听起来太抽象，锚定案例是一款叫 Don't Pray 的 Steam 游戏。它是一款 3D PvP 魔法射击游戏，通过 Steam 进行多人连接，带语音聊天，由一个小团队用了大约两个半月做出来。你可以在 store.steampowered.com/app/4176260/Dont_Pray/ 找到它。

架构值得描述一下，因为它展示了一个真实的 Summer Engine 多人栈是什么样。autoload 栈包括：负责初始化和大厅管道的 SteamManager，掌管本地游戏会话的 SessionManager，抽象传输层的 NetworkManager，运行实际数据包层的 P2PNetwork autoload，以及三个用于镜像特定游戏状态的同步 autoload，即用于共享世界状态的 P2PGameSync、用于玩家职业选择的 P2PClassSync 和用于敌人 AI 同步的 P2PNPCSync。还有一个独立的 VoiceChatManager autoload 在所有这些之上跑 Steam Voice。

宿主权威坐在中心。一名玩家运行权威的游戏状态，其他玩家都运行一个本地预测、再与宿主对账的客户端。游戏还有一个两分钟的重连宽限窗口，所以如果某个玩家断线，他可以重新加入同一场会话而不丢角色。这种功能 AI 工具通常会跳过、人类通常事后才加，但技能库把它当作标准模式的一部分。

这在 AI 用量上花了多少钱？开发者的账号在整个开发期间大约花了两千美元的 AI 额度。这不是小数目，但相对于同样的日历时间雇一名多人程序员的成本，只是其中一小块，而且游戏现在已经上线并在 Steam 上产生收入。

智能体怎么帮你

更有意思的问题是：你让它做多人时，智能体从头到尾到底做了什么。技能库使用即时调用（just-in-time recall），也就是说，智能体只在识别到你请求中存在网络意图时才加载多人技能集。你不必手动挂技能，也不用记什么特殊命令。你说一句“把这做成合作模式”，对的脚手架就会出现。

典型的第一轮会产出一个点对点初始化脚本，包含创建大厅、加入大厅以及把基础的对等连接回调接到一个全局 autoload 上。下一轮通常会通过 MultiplayerSpawner 复制玩家场景，并加一个用于位置和旋转的 MultiplayerSynchronizer。再下一轮会为共享资源（比如拾取物或门）加上宿主权威。等你开始谈语音聊天或重连逻辑时，技能库已经在引用 Don't Pray 实际落地的那些模式了。

你依旧要审阅架构决策。智能体不会发明一套新颖的回滚 netcode 系统，你也不应希望它这么做。它擅长的是样板代码、大厅接线、同步节点、标准的宿主权威模式。这才是独立多人游戏的大半工作面，也正是通常会吃掉人类工程师好几周时间的部分。

仍然难的部分

假装多人游戏里所有事情都已解决是不诚实的。P2P 路线之外，存在真实的墙。

专用服务器托管是第一堵墙。Steam P2P 在好友列表合作和小型大厅上非常合适，但它依赖某个玩家做宿主，这意味着宿主的连接成了游戏质量的天花板。对于竞技性游戏或更大规模的会话，你最终会想要真实数据中心里的专用服务器，这是另一类运营问题。

区域路由是第二堵墙。一旦有了专用服务器，你就得决定某个玩家加入哪一台，这意味着撮合基础设施、ping 估算和回退逻辑。

大规模反作弊是第三堵墙。宿主权威给你一个基线，但对于排位竞技对局，你最终会想要更强的东西，而标准的内核级反作弊厂商是一项独立的集成。

这些都是真实的问题。它们不会仅凭当前的技能库被解决，谁告诉你解决了，请不要相信。

即将到来：Crafty

对于希望那些更难的问题有人替他们处理的开发者，我们正在搭建一个叫 Crafty 的平台。可以把它想象成 Summer Engine 上的一层 Roblox 风格的平台。创作者把签名的游戏包发到托管的服务器上，玩家通过 Crafty 客户端加入。它仍在开发中，尚未对外提供。

关于它在内部进展的几个诚实细节。平台 API 跑在 Railway 上。游戏服务器跑在 Fly.io 上用于区域分布。它有一个 SDK，包含 CraftyGame、CraftyPlayer、CraftyCharacter3D、CraftyTeams、CraftyScore、CraftyData、CraftyEconomy、CraftyUI 和 CraftyInput 这样的类。提交流水线已就绪，支持签名的游戏包，状态同步用 ENet UDP，以三十赫兹运行。M1 到 M4 四个里程碑已经在内部完成。下一个里程碑——玩家可真正购买客户端、创作者可向其发布游戏的公共抢先体验——尚未启动。

重要的定位：Crafty 不是一个给你独立 Steam 游戏插用的 netcode SDK。那是另一款产品。如果你要做一款以自己的品牌登陆 Steam 的游戏，Godot 网络加 GodotSteam 这条路今天就是正确答案，Crafty 上线之后它仍然是正确答案。Crafty 面向那些就是想发布到托管多人平台、而不是自己运营服务的创作者。

Crafty 公开访问开放时我们会发布更多信息。眼下唯一诚实的说法是：即将到来，开发中，尚未提供。

这对你意味着什么

画面层次分得很清楚。如果你是独立开发者，今天你就能交付 Steam P2P 的合作或 PvP。Don't Pray 就是证明。技能库做了大部分脚手架，GodotSteam 封装搞定传输，语音聊天近乎白送。小团队两个半月的开发周期，如今对一款真实可上线的多人游戏来说是现实的。

如果你是一个小型工作室，你能比以前快得多地原型化联网游戏。技能库意味着第一个可玩的多人构建只在数天之外，而不是数周。你可以在投入完整生产排期之前先验证一个多人玩法概念。

如果你是一家更大的工作室或加速器团队的一员，你可以用同一个循环在几天内验证多人玩法概念。AI 负责搭脚手架，你的资深工程师专注于设计问题以及技术栈中真正新颖的部分。

论点很简单：同一台引擎，跟着你扩展。一个发布首款合作游戏的独立开发者和一个原型化下一款作品的工作室，用的是同一套工具链、同一套技能库、同一台引擎。工作可以干净地向上扩展，不用从头来过。

从哪里开始

到 www.summerengine.com/download 下载 Summer Engine，从 www.summerengine.com/templates 打开一个 3D 模板，让智能体帮你搭一个合作大厅。如果你更想把 AI 接入到现有的 Godot 项目里，www.summerengine.com/mcp 这页讲了 MCP 路线。完整的智能体栈在 Godot AI 套件解析 和 引擎原生智能体外壳一文 中有完整记录。

技能库在 github.com/SummerEngine/summer 开源。Don't Pray 的 Steam 页面在 store.steampowered.com/app/4176260/Dont_Pray/，如果你想看看用这个技术栈做出的实际上线的多人游戏是什么样，可以去看看。

AI 多人不是未来的能力。它是当下的能力，并且有一款上线的 Steam 游戏作为证明。现在更有意思的问题是：你接下来要做什么。

常见问题

今天我能用 Summer Engine 加 AI 做一款真正的多人游戏吗？

可以。Summer Engine 兼容 Godot 4，后者自带完整的高层网络功能。结合用于 Steam 点对点的 GodotSteam 和多人技能库，AI 智能体现在就可以搭大厅、同步状态并接入语音聊天。

Summer Engine 底层用了什么多人技术？

通过 MultiplayerAPI、MultiplayerSpawner 和 MultiplayerSynchronizer 提供的 Godot 4 原生网络，加上用于直连的 ENet UDP，以及用于 Steam P2P 大厅与语音的 GodotSteam 封装。

有没有用这种方式做出来、并已发售的 Steam 游戏？

有。Don't Pray 是一款 3D PvP 魔法射击游戏，已在 Steam 上线，通过 Steam 进行点对点连接并带语音聊天。由一个小团队用了大约两个半月做完。

Crafty 是什么？

Crafty 是我们正在搭建的一个 Roblox 风格平台。创作者将游戏包发布到托管服务器上，玩家通过 Crafty 客户端加入。它仍在开发中，尚未对外提供。

Crafty 和今天提供的多人支持是同一件事吗？

不是。今天的多人指的是 Godot 4 网络在你自己独立游戏内部运行，包括 Steam P2P。Crafty 是一个单独的托管平台，有它自己的服务器和 SDK。两条路解决的是不同的问题。

AI 智能体真的会写网络代码吗？

智能体使用多人技能库来搭脚手架，包括大厅、宿主权威状态以及被复制的节点。架构仍由你审阅，而像回滚或大规模权威这类复杂系统需要人工介入。

现在能现实地做出哪些类型的多人游戏？

两到八人的合作游戏、小型 PvP 竞技、非对称多人、聚会类游戏，在 Steam P2P 上都是现实可行的。海量并发会话、以及依赖专用服务器托管的排位竞技玩法，并不能靠 P2P 路线解决。

AI 多人还有哪些难点？

专用服务器托管、区域路由、撮合基础设施和大规模反作弊。这些都是路线图上的项目，仅靠当前的技能库并不能解决。

多人技能库是开源的吗？

是的。技能文件位于 Summer CLI 仓库的 multiplayer-and-networking 目录下，以 MIT 协议分发。

今天就想试试，应该从哪里开始？

下载 Summer Engine，打开一个 3D 模板，让智能体搭一个合作大厅。技能库会处理脚手架部分。之后就像迭代其他功能一样去打磨设计。