pixelheros/.qoder/repowiki/zh/content/奖励系统/奖励机制/奖励触发机制.md

奖励触发机制

**本文档引用的文件** - [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)

目录

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

事件监听注册机制

在MissionComp组件的onLoad方法中，系统注册了多个关键的游戏事件监听器，包括GameEvent.FightEnd、GameEvent.MonDead、GameEvent.HeroDead等。这些监听器构成了奖励触发系统的核心基础，确保在特定游戏事件发生时能够及时响应并执行相应的奖励逻辑。

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

Section sources

• MissionComp.ts
• GameEvent.ts

战斗事件响应逻辑

当怪物死亡或英雄死亡事件发生时，系统会通过相应的事件处理器更新战斗状态数据。do_mon_dead方法在接收到GameEvent.MonDead事件后，会减少当前关卡中的怪物数量计数；而do_hero_dead方法在处理GameEvent.HeroDead事件时，会减少英雄数量，并在英雄全部阵亡时触发战斗结束事件。

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
• MissionComp.ts

Section sources

• MissionComp.ts
• HeroViewComp.ts

奖励发放触发流程

奖励发放的触发主要通过fight_end和to_end_fight方法实现。当战斗结束条件满足时，系统会调度GameEvent.FightEnd事件，进而触发fight_end方法执行。该方法会在0.5秒延迟后清理战斗组件并重置游戏状态，确保奖励发放过程的稳定性和完整性。

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

Section sources

• MissionComp.ts

失败情况下的奖励处理

在战斗失败的情况下，系统会通过do_hero_dead方法中的逻辑判断来处理奖励。当英雄数量减至零或以下时，系统会立即派发GameEvent.FightEnd事件，并携带{victory:false}参数，同时打开胜利/失败界面，传递当前累积的奖励数据和游戏数据。

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

Section sources

• MissionComp.ts
• VictoryComp.ts

事件派发与数据更新链条

整个奖励触发系统依赖于清晰的事件派发与数据更新链条。从怪物死亡到最终奖励展示，每个环节都有明确的数据流转路径。系统使用smc.vmdata.mission_data作为共享数据存储，确保各个组件之间能够同步最新的战斗状态信息。

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
• VictoryComp.ts

Section sources

• MissionComp.ts
• VictoryComp.ts

常见异常排查方案

在实际运行过程中，可能会遇到一些常见的异常情况。以下是针对这些异常的排查方案：

1. 事件未正确触发：检查事件名称是否拼写正确，确认事件监听器是否已正确注册。
2. 奖励数据丢失：验证rewards数组和game_data对象的初始化时机，确保在战斗开始前已完成初始化。
3. 界面显示异常：检查VictoryComp组件的onAdded方法中数据接收逻辑，确保参数传递正确。
4. 性能问题：监控update方法的执行频率，避免不必要的计算开销。

flowchart LR
A[问题现象] --> B{问题类型}
B --> |事件问题| C[检查事件名称]
B --> |数据问题| D[检查数据初始化]
B --> |界面问题| E[检查参数传递]
B --> |性能问题| F[优化update逻辑]

Section sources

• MissionComp.ts
• VictoryComp.ts

结论

通过对MissionComp.ts中奖励触发逻辑的深入分析，我们了解到该系统采用事件驱动架构，通过注册和监听关键游戏事件来实现奖励的累积和发放。系统设计合理，各组件职责分明，数据流转清晰，为游戏的战斗奖励机制提供了可靠的支撑。