用 Codex 做出第一款天工引擎游戏

这不是“先学编辑器”的教程。你把游戏目标交给 AI 智能体，再用天工引擎与 ForgeAX Game 把它变成可玩、可检查的结果。

请先完成 ForgeAX Game 安装。本篇假设项目已经初始化，AI 客户端也能读取天工引擎状态。

目标：一个完整的小循环

先把范围压到智能体能一次实现并完整验证。本篇以霓虹收集游戏为例：

WASD 移动
8 个收集物
进度与胜利状态
浏览器 Play 构建

1 · 同时描述行为与验收

一条好用的游戏需求包含四件事：玩家做什么、世界发生什么变化、怎样成功，以及最终必须验证什么。

游戏任务书 · 范围小 · 循环完整

在活动天工引擎游戏中制作一个小型 3D 霓虹收集游戏。
- 玩家使用 WASD 移动，相机保持清晰易读。
- 在紧凑场地中放置 8 个发光能量碎片。
- 收集碎片后，屏幕计数器更新。
- 集齐全部碎片后，显示明确的胜利状态。
先读取已安装的 Engine Skills 和准确 SDK 声明，不要猜 API。
运行游戏，打开 Play 地址，测试移动与收集，观察到失败就继续修复。

2 · 智能体在背后执行什么

天工引擎会把开放式需求压进一条有边界、能产生证据的闭环：

检查 — 读取活动游戏、Runtime 与 Engine SDK 身份。
学习 — 打开相关引擎 Skills、类型声明与可运行模板。
实现 — 只在活动游戏中修改最小且完整的一组文件。
运行 — 通过经过验证的 Runtime 构建并获得 Play 地址。
验证 — 操作真实页面、检查错误并修复到行为得到证明。

3 · 这个小游戏会用到哪些引擎能力

玩家看到的结果	引擎能力	为什么适合 AI 操作
玩家、碎片与场地作为游戏对象存在	ECS World、组件与调度	状态与更新顺序显式、可查询。
浏览器里出现有光照的 3D 场景	渲染投影、材质、灯光与相机	可以检查渲染输入与 pass 结构，而不是靠猜。
移动与碰撞稳定可控	输入与物理领域	每个领域拥有自己的数据与执行契约。
进度与胜利反馈清晰可见	State + HTML/CSS 或 Engine UI	状态转换显式，表现层也能单独验证。
项目可以稳定重复构建	Pack、资产 GUID 与版本化 Runtime	源码、发布资产与运行身份可追溯。

4 · 按玩家感受迭代，而不是按文件下命令

核心循环跑通后，每次只提出一个体验层目标。智能体会自己判断需要改哪些系统与资产。

第二轮 · 手感

让移动更灵敏，拾取时增加短促的发光脉冲和声音，
并让胜利反馈在桌面与窄屏浏览器里都清晰可读。
修改后重新运行并验证完整循环。

第三轮 · 视觉方向

使用引擎材质、灯光和后处理，把场地统一成青蓝与琥珀色科幻风格。
保持玩法信息清晰，并在真实 Play 构建中对比结果后再报告完成。

5 · 什么才叫完成

状态里报告的活动游戏就是你准备修改的游戏。
启动结果显示 Runtime 与 Engine SDK 身份匹配。
Play 地址能打开，没有致命浏览器或运行时错误。
真实操作过移动、全部收集物、进度与胜利状态。

项目目录才是你的真相来源。以后关闭再打开 AI 客户端，也能重新读取状态并继续同一款游戏。