9d17707c3b
明确属性型与机制型天赋的区别，建立配置规范： 1. 属性型效果必须使用 Attrs 作为 Key 2. 机制型效果需使用独立枚举 Mechanic 3. 新增配置校验规则避免误用
154 lines
7.5 KiB
Markdown
154 lines
7.5 KiB
Markdown
|
||
# 技能系统优化建议（Design3）
|
||
|
||
目标：在尽量少改代码的前提下，把技能的“可配置性、可扩展性、可组合性”拉起来，让新增技能与 build 更容易产出差异。
|
||
|
||
## 一、先修复会直接抹平 build 的关键问题（优先级最高）
|
||
|
||
1) 攻速/技速对 CD 生效
|
||
|
||
- 问题：HeroSkills.resetCD 先按 AS/SS 计算 cd，但随后又覆盖回 cd_max，导致 AS/SS 永远不影响技能循环。
|
||
- 结果：攻速流、技速流、触发流的 build 直接被抹平。
|
||
|
||
2) 统一百分比/概率单位体系
|
||
|
||
- 现状：
|
||
- 概率判定使用 0–100（checkChance）。
|
||
- add_hp/add_mp 的百分比逻辑按 0–1（value * HP_MAX）。
|
||
- 配置层（TDLevelOptions、TalSet）同时出现 0.14 表示 14% 的写法。
|
||
- 建议：所有“概率/百分比”统一用 0–100 的“百分比点数”，显示与逻辑一致。
|
||
|
||
3) 天赋 count 配置生效 + 天赋 key 统一
|
||
|
||
- 问题：
|
||
- **Count 容易失效**：如果 `TalComp.addTal` 中把 `count` 写死为 `1`，配置表 `talConf.count` 就会被忽略。例如“下 5 次暴击”的天赋会退化为“下 1 次暴击”。
|
||
- 校验点：`this.Tals[uuid].count` 必须来自 `tConf.count`，而不是常量。
|
||
- **Key 混用导致逻辑断裂**：
|
||
- 写入方：`TalComp` 使用 `TalEffet` 枚举值写入（如 `TalEffet.DMG_RED = 10`）。
|
||
- 读取方：`HeroAtkSystem` 使用 `Attrs` 枚举值读取（如 `Attrs.DMG_RED = 24`）。
|
||
- 结果：天赋效果写入了错误的 Key（如 Key 10 对应 `Attrs.AP`），导致真正的伤害减免逻辑（读 Key 24）读不到数据，天赋完全失效。
|
||
- 建议：
|
||
- 废弃 `TalEffet` 中的 Key 定义，统一使用 `Attrs` 枚举作为 Key。
|
||
- 在 `TalComp.addTal` 中读取 `tConf.count` 写入 `talent.count`，并保证所有“次数型天赋”的消耗端也使用同一套 Key。
|
||
|
||
补充：TalSet 与 HeroAttrs 的“可一一对应”边界（避免后续继续混淆）
|
||
|
||
- 结论：可以建立一一对应，但必须先把“键域”拆开。
|
||
- 重要澄清：**“有条件触发”不等于“机制型”**。
|
||
- `TriType`/`Trigger` 只决定“什么时候触发”；
|
||
- “属性型/机制型”决定“触发后往哪里写数据、怎么被消耗”。
|
||
- **属性型效果（可一一对应）**：所有本质是“修改某个战斗属性”的天赋，统一用 `Attrs` 作为唯一 Key。
|
||
- 例：减伤 -> `Attrs.DMG_RED`，反伤 -> `Attrs.THORNS`，风怒倍率/风怒触发相关如果要做成属性，也应落到 `Attrs.WFUNY`。
|
||
- 这一类天赋的表现形式建议只允许：数值型（VALUE）或百分比型（RATIO）的叠加/消耗。
|
||
- **机制型效果（不可强行一一对应）**：本质是“改变行为/流程”的天赋，不要硬塞进 `Attrs`，而应该走独立的机制 Key。
|
||
- 例：下次技能额外释放（D_SKILL）、下 N 次普攻必暴（C_ATK）、下 N 次技能必暴（C_SKILL）。这些不是“暴击率+X%”，而是“保证命中事件改写”，语义不同。
|
||
- 强行映射到 `Attrs.CRITICAL` 会造成策划误配：玩家以为是概率加成，但实际是保底机制，体验会断层。
|
||
|
||
- 推荐的设计规范（给策划与程序统一语言）：
|
||
- **字段含义固定化**：
|
||
- `effet` 只表达“这是属性型还是机制型”。
|
||
- `key` 才是具体作用目标：属性型 `key = Attrs.*`；机制型 `key = Mechanic.*`（独立枚举，值域不与 Attrs 重叠）。
|
||
- **配置校验规则**：
|
||
- 只要是属性型天赋：必须能在 `HeroAttrs.ts` 找到同名或同义的 `Attrs`；找不到就不允许配置。
|
||
- 只要是机制型天赋：必须有对应的消耗点（例如攻击/技能系统里明确消耗一次），否则 count 只会累加成“无效库存”。
|
||
- 现状提醒：`TalAttrs` 的确已经把一部分属性（冻结/眩晕/击退/沉默/暴击等）映射到 `Attrs`，但这只覆盖了 `BUFF` 这类“属性叠加”分支；计数型效果如果仍用 `TalEffet` 作为 Key，就会再次出现写入/读取不一致。
|
||
|
||
## 二、把 SkillSet 变成“少字段但强表达”的可配置系统
|
||
|
||
当前 SkillConfig 字段很多，但真正稳定生效的只有少数（ap/map/DType/RType/EType/speed/dis/hit/cd/cost/sp_name）。
|
||
|
||
建议把技能配置分成两层：
|
||
|
||
- 核心战斗字段（必须生效）：
|
||
- 伤害：ap/map + DType
|
||
- 弹道：RType + speed + dis
|
||
- 命中：hit（穿透次数）
|
||
- 生命周期：EType（建议只保留 animationEnd/collision 两类，其他先不让配）
|
||
|
||
- 扩展字段（等系统补齐后开放）：
|
||
- 多目标：t_num/hit_num
|
||
- DOT：hitcd + timeEnd
|
||
- buff/debuff：buffs/neAttrs + chance
|
||
- 前摇/结束动画：ready/EAnm/DAnm
|
||
|
||
做法：短期不改字段也可以，但在设计上约束“哪些字段可用、哪些字段暂不承诺”。
|
||
|
||
## 三、用“技能变体（SkillID 替换）”快速放大组合数（最划算）
|
||
|
||
你现在每个英雄主动技能数量少（技能+大招），想提高 build 兴趣，不要一口气做几十个新技能。
|
||
|
||
建议：每个技能做 2–4 个“配置变体”，通过替换 s_uuid 实现。
|
||
|
||
示例：
|
||
|
||
- 火球（基础） -> 爆裂火球（碰撞盒更大） -> 穿透火球（hit 更高） -> 集束火球（低伤多发）
|
||
- 风刃（基础） -> 远程风刃（dis 更长） -> 快速风刃（speed 更高，hit 较低） -> 重刃（map 更高，speed 更低）
|
||
|
||
收益：
|
||
|
||
- 不依赖 t_num/hit_num/buffs/neAttrs 等未落地字段。
|
||
- 组合数近似按“技能变体数 × 天赋组合 × 强化路径”指数增长。
|
||
|
||
## 四、把天赋从“加数值”升级为“改机制”（触发器 + 处理器）
|
||
|
||
现状：TriType 很全，但实际只在 ATK/SKILL/MAX 更新触发，DMG/HPL/LUP 等缺来源。
|
||
|
||
建议的最小升级：
|
||
|
||
1) 先把触发源补齐：
|
||
|
||
- DMG：受伤时更新
|
||
- LUP：升级时更新
|
||
- HPL/HPA：血量变化达到阈值更新
|
||
- DEAD：击杀/死亡时更新
|
||
|
||
2) 天赋效果以“机制改造”为主：
|
||
|
||
- 下一次技能额外释放一次
|
||
- 下一次必暴/必定击退
|
||
- 技能变体替换（把 s_uuid 换成强化版本）
|
||
- 元素转化（把 DType 从 ATK 改成 FIRE 等，形成元素 build）
|
||
|
||
这样即使每局只拿 4 个天赋，组合也会很丰富。
|
||
|
||
## 五、给技能增加“关键词（Tag）”让天赋可泛化（中期目标）
|
||
|
||
建议新增 tags（概念层）：
|
||
|
||
- Projectile / Melee / AoE / Beam
|
||
- Element: Fire/Ice/Wind/Phys
|
||
- Utility: Control/Sustain/Burst/Clear
|
||
|
||
天赋用 tags 做筛选：
|
||
|
||
- “所有 Projectile 分裂 +1”
|
||
- “所有 Fire 技能命中后额外一次伤害（或改成更大碰撞体）”
|
||
- “所有 AoE 范围 +20%”
|
||
|
||
收益：一个天赋能作用多个技能，build 会自然爆炸。
|
||
|
||
## 六、让技能表现更稳定的工程建议（减少体验噪音）
|
||
|
||
1) 明确技能销毁策略
|
||
|
||
- 推荐只支持：
|
||
- animationEnd（动画结束销毁）
|
||
- collision（碰撞触发销毁或 hit 次数耗尽销毁）
|
||
|
||
2) 统一命中次数规则
|
||
|
||
- 只保留一个概念：pierce（命中次数上限）
|
||
- 技能用 hit 表达基础穿透，角色属性用 PUNCTURE 叠加。
|
||
|
||
3) 技能范围命中逻辑选择一种实现并固定
|
||
|
||
- 方案A：完全靠碰撞体（推荐，少代码）
|
||
- 方案B：施法阶段选目标（t_num/hit_num），但必须补齐对应系统，否则不要给策划配。
|
||
|
||
## 七、推荐落地顺序（两周内能看到 build 明显变丰富）
|
||
|
||
1) 修复：CD 计算、单位体系、天赋 count/key
|
||
2) 新增：每个主技能 2–3 个变体（SkillID 替换）
|
||
3) 补齐：DMG/LUP/HPL 等触发源，让天赋真正“可构筑”
|
||
4) 扩展：tags + 泛化天赋
|