From 3c5515aec4d3ab2bd3c6d99f179f22d4db854b6e Mon Sep 17 00:00:00 2001 From: DKChan <524912269@qq.com> Date: Mon, 5 Oct 2026 06:02:21 +0800 Subject: [PATCH] =?UTF-8?q?=E5=A5=87=E7=89=A9=20v2.6=EF=BC=9A=E4=BF=AE?= =?UTF-8?q?=E6=AD=A3=E6=A0=B8=E5=BF=83=E5=BE=AA=E7=8E=AF=E5=9B=BE=E2=80=94?= =?UTF-8?q?=E2=80=94=E5=A5=87=E7=89=A9=E4=B8=8D=E6=98=AF=E6=89=93=E4=B8=80?= =?UTF-8?q?=E5=9C=BA=E6=88=98=E6=96=97=E7=BB=99=E4=B8=80=E4=BB=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 用户纠错：原图把「关内 排雷推理 → 战斗结算 → 通关 → 得到一份奇物」 画成一条链，读起来就是每场战斗通关都给一份。 **错在哪**：把关内普通战斗的"打完"与关底 Boss 的"击败"混为一谈。 按 [冒险结构](冒险结构.md) 的定义，**通关一关 = 该关关底 Boss 被击杀** ——所以"击败 Boss"与"通过这一关"是**同一个时刻，不是一条链上的两步**。 用户原话点得准："击败 boss 之后通过关卡，这跟打败 boss 是一个渠道。" 改法（五处，链条口径与渠道名一并统一）： 1. **图改分支结构**：普通战斗节点 → 打完不给、往下走；奖励节点 / 商店 各自兑付；关底 Boss 击败 ═ 一次专长三选一 + 通关回血 → 进下一关 2. **显式口径"一关只兑付一次，不是一场战斗给一份"**——写在图下方 3. **2.1 节渠道名**：「终局前 Boss 击败后」→「关底 Boss 击败（即通过这一关）」， 并写明触发点就是关卡推进本身那一刻，不是"战斗结算之后再奖一次" 4. **文首引言加"兑付频率"条**（标为三条渠道的共同前提，先看那条）； 交叉表渠道名、registry 的 acquisition 字段同步 5. 06-待办清单新增"兑付频率（用户纠错后写死）"条目，注明勿再改回链式 连带修掉一处 v2.4 遗留污染：2.1 节节点类型封闭枚举五种里的"奖励" 曾被批量替换误伤成"奇物"（节点类型里没有奇物这一类），已复原为 「战斗 / Boss / 奖励 / 恢复 / 商店」。 术语微调：「终局 Boss 不给」→「末关的 Boss 击败后不给」——前者读起来 像在讲一个叫"终局 Boss"的实体，实际是"最后一关的那个 Boss"。 数据层零变更；未 merge 回 master（本会话零测试）。 --- design/gdd/06-待办清单.md | 5 +++-- design/gdd/systems/冒险循环/奇物.md | 31 +++++++++++++++++++++-------- design/registry/entities.yaml | 2 +- 3 files changed, 27 insertions(+), 11 deletions(-) diff --git a/design/gdd/06-待办清单.md b/design/gdd/06-待办清单.md index 62c359f4..183c5193 100644 --- a/design/gdd/06-待办清单.md +++ b/design/gdd/06-待办清单.md @@ -31,13 +31,14 @@ **用户定案（2026-10-05，v2.1 收口）**：分类 × 渠道交叉开关表—— -| 分类 \ 渠道 | 奖励节点 | 商店 | 终局前 Boss 击败后 | +| 分类 \ 渠道 | 奖励节点 | 商店 | 关底 Boss 击败＝通过这一关（末关不给） | |---|---|---|---| | 机制类（专长） | **门票形式** | **门票形式** | **直接给**（唯一直接渠道） | | 属性提升类 | 出 | 出（训练） | 不出现 | | 资源类 | 出 | 出（金币除外；**回复在内**） | 不出现 | -**Boss 渠道是专长的独占渠道，也是唯一直接给专长的渠道**——另两类都不走这里；奖励节点与商店不直接给专长，而是给一个**「专长获取」道具（门票）**，拿到后开专长三选一。形状是"一块独占 + 两块并行"，不是三块平分。**终局 Boss 不给**（打赢时冒险已结束，无后续关卡可消费），兑付只发生在终局之前的 Boss。用户原话："我在获取特性的时候，可以有些比较罕见的道具，让我立马得到一个专长，就给它一点不确定性，一点随机性"。**确定性优先**：专长不因没 roll 到就构筑不起来。用户同时明确：先定大意念再分小类，渠道与分类是两根互不决定的轴。 +**Boss 渠道是专长的独占渠道，也是唯一直接给专长的渠道**——另两类都不走这里；奖励节点与商店不直接给专长，而是给一个**「专长获取」道具（门票）**，拿到后开专长三选一。形状是"一块独占 + 两块并行"，不是三块平分。**末关的 Boss 击败后不给**（打赢时冒险已结束，无后续关卡可消费），兑付只发生在还有下一关可去的那些关底 Boss 身上。用户原话："我在获取特性的时候，可以有些比较罕见的道具，让我立马得到一个专长，就给它一点不确定性，一点随机性"。**确定性优先**：专长不因没 roll 到就构筑不起来。用户同时明确：先定大意念再分小类，渠道与分类是两根互不决定的轴。 +**兑付频率（2026-10-05 用户纠错后写死）**：这条渠道的触发点是**关底 Boss 被击败**，而按 [冒险结构](systems/冒险循环/冒险结构.md) 的定义，**打掉关底 Boss 恰好就等于"通过这一关"**——两者是同一个时刻，不是一条链上的两步。**奇物不是打一场战斗给一份**：关内普通战斗节点打完了什么也不给，一关之内奇物只兑付一次。（此前《奇物》文档的"核心循环位置"图把"战斗结算 → 通关 → 得到一份奇物"画成一条链，读起来像每场战斗通关都给一份——已于 v2.6 修正为分支图并加此口径，勿再改回链式。） **门票归机制类，不归资源类**：它给的不是"余量"而是"一件你以前不会的事"，只是把选择推迟到一次三选一。**为什么只给门票**：若商店能直接买到指定专长，玩家就能用金币把构筑买出来，Boss 渠道"打赢才拿到"就失去意义；门票保留惊喜（开出的是三选一不是指定），但不让钱定点购买。 diff --git a/design/gdd/systems/冒险循环/奇物.md b/design/gdd/systems/冒险循环/奇物.md index 005b77ce..2cd0c468 100644 --- a/design/gdd/systems/冒险循环/奇物.md +++ b/design/gdd/systems/冒险循环/奇物.md @@ -5,10 +5,12 @@ > 它是一个概念，不是一套东西。下面有**两根互不相干的轴**： > > - **分类轴**回答"给的是什么"——三个枚举：机制类 / 属性提升类 / 资源类； -> - **渠道轴**回答"从哪来"——奖励节点 / 商店 / 关底 Boss 击败后。 +> - **渠道轴**回答"从哪来"——奖励节点 / 商店 / 关底 Boss 击败（即通过这一关）。 > > 一个奇物属于哪个分类，不决定它从哪个渠道来；反过来也一样。两者的交叉由第 2 节那张开关表定死。 > +> **兑付频率（先看这条，它是三条渠道的共同前提）**：奇物**不是打一场战斗给一份**。关内的普通战斗节点打完了什么也不给；一关之内奇物**只兑付一次**，触发点是**关底 Boss 被击败**——而按 [冒险结构](冒险结构.md) 的定义，打掉关底 Boss 恰好就等于"通过这一关"，这两件事是同一个时刻，不是一条链上的两步。 +> > 状态：**已实现**（2026-10-04 双层 BD 实施批落地）。本文件是奇物的唯一定义文档。 > > 数值纪律：本文件只写概念、取值域与指路；每件给多少、效果是什么一律不进正文，事实源是 `game/data/tables/relics.tres` 与 `game/data/tables/adventure.tres`。 @@ -35,11 +37,20 @@ ## 在核心循环中的位置 ``` -【关内】排雷推理 → 战斗结算 → 通关 ──┐ - ├─→ 得到一份奇物 ─→ 后续关卡带着它继续 - 奖励节点・商店・Boss 击败后 ┘ +一次冒险 = 若干关卡串联，每关 = 一条节点链 + 一个关底 Boss + + 关内普通战斗节点 ──▶ 打完不给奇物，继续往下走 + │ + ├─ 奖励节点 ──▶ 一次三选一（属性提升类 / 资源类，罕见门票） + ├─ 商店 ──▶ 花钱买（属性提升类 / 资源类，罕见门票） + │ + 关底 Boss 击败 ═══╗ ← 打掉关底 Boss 就是「通过这一关」，同一件事 + ╰──────────╬──▶ 一次专长三选一（机制类） + ╰──▶ 通关回血 ──▶ 进下一关，带着它继续 ``` +**关键：一关只兑付一次，不是一场战斗给一份。** 触发点是**关底 Boss 被击败**，而这恰好就等于"通过这一关"（[冒险结构](冒险结构.md) 定义：通关一关 = 该关关底 Boss 被击杀）——**这两件事是同一个时刻，不是一条链上的两步**。关内普通战斗节点打完了什么也不给，直接往下走。 + 奇物处在「一次冒险」这一层：它不是一场战斗里的临时状态，也不跨冒险留存。上游是三条渠道，下游是之后所有关卡的排雷与结算——拿到了，下一关就开始生效。 ## 核心规则 @@ -107,7 +118,7 @@ 三个渠道各只取走分类的一部分。这张表是奇物概念的第二个维度——它和分类轴互不决定，改其中一根不必动另一根。 -| 分类 \ 渠道 | 奖励节点 | 商店 | 终局前 Boss 击败后（见 2.1） | +| 分类 \ 渠道 | 奖励节点 | 商店 | 关底 Boss 击败＝通过这一关（见 2.1） | |---|---|---|---| | **机制类**（专长） | 门票形式（见 2.2） | 门票形式（见 2.2） | **直接给**（唯一的直接渠道） | | **属性提升类** | 出 | 出（口径「训练」） | 不出现 | @@ -122,13 +133,15 @@ 两条的管辖范围不同：前者决定"这张表的格子填不填"，后者决定"填了的格子里装不装得全"。 -#### 2.1 机制类的主渠道：终局前 Boss 击败后 +#### 2.1 机制类的主渠道：关底 Boss 击败（即通过这一关） 专长的专属渠道，时机确定——打赢就有，不需要看脸。构筑的节奏由此可预期：玩家能规划"第几关拿到第一个专长"。品类原型是杀戮尖塔（每层 Boss 后必给遗物）与哈迪斯（Boss 后必给恩赐）——打赢了一定拿到东西，是这类游戏的通例。 -**终局 Boss 不给**：兑付只发生在**终局之前的 Boss** 身上——打赢最终 Boss 时冒险已经结束，没有后续关卡可消费，给了也无处生效。三关结构下，一局的确定性专长兑付次数由此确定（每个终局前 Boss 一次）。 +**这个渠道的触发点就是「关底 Boss 被击败」**——而按 [冒险结构](冒险结构.md) 的定义，打掉关底 Boss 恰好就等于"通过这一关"。所以这条渠道的全名是**关底 Boss 击败（即通过这一关）**：它不是"战斗结算之后再来一次奖励"的独立步骤，而**就是关卡推进本身那一刻**。关内的普通战斗节点打完了什么也不给；一关之内奇物只兑付这一次。 -**不新增节点类型**：专长挂在 Boss 节点的兑付面上（击败后追加一次专长三选一），[关卡节点地图](关卡节点地图.md) 的节点类型仍是封闭枚举五种（战斗 / Boss / 奇物 / 恢复 / 商店），词表零扩类。此前"要不要为专长新设一类节点"的悬案由此收口。 +**终局那关的 Boss 击败后不给**：兑付只发生在**还有下一关可去**的那些关底 Boss 身上——打赢最终 Boss 时冒险已经结束，没有后续关卡可消费，给了也无处生效。三关结构下，一局的确定性专长兑付次数由此确定（每个终局前 Boss 一次）。 + +**不新增节点类型**：专长挂在 Boss 节点的兑付面上（击败后追加一次专长三选一），[关卡节点地图](关卡节点地图.md) 的节点类型仍是封闭枚举五种（战斗 / Boss / 奖励 / 恢复 / 商店），词表零扩类。此前"要不要为专长新设一类节点"的悬案由此收口。 #### 2.2 专长门票：非 Boss 渠道怎么给专长 @@ -313,5 +326,7 @@ | v2.1 | 2026-10-05 | **交叉表收口（用户拍板）**：Boss 渠道**只出专长**，属性提升类与资源类在此均不出现——三条渠道的形状定为"一块独占 + 两块并行"，专长靠打赢、其余靠抽取与购买。Boss 兑付明确为**终局前**的 Boss，终局 Boss 不给（无后续关卡可消费）。新增 2.4 节**「计价物不自售」规则**：金币不进商店既不拆分类也不开特例，而是写成两轴交叉处的一条约束——商店的计价物是金币，故金币不进商店；按"能不能进商店"反推分类等于用渠道轴去切分类轴，两根轴会缠回去。 | | v2.2 | 2026-10-05 | **门票形态 + 约束分层 + 默认原则**。① 用户明确：奖励节点与商店不直接给专长，而是给一个**「专长获取」道具**，拿到后开专长三选一——交叉表机制类在两渠道由"不出现"改为"**门票形式**"；门票归机制类（给的是一件以前不会的事，只是把选择推迟），理由是防止用钱定点买构筑。② 用户质疑「计价物不自售」本质是特判——**承认成立**：它确实是在分类白名单之外加的一道过滤，与死特判的区别在于把"枚举例外"变成"**可计算谓词**"（新渠道/新奖励自动判定）。2.4 改写为**三层约束**（分类白名单 / 可计算谓词 / 显式例外清单），并给出判断标准：结构性原因可写成谓词，设计性原因只能进清单且每条须写理由；三个方案（单独分类 / 谓词 / 死特判）的代价并列摆出，不藏折中。③ 用户定**默认原则**：除已登记的特殊规则外，分类内的东西都要在池子里——据此**回复应在商店内**，现行 shop.tres 货架缺它是"现状与表格不对齐"，须在实施批补上。 | | v2.3 | 2026-10-05 | **门票机制细化 + 默认原则表述修正**。① 门票**拿到即开、不可囤积**（用户定）——不进持有集，防止玩家把关键决策无限推迟，也防持有物语义从后门回来。② 门票的"罕见"**只在概率不在价格**，一局限购一次，并加**计步保底**：连续 5 次三选一展示未出现则第 6 次必出；计数跨奖励节点与商店共享、**刷新后的重新展示计入**（用户明定含刷新），限购用满后保底不再触发。③ **修正 v2.2 的误读**：把"分类在某渠道不出现"当成需要理由的缺格是错的——渠道出哪些分类是渠道轴的定位（Boss 只出专长），不是例外；默认原则只管**分类内部**的成员齐不齐。④ 专长总量与档位阈值的匹配按用户决定**延后**（待第四关内容批后实测复裁），另单独登记 charge 标签仅 3 件、永远达不到档二的数据缺陷。 | +| **v2.6** | 2026-10-05 | **修正核心循环位置图：奇物不是打一场战斗给一份**（用户纠错）。原图把"关内 排雷推理 → 战斗结算 → 通关 → 得到一份奇物"画成一条链，读起来就是每场战斗通关都给一份——**错在把关内普通战斗的通关与关底 Boss 的通关混为一谈**。按 [冒险结构](冒险结构.md) 的定义，**通关一关 = 该关关底 Boss 被击杀**，所以"击败 Boss"与"通过这一关"是同一个时刻、不是一条链上的两步。改法：① 图改为分支结构（普通战斗节点→不给、往下走；关底 Boss 击败→专长三选一＋通关回血）；② **一关只兑付一次**写成显式口径；③ 2.1 节渠道名由"终局前 Boss 击败后"改为"关底 Boss 击败（即通过这一关）"，并写明触发点就是关卡推进本身那一刻；④ 文首引言加"兑付频率"条，交叉表渠道名与 registry 同步；⑤ 连带修掉一处污染——节点类型封闭枚举五种里的"奖励"曾被 v2.4 批量替换误伤成"奇物"（节点类型里没有奇物这一类），已复原。 | + | **v2.5** | 2026-10-05 | **第三类定名「资源类」**（用户拍板，父节点定为「奇物」后解锁）。定名依据：行动点上限 / 刷新次数 / 金币 / 回复都是可以调动、可以花掉的余量。「资源」偏泛（能力资源、财富资源都叫资源），因此在 1.5 写死判据句——**给的是可消耗或可重掷的余量，不是角色基础属性的永久抬升**，这一句是把泛用词收回本类定义的唯一凭据。**回复归属同时定案：留在资源类，不独立成第四类**——它与金币同为即时兑付、判据同源，拆出去第四类只剩两项且与本类判据重合。附带修复：1.5 段末与「### 2. 渠道轴」标题粘连（缺换行）。 | | **v2.4** | 2026-10-05 | **顶层由「奖励」改名为「奇物」（Wondrous Item）**。用户否决了「奖励」「收益」与全部自造词（进益/造化/机缘/遇获），要求回到 DND／西幻既有名词。定名依据：DMG 魔法物品九分类中的 Wondrous Item，官方中文译名即「奇物」，是专装不好归类但有奇效之物的兜底杂类——正好对应本概念下三个互不相干的分类。此前考虑过的 Treasure（宝物）因偏财物、装不下专长而落选；roguelike 品类惯例 Relic 因用户否决遗物落选。**代码词族定为 `curio_*`、`ADVENTURE_CURIO`**（`reward_*` 已被 `reward_pick` / `reward_node` / `reward_preview` 占用，不能对齐）。 | diff --git a/design/registry/entities.yaml b/design/registry/entities.yaml index 3f21506d..523aa068 100644 --- a/design/registry/entities.yaml +++ b/design/registry/entities.yaml @@ -584,7 +584,7 @@ entities: categories: 封闭三类 {机制类, 属性提升类, 资源类}（v2.0 起；v1.1 曾用两类、v1.0 曾用 {rule, stat}，均已作废）。机制类（专长 Feat）——在结算管线某个挂点上给自己加一条规则，同标签持有项数达阈值时质变，事实源 relics.tres；属性提升类（ASI）——抬高生命上限 / AC / 攻击三轴基础值，进冒险加算区，事实源 adventure.tres；资源类（命名待定）——给"可用的量"，不抬高战斗属性也不改规则：行动点上限 / 刷新次数 / 金币 / 回复，不进加算区、多数不进持有集，事实源 adventure.tres scope: 作用对象 = 角色本人与其参与的结算（不改敌人、不改棋盘生成、不改关卡内容）；**例外**——刷新次数作用在三选一界面而非角色身上，不进加算区；时间范围 = 整局冒险，机制类与属性提升类跨关携带、关间不清零，金币与回复即时兑付；归属范围 = 不进账号永久进度，不带到下一次冒险 lifecycle: 候选池构建（冒险开局一次）→ 在渠道上出现（三选一形式）→ 选定（自池中剔除不再复现；选到「专长获取」时立刻再开一次专长 N 选一）→ 持有生效或即时兑付 → 冒险以任一结局收束时整集清零；断点记录持有集与剩余候选池 - acquisition: 三条渠道的**目标分工（交叉开关，v2.2 收口）**——机制类：主渠道＝**终局前** Boss 击败后（**唯一直接给的渠道**，不新增节点类型、挂 Boss 节点兑付面；终局 Boss 不给——无后续关卡可消费），奖励节点与商店**只给「专长获取」门票**——**拿到即开、不可囤积**，不进持有集（选中/买下同一时刻开专长三选一；可囤积会让玩家无限推迟关键决策，且把持有物语义从后门放回）。门票归机制类（给的是一件以前不会的事，只是把选择推迟）。罕见**只在概率不在价格**，一局限购一次，**计步保底**：连续 5 次三选一展示未出现→第 6 次必出（计数＝展示次数、刷新重展计入、奖励节点与商店共享、触发清零、限购用满后不再触发）；属性提升类：奖励节点 + 商店（口径「训练」）；资源类：奖励节点 + 商店（**金币除外、回复在内**）；后两类均不出现在 Boss 渠道。形状＝「一块独占 + 两块并行」，专长靠打赢、其余靠抽取与购买。**默认原则**：除已登记的特殊规则外，分类内的东西都要在它该出现的渠道池子里——任何不出现都须登记理由**现行实现三渠道共用同一候选池、三类混编**，分工尚未实施，登记于 06-待办清单 BD 分层条目 + acquisition: 三条渠道的**目标分工（交叉开关，v2.2 收口）**——机制类：主渠道＝**关底 Boss 击败＝通过这一关**（**唯一直接给的渠道**；不新增节点类型、挂 Boss 节点兑付面；末关的 Boss 击败后不给——无后续关卡可消费）。**兑付频率**：奇物不是打一场战斗给一份，关内普通战斗节点不给任何奇物，一关之内只兑付一次（奖励节点与商店同理，各节点各自兑付），奖励节点与商店**只给「专长获取」门票**——**拿到即开、不可囤积**，不进持有集（选中/买下同一时刻开专长三选一；可囤积会让玩家无限推迟关键决策，且把持有物语义从后门放回）。门票归机制类（给的是一件以前不会的事，只是把选择推迟）。罕见**只在概率不在价格**，一局限购一次，**计步保底**：连续 5 次三选一展示未出现→第 6 次必出（计数＝展示次数、刷新重展计入、奖励节点与商店共享、触发清零、限购用满后不再触发）；属性提升类：奖励节点 + 商店（口径「训练」）；资源类：奖励节点 + 商店（**金币除外、回复在内**）；后两类均不出现在 Boss 渠道。形状＝「一块独占 + 两块并行」，专长靠打赢、其余靠抽取与购买。**默认原则**：除已登记的特殊规则外，分类内的东西都要在它该出现的渠道池子里——任何不出现都须登记理由**现行实现三渠道共用同一候选池、三类混编**，分工尚未实施，登记于 06-待办清单 BD 分层条目 boundary: 判据走生命周期——**一次冒险内获得、冒险收束即清零的是奇物；跨冒险跟着你走的是魔法道具**。奇物永不进同调位，魔法道具永不进当局随机渠道；与元进度天赋树两层互不代位 data_sources: relics.tres（机制类定义行）/ adventure.tres（属性提升类与资源类的种类配额与值）/ shop.tres（货架取舍） open_questions: ①类内异质性已登记——金币与回复是即时兑付、不进持有集不持续生效，与行动点上限/刷新次数生命周期不同，靠这条描述把"资源"从泛用词收回到本类定义内；②专长门票尚未入表（出现概率/配额/限购次数/保底阈值四参数均无事实源）；③确定性渠道一局两次专长 vs 档位阈值（同标签 ≥2 档一 / ≥4 档二）——**档二在三关结构下几乎不可达**，用户定延后复裁（触发＝第四关内容批后实测）；④charge 标签仅 3 件、永远达不到档二（数据层缺陷，独立登记，勿被上条盖掉）；⑤断点存档键 5 个（bonus_deck / bonus_taken / bonus_pending / bonus_result / bonus_aux_carry）是否随存档版本迁移换名待裁