refactor(game): 移除已弃用的事件常量
- 删除 UpdateHero 和 UpdateFightHero 事件 - 移除 MISSION_UPDATE 事件常量 - 优化游戏事件枚举定义
This commit is contained in:
panw
167
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励UI集成.md
Normal file
167
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励UI集成.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# 奖励UI集成
|
||||
|
||||
<cite>
|
||||
**本文档中引用的文件**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
- [GameUIConfig.ts](file://assets/script/game/common/config/GameUIConfig.ts)
|
||||
- [GameEvent.ts](file://assets/script/game/common/config/GameEvent.ts)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts)
|
||||
- [Design.md](file://assets/script/Design.md)
|
||||
</cite>
|
||||
|
||||
## 目录
|
||||
1. [简介](#简介)
|
||||
2. [项目结构](#项目结构)
|
||||
3. [核心组件](#核心组件)
|
||||
4. [架构概述](#架构概述)
|
||||
5. [详细组件分析](#详细组件分析)
|
||||
6. [依赖分析](#依赖分析)
|
||||
7. [性能考虑](#性能考虑)
|
||||
8. [故障排除指南](#故障排除指南)
|
||||
9. [结论](#结论)
|
||||
|
||||
## 简介
|
||||
本文档详细说明了MissionComp组件如何与胜利界面（Victory）进行集成，重点分析了oops.gui.open(UIID.Victory)调用时传递rewards和game_data参数的具体实现。文档解释了胜利界面如何解析这些数据并渲染三选一奖励选项，描述了从战斗结束到奖励界面展示的完整用户流程，包括延迟调度（scheduleOnce）的时间控制策略。同时提供了UI数据绑定错误的诊断方法，并给出了自定义奖励展示效果的扩展建议。
|
||||
|
||||
## 项目结构
|
||||
项目结构显示了游戏的核心脚本位于assets/script/game目录下，其中map子目录包含了MissionComp和VictoryComp等关键组件。这些组件通过ECS架构进行组织，实现了战斗逻辑与UI展示的分离。资源文件和配置文件分别存放在resources和config目录中，形成了清晰的模块化结构。
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph "Assets"
|
||||
subgraph "Script"
|
||||
subgraph "Game"
|
||||
subgraph "Map"
|
||||
MissionComp --> VictoryComp
|
||||
MissionComp --> TopComp
|
||||
MissionComp --> GuideSetpComp
|
||||
end
|
||||
subgraph "Common"
|
||||
SingletonModuleComp --> GameEvent
|
||||
SingletonModuleComp --> GameUIConfig
|
||||
end
|
||||
end
|
||||
end
|
||||
subgraph "Resources"
|
||||
subgraph "Config"
|
||||
NetCodeJson --> MapJson
|
||||
end
|
||||
LanguageJson --> ZhJson
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
- [GameUIConfig.ts](file://assets/script/game/common/config/GameUIConfig.ts)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
|
||||
## 核心组件
|
||||
核心组件包括MissionComp和VictoryComp，分别负责战斗逻辑管理和胜利界面展示。MissionComp组件通过事件系统监听战斗状态变化，在战斗结束后触发胜利界面的打开，并传递奖励数据。VictoryComp组件接收这些数据并在onAdded方法中进行处理，实现奖励选项的动态渲染。
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L17-L150)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L13-L74)
|
||||
|
||||
## 架构概述
|
||||
系统采用ECS（实体-组件-系统）架构模式，通过事件驱动机制实现组件间的通信。战斗逻辑与UI展示完全分离，MissionComp作为战斗逻辑控制器，负责管理战斗状态和奖励生成；VictoryComp作为UI控制器，负责解析和展示奖励数据。这种架构设计提高了代码的可维护性和可扩展性。
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[MissionComp] --> |dispatchEvent| B[GameEvent.FightEnd]
|
||||
B --> C[VictoryComp]
|
||||
C --> |open UIID.Victory| D[奖励界面]
|
||||
D --> |用户选择| E[奖励应用]
|
||||
E --> |dispatchEvent| F[GameEvent.MissionEnd]
|
||||
F --> G[游戏状态更新]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L66-L116)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L13-L74)
|
||||
|
||||
## 详细组件分析
|
||||
|
||||
### MissionComp分析
|
||||
MissionComp组件是战斗逻辑的核心控制器，负责管理整个战斗流程。当英雄死亡或战斗结束时，该组件会触发相应的事件处理函数，并通过oops.gui.open方法打开胜利界面。
|
||||
|
||||
#### 战斗结束流程
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant MissionComp as MissionComp
|
||||
participant VictoryComp as VictoryComp
|
||||
participant OopsGUI as oops.gui
|
||||
MissionComp->>MissionComp : do_hero_dead()
|
||||
MissionComp->>MissionComp : check hero_num <= 0
|
||||
MissionComp->>MissionComp : dispatchEvent(FightEnd)
|
||||
MissionComp->>OopsGUI : open(UIID.Victory, args)
|
||||
OopsGUI->>VictoryComp : instantiate victory prefab
|
||||
VictoryComp->>VictoryComp : onAdded(args)
|
||||
VictoryComp->>VictoryComp : parse rewards and game_data
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L32-L70)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L13-L74)
|
||||
|
||||
### VictoryComp分析
|
||||
VictoryComp组件负责胜利界面的展示和交互处理。该组件通过onAdded方法接收来自MissionComp的数据参数，并在界面上渲染相应的奖励选项。
|
||||
|
||||
#### 数据传递与解析
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start([UI打开]) --> OnAdded["onAdded(args)"]
|
||||
OnAdded --> CheckArgs{"args存在?"}
|
||||
CheckArgs --> |是| ParseGameData["解析game_data"]
|
||||
ParseGameData --> UpdateUI["更新UI元素"]
|
||||
UpdateUI --> ScheduleNext["scheduleOnce显示next按钮"]
|
||||
ScheduleNext --> End([界面就绪])
|
||||
CheckArgs --> |否| DefaultValues["使用默认值"]
|
||||
DefaultValues --> UpdateUI
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L13-L37)
|
||||
- [GameUIConfig.ts](file://assets/script/game/common/config/GameUIConfig.ts#L9-L22)
|
||||
|
||||
## 依赖分析
|
||||
组件间的依赖关系清晰明确，MissionComp依赖于GameEvent和UIID枚举来触发界面切换，VictoryComp依赖于SingletonModuleComp来访问全局游戏数据。这种依赖关系通过import语句在代码中显式声明，确保了模块间的松耦合。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[MissionComp] --> B[GameEvent]
|
||||
A --> C[UIID]
|
||||
A --> D[SingletonModuleComp]
|
||||
E[VictoryComp] --> F[GameEvent]
|
||||
E --> G[SingletonModuleComp]
|
||||
E --> H[ItemComp]
|
||||
D --> I[vmdata]
|
||||
G --> I
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L33)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L37)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts#L0-L41)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L33)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L37)
|
||||
|
||||
## 性能考虑
|
||||
系统在性能方面采用了多种优化策略。首先，通过scheduleOnce方法实现了界面元素的延迟显示，避免了瞬间大量UI更新带来的性能冲击。其次，组件的销毁通过reset方法完成，确保了内存的及时释放。最后，事件系统的使用减少了组件间的直接调用，降低了耦合度和性能开销。
|
||||
|
||||
## 故障排除指南
|
||||
当遇到UI数据绑定错误时，应首先检查数据传递路径。确保MissionComp中的rewards和game_data字段正确初始化，并在oops.gui.open调用时作为参数传递。在VictoryComp的onAdded方法中，验证args参数是否包含预期的数据字段。如果问题仍然存在，检查SingletonModuleComp中的vmdata结构是否与UI绑定要求一致。
|
||||
|
||||
**Section sources**
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L13-L74)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts#37-L87)
|
||||
|
||||
## 结论
|
||||
MissionComp与Victory界面的集成通过清晰的事件驱动机制和数据传递模式实现。系统利用scheduleOnce方法控制界面元素的显示时机，提供了流畅的用户体验。通过分析代码结构和数据流，可以有效诊断和解决UI集成中的常见问题，并为自定义奖励展示效果提供扩展基础。
|
||||
169
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励数据流.md
Normal file
169
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励数据流.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# 奖励数据流
|
||||
|
||||
<cite>
|
||||
**本文档引用文件**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
- [MissionMonComp.ts](file://assets/script/game/map/MissionMonComp.ts)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts)
|
||||
- [Mon.ts](file://assets/script/game/hero/Mon.ts)
|
||||
</cite>
|
||||
|
||||
## 目录
|
||||
1. [引言](#引言)
|
||||
2. [奖励数据生命周期](#奖励数据生命周期)
|
||||
3. [rewards数组存储格式与UI展示](#rewards数组存储格式与ui展示)
|
||||
4. [game_data对象累加逻辑](#game_data对象累加逻辑)
|
||||
5. [数据同步策略](#数据同步策略)
|
||||
6. [数据丢失问题调试](#数据丢失问题调试)
|
||||
7. [结论](#结论)
|
||||
|
||||
## 引言
|
||||
本文档系统阐述了奖励数据在MissionComp组件中的完整生命周期管理过程。从data_init方法初始化rewards数组和game_data对象开始，到do_drop方法接收掉落物品参数并更新数据结构的全过程。详细解释了rewards数组的存储格式设计及其与UI展示的对应关系，分析了game_data对象中exp、gold、diamond字段的累加逻辑与数据一致性保障机制，说明了MissionComp与全局状态管理smc.vmdata.mission_data的数据同步策略，并提供了数据丢失问题的调试方法。
|
||||
|
||||
## 奖励数据生命周期
|
||||
|
||||
奖励数据在MissionComp组件中的生命周期始于任务开始时的初始化，终于任务结束时的数据清理。整个生命周期通过事件驱动的方式进行管理，确保数据的准确性和一致性。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["任务开始 MissionStart"] --> B["data_init初始化"]
|
||||
B --> C["do_drop接收掉落物品"]
|
||||
C --> D["更新rewards数组"]
|
||||
D --> E["更新game_data对象"]
|
||||
E --> F["任务结束 FightEnd"]
|
||||
F --> G["数据同步到全局状态"]
|
||||
G --> H["打开胜利界面"]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
|
||||
## rewards数组存储格式与UI展示
|
||||
|
||||
rewards数组用于存储任务过程中获得的所有掉落物品信息。该数组在data_init方法中被初始化为空数组，随着任务进行逐步填充。数组的设计考虑了后续UI展示的需求，每个元素代表一个掉落物品。
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class MissionComp {
|
||||
+rewards : any[]
|
||||
+game_data : any
|
||||
+data_init()
|
||||
+do_drop(drop_item[], game_data)
|
||||
}
|
||||
class VictoryComp {
|
||||
+rewards : any[]
|
||||
+game_data : any
|
||||
+onAdded(args)
|
||||
}
|
||||
MissionComp --> VictoryComp : "传递数据"
|
||||
```
|
||||
|
||||
当任务结束时，rewards数组作为参数传递给胜利界面(VictoryComp)，实现数据的跨组件传递。这种设计模式确保了奖励数据的完整性和可追溯性。
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L33)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L37)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L33)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L37)
|
||||
|
||||
## game_data对象累加逻辑
|
||||
|
||||
game_data对象包含exp、gold、diamond三个核心字段，用于记录任务过程中的经验值、金币和钻石奖励。这些数据的累加逻辑通过do_drop方法实现，确保每次获得奖励时都能正确更新。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["do_drop方法"] --> B["接收game_data参数"]
|
||||
B --> C{"参数有效性检查"}
|
||||
C --> |有效| D["累加exp、gold、diamond"]
|
||||
C --> |无效| E["使用默认值{exp:0,gold:0,diamond:0}"]
|
||||
D --> F["更新本地game_data对象"]
|
||||
F --> G["数据一致性保障"]
|
||||
```
|
||||
|
||||
数据一致性通过以下机制保障：
|
||||
1. 初始化时设置默认值
|
||||
2. 参数传递时提供默认值
|
||||
3. 事件驱动更新，避免直接修改
|
||||
4. 任务结束时统一同步到全局状态
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L32-L70)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L32-L70)
|
||||
|
||||
## 数据同步策略
|
||||
|
||||
MissionComp组件与全局状态管理smc.vmdata.mission_data之间采用事件驱动的数据同步策略。当特定事件发生时，相关数据会被同步到全局状态，确保数据的一致性和可访问性。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant MissionComp
|
||||
participant smc_vmdata
|
||||
participant VictoryComp
|
||||
MissionComp->>MissionComp : data_init()
|
||||
MissionComp->>smc_vmdata : 初始化mission_data状态
|
||||
MissionComp->>MissionComp : do_drop(drop_item, game_data)
|
||||
MissionComp->>MissionComp : 更新本地数据
|
||||
MissionComp->>smc_vmdata : 同步关键状态(如mon_num)
|
||||
MissionComp->>VictoryComp : FightEnd事件
|
||||
VictoryComp->>VictoryComp : 接收rewards和game_data
|
||||
VictoryComp->>smc_vmdata : 最终数据持久化
|
||||
```
|
||||
|
||||
除了直接的奖励数据，其他任务相关状态如怪物数量(mon_num)、英雄数量(hero_num)等也会同步到全局状态，为其他组件提供必要的上下文信息。
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L66-L116)
|
||||
- [MissionMonComp.ts](file://assets/script/game/map/MissionMonComp.ts#L102-L136)
|
||||
- [Mon.ts](file://assets/script/game/hero/Mon.ts#L57-L93)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L66-L116)
|
||||
- [MissionMonComp.ts](file://assets/script/game/map/MissionMonComp.ts#L102-L136)
|
||||
- [Mon.ts](file://assets/script/game/hero/Mon.ts#L57-L93)
|
||||
|
||||
## 数据丢失问题调试
|
||||
|
||||
为确保奖励数据的完整性和可靠性，需要建立系统的调试方法来检测和解决潜在的数据丢失问题。以下是常见的调试策略和检查点：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["数据丢失问题"] --> B["检查事件监听"]
|
||||
A --> C["验证数据初始化"]
|
||||
A --> D["确认数据传递"]
|
||||
A --> E["检查异常处理"]
|
||||
B --> B1["MissionStart事件是否正确触发"]
|
||||
B --> B2["do_drop事件参数是否完整"]
|
||||
B --> B3["FightEnd事件是否携带数据"]
|
||||
C --> C1["data_init是否清空rewards数组"]
|
||||
C --> C2["game_data是否重置为默认值"]
|
||||
D --> D1["胜利界面是否正确接收参数"]
|
||||
D --> D2["数据结构是否匹配"]
|
||||
E --> E1["异常情况下数据是否保存"]
|
||||
E --> E2["网络中断时的恢复机制"]
|
||||
```
|
||||
|
||||
关键调试检查点包括：
|
||||
1. 确认data_init方法在每次任务开始时都被正确调用
|
||||
2. 验证do_drop方法接收的参数格式是否符合预期
|
||||
3. 检查FightEnd事件触发时是否正确传递了rewards和game_data
|
||||
4. 确保异常情况下（如游戏崩溃）有适当的数据恢复机制
|
||||
5. 验证全局状态smc.vmdata.mission_data的更新时机和内容
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L114-L150)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts#L47-L86)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L114-L150)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts#L47-L86)
|
||||
|
||||
## 结论
|
||||
MissionComp组件中的奖励数据管理采用了一套完整的生命周期管理体系。通过data_init方法初始化数据结构，do_drop方法处理奖励更新，最终通过事件机制将数据传递给胜利界面展示。rewards数组和game_data对象的设计充分考虑了UI展示需求和数据一致性要求。与全局状态管理smc.vmdata.mission_data的同步策略确保了数据的可靠性和可访问性。为防止数据丢失，建议建立完善的调试机制，重点关注事件触发、数据初始化、参数传递和异常处理等关键环节。
|
||||
272
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励机制.md
Normal file
272
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励机制.md
Normal file
@@ -0,0 +1,272 @@
|
||||
# 奖励机制
|
||||
|
||||
<cite>
|
||||
**本文档引用文件**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
- [GameEvent.ts](file://assets/script/game/common/config/GameEvent.ts)
|
||||
- [GameUIConfig.ts](file://assets/script/game/common/config/GameUIConfig.ts)
|
||||
- [MissionMonComp.ts](file://assets/script/game/map/MissionMonComp.ts)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts)
|
||||
- [Design.md](file://assets/script/Design.md)
|
||||
</cite>
|
||||
|
||||
## 目录
|
||||
1. [奖励系统概述](#奖励系统概述)
|
||||
2. [三选一奖励机制](#三选一奖励机制)
|
||||
3. [FightSet常量配置与奖励类型](#fightset常量配置与奖励类型)
|
||||
4. [奖励数据结构与流程](#奖励数据结构与流程)
|
||||
5. [掉落处理与数据更新](#掉落处理与数据更新)
|
||||
6. [奖励界面触发与数据传递](#奖励界面触发与数据传递)
|
||||
7. [扩展新奖励类型](#扩展新奖励类型)
|
||||
|
||||
## 奖励系统概述
|
||||
|
||||
本游戏采用肉鸽（Roguelike）塔防玩法，奖励系统是核心成长机制之一。玩家通过击败怪物获得金币，并在每波战斗结束后从三个奖励选项中选择一个，用于强化英雄能力。奖励类型包括属性提升、技能升级、装备获取、新技能解锁等，不同奖励具有不同的战力评分和金币消耗，玩家需要根据当前局势进行策略性选择。
|
||||
|
||||
奖励系统通过事件驱动机制实现，主要由`MissionComp`组件负责奖励数据的收集与分发，`VictoryComp`组件负责奖励界面的展示与交互。系统采用ECS架构，通过事件总线（`oops.message`）进行组件间通信，确保了高内聚低耦合的设计原则。
|
||||
|
||||
**Section sources**
|
||||
- [Design.md](file://assets/script/Design.md#L0-L40)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L1-L150)
|
||||
|
||||
## 三选一奖励机制
|
||||
|
||||
三选一奖励机制是游戏的核心决策系统，其触发条件为每波怪物被全部击败后。当`MissionMonComp`组件检测到当前波次怪物全部死亡时，会触发`FightEnd`事件，进而启动奖励选择流程。
|
||||
|
||||
该机制的实现逻辑如下：
|
||||
1. 战斗结束时，`MissionComp`组件监听到`FightEnd`事件
|
||||
2. 收集本局战斗的奖励数据（金币、经验、钻石等）
|
||||
3. 构建奖励选项数组，通常包含三个不同强度的奖励
|
||||
4. 通过GUI系统打开胜利界面（Victory界面），并传递奖励数据
|
||||
5. 玩家在界面中选择一个奖励，系统应用对应效果
|
||||
|
||||
奖励选项的设计遵循"弱、一般、强"的梯度原则，不同选项消耗的金币数量不同，战力评分也不同，鼓励玩家进行策略性决策。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant MissionMonComp as MissionMonComp
|
||||
participant MissionComp as MissionComp
|
||||
participant VictoryComp as VictoryComp
|
||||
participant GUI as GUI系统
|
||||
MissionMonComp->>MissionComp : MonDead事件(最后一只怪物死亡)
|
||||
MissionComp->>MissionComp : 检查怪物数量是否为0
|
||||
MissionComp->>MissionComp : 触发FightEnd事件
|
||||
MissionComp->>MissionComp : 收集game_data(金币、经验等)
|
||||
MissionComp->>GUI : 打开Victory界面并传递数据
|
||||
GUI->>VictoryComp : 初始化奖励界面
|
||||
VictoryComp->>Player : 显示三个奖励选项
|
||||
Player->>VictoryComp : 选择奖励
|
||||
VictoryComp->>MissionComp : 应用所选奖励效果
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L23-L70)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L19-L37)
|
||||
- [MissionMonComp.ts](file://assets/script/game/map/MissionMonComp.ts#L102-L136)
|
||||
|
||||
## FightSet常量配置与奖励类型
|
||||
|
||||
`FightSet`枚举定义在`Mission.ts`文件中，包含了游戏的核心配置常量，其中与奖励系统直接相关的配置项包括：
|
||||
|
||||
- `GREEN_GOLD=1`：绿色金币，基础奖励单位
|
||||
- `BLUE_GOLD=2`：蓝色金币，中级奖励单位
|
||||
- `PURPLE_GOLD=3`：紫色金币，高级奖励单位
|
||||
- `ORANGE_GOLD=4`：橙色金币，稀有奖励单位
|
||||
- `ATK_ADD_GLOD=1`：伙伴攻击力增加对应的金币奖励值
|
||||
|
||||
这些常量定义了不同品质奖励的数值基准，系统根据这些基准值计算实际奖励数量。例如，普通怪物可能掉落`GREEN_GOLD`数量的金币，而精英怪物或Boss可能掉落`PURPLE_GOLD`或`ORANGE_GOLD`数量的金币。
|
||||
|
||||
此外，`FightSet`还定义了其他影响奖励获取的参数，如`MORE_RC=10`表示通过观看广告可获得的额外次数，这与奖励系统的双倍奖励功能相关联。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L35)
|
||||
|
||||
## 奖励数据结构与流程
|
||||
|
||||
### 数据结构分析
|
||||
|
||||
`MissionComp`组件中定义了两个关键数据结构：
|
||||
|
||||
1. **rewards数组**：用于存储掉落物品列表
|
||||
```typescript
|
||||
rewards:any[]=[]
|
||||
```
|
||||
|
||||
2. **game_data对象**：用于存储游戏数据
|
||||
```typescript
|
||||
game_data:any={
|
||||
exp:0,
|
||||
gold:0,
|
||||
diamond:0
|
||||
}
|
||||
```
|
||||
|
||||
`rewards`数组存储具体的物品奖励，如装备、技能书等；`game_data`对象则存储基础资源类奖励，包括经验值、金币和钻石。
|
||||
|
||||
### 奖励收集流程
|
||||
|
||||
奖励数据的收集与分发流程如下：
|
||||
|
||||
1. **初始化阶段**：在`data_init()`方法中，重置`rewards`数组和`game_data`对象
|
||||
2. **战斗阶段**：通过监听`MonDead`事件，逐步累积奖励数据
|
||||
3. **结束阶段**：当战斗结束时，将收集到的奖励数据传递给胜利界面
|
||||
|
||||
数据流从怪物死亡事件开始，经过`MissionComp`组件的收集处理，最终传递给`VictoryComp`组件进行展示，形成了完整的奖励数据流转闭环。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[怪物死亡] --> B{是否为最后一只}
|
||||
B --> |是| C[触发FightEnd事件]
|
||||
B --> |否| D[继续战斗]
|
||||
C --> E[收集奖励数据]
|
||||
E --> F[填充rewards数组和game_data]
|
||||
F --> G[打开Victory界面]
|
||||
G --> H[展示奖励选项]
|
||||
H --> I[玩家选择奖励]
|
||||
I --> J[应用奖励效果]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L23-L33)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L133-L135)
|
||||
|
||||
## 掉落处理与数据更新
|
||||
|
||||
`do_drop`方法是处理掉落物品和更新游戏数据的核心方法。该方法接收两个参数：`drop_item`数组和`game_data`对象，分别表示掉落的物品列表和基础资源奖励。
|
||||
|
||||
```typescript
|
||||
do_drop(drop_item:any[],game_data:any={exp:0,gold:0,diamond:0}){
|
||||
// console.log("[MissionComp] do_drop",drop_item,game_data)
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
虽然当前实现为空，但从方法签名可以看出其设计意图：
|
||||
- `drop_item`参数接收掉落的物品数组，可能包含装备、道具等
|
||||
- `game_data`参数接收基础资源奖励，默认值为零
|
||||
- 方法内部应实现将掉落物品添加到`rewards`数组，并将资源奖励累加到`game_data`对象中
|
||||
|
||||
在`MissionMonComp`组件中，可以找到实际的奖励发放逻辑。当关卡类型为"event"（事件关卡）时，会触发随机事件，其中`EventType.TREASURE`（宝藏事件）会直接增加50金币：
|
||||
```typescript
|
||||
switch (this.currentEvent) {
|
||||
case EventType.TREASURE:
|
||||
smc.vmdata.mission_data.gold += 50; // 增加50金币
|
||||
break;
|
||||
}
|
||||
```
|
||||
|
||||
这种设计模式表明，实际的奖励发放可能分散在多个组件中，最终由`MissionComp`统一收集和管理。
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L60-L63)
|
||||
- [MissionMonComp.ts](file://assets/script/game/map/MissionMonComp.ts#L145-L148)
|
||||
|
||||
## 奖励界面触发与数据传递
|
||||
|
||||
### 事件监听机制
|
||||
|
||||
`MissionComp`组件通过事件监听机制触发奖励界面的展示。在`onLoad`方法中，注册了对`FightEnd`事件的监听：
|
||||
|
||||
```typescript
|
||||
this.on(GameEvent.FightEnd,this.fight_end,this)
|
||||
```
|
||||
|
||||
当战斗结束时，`fight_end`方法会被调用，该方法通过`oops.gui.open`方法打开胜利界面，并传递奖励数据：
|
||||
|
||||
```typescript
|
||||
oops.gui.open(UIID.Victory,{victory:false,rewards:this.rewards,game_data:this.game_data})
|
||||
```
|
||||
|
||||
### 数据传递机制
|
||||
|
||||
数据传递通过`open`方法的参数实现，传递了三个关键数据：
|
||||
- `victory`：布尔值，表示战斗结果
|
||||
- `rewards`：奖励物品数组
|
||||
- `game_data`：基础资源数据对象
|
||||
|
||||
在`VictoryComp`组件的`onAdded`方法中接收这些数据：
|
||||
|
||||
```typescript
|
||||
onAdded(args: any) {
|
||||
if(args.game_data){
|
||||
this.game_data=args.game_data
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这种事件驱动的数据传递机制确保了组件间的松耦合，`MissionComp`只需关注奖励数据的收集，而`VictoryComp`只需关注奖励数据的展示，职责分离清晰。
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class MissionComp {
|
||||
+rewards : any[]
|
||||
+game_data : any
|
||||
+onLoad()
|
||||
+fight_end()
|
||||
+do_drop()
|
||||
}
|
||||
class VictoryComp {
|
||||
+rewards : any[]
|
||||
+game_data : any
|
||||
+onAdded(args)
|
||||
+victory_end()
|
||||
}
|
||||
class GameEvent {
|
||||
+FightEnd : "FightEnd"
|
||||
+MissionEnd : "MissionEnd"
|
||||
}
|
||||
class UIID {
|
||||
+Victory : 2
|
||||
}
|
||||
MissionComp --> GameEvent : "监听"
|
||||
MissionComp --> UIID : "使用"
|
||||
MissionComp --> VictoryComp : "传递数据"
|
||||
VictoryComp --> GameEvent : "触发"
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L23-L33)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L35-L37)
|
||||
- [GameEvent.ts](file://assets/script/game/common/config/GameEvent.ts#L43)
|
||||
- [GameUIConfig.ts](file://assets/script/game/common/config/GameUIConfig.ts#L30)
|
||||
|
||||
## 扩展新奖励类型
|
||||
|
||||
### 配置修改步骤
|
||||
|
||||
1. **在Mission.ts中添加常量**：在`FightSet`枚举中添加新的奖励类型常量
|
||||
```typescript
|
||||
NEW_REWARD_TYPE=5 // 新奖励类型
|
||||
```
|
||||
|
||||
2. **在RogueConfig.ts中定义事件**：如果涉及新事件类型，需在`EventType`枚举中添加
|
||||
```typescript
|
||||
NEW_EVENT = "new_event"
|
||||
```
|
||||
|
||||
3. **更新事件概率配置**：在`EventConfig`中添加新事件的触发概率
|
||||
|
||||
### 代码集成步骤
|
||||
|
||||
1. **修改MissionComp.ts**：
|
||||
- 在`game_data`对象中添加新奖励字段
|
||||
- 在`do_drop`方法中处理新奖励类型的逻辑
|
||||
- 确保`rewards`数组能正确存储新类型的奖励物品
|
||||
|
||||
2. **更新VictoryComp.ts**：
|
||||
- 在`onAdded`方法中处理新奖励数据
|
||||
- 更新界面展示逻辑以支持新奖励类型的显示
|
||||
|
||||
3. **添加事件处理**：在`MissionMonComp`或相关组件中添加对新奖励事件的处理逻辑
|
||||
|
||||
4. **更新UI配置**：确保GUI系统能正确加载和显示新奖励类型的界面元素
|
||||
|
||||
通过以上步骤，可以无缝集成新的奖励类型，系统的设计具有良好的扩展性，新增奖励类型不会影响现有功能的稳定性。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L35)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts#L47-L86)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L23-L70)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L19-L37)
|
||||
177
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励触发机制.md
Normal file
177
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励触发机制.md
Normal file
@@ -0,0 +1,177 @@
|
||||
# 奖励触发机制
|
||||
|
||||
<cite>
|
||||
**本文档引用的文件**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [GameEvent.ts](file://assets/script/game/common/config/GameEvent.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
- [MissionHeroComp.ts](file://assets/script/game/map/MissionHeroComp.ts)
|
||||
- [HeroViewComp.ts](file://assets/script/game/hero/HeroViewComp.ts)
|
||||
- [Mon.ts](file://assets/script/game/hero/Mon.ts)
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts)
|
||||
</cite>
|
||||
|
||||
## 目录
|
||||
1. [简介](#简介)
|
||||
2. [事件监听注册机制](#事件监听注册机制)
|
||||
3. [战斗事件响应逻辑](#战斗事件响应逻辑)
|
||||
4. [奖励发放触发流程](#奖励发放触发流程)
|
||||
5. [失败情况下的奖励处理](#失败情况下的奖励处理)
|
||||
6. [事件派发与数据更新链条](#事件派发与数据更新链条)
|
||||
7. [常见异常排查方案](#常见异常排查方案)
|
||||
8. [结论](#结论)
|
||||
|
||||
## 简介
|
||||
本文档深入分析基于事件驱动的奖励触发机制，重点解析`MissionComp.ts`中`onLoad`方法注册的事件监听器。详细说明`do_mon_dead`、`do_hero_dead`等方法如何响应战斗事件并累积奖励数据，以及`fight_end`和`to_end_fight`方法中奖励发放的触发时机与条件判断逻辑。
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L1-L20)
|
||||
|
||||
## 事件监听注册机制
|
||||
在`MissionComp`组件的`onLoad`方法中，系统注册了多个关键的游戏事件监听器，包括`GameEvent.FightEnd`、`GameEvent.MonDead`、`GameEvent.HeroDead`等。这些监听器构成了奖励触发系统的核心基础，确保在特定游戏事件发生时能够及时响应并执行相应的奖励逻辑。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[onLoad] --> B[注册GameEvent.MissionStart]
|
||||
A --> C[注册GameEvent.MonDead]
|
||||
A --> D[注册GameEvent.HeroDead]
|
||||
A --> E[注册GameEvent.FightEnd]
|
||||
A --> F[注册GameEvent.MissionEnd]
|
||||
A --> G[注册GameEvent.DO_AD_BACK]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L15-L21)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L15-L21)
|
||||
- [GameEvent.ts](file://assets/script/game/common/config/GameEvent.ts#L1-L70)
|
||||
|
||||
## 战斗事件响应逻辑
|
||||
当怪物死亡或英雄死亡事件发生时，系统会通过相应的事件处理器更新战斗状态数据。`do_mon_dead`方法在接收到`GameEvent.MonDead`事件后，会减少当前关卡中的怪物数量计数；而`do_hero_dead`方法在处理`GameEvent.HeroDead`事件时，会减少英雄数量，并在英雄全部阵亡时触发战斗结束事件。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Mon as 怪物
|
||||
participant HeroViewComp as HeroViewComp
|
||||
participant MissionComp as MissionComp
|
||||
Mon->>HeroViewComp : 被击败
|
||||
HeroViewComp->>HeroViewComp : do_dead()
|
||||
HeroViewComp->>HeroViewComp : 调度HeroDead事件
|
||||
HeroViewComp->>MissionComp : dispatchEvent(GameEvent.HeroDead)
|
||||
MissionComp->>MissionComp : do_hero_dead()
|
||||
MissionComp->>MissionComp : 更新英雄数量
|
||||
MissionComp->>MissionComp : 检查是否全部阵亡
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [HeroViewComp.ts](file://assets/script/game/hero/HeroViewComp.ts#L570-L580)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L58-L67)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L58-L67)
|
||||
- [HeroViewComp.ts](file://assets/script/game/hero/HeroViewComp.ts#L570-L580)
|
||||
|
||||
## 奖励发放触发流程
|
||||
奖励发放的触发主要通过`fight_end`和`to_end_fight`方法实现。当战斗结束条件满足时，系统会调度`GameEvent.FightEnd`事件，进而触发`fight_end`方法执行。该方法会在0.5秒延迟后清理战斗组件并重置游戏状态，确保奖励发放过程的稳定性和完整性。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[战斗结束条件满足] --> B[dispatchEvent(FightEnd)]
|
||||
B --> C[fight_end方法执行]
|
||||
C --> D[延迟0.5秒]
|
||||
D --> E[设置smc.mission.play=false]
|
||||
D --> F[设置smc.mission.pause=false]
|
||||
D --> G[cleanComponents()]
|
||||
G --> H[销毁HeroViewComp]
|
||||
G --> I[销毁AtkConCom]
|
||||
G --> J[销毁SkillViewCom]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L99-L114)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L99-L114)
|
||||
|
||||
## 失败情况下的奖励处理
|
||||
在战斗失败的情况下，系统会通过`do_hero_dead`方法中的逻辑判断来处理奖励。当英雄数量减至零或以下时，系统会立即派发`GameEvent.FightEnd`事件，并携带`{victory:false}`参数，同时打开胜利/失败界面，传递当前累积的奖励数据和游戏数据。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[英雄死亡] --> B[do_hero_dead执行]
|
||||
B --> C[英雄数量减1]
|
||||
C --> D{英雄数量<=0?}
|
||||
D --> |是| E[派发FightEnd事件]
|
||||
D --> |否| F[继续战斗]
|
||||
E --> G[打开胜利界面]
|
||||
G --> H[传递rewards数组]
|
||||
G --> I[传递game_data对象]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L62-L67)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L62-L67)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L1-L74)
|
||||
|
||||
## 事件派发与数据更新链条
|
||||
整个奖励触发系统依赖于清晰的事件派发与数据更新链条。从怪物死亡到最终奖励展示，每个环节都有明确的数据流转路径。系统使用`smc.vmdata.mission_data`作为共享数据存储，确保各个组件之间能够同步最新的战斗状态信息。
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
MONSTER ||--o{ MISSION_DATA : "死亡时"
|
||||
HERO ||--o{ MISSION_DATA : "死亡时"
|
||||
MISSION_DATA ||--o{ REWARDS : "累积"
|
||||
MISSION_DATA ||--o{ GAME_DATA : "累积"
|
||||
REWARDS ||--o{ VICTORY_UI : "显示"
|
||||
GAME_DATA ||--o{ VICTORY_UI : "显示"
|
||||
class MISSION_DATA {
|
||||
int mon_num
|
||||
int hero_num
|
||||
float fight_time
|
||||
int level
|
||||
}
|
||||
class REWARDS {
|
||||
array rewards[]
|
||||
}
|
||||
class GAME_DATA {
|
||||
int exp
|
||||
int gold
|
||||
int diamond
|
||||
}
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L23-L24)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L19-L20)
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L23-L24)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L19-L20)
|
||||
|
||||
## 常见异常排查方案
|
||||
在实际运行过程中，可能会遇到一些常见的异常情况。以下是针对这些异常的排查方案：
|
||||
|
||||
1. **事件未正确触发**：检查事件名称是否拼写正确，确认事件监听器是否已正确注册。
|
||||
2. **奖励数据丢失**：验证`rewards`数组和`game_data`对象的初始化时机，确保在战斗开始前已完成初始化。
|
||||
3. **界面显示异常**：检查`VictoryComp`组件的`onAdded`方法中数据接收逻辑，确保参数传递正确。
|
||||
4. **性能问题**：监控`update`方法的执行频率，避免不必要的计算开销。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[问题现象] --> B{问题类型}
|
||||
B --> |事件问题| C[检查事件名称]
|
||||
B --> |数据问题| D[检查数据初始化]
|
||||
B --> |界面问题| E[检查参数传递]
|
||||
B --> |性能问题| F[优化update逻辑]
|
||||
```
|
||||
|
||||
**Section sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L133-L135)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L32-L33)
|
||||
|
||||
## 结论
|
||||
通过对`MissionComp.ts`中奖励触发逻辑的深入分析，我们了解到该系统采用事件驱动架构，通过注册和监听关键游戏事件来实现奖励的累积和发放。系统设计合理，各组件职责分明，数据流转清晰，为游戏的战斗奖励机制提供了可靠的支撑。
|
||||
234
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励配置.md
Normal file
234
.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励配置.md
Normal file
@@ -0,0 +1,234 @@
|
||||
# 奖励配置
|
||||
|
||||
<cite>
|
||||
**本文档引用文件**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts)
|
||||
- [RogueConfig.ts](file://assets/script/game/map/RogueConfig.ts)
|
||||
- [HeroAttrs.ts](file://assets/script/game/common/config/HeroAttrs.ts)
|
||||
</cite>
|
||||
|
||||
## 目录
|
||||
1. [奖励配置概述](#奖励配置概述)
|
||||
2. [FightSet枚举中的奖励配置项](#fightset枚举中的奖励配置项)
|
||||
3. [常量在奖励机制中的作用](#常量在奖励机制中的作用)
|
||||
4. [奖励平衡性调整方法](#奖励平衡性调整方法)
|
||||
5. [新增奖励类型的配置方法](#新增奖励类型的配置方法)
|
||||
6. [配置数据与运行时逻辑的映射关系](#配置数据与运行时逻辑的映射关系)
|
||||
7. [配置变更的正确加载机制](#配置变更的正确加载机制)
|
||||
|
||||
## 奖励配置概述
|
||||
|
||||
本节详细解析Mission.ts文件中FightSet枚举的奖励相关配置项，包括金币、经验、钻石的数值定义与获取规则。同时解释TAL_NUM天赋数量、MORE_RC广告奖励次数等常量在奖励机制中的作用，并提供修改FightSet常量调整奖励平衡性的方法。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
|
||||
## FightSet枚举中的奖励配置项
|
||||
|
||||
FightSet枚举定义了游戏中各种奖励相关的配置项，主要包括：
|
||||
|
||||
- **金币奖励配置**：
|
||||
- GREEN_GOLD=1：绿色金币的数值定义
|
||||
- BLUE_GOLD=2：蓝色金币的数值定义
|
||||
- PURPLE_GOLD=3：紫色金币的数值定义
|
||||
- ORANGE_GOLD=4：橙色金币的数值定义
|
||||
|
||||
- **经验奖励**：
|
||||
- ATK_ADD_GLOD=1：攻击增加金币的数量
|
||||
|
||||
- **钻石奖励**：
|
||||
- 通过广告获取的钻石奖励次数由MORE_RC常量控制
|
||||
|
||||
这些配置项在游戏运行时被用于计算玩家完成任务后获得的奖励数量。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L35)
|
||||
|
||||
## 常量在奖励机制中的作用
|
||||
|
||||
### TAL_NUM天赋数量
|
||||
|
||||
TAL_NUM=3定义了玩家可选择的天赋数量。这个常量直接影响玩家在游戏中的成长路径和策略选择，是奖励机制中的重要组成部分。
|
||||
|
||||
### MORE_RC广告奖励次数
|
||||
|
||||
MORE_RC=10定义了通过观看广告可以获得的额外奖励次数。这个常量控制着玩家通过广告获取奖励的频率和数量，是游戏内经济系统的重要调节参数。
|
||||
|
||||
### 其他相关常量
|
||||
|
||||
- ATK_ADD_COUNT=4：伙伴攻击力增加的数量
|
||||
- CRIT_DAMAGE=50：暴击伤害的百分比
|
||||
- ONE_WAVE_TIME=30：单波次的时间长度
|
||||
|
||||
这些常量共同构成了游戏奖励机制的基础框架。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
|
||||
## 奖励平衡性调整方法
|
||||
|
||||
通过修改FightSet常量可以调整游戏的奖励平衡性：
|
||||
|
||||
### 调整金币奖励
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始] --> B[修改FightSet中的金币常量]
|
||||
B --> C[GREEN_GOLD=1 -> 2]
|
||||
B --> D[BLUE_GOLD=2 -> 3]
|
||||
B --> E[PURPLE_GOLD=3 -> 4]
|
||||
B --> F[ORANGE_GOLD=4 -> 5]
|
||||
C --> G[增加金币获取速度]
|
||||
D --> G
|
||||
E --> G
|
||||
F --> G
|
||||
G --> H[测试游戏平衡性]
|
||||
H --> I[根据反馈进一步调整]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L35)
|
||||
|
||||
### 调整经验获取
|
||||
|
||||
通过调整ATK_ADD_GLOD等常量可以改变玩家获取经验的速度，从而影响游戏进度和难度曲线。
|
||||
|
||||
### 调整广告奖励
|
||||
|
||||
修改MORE_RC常量可以控制玩家通过广告获取奖励的次数，影响游戏内购和广告收入的平衡。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L66-L70)
|
||||
|
||||
## 新增奖励类型的配置方法
|
||||
|
||||
### 添加新的奖励类型
|
||||
|
||||
要在游戏中新增奖励类型，需要执行以下步骤：
|
||||
|
||||
1. 在FightSet枚举中添加新的奖励常量
|
||||
2. 在游戏逻辑中添加对新奖励类型的处理
|
||||
3. 在UI界面中添加新奖励类型的显示
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class FightSet {
|
||||
+GREEN_GOLD : number
|
||||
+BLUE_GOLD : number
|
||||
+PURPLE_GOLD : number
|
||||
+ORANGE_GOLD : number
|
||||
+NEW_REWARD_TYPE : number
|
||||
}
|
||||
class MissionComp {
|
||||
+rewards : any[]
|
||||
+game_data : any
|
||||
+do_drop(drop_item[], game_data) : void
|
||||
}
|
||||
class VictoryComp {
|
||||
+rewards : any[]
|
||||
+game_data : any
|
||||
+onAdded(args) : void
|
||||
}
|
||||
FightSet --> MissionComp : "使用"
|
||||
FightSet --> VictoryComp : "使用"
|
||||
MissionComp --> VictoryComp : "传递数据"
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L74)
|
||||
|
||||
### 特殊道具奖励配置
|
||||
|
||||
要添加特殊道具作为奖励，可以在FightSet枚举中添加新的常量，例如：
|
||||
|
||||
- SPECIAL_ITEM_1=5：特殊道具1的标识
|
||||
- SPECIAL_ITEM_2=6：特殊道具2的标识
|
||||
|
||||
然后在奖励发放逻辑中处理这些新的奖励类型。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L47-L50)
|
||||
|
||||
## 配置数据与运行时逻辑的映射关系
|
||||
|
||||
### 数据流分析
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant MissionComp as MissionComp
|
||||
participant SingletonModuleComp as SingletonModuleComp
|
||||
participant VictoryComp as VictoryComp
|
||||
participant UI as UI界面
|
||||
MissionComp->>SingletonModuleComp : 更新smc.vmdata.mission_data
|
||||
SingletonModuleComp->>VictoryComp : 传递game_data和rewards
|
||||
VictoryComp->>UI : 显示奖励信息
|
||||
UI->>SingletonModuleComp : 确认奖励领取
|
||||
SingletonModuleComp->>MissionComp : 更新全局数据
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts#L0-L41)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L74)
|
||||
|
||||
### 配置数据的使用
|
||||
|
||||
FightSet枚举中的常量在多个组件中被引用：
|
||||
|
||||
- MissionComp使用这些常量来计算奖励
|
||||
- VictoryComp使用这些常量来显示奖励信息
|
||||
- SingletonModuleComp使用这些常量来存储全局游戏数据
|
||||
|
||||
这种设计实现了配置数据与运行时逻辑的分离，便于维护和调整。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L74)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts#L0-L41)
|
||||
|
||||
## 配置变更的正确加载机制
|
||||
|
||||
### 配置加载流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[游戏启动] --> B[加载Mission.ts配置]
|
||||
B --> C[初始化FightSet常量]
|
||||
C --> D[创建SingletonModuleComp实例]
|
||||
D --> E[初始化smc.vmdata.mission_data]
|
||||
E --> F[MissionComp引用FightSet常量]
|
||||
F --> G[游戏运行时使用配置]
|
||||
G --> H[配置变更]
|
||||
H --> I[重新加载配置]
|
||||
I --> J[更新所有相关组件]
|
||||
J --> K[应用新配置]
|
||||
```
|
||||
|
||||
**Diagram sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts#L0-L41)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
|
||||
### 确保配置正确加载
|
||||
|
||||
为确保配置变更在游戏中正确加载，需要遵循以下原则：
|
||||
|
||||
1. 所有组件都应从SingletonModuleComp获取全局数据
|
||||
2. 配置变更后需要通知所有相关组件更新
|
||||
3. 使用事件机制（如oops.message）来同步配置变更
|
||||
|
||||
通过这些机制，可以确保配置变更能够正确地应用到游戏的所有部分。
|
||||
|
||||
**Section sources**
|
||||
- [Mission.ts](file://assets/script/game/common/config/Mission.ts#L0-L59)
|
||||
- [SingletonModuleComp.ts](file://assets/script/game/common/SingletonModuleComp.ts#L0-L41)
|
||||
- [MissionComp.ts](file://assets/script/game/map/MissionComp.ts#L0-L150)
|
||||
- [VictoryComp.ts](file://assets/script/game/map/VictoryComp.ts#L0-L74)
|
||||
Reference in New Issue
Block a user