抓大鹅PRD-王子民
Some checks failed
CI / verify (push) Has been cancelled

This commit is contained in:
2026-04-30 17:15:18 +08:00
parent a560e4e6c1
commit b5f02fff61
2 changed files with 719 additions and 1 deletions

View File

@@ -0,0 +1,718 @@
# AI 原生抓大鹅 Match3D 玩法创作工具与玩法系统 PRD
更新时间:`2026-04-30`
## 0. 文档目的
这份 PRD 用于在当前平台内新增一条“抓大鹅”玩法模板链路,并把首版 demo 的产品边界、创作链路、运行规则和工程落点冻结到可以继续拆技术方案的程度。
本玩法对外展示名称为“抓大鹅”,子标题为“经典消除玩法”;开发代号为 `Match3D`。本文统一使用 `Match3D` 表示工程玩法域。
本次不是区分“抓大鹅”和 `Match 3D` 两套模板,也不是只做一个前端临时小游戏。它们的基础交互逻辑一致,后续差异只作为节奏和规则优化项继续迭代。
首版目标先抛出单局 demo边体验边打磨最终目标仍要与拼图玩法一样接入作品广场、他人作品游玩和后续关卡推荐。
---
## 1. 一句话定义
让陶泥主通过 Agent 对话确认题材、需要消除次数和难度,系统编译出一个可试玩、可发布的单局抓大鹅玩法作品;玩家在 `10` 分钟倒计时内点击圆形空间中可见物品,把物品放入下方 `7` 格备选栏,每凑齐 `3` 个同物品 id 自动消除,最终清空圆形空间内全部物品即胜利。
---
## 2. 产品定位
## 2.1 模板名称
1. 对外模板名称:`抓大鹅`
2. 对外子标题:`经典消除玩法`
3. 开发代号:`Match3D`
4. 内部玩法域命名应独立于 RPG、拼图和大鱼吃小鱼不挂在旧 `customWorld``rpgWorld``puzzle``bigFish` 语义下。
## 2.2 首版目标
首版只做单局 demo 主链:
```text
平台创作入口
-> 选择“抓大鹅”
-> Agent 对话确认题材、需要消除次数、难度
-> 生成待发布结果页
-> 编辑作品基础信息
-> 发布前试玩
-> 发布作品
-> 玩家进入单局运行态
-> 胜利 / 失败结算
```
## 2.3 最终目标
后续完整链路需要补齐:
1. 发布后的作品进入首页、分类页和作品广场。
2. 玩家可游玩他人发布的抓大鹅作品。
3. 支持后续关卡推荐。
4. 记录成绩,并预留排行榜机制。
5. 支持已发布作品二次编辑。
---
## 3. 与现有平台链路的关系
## 3.1 复用什么
1. 复用平台创作中心入口。
2. 复用 Agent-first 创作体验。
3. 复用“创作会话 -> 结果页 -> 发布 -> 运行态”的平台主链。
4. 复用作品基础信息、标签、封面、发布接口和作品管理体验。
5. 复用现有 Rust / SpacetimeDB 后端基线。
## 3.2 不复用什么
1. 不复用 RPG 的世界、角色、章节、剧情推进结构。
2. 不复用拼图的网格切图、交换、合并块和下一关推荐算法。
3. 不复用大鱼吃小鱼的实时吞噬、实体等级和摇杆移动规则。
4. 不把 Match3D 运行规则写成前端本地真相源。
5. 不使用 `server-node` 或 PostgreSQL 作为新增玩法后端。
## 3.3 独立玩法域要求
Match3D 必须形成独立玩法域,后续技术方案至少需要覆盖:
1. `module-match3d` 纯领域 crate。
2. `spacetime-module` 内的 Match3D 表与 procedure。
3. `shared-contracts` 内的 Match3D DTO。
4. `spacetime-client` 内的 Match3D 调用封装。
5. `api-server` 内的 Match3D facade 路由。
6. 前端 Match3D 创作、结果页、试玩和运行态组件。
---
## 4. 本次目标
首版 demo 必须满足:
1. 平台新增“抓大鹅”玩法创作入口。
2. 创建流程采用 Agent 对话收集关键配置。
3. Agent 必须在进入结果页前确认:
- 题材主题
- 需要消除次数
- 难度 `1~10`
4. 支持系统自动补全配置,用户确认后开始创造。
5. 题材阶段允许上传参考图片。
6. 结果页支持编辑游戏名称、标签、封面图等基础发布信息。
7. 发布前支持试玩,并允许随时停止和修改配置。
8. 发布不要求试玩通关。
9. 单局运行态使用 `10` 分钟倒计时。
10. 下方备选栏固定为 `7` 个格子。
11. 玩家点击可见物品后,物品飞入备选栏。
12. 备选栏中每凑齐 `3` 个相同物品 id 自动消除。
13. 清空圆形空间中全部物品即胜利。
14. 倒计时结束或备选栏满即失败。
15. 胜利 / 失败后展示结算界面。
16. 点击判定、入槽、消除、失败、胜利必须由后端裁决。
---
## 5. 明确不做
首版 demo 明确不做:
1. 不做抓大鹅和 `Match 3D` 的模板分裂。
2. 不做多关卡关卡链。
3. 不做排行榜正式展示。
4. 不做道具,但需要预留功能口。
5. 不做洗牌、重置、旋转、放大等局内操作。
6. 不做真实 3D 模型。
7. 不做真实 3D 物理遮挡。
8. 不做真实物理碰撞结算。
9. 不做必须试玩通关才能发布的门槛。
10. 不把玩法规则说明长文默认写入 UI 面板。
11. 不在前端即时完成规则裁决。
12. 不使用 `server-node` 或 PostgreSQL 新增实现。
---
## 6. 创作端设计
## 6.1 创作方式
Match3D 首版参考拼图早期的 Agent 对话收集锚点,而不是拼图后期的纯表单入口。
Agent 的职责是帮助用户确认可以直接编译 demo 的最小配置:
1. 题材主题。
2. 需要消除次数。
3. 游戏难度。
## 6.2 必填配置
### 题材主题
题材决定后续生成或选择物品素材的方向。用户可以自定义主题,例如水果、玩具、食物、符号等。
首版 demo 不要求真实生成题材物品素材,只需保留题材字段,并使用 `10` 种颜色形状组合且差异足够明显的素材完成玩法验证。
### 需要消除次数
用户输入任意正整数。
该字段不是胜利条件,而是本局总物品规模配置:
```text
本局最终物品数 = 需要消除次数 * 3
```
例如用户填写需要消除 `4` 次,则场景中最终生成 `12` 件物品。最终目标仍然是清空空间中全部物品。
### 难度
用户输入 `1~10` 的数字,代表从低到高的难度感受。
首版 demo 中,用户只需凭感觉选择难度;具体难度规则由系统内部解释。后续优化阶段再细化难度曲线、生成算法和遮挡策略。
## 6.3 自动配置
如果用户不想逐项填写,系统可以自动补全题材、需要消除次数和难度。
自动补全后的配置必须展示给用户确认,用户确认后才能开始创造。
## 6.4 参考图片
题材阶段允许用户上传参考图片。
首版只支持图片参考,不支持视频参考。参考图片用于影响题材表现,不作为运行时规则裁决依据。
---
## 7. 结果页设计
## 7.1 结果页定位
结果页是待发布作品的最小工作台,不是只读总结页。
首版结果页尽量复用其他玩法模板的结果页结构,重点保证基础信息编辑、试玩和发布链路跑通。
## 7.2 必备字段
结果页至少包含:
1. 游戏名称。
2. 标签。
3. 封面图。
4. 题材主题。
5. 需要消除次数。
6. 难度。
7. 试玩入口。
8. 发布入口。
## 7.3 素材生成边界
首版结果页暂时不生成额外素材。
后续如果需要生成题材物品、伪 3D 物品、场景背景或封面图,需要先补充本文档或新增技术方案,再进入编码。
## 7.4 发布前试玩
发布前需要支持试玩当前关卡。
试玩目的不是强制验证通关,而是帮助用户确认:
1. 题材表现是否符合预期。
2. 物品数量是否符合预期。
3. 难度体感是否符合预期。
试玩过程中必须支持随时停止并返回修改配置。
## 7.5 发布门槛
发布时必须完成基础信息填写。
首版不要求用户试玩通关后才能发布。
---
## 8. 运行时玩法系统
## 8.1 单局时长
一局暂定 `10` 分钟倒计时。
倒计时结束时,如果玩家未清空圆形空间中的全部物品,则关卡失败。
该设计后续可根据体验调整,但调整前需要先更新文档。
## 8.2 场景空间
运行时主交互空间是一个有边界的圆形空间。
1. 圆形空间使用俯视角。
2. 背景环境资源后续可以尝试伪 3D 视角效果。
3. 圆形空间边界是中间交互图案的边界。
4. 物品不能超出圆形边界。
## 8.3 物品生成规模
首版按用户填写的需要消除次数计算总物品数:
```text
totalItemCount = clearCount * 3
```
每种物品数量必须是 `3` 的倍数,避免生成无法通关的局。
## 8.4 阶段陆续生成
每局物品允许阶段陆续生成。
玩家启动游戏时,圆形空间里需要给玩家“已经装满”的视觉感受。
根据参考游戏推算,首次初始刷新时表层约 `30~40` 件物品。首版需注意性能消耗,具体刷新规则在 demo 体验后继续优化。
## 8.5 物品资产
首版 demo 使用 2D 图案素材。
1. demo 只需提供 `10` 种颜色形状组合。
2. `10` 种素材需要差异足够明显。
3. 后续可以尝试替换为伪 3D 或 3D 模型。
4. 用户题材主题后续会映射为符合常识预期的物品集合。
示例:水果题材可以对应红色苹果、黄色香蕉、紫色葡萄等。
## 8.6 物品 id 与图案
同样物品按物品 id 判断。
1. 每个物品有唯一类型 id。
2. 当前 demo 中,一个物品 id 对应一个图案。
3. 需要预留一个物品 id 对应多个图案的设计空间。
## 8.7 遮挡与点击
圆形空间里的物品可以重叠、遮挡、堆叠。
首版使用 2D 逻辑实现遮挡和点击判定:
1. 被完全遮挡的物品不允许点击。
2. 如果物品有局部露出,且露出区域可被点击选中,则允许点击。
3. 具体露出区域判定使用 2D 逻辑的最优方案,不做真实 3D 遮挡。
## 8.8 点击入槽
玩家点击通过后,后端裁决该物品可选中。
前端播放飞行动画,把物品放入下方备选栏。
飞行动画过程中,物品不再与其他物品产生碰撞。
## 8.9 备选栏
下方备选栏固定为 `7` 个格子。
1. 每次成功点击后,物品进入备选栏。
2. 备选栏中每出现 `3` 个相同物品 id自动消除并腾出格子。
3. 如果备选栏满且无法消除,则判定关卡失败。
## 8.10 胜利
圆形空间内全部物品被消除后,播放胜利动画并展示胜利界面。
胜利结算页至少展示:
1. 结果状态。
2. 使用时间。
3. 再来一局按钮。
4. 返回作品详情的通用按钮。
## 8.11 失败
失败条件:
1. 倒计时结束。
2. 备选栏满。
失败结算页至少展示:
1. 失败原因。
2. 关卡完成进度。
3. 重新开始按钮。
4. 返回上层按钮。
---
## 9. 难度设计
## 9.1 首版难度口径
首版 demo 只有一个关卡,难度递增体感来自单局动态加载过程。
用户输入的难度 `1~10` 暂作为后端布局和生成算法参数,不在 UI 中展示具体规则说明。
## 9.2 已确认的难度方向
后续难度优化需要围绕以下方向细化:
1. 可选物品逐渐变小,更容易误触或更难分辨。
2. 空间表层直观看到可凑成 `3` 个消除的类型变少。
3. 更多可消除组合被堆叠在下方,玩家需要利用备选栏作出决策。
4. 倒计时带来持续压力。
## 9.3 待体验后冻结
以下规则需要 demo 体验后再冻结:
1. 不同难度对应的物品数量、尺寸、遮挡层数和可见组合比例。
2. 阶段加载节奏。
3. 首屏表层物品数量的性能上限。
4. 局内动态难度变化公式。
---
## 10. 前后端职责边界
## 10.1 后端职责
后端必须作为规则真相源,负责:
1. 创建玩法草稿。
2. 编译运行时初始局面。
3. 生成物品序列与布局。
4. 判断物品是否可点击。
5. 处理点击入槽。
6. 判断 `3` 个相同物品 id 消除。
7. 判断备选栏满失败。
8. 判断倒计时结束失败。
9. 判断清空空间胜利。
10. 记录成绩所需的基础数据。
## 10.2 前端职责
前端只负责:
1. 展示 Agent 创作界面。
2. 展示结果页和基础编辑表单。
3. 上传参考图片。
4. 展示运行态场景、物品、倒计时和备选栏。
5. 发送玩家点击意图。
6. 播放点击、飞入、消除、胜利和失败动画。
7. 展示结算界面。
前端不得自行完成规则裁决。
## 10.3 防作弊要求
首版即按正式版本搭建规则裁决链路。
前端不可信任本地点击、消除、胜利或成绩结果;所有关键状态必须由后端裁决后下发。
---
## 11. 状态结构建议
## 11.1 创作配置
```ts
interface Match3DCreatorConfig {
themeText: string;
referenceImageSrc?: string;
clearCount: number;
difficulty: number;
}
```
字段说明:
1. `themeText`:题材主题。
2. `referenceImageSrc`:可选参考图片。
3. `clearCount`:需要消除次数,必须为正整数。
4. `difficulty`:难度,范围为 `1~10`
## 11.2 作品结构
```ts
interface Match3DWorkProfile {
profileId: string;
ownerUserId: string;
sourceSessionId: string;
gameName: string;
themeText: string;
summaryText: string;
tags: string[];
coverImageSrc: string;
clearCount: number;
difficulty: number;
publicationStatus: 'Draft' | 'Published';
playCount: number;
updatedAt: number;
publishedAt?: number;
}
```
## 11.3 运行态快照
```ts
interface Match3DRunSnapshot {
runId: string;
profileId: string;
status: 'Running' | 'Won' | 'Failed' | 'Stopped';
startedAtMs: number;
durationLimitMs: number;
remainingMs: number;
clearCount: number;
totalItemCount: number;
clearedItemCount: number;
traySlots: Match3DTraySlot[];
items: Match3DItemSnapshot[];
failureReason?: 'TimeUp' | 'TrayFull';
}
```
## 11.4 物品快照
```ts
interface Match3DItemSnapshot {
itemInstanceId: string;
itemTypeId: string;
visualKey: string;
x: number;
y: number;
radius: number;
layer: number;
state: 'InBoard' | 'Flying' | 'InTray' | 'Cleared';
clickable: boolean;
}
```
## 11.5 备选栏快照
```ts
interface Match3DTraySlot {
slotIndex: number;
itemInstanceId?: string;
itemTypeId?: string;
visualKey?: string;
}
```
---
## 12. 工程落点建议
## 12.1 纯领域 crate
新增:
```text
server-rs/crates/module-match3d
```
职责:
1. 创作配置校验。
2. 物品生成规划。
3. 2D 遮挡与可点击判定。
4. 点击入槽规则。
5. 三个同物品 id 消除规则。
6. 胜负判定。
7. 成绩基础数据计算。
## 12.2 SpacetimeDB 表
后续技术方案需冻结至少以下表:
1. `match3d_agent_session`
2. `match3d_agent_message`
3. `match3d_work_profile`
4. `match3d_runtime_run`
如表结构变化,必须同步对齐 `migration.rs`
## 12.3 Procedure
后续技术方案需冻结至少以下 procedure
1. `create_match3d_agent_session`
2. `submit_match3d_agent_message`
3. `compile_match3d_draft`
4. `update_match3d_work`
5. `publish_match3d_work`
6. `start_match3d_run`
7. `stop_match3d_run`
8. `click_match3d_item`
9. `restart_match3d_run`
10. `get_match3d_run`
## 12.4 shared contracts
建议新增:
```text
server-rs/crates/shared-contracts/src/match3d_agent.rs
server-rs/crates/shared-contracts/src/match3d_works.rs
server-rs/crates/shared-contracts/src/match3d_runtime.rs
packages/shared/src/contracts/match3dAgent.ts
packages/shared/src/contracts/match3dWorks.ts
packages/shared/src/contracts/match3dRuntime.ts
```
## 12.5 api-server facade
建议新增 Match3D 独立路由,不挂在其他玩法路由下:
```text
POST /api/creation/match3d/sessions
POST /api/creation/match3d/sessions/:sessionId/messages
POST /api/creation/match3d/sessions/:sessionId/compile
PATCH /api/creation/match3d/works/:profileId
POST /api/creation/match3d/works/:profileId/publish
POST /api/runtime/match3d/works/:profileId/runs
POST /api/runtime/match3d/runs/:runId/stop
POST /api/runtime/match3d/runs/:runId/click
POST /api/runtime/match3d/runs/:runId/restart
GET /api/runtime/match3d/runs/:runId
```
---
## 13. 发布与分发
## 13.1 首版发布
首版发布需要完成基础信息:
1. 游戏名称。
2. 标签。
3. 封面图。
4. 题材主题。
5. 需要消除次数。
6. 难度。
## 13.2 广场接入
最终版本需要接入:
1. 首页。
2. 分类页。
3. 作品广场。
4. 他人作品游玩。
5. 后续关卡推荐。
首版 demo 可先不完整实现广场推荐,但作品结构必须预留正式发布字段。
## 13.3 成绩记录
首版记录并预留:
1. 用户 id。
2. 是否通关。
3. 通关时间。
4. 失败原因。
排行榜展示首版暂不做,后续优化可能新增。
## 13.4 二次编辑
已发布作品需要支持二次编辑。
编辑后仍应保留同一个作品归属,不应因为再次发布创建重复作品。
---
## 14. UI 要求
## 14.1 创作入口
创作入口只展示必要信息,不默认堆叠玩法规则说明。
## 14.2 Agent 工作区
Agent 每轮优先追问最影响 demo 生成的一个问题。
已确认的信息应清晰展示给用户确认:
1. 题材主题。
2. 需要消除次数。
3. 难度。
## 14.3 结果页
结果页保持清爽,复用平台已有作品结果页风格。
点击按钮弹出独立面板时,不实现成在当前面板下面展开内容。
## 14.4 运行态
运行态需要移动端优先:
1. 圆形空间占据主要视觉区域。
2. 下方 `7` 格备选栏固定清晰。
3. 倒计时可见但不遮挡物品。
4. 点击、飞入、消除反馈清楚。
5. 胜利 / 失败结算面板独立展示。
---
## 15. 验收标准
首版 PRD 对应 demo 验收标准:
1. 用户可从平台创作入口进入“抓大鹅”模板。
2. Agent 能确认题材、需要消除次数和难度。
3. 用户可上传参考图片。
4. 系统可生成待发布结果页。
5. 用户可编辑游戏名称、标签、封面图等基础信息。
6. 用户可发布前试玩,且试玩失败不阻断发布。
7. 运行态能展示圆形空间、倒计时、物品和 `7` 格备选栏。
8. 物品可重叠、遮挡、堆叠。
9. 被完全遮挡物品不可点击,露出可点击区域的物品可点击。
10. 点击通过后物品飞入备选栏。
11. 备选栏中 `3` 个相同物品 id 自动消除。
12. 清空空间中全部物品后胜利。
13. 倒计时结束或备选栏满后失败。
14. 胜利结算展示使用时间。
15. 失败结算展示完成进度和重新开始按钮。
16. 关键规则由后端裁决,前端不本地判定胜负。
17. 相关中文文档通过编码检查。
---
## 16. 推荐落地顺序
## 阶段 A冻结技术方案
1. 基于本文补 `Match3D` 技术落地方案。
2. 冻结表结构、procedure、DTO、api-server 路由。
3. 对齐 `migration.rs`
## 阶段 B创作与结果页
1. 新增平台创作入口。
2. 接入 Agent 会话。
3. 编译草稿并进入结果页。
4. 复用基础信息编辑和发布链。
## 阶段 C后端运行态
1. 新增 `module-match3d` 规则。
2. 新增 SpacetimeDB 运行态表和 procedure。
3. 实现开始、点击、消除、失败、胜利。
## 阶段 D前端运行态
1. 展示圆形空间和 2D 物品。
2. 展示 `7` 格备选栏。
3. 接入点击接口和后端快照。
4. 补飞入、消除、胜负动画。
## 阶段 E分发与成绩预留
1. 接入首页、分类页和广场投影。
2. 记录成绩基础数据。
3. 预留排行榜和后续关卡推荐。
---
## 17. 一句话结论
Match3D 首版不是临时前端 demo而是以“抓大鹅”模板为外壳、以后端规则裁决为真相源、以独立玩法域为工程边界的单局经典消除玩法链路首轮先跑通题材创作、结果页、试玩、发布和单局清空胜负闭环。