竞技场与镜像 PVP
0. 本篇结论
本功能定义竞技场与镜像 PVP的功能定位、玩家流程、核心规则、UI 状态、配置与系统边界；本次整理状态为 draft；原声明为 producer_review_needed / canonical_candidate，不提升为批准规则。
整理来源与事实层级（WEN-12 draft）
- 固定来源：
project2-docs@ec43be0e13c8624cfafd36c0fd803f3b89733fff的features/arena-pvp.md、feature-map.md、manifest.yaml；原审核状态均为producer_review_needed / canonical_candidate。 - §5 中“需要定义”明确表示缺失设计；镜像/异步形态、排名制、赛季和奖励周期均未获确认，不新增次数、积分或段位方案。
- 已确认基线仅指固定文档路径、原声明及既有规则编号；原件与逐条产品批准记录缺证，不能将其转成“已确认产品规则”。本轮未读取游戏实现、配置或运行版本，当前版本是否上线全部待定。
- 边界：竞技场保留镜像对手、挑战次数、防守快照与排名变化候选；排行榜页面只作普通榜责任入口，竞技场自身分页/接口仍缺证，不建立共享 contract；不把普通榜的 Top999/首通规则套入竞技场。通用战斗引用 战斗关卡与 技能战斗效果（B1-D）。
- 来源登记、两侧证据、影响与用户决定点见 玩法整理台账，对应
B1E-Q07。后文验收为候选检查项，本轮未执行游戏验收。
1. 功能定位
竞技场提供玩家间异步对抗、排名竞争和周期奖励。Excel 中描述为“常规 pvp / 镜像”，因此本候选稿按镜像阵容战斗而非实时 PVP 处理，具体战斗形态仍需制作人确认。
2. 范围
In Scope：竞技场入口、镜像对手、挑战次数、匹配/刷新、战斗结算、排名变化、防守阵容、赛季或周期奖励、排行榜和红点。
Out of Scope：实时联机 PVP、公会战、世界 Boss 伤害排行、普通关卡排行榜、完整战斗技能规则。
3. 玩家入口、解锁与提示
入口候选位于日常玩法、主界面玩法入口或排行榜入口。解锁条件可能依赖主线关卡、玩家等级或功能开放配置。红点用于提示免费挑战次数、奖励可领取或排名变化。
4. 核心玩家流程
- 玩家进入竞技场，查看当前排名、奖励和可挑战对手。
- 玩家选择或刷新镜像对手。
- 系统根据玩家当前阵容和对手镜像阵容进入战斗。
- 战斗结束后后端校验结果并更新排名、积分、次数和奖励状态。
- 玩家领取每日、赛季或排名奖励。
5. 核心规则
5.1 挑战消耗与对手来源
ARENA-PVP-R-001：需要定义挑战消耗、每日免费次数、购买次数和刷新规则。ARENA-PVP-R-002：镜像对手需要明确来自真实玩家快照、机器人配置还是混合池。
5.2 防守阵容与排名规则
ARENA-PVP-R-003：防守阵容保存必须校验英雄拥有、主角装备/符文/技能卡等快照范围。ARENA-PVP-R-004：排名变化需要定义胜利交换、积分制或分段制。
5.3 结算、赛季与奖励
ARENA-PVP-R-005：结算必须以状态权威为准，客户端不能单独决定排名和奖励。ARENA-PVP-R-006：赛季、每日重置和奖励发放需要明确时区。
5.4 操作矩阵
N/A。当前不在策划案正文中复述核心玩家流程；进入 PLAN 时，仅对状态变化、消耗/产出、奖励发放、跨系统反馈或失败反馈补齐操作矩阵。
6. UI 状态与交互
6.1 界面图与交互说明
N/A。当前未从迁移草稿中映射到界面图片；如后续涉及 UI 改动，应补充界面图、线框图或参考图。
6.2 页面结构与交互
UI 需要竞技场主页、排名展示、对手列表、刷新按钮、挑战按钮、奖励预览、防守阵容、战斗结果、排名变化动画、次数不足和奖励可领取态。
6.3 UI 页面状态表
N/A。当前仅保留已绑定页面/状态的参考图和页面结构说明；具体可执行状态在 UI 评审或 UI brief 中确认。
7. 配置、数据与 Contract
本节只记录策划案需要的逻辑数据与跨部门 contract，不预设物理配置表、协议文件、service 文件或 仓库落点。正式命名、字段名、接口名、协议对象名、文件名和仓库落点进入执行前由 Work Package 的 contract-registry.yaml、execution brief 和对应执行任务确认。
7.1 策划数据需求
策划数据需求只描述逻辑数据域、逻辑字段或规则语义，不等同于配置表字段名、协议字段名或数据库字段名。正式字段命名进入 contract-registry.yaml、execution brief 和对应执行任务确认。
| 数据域 | 逻辑字段 / 规则 | 设计含义 | 必填 / 边界 | 产出责任 |
|---|---|---|---|---|
| 竞技场开放规则 | 开放条件、每日免费次数、购买次数、挑战消耗、刷新规则 | 定义入口开放、挑战消耗和次数刷新 | 进入执行前补齐默认值、边界和可选性 | Planning |
| 对手池规则 | 匹配范围、快照字段、机器人模板、刷新策略 | 定义镜像玩家、机器人或混合池来源 | 进入执行前补齐默认值、边界和可选性 | Planning / Backend |
| 排名与奖励规则 | 排名算法、积分/段位、赛季周期、每日奖励、赛季奖励 | 定义排名变化、赛季和奖励发放 | 进入执行前补齐默认值、边界和可选性 | Planning |
7.2 运行时数据与接口需求
| Contract | 设计含义 | 使用方 | 说明 |
|---|---|---|---|
| 防守阵容快照 | 保存用于被挑战的玩家阵容和养成快照 | 服务端 / 客户端 | 需校验英雄拥有和装备/符文/技能卡范围 |
| 挑战结算 | 处理胜负、排名变化和奖励发放 | 服务端 / 客户端 | 结算以状态权威为准，客户端不可单独决定排名 |
| 赛季状态 | 维护每日重置、赛季结算和奖励状态 | 服务端 | 需要明确时区 |
7.3 跨部门 Contract 命名清单
| Contract 类型 | 逻辑对象 | 命名状态 | 阻塞阶段 | 说明 |
|---|---|---|---|---|
| 配置数据 | 开放、次数、购买、匹配、排名、奖励和赛季 | 待 PLAN 确认 | PLAN 前 | 不预设物理配置表名 |
| 协议 / API | 竞技场主页、刷新对手、保存防守、开始挑战、提交结算、领取奖励 | 待 PLAN 确认 | 执行前 | 由服务端 / UI brief 确认 |
| 错误码 | 次数不足、对手过期、阵容非法、赛季已结束、奖励不可领取 | 待 PLAN 确认 | 执行前 | 需要玩家提示 |
| 埋点事件 | 竞技场打开、挑战开始、挑战胜负、奖励领取 | 待 PLAN 确认 | PLAN 前 | 由 analytics 方案确认 |
8. 系统边界
| 方向 | 负责内容 | 备注 |
|---|---|---|
| Planning | 逻辑数据、数值、文本需求、资源需求 | 进入执行前由 PL 任务细化 |
| 服务端 | 协议、校验、持久化、奖励发放、幂等与安全 | 仅相关功能需要 |
| 客户端 | UI、交互、表现、本地状态、红点和跳转 | 仅相关功能需要 |
| 美术 | 图标、模型、特效、音频和导出资源 | 仅相关功能需要 |
| Ops / GM | 后台配置、运营投放、公告、补偿和数据看板 | 仅相关功能需要 |
客户端与表现
客户端需要竞技场 UI、对手列表模型、战斗入口、防守阵容设置、结算表现、排名变化反馈和红点。镜像战斗若复用普通战斗，需要明确 AI、属性快照和技能释放规则。
美术与音频需求
需要竞技场入口图标、排名徽章、奖励图标、胜负结算表现、对手头像框、段位或排名资源、刷新/挑战反馈音效。
9. 数值、经济与奖励
需要设计挑战次数、购买消耗、胜负奖励、每日奖励、赛季奖励、排名奖励和可能的竞技货币。奖励发放必须引用 item-resource，排名展示可复用 ranking，战力和门槛可引用 player-level-energy-power-privilege。
10. 异常、安全与运营边界
10.1 异常与安全
需要处理重复结算、伪造战斗结果、排名并发、对手快照过期、赛季切换、奖励重复领取、次数扣减失败、断线重连和客户端战斗模拟差异。
10.2 埋点与运营
建议记录进入、刷新、挑战开始、挑战胜负、排名变化、奖励领取、次数购买、对手类型和战斗流失点。竞技场可作为中长期留存和强度验证指标。
11. Feature Relations 与回归范围
Feature Relations
依赖 battle-mission、character-hero、combat-skill、equipment、rune、ranking、item-resource 和 main-entry-red-dot。可能影响 task 和 activity-timeopen。
回归范围
以 Feature Relations 影响功能、核心玩家流程、配置与系统边界为基础；进入执行前由 PLAN / QA brief 细化最小回归范围。
12. 验收标准
12.1 关键验收结论
竞技场入口、对手刷新、镜像战斗、排名变化、次数扣减、奖励领取、重登恢复、赛季重置和异常结算都需验证。正式拆包前必须确认是否为当前版本功能。
12.2 规则验收清单
规则文本统一在§5维护；以下仅保留编号作为候选验收引用，不另存一份规则，也不代表验收已通过。
-
ARENA-PVP-R-001：核对§5同编号规则的候选行为与边界。 -
ARENA-PVP-R-002：核对§5同编号规则的候选行为与边界。 -
ARENA-PVP-R-003：核对§5同编号规则的候选行为与边界。 -
ARENA-PVP-R-004：核对§5同编号规则的候选行为与边界。 -
ARENA-PVP-R-005：核对§5同编号规则的候选行为与边界。 -
ARENA-PVP-R-006：核对§5同编号规则的候选行为与边界。
12.3 执行层验收
- 如填写操作矩阵，成功路径、失败场景、玩家反馈和状态权威均已覆盖。
- 如填写 UI 页面状态表，页面 / 弹窗状态均已覆盖，或明确标记为
N/A。 - Section 7 中标记为 PLAN 前或执行前阻塞的 contract 已在
contract-registry.yaml、execution brief 或执行任务中确认。 - 相关 Feature Relations 回归通过。
13. 待澄清问题 / Open Questions
- 竞技场是否为当前版本正式玩法。
- “镜像”是玩家防守阵容快照、机器人镜像还是本地模拟。
- 排名规则采用交换排名、积分、段位还是混合制。
- 是否需要和现有
ranking文档合并，还是作为独立玩法 feature。
14. 变更记录
| 日期 | 版本 | 修改人 | 变更摘要 |
|---|---|---|---|
| 2026-10-13 | WEN-12 draft | AutoDev Symphony | 保留原审核声明；补充来源/层级/玩法边界及待定台账；规则验收改为编号引用，移除尾部重复空图段 |
| 2026-06-16 | v0.2 | Codex | 补充规则编号、操作矩阵、UI 状态表、逻辑字段和执行层验收锚点 |
| 2026-06-16 | v0.1 | Codex | 按新版功能策划案模板重排章节；保留既有规则内容并映射参考图 |