AI 开发网页小游戏，先让一局游戏完整结束
最后更新:
用成熟引擎处理渲染与碰撞，用明确规则控制开始、得分、结束和重开。本文是 Phaser 教学路线，整局游戏尚未实跑。
把第一款游戏写成一张能判输赢的规则卡
教学游戏叫“圆片收集练习”：玩家控制一个方块，在一屏场地内移动，45 秒内收集 6 个圆片即胜利。圆片接触一次只计一分，时间归零时未收集完则结束；点击重开后位置、得分和倒计时全部恢复。玩法数据都是教学设定，不是已发布产品或玩家测试结果。
第一版先证明一局能开始、可操作、会结束、能再次开始。关卡地图、道具商店和账号系统不在同一条验收里。你要交给 AI 的是确定的状态与触发条件，而不是“做一个好玩的小游戏”；好不好玩还需要实际试玩，不能从代码长度或生成速度推断。
先固定 Phaser 教程代际，再使用引擎已有能力
本页沿 Phaser 官方首个游戏教程中的 Phaser 3 路线组织场景和物理配置，官方页面核对日期为 2026-09-12。实施时把实际版本、依赖锁文件和教程入口记录下来；教程代际不等于最新发布版本，不能把不同代际的代码直接拼在一起。本文没有安装依赖或验证某个版本组合。
本例只需要简单形状与重叠检测，可以研究 Arcade Physics；官方说明其面向矩形和圆形等轻量场景，复杂形状或约束需另行选型，参见 Phaser Physics，核对日期 2026-09-12。渲染循环、输入分发和物理更新交给引擎，业务代码只决定得分、目标数量与结束条件，不另写一套碰撞引擎再称为 Phaser 实现。
状态表先约束计分、时间和输入
ready 时等待开始，playing 才响应移动和收集，paused 保留本局进度，won 与 lost 都停止计分。最后一个圆片被收集和计时结束可能出现在同一帧，需预先规定优先级；本教学约定先结算本帧有效收集，再判超时，并由单一结束入口只结算一次。这个规则应写进实现，而不是由回调碰巧先后决定。
切换浏览器标签时，本例选择进入暂停，回来后由用户主动继续。计时使用引擎的时间机制配合暂停状态，不能简单依赖每帧减一。下面是待实现状态契约，尚未有浏览器操作记录；它给 AI 和复核者同一份判定标准。
| 状态 | 可接受动作 | 得分和时间 | 离开条件 |
|---|---|---|---|
| ready | 开始 | 得分 0，剩余 45 秒 | 用户开始进入 playing |
| playing | 移动、收集、暂停 | 圆片一次计分，倒计时推进 | 集齐、超时或暂停 |
| paused | 继续、重开 | 冻结本局状态 | 主动继续或新开一局 |
| won | 重开 | 保存最终得分，停止计时 | 重开恢复初始状态 |
| lost | 重开 | 保存失败结果，停止计时 | 重开恢复初始状态 |
开发任务围绕场景、碰撞和一次性结算拆分
Phaser 的 Scene 可组织加载、菜单与关卡，并管理各自的输入与更新，参见 Phaser Scenes，核对日期 2026-09-12。教学实现可以采用加载场景和单局场景：先确保资源可见，再接入玩家、圆片与碰撞。收集时立即将圆片标记为已处理，避免连续重叠触发多次计分。
下方配置片段仅说明零重力的 Arcade 路线，GameScene 需要另行实现，不是可单独运行的完整程序。后面的任务提示词让 Agent 在已有工程里逐步完成玩法，并保留实际运行证据；不能用一个静态得分页面交差，也不能让模型在每一帧参与判断。
const config = {
type: Phaser.AUTO,
width: 800,
height: 600,
physics: {
default: "arcade",
arcade: { gravity: { x: 0, y: 0 }, debug: false }
},
scene: [GameScene]
};
// 依赖：已加载同代际 Phaser，并已实现 GameScene。
new Phaser.Game(config);使用项目固定版本的 Phaser 与 Arcade Physics 实现单屏收集游戏。
玩法：45 秒收集 6 个圆片，接触一次只加一分。
状态：ready、playing、paused、won、lost；结束只能结算一次。
同帧先结算有效收集再判断超时；标签隐藏暂停，回来等待继续。
输入：键盘方向键与触摸方向控制，不要求玩家点击精细小目标。
引擎负责渲染、时间和碰撞，不编写替代引擎。
重开要清理旧定时器和监听器，恢复初始位置、目标与分数。
交付本地入口、资产清单、实际试玩记录与尚未验证的设备。资产路径和触摸输入也是玩法的一部分
先用拥有使用权的清晰方块与圆片素材，背景保证玩家、目标和文字容易区分。维护一份资源清单，记录本地路径、尺寸、用途和授权依据；不要让 AI 随意引用一个无法确认许可或随时失效的图片地址。加载失败时保留可观察错误并停止开局，而不是空白画布旁边仍显示“游戏开始”。
触摸版本可以用屏幕方向控制，把输入转换成与键盘相同的移动意图。按下、松开、手指移出和系统中断都要清理输入状态，避免角色一直向一个方向走。画布缩放后，输入位置应采用引擎提供的坐标转换；手机上还需检查横竖屏、浏览器工具栏和页面滚动是否干扰操作。代码能解析并不能证明这些体验正常。
验收必须真的玩，截图与像素检查各有用途
先在本地运行环境打开游戏，观察画布有实际像素变化、资源可见、玩家能移动。连续收集同一圆片附近的重叠帧，确认只加一分；再完成胜利局、等待失败局、暂停继续并连续重开三次。每次保存状态、得分和剩余目标数，避免只看结束弹窗里的文字。下表是待执行清单，本页没有宣称这些测试通过。
截图可检查遮挡和资源位置，两个不同时刻的画布像素可帮助确认画面不是静止占位，但像素变化不能证明碰撞、计分或重开正确。还要分别执行桌面键盘与移动端触摸流程，记录浏览器、设备、分辨率和页面错误。性能结论要来自目标设备测试，不能拿开发电脑的流畅感保证所有手机体验。
| 试玩步骤 | 观察值 | 预期结果 |
|---|---|---|
| 开局并移动 | 玩家坐标、画布像素 | 坐标变化，场内移动，画面非空 |
| 持续接触一个圆片 | score、activeTargets | 只加一分，目标减少一个 |
| 收集第六个圆片 | state、结束次数 | won，一次结算 |
| 不收集直到归零 | state、remainingTime | lost，后续输入不再计分 |
| 切走标签再回来 | state、玩家输入状态 | 暂停，等待继续，没有黏住的方向 |
| 连续重开三次 | 分数、圆片数、计时速度 | 全部重置，无重复监听导致的加速 |
从能玩到交付，留下可复现的关卡与版本
交付目录应包含源码、依赖锁文件、资源和许可清单、运行说明、产物版本以及已测设备。关卡参数最好单独保存：圆片数量、初始位置、玩家速度和倒计时不埋在到处都是的常量里。采用固定初始布局验收，等基本规则稳定后再考虑随机生成，随机种子也要可记录，便于重现难以触发的问题。
发布前另行核对托管配置、资源路径和缓存更新方式。线上资源 404、旧脚本搭配新贴图都会让本地通过的游戏出错；需要在实际入口复核整局。本文没有线上入口、商店上架、广告接入或收费发布结果，平台审核要求由实施者在正式发布时通过官方文档复查。
收益讨论应建立在真实试玩与使用数据上
接单可以约定一套玩法、关卡数、素材交付和维护周期，自有产品则要通过真实试玩了解操作门槛、失败原因和重复游玩意愿。不要把“能生成小游戏”自动推成广告收入或付费转化；画面是否清楚、规则是否公平、玩家愿不愿意再玩，都需要用户反馈。教学流程不提供收入预测。
成本包括编程辅助、素材、测试设备时间、托管和后续兼容修复。模型价格以价格页为准，开发工具按订阅与 API 比较记账。这个教学玩法运行时无需模型参与；若将来加动态剧情或文本生成，应单独设计延迟、失败降级和内容复核，不让基本操作依赖远程响应。
常见问题
本文能直接下载一款已经实跑的游戏吗？
不能。本文提供 Phaser 教学路线、玩法契约和待执行验收表，配置片段也依赖另行实现的场景，没有整局游戏实跑记录。
为什么不让 AI 从零写碰撞和渲染引擎？
这个任务的重点是玩法交付。用成熟引擎处理基础机制，才能把验证精力放到规则、输入、状态转换和目标设备体验。
Phaser 配置片段代表已经锁定最新版本吗？
不代表。本文引用官方 Phaser 3 教程路线，实施时需要固定实际依赖版本并匹配文档，不混用不同代际的接口。
截图有画面就能算可玩吗？
不能。还需验证输入、碰撞、计分、胜负、暂停与重开。画布像素检查能发现空白或静止占位，但不能代替玩法测试。
小游戏每一局都要消耗模型额度吗？
这个确定性收集玩法不需要。模型辅助发生在开发阶段；只有另行加入生成式功能，运行时才可能产生模型请求。