大多数「用 AI 做游戏」的教程到「能跑起来了」就戛然而止。网页游戏的门槛更高：陌生人点开链接，你只有几秒钟说服他留下来，否则进度条就赢了。这个约束——网页游戏必须先下载才能玩——决定了下面每一个决策，也是那些泛泛而谈的教程跳过不讲的地方。
这是一份实操指南。读完之后，你会明白什么是网页原生游戏，从哪个模板开始，用什么提示词来构建它，以及一个 Web 版本要能通过一个链接直接游玩需要什么。Summer Engine 可以为 GDScript 项目导出 Web 版本，所以导出这一步会讲怎么做出 Web 版本并发布到 Summer Games。
{/* IMAGE: A browser tab with a short arcade game running inside it, and a "copy link" share button. 1200x630, screenshot */}
什么才是真正的网页原生游戏
网页游戏不是「恰好能在浏览器里跑」的游戏。真正好的网页游戏是由三个约束塑造出来的，忽视这些约束，正是大多数浏览器游戏被点开、加载、然后关掉的原因。
加载要快。 这是重中之重。网页游戏必须先下载才能玩，而顺着链接进来的玩家几乎没有耐心等进度条。一款精简的 2D 游戏几秒内就能加载完。一个臃肿的项目会让玩家在标题画面出现之前就离开。
操作要用浏览器自带的东西。 鼠标、键盘，手机上是触摸屏。没有手柄，没有安装，没有额外设置。围绕这些设计控制方式，否则你会失去所有从链接进来的休闲玩家。
单局要短且完整。 大多数网页游戏的流量来自分享链接和几分钟的碎片时间。一款五秒能看懂、两分钟能打完一局的游戏，天生适合这个场景。四十小时的史诗 RPG 不适合，哪怕它技术上能在标签页里运行。
设计一款整体体验能在这三个约束下成立的游戏，网页就会帮你完成发行工作。与之对抗，再多的打磨也救不了你的链接。
先定规模：做一款能在标签页里赢的小游戏
网页奖励小巧。短平快的街机游戏、单屏解谜、追高分、每日一题式的文字游戏、紧张的生存射击——这些天生适合这个介质：加载快、上手即懂、一局就能有满足感。
本指南将构建一款追高分街机游戏：你控制一个角色，敌人不断生成并逼近，你尽可能存活并得分，「死亡—显示得分—再来一局」的循环清晰干脆。这是最具网页气质的游戏结构，能套进任何玩法外壳（躲避、射击、收集），并且能在一个小小的构建过程中验证所有网页专属的经验。
你的第一个目标是能让人真正玩一局的最小可玩版本：
用鼠标或键盘控制的角色
一种随时间生成的威胁
存活期间持续累加的得分
清晰的游戏结束界面和即时重开
这就是一款完整的网页游戏。如果一局能让人觉得有趣，再去扩展内容。如果这都做不到，加更多敌人类型也救不了它。
第一步：选对模板
打开 Summer Engine，新建一个项目，选择 2D 模板。对于俯视角街机游戏，2D Top-Down 模板是最佳起点：它提供了一个角色、移动逻辑和摄像机，你的第一条提示词是在一个已经能动的游戏基础上迭代，而不是面对一个空场景。
在 Summer Engine 模板 中浏览所有选项。坚持用 2D 来做第一款网页游戏，理由不是对画面的偏见，而是加载时间。3D 模板会输出更多数据，更多数据意味着更慢的下载，更慢的下载正是流失网页玩家的直接原因。先从 2D 开始，保持小巧，等你亲身体会到体积对加载的影响之后，再考虑做 3D。
{/* IMAGE: Summer Engine template browser with the 2D Top-Down template highlighted. 1200x675, screenshot */}
第二步：用一段话描述整个游戏
先不要逐个机制地写提示词。先用一段话把这款小游戏的整体形态告诉 AI，让它构建出一个连贯的初始版本，然后再逐步打磨。
构建一款俯视角街机生存游戏。玩家控制单个角色，用 WASD 或方向键流畅移动，始终保持在屏幕范围内。敌人从屏幕边缘每隔几秒生成，向玩家移动。敌人碰到玩家即游戏结束。存活时间越长得分越高，且越到后期得分速率越快。游戏结束时显示最终得分，以及「按空格键重新开始」的提示，点击后立即重开。保持简洁易读。
运行它。你会得到一个粗糙但真实的游戏：能移动的角色、追着你的威胁、得分，以及重开按钮。这个可运行的雏形就是后续所有步骤的改进基础。抵制住在核心单局手感变好之前就添加第二种敌人或道具的冲动。
第三步：让控制手感适配浏览器
这是网页专属的一步。从链接进来的休闲玩家，在移动角色的前三秒就会对你的游戏做出判断。如果移动感觉迟钝或有延迟，他们就会离开。
让角色移动手感更灵活：迅速加速到满速，迅速停止，不要有飘移感。确保斜向移动速度不快于直线移动。始终让角色完整地保持在可见屏幕范围内。
然后主动决定你的输入方案。鼠标加键盘是最安全的默认选项，大多数网页游戏也保持这个方案。但如果你希望游戏在手机上也能玩（分享链接带来的流量中，手机占了很大比例），添加触控：
添加触控操作，使游戏可以在手机上游玩：让玩家拖动手指来移动角色。同时保留键盘控制，使游戏在桌面端和移动端都能玩。
两种方式都要测试。在真实手机上测试触控，而不是用桌面浏览器的手机模拟器，因为真实触控的感觉截然不同。让网页游戏死得最快的，就是上线时只有作者自己知道怎么操作。
第四步：打磨让一局游戏好玩的循环
追高分游戏的生命在于核心单局。把时间花在这里，而不是堆砌内容。
让敌人随着玩家存活时间延长而更快生成、移动更快，使游戏难度逐渐提升。玩家死亡时添加短暂的闪光效果和轻微屏幕抖动，使游戏结束有冲击感。让得分显示大而清晰，放在角落。游戏结束时显示最终得分和本局最高分，让玩家想再来一局。
「再来一局」的冲动是网页街机游戏的全部引擎。连续测试十局。难度曲线让你向前倾了吗？死亡感觉公平还是莫名其妙？看到最高分会让你按下重开吗？如果以一个纯色方块作为角色也能给出肯定答案，你就已经有了一款真正的网页游戏。如果不能，先修好这个单局，再去添加任何东西。
{/* IMAGE: The arcade game mid-round with a large score in the corner and several enemies closing in. 1200x675, screenshot */}
第五步：打开编辑器，手动调整数值
这是 Summer Engine 作为真正的引擎而非黑盒所带来的价值。一款精密的街机游戏是一堆小数字的集合：角色速度、刷怪速率、难度爬坡幅度、每秒得分。每改一个就重新写提示词等 AI 处理，太慢了。
因为输出的是标准的 Godot 4 兼容项目，你可以直接打开脚本改某一个数值。把刷怪间隔缩短零点一秒，运行，感受一下。把角色速度提高一点，运行，感受一下。一次改一个值，每次改完立即跑一下，这比用文字描述修改内容然后等待 AI 处理要快得多。AI 负责搭建系统，你来把它们调到你想要的手感。
第六步：导出前先管住体积
这一步是让人愿意玩的网页游戏和在进度条前被放弃的网页游戏之间的分水岭。导出体积就是加载时间，加载时间就是留存率。
两个比任何其他因素都更容易让体积失控的元凶：
未压缩的音频。 几个原始 WAV 文件的体积可能超过整个游戏的其他部分。音乐和较长的音效使用压缩格式。
超大纹理。 一张 4096 像素的图片只作为屏幕上一个小图标使用，是纯粹浪费的兆字节。将图片分辨率控制在游戏实际显示所需的大小。
然后删除所有闲置素材，那些在实验过程中留在项目里的东西。一款精简的 2D 游戏可以导出到几兆字节，几秒内加载完；一个不加管控的项目可能膨胀到几十兆字节，在第一帧出现之前就流失了玩家。在导出前处理好这些，而不是等到发现没人玩才亡羊补牢。
第七步：导出到网页并分享链接
现在把它变成真正的网页游戏，而不只是精神上的网页游戏。从引擎 0.7 起，Summer 桌面编辑器自带 Summer 自己的 Web 导出模板（WebGPU，Forward+ 或 Mobile 渲染器），所以 GDScript 项目可以直接导出 Web 版本。Web 版本是一个根目录含 index.html 的标准静态 .zip。这就是你的完整游戏，可以在浏览器中游玩。使用 C# 的项目无法导出到 Web，这是 Godot 4 的限制，所以网页游戏请只用 GDScript。其他支持 Web 导出的工具，比如 GDevelop、Construct 或 GameMaker，也会生成类似的一组普通网页文件。
从 Summer 上线时，把 .zip 发布到 Summer Games（summer.games），玩家就能在浏览器里玩。对一般的 Web 导出来说，itch.io 是常见的选择：把导出文件打包成 zip 上传，标记为可在浏览器中游玩，你就能得到一个链接和可嵌入的播放器，完全免费。GitHub Pages 或任何静态托管服务同样可行，因为 Web 导出的就是普通网页文件。在 itch.io 上，浏览器游戏的上传总大小不能超过 500 MB，单个文件不超过 200 MB，文件数不超过 1,000 个。关于 Godot 4 Web 导出的详细操作（设置、常见问题以及每个文件的作用），Godot 网页导出指南 针对标准 Godot 编辑器有深入介绍。标准 Godot 在 Web 上使用 Compatibility 渲染器，而 Summer 自己的 Web 模板使用 WebGPU，搭配 Forward+ 或 Mobile。Godot 4.3 及以上版本可以导出单线程 Web 版本，不需要特殊的服务器响应头；只有开启线程支持时才需要 COOP 和 COEP 响应头。
Agent 可以用 MCP 工具 summer_export_game（目标 web）和 summer_publish_build 完成同样的步骤。如果是浏览器 Game Jam，请确认 Web 版本能在 Jam 要求的浏览器里运行。
有了链接之后，在一台不是你自己的设备上、在正常网络连接下测试它。你的本地加载是瞬时的，会掩盖真实的等待时间。链接才是产品。把它分享出去，观察玩家能坚持多久，然后根据你学到的东西调整难度和加载时间。
AI 擅长什么，不擅长什么
AI 擅长的是搭架子。移动控制器、敌人的生成和追击逻辑、计分系统、难度爬坡、游戏结束与重开循环、基本的触控控制——这些都是成熟的系统，用自然语言描述比手写要快得多。
留给你自己的是：手感、调参，以及网页纪律。移动的响应感、让一局紧张而不无聊的刷怪速率、能赢得「再来一局」的难度曲线，以及让加载时间保持低位的体积控制。AI 会愉快地构建出一个功能完整但加载需要十五秒、操作感觉像在踩泥的游戏，因为那些是调参和打包问题，不是代码问题。第三步、第四步和第六步，才是你真正花时间的地方。
关于这套工作流的通用版本，make-a-browser-game-with-ai 这篇配套指南适用于任何游戏类型。对于天生适合标签页的游戏形态，making a game like Vampire Survivors 和 making a game like Wordle 的拆解都针对了在网页上特别出色的类型。
开始构建
网页游戏不是桌面游戏的缩小版。它是围绕一个事实设计的游戏：它必须在浏览器里加载，然后才能玩，在链接落地的任何设备上。做一款能在标签页里赢的小游戏，把单局调到让人想再玩一次，保持文件精简以便快速加载，然后导出到网页并分享链接。
Summer Engine 免费下载和使用，无水印，也无需向 Summer 支付版税。它可以为 GDScript 项目导出 Web 版本，发布到 Summer Games 后，玩家就能在浏览器里玩。从一个 2D 模板 开始，按照本指南构建单局街机游戏，在添加任何额外功能之前先把核心单局手感调好。如果你想用 AI 生成的美术替代占位方块，AI 2D game asset generator 这篇覆盖了这方面的内容。
每一款曾经广泛传播的网页游戏都做了同一件事：加载快，上手即玩，让一个陌生人想把链接发给另一个人。为此而设计，浏览器会帮你完成其余的事。