Unity实战：事件驱动的组合条件检测系统设计与实现

之前在游戏项目里接到一个交互需求，玩家需要在关卡中收集“果冻”和“红宝石”两类物品，当某种组合条件达成时，系统要自动检测并触发隐藏奖励。比如这里说的“检测到双果冻双红宝石”，翻译成开发语言就是：玩家的当前数据中同时存在两颗果冻、两颗红宝石时，事件系统要检测到这个状态，并执行后续逻辑。

初看这只是一个简单的数量判断，但真正落地时你会发现，它牵涉到物品数据的存储、变化通知、条件判定、重复触发控制、事件解耦等多个环节。如果直接把if写在业务逻辑里，后续每增加一个组合条件，就要改一片代码，排查起来也很痛苦。这篇文章就围绕“检测到双果冻双红宝石”这类组合条件需求，拆解一套通用的事件检测方案，并用 C# 和 Unity 环境实现一个可运行的实战示例。

无论你是刚接触游戏逻辑开发的新手，还是需要在现有项目中加入成就、合成、隐藏条件系统的开发者，这篇文章都能给你一个可以直接复用的实现思路。

1. 背景与核心概念

1.1 “双果冻双红宝石”本质是什么

很多看起来像策划文案的需求，落到底层都是一种“组合条件检测”。所谓“双果冻双红宝石”，核心包含两个维度：

• 物品种类：果冻、红宝石，分别代表两种不同的资源。
• 数量阈值：“双”代表每个种类的数量至少为 2。

所以需求本身可以描述为：

当 itemCount[Jelly] >= 2 且 itemCount[Ruby] >= 2 时，触发事件。

从技术角度，只要玩家背包中的物品数量发生变化，我们就要重新检查所有组合条件。满足条件时触发对应事件，不满足时不做额外处理。

1.2 这类需求的常见应用场景

在实际游戏项目中，下面这些玩法都会用到类似逻辑：

• 成就系统：玩家收集到 X 个物品 A、Y 个物品 B，解锁成就。
• 合成系统：当背包同时拥有若干材料，解锁合成按钮或自动合成。
• 隐藏关卡解锁：满足特定组合条件后，地图上出现隐藏入口。
• 任务目标进度：任务要求玩家“获得 2 个果冻、2 个红宝石”，界面需要实时刷新进度。
• 商店促销条件：持有特定道具组合时，解锁折扣购买权限。

这些场景的共同点是：条件不是单一物品的数量判断，而是多个物品的组合判断，而且需要响应数据变化。

1.3 为什么要单独做一个检测系统

也许有人会说，这个需求用一个if不就行了吗？

if (backpack.GetCount(ItemType.Jelly) >= 2 && backpack.GetCount(ItemType.Ruby) >= 2) { // 触发逻辑 }

确实，如果只有这一处逻辑，这样写没问题。但项目一旦变大，问题就会暴露出来：

1. 条件散落：每个需要判断的地方都写一遍相同逻辑，改数量阈值要全局搜索。
2. 触发时机难控制：物品变化可能来自拾取、商店购买、任务奖励、战斗掉落，你很难在所有入口都补上判断代码。
3. 重复触发风险：如果不记录上一次状态，玩家只要一直停留在达标状态，事件就会被反复执行。
4. 扩展性差：今天要检测“双果冻双红宝石”，明天还要检测“三宝石两水晶”，每加一个条件都动业务代码。

因此，更好的做法是把“物品数据”和“条件检测”拆开，做成一个独立的检测器，由数据变更事件驱动。这样业务层只需要关心“收到通知后怎么做”，而不需要关心“什么时候该检测”。

2. 环境准备与实现思路

本文的示例以 C# 和 Unity 作为演示环境。核心检测逻辑本身不依赖 Unity API，所以你可以直接把它放到纯 C# 控制台项目中运行，也可以封装成 Unity 脚本挂在场景里。

• 开发工具：Visual Studio 2022 或 Visual Studio Code
• 运行环境：.NET 6 / .NET 8，或者 Unity 2021 LTS 及以上
• 编程语言：C#
• 示例类型：控制台模拟 + Unity 挂载脚本

版本不需要完全照搬，因为核心用到的都是 C# 基础集合和事件委托，在大部分现代版本中都可以直接编译运行。重点是理解设计思路，版本差异影响不大。

整体设计分成三个模块：

这样的分层好处很明显：背包只负责数据存储，检测器只负责条件判断，业务逻辑写在外部监听方法里面。三者不互相耦合，后期替换存储方式、增加条件都非常方便。

3. 核心数据结构设计

3.1 物品类型枚举

首先定义物品类型。示例中先用“果冻”和“红宝石”两类，但为了便于扩展，可以预留几个占位类型。

// 文件路径：Models/ItemType.cs public enum ItemType { None = 0, Jelly = 1, Ruby = 2, Coin = 3, Crystal = 4 }

None作为默认空值可以避免变量未初始化的问题，实际项目中如果物品很多，也可以改成字符串 ID 或配置表 ID。

3.2 背包数据类

背包的核心职责是维护一个Dictionary<ItemType, int>映射表，记录每个物品类型的当前数量。对外提供增加、移除、查询、快照等方法。

这里要注意一个设计细节：背包不负责触发“双果冻双红宝石”这种具体条件。它只维护数据本身，并通过事件把“数据变了”这个信号发出去。

// 文件路径：Managers/BackpackManager.cs using System; using System.Collections.Generic; public class BackpackManager { private readonly Dictionary<ItemType, int> _itemCounts = new Dictionary<ItemType, int>(); /// <summary> /// 物品数量变化时触发，参数分别为物品类型和最新数量。 /// </summary> public event Action<ItemType, int> OnItemChanged; /// <summary> /// 增加物品数量。 /// </summary> public void AddItem(ItemType type, int amount = 1) { if (type == ItemType.None || amount <= 0) { return; } if (!_itemCounts.ContainsKey(type)) { _itemCounts[type] = 0; } _itemCounts[type] += amount; OnItemChanged?.Invoke(type, _itemCounts[type]); } /// <summary> /// 移除物品数量。数量不足时不做扣除，并返回 false。 /// </summary> public bool RemoveItem(ItemType type, int amount = 1) { if (type == ItemType.None || amount <= 0) { return false; } if (!_itemCounts.ContainsKey(type) || _itemCounts[type] < amount) { return false; } _itemCounts[type] -= amount; OnItemChanged?.Invoke(type, _itemCounts[type]); return true; } /// <summary> /// 获取指定物品的当前数量。 /// </summary> public int GetCount(ItemType type) { if (type == ItemType.None) { return 0; } _itemCounts.TryGetValue(type, out int count); return count; } /// <summary> /// 获取物品数量的快照，避免外部直接修改内部字典。 /// </summary> public Dictionary<ItemType, int> Snapshot() { return new Dictionary<ItemType, int>(_itemCounts); } }

几个值得注意的地方：

• 移除物品时先校验数量，避免出现负数。
• 数据变化后统一调用OnItemChanged，这样检测器只需要监听这一个事件。
• Snapshot()返回的是副本，外部无法直接改动内部数据。

4. 编写组合条件检测器

4.1 检测器的基础框架

CombinationDetector是本文的核心。它本身不关心业务具体逻辑，只负责一件事：判断目标物品数量是否达标，并在状态发生变化时通知外部。

先定义一个条件描述类，用来表达“需要哪些物品，各需要多少个”。

// 文件路径：Core/ItemCondition.cs using System.Collections.Generic; /// <summary> /// 组合条件：例如“双果冻双红宝石” /// </summary> public class ItemCondition { /// <summary> /// 条件名称，便于日志输出。 /// </summary> public string ConditionName { get; set; } /// <summary> /// 需要的物品类型和对应数量。 /// </summary> public Dictionary<ItemType, int> RequiredItems { get; set; } = new Dictionary<ItemType, int>(); }

然后是检测器类：

// 文件路径：Core/CombinationDetector.cs using System; using System.Collections.Generic; public class CombinationDetector { private readonly ItemCondition _condition; private bool _wasTriggered; /// <summary> /// 条件从未达标变为达标时触发。 /// </summary> public event Action<ItemCondition> OnConditionMatched; /// <summary> /// 条件从达标变为不达标时触发。 /// </summary> public event Action<ItemCondition> OnConditionLost; public CombinationDetector(ItemCondition condition) { _condition = condition; } /// <summary> /// 根据背包数据检查条件是否满足。建议在背包变化事件中调用。 /// </summary> public void ForceCheck(BackpackManager backpack) { bool isSatisfied = IsConditionMatched(backpack); if (isSatisfied && !_wasTriggered) { // 从未达标变成达标 _wasTriggered = true; OnConditionMatched?.Invoke(_condition); } else if (!isSatisfied && _wasTriggered) { // 从达标变成不达标 _wasTriggered = false; OnConditionLost?.Invoke(_condition); } } private bool IsConditionMatched(BackpackManager backpack) { foreach (KeyValuePair<ItemType, int> pair in _condition.RequiredItems) { int currentCount = backpack.GetCount(pair.Key); if (currentCount < pair.Value) { return false; } } return true; } /// <summary> /// 重置状态，用于玩家进入新关卡时恢复初始状态。 /// </summary> public void Reset() { _wasTriggered = false; } }

这个实现最重要的地方是_wasTriggered状态标记。它确保了：

• 玩家一直持有双果冻双红宝石时，事件只触发一次，不会因为每次背包变化都触发。
• 当玩家消耗掉部分物品、条件不再满足后，状态会被重置，下次再收集又不会再次触发。

如果你需要“持续输出进度”而不是“只触发一次”，可以在外层另加一个进度条监听，不做门槛判断，而是直接展示当前数量。

4.2 把检测器接入背包事件

检测器写好了，现在要把它和背包关联起来。最简单的做法是订阅背包的OnItemChanged事件，然后在回调里调用ForceCheck。

这里我把整个流程封装成一个管理器，用来统一配置多个条件：

// 文件路径：Managers/ConditionManager.cs using System; using System.Collections.Generic; public class ConditionManager { private readonly BackpackManager _backpack; private readonly List<CombinationDetector> _detectors = new List<CombinationDetector>(); public ConditionManager(BackpackManager backpack) { _backpack = backpack; _backpack.OnItemChanged += HandleItemChanged; } /// <summary> /// 注册一个组合条件。 /// </summary> public void AddCondition(ItemCondition condition) { var detector = new CombinationDetector(condition); detector.OnConditionMatched += HandleConditionMatched; detector.OnConditionLost += HandleConditionLost; _detectors.Add(detector); // 注册后先立即检测一次，避免错过初始状态 detector.ForceCheck(_backpack); } /// <summary> /// 清空所有条件，并在销毁时取消事件订阅。 /// </summary> public void Clear() { foreach (CombinationDetector detector in _detectors) { detector.OnConditionMatched -= HandleConditionMatched; detector.OnConditionLost -= HandleConditionLost; } _detectors.Clear(); _backpack.OnItemChanged -= HandleItemChanged; } private void HandleItemChanged(ItemType type, int newCount) { // 只要物品数量发生变化，就重新检查所有条件 foreach (CombinationDetector detector in _detectors) { detector.ForceCheck(_backpack); } } private void HandleConditionMatched(ItemCondition condition) { // 外部可以订阅这个事件，由业务层决定触发什么功能 Console.WriteLine($"[条件达成] {condition.ConditionName}"); } private void HandleConditionLost(ItemCondition condition) { Console.WriteLine($"[条件失效] {condition.ConditionName}"); } }

这样设计后，业务层只需要在开始时注册一次条件，之后所有判断和触发都是自动的。后面要新增“三宝石两水晶”之类的条件，也只需要往ConditionManager里添加新的ItemCondition，不需要改动背包和检测器代码。

4.3 使用一组代码模拟整个流程

为了让读者可以直接看到效果，我写了一个不带 Unity 依赖的控制台示例，完整模拟从 0 收集到触发事件的流程。

// 文件路径：Program.cs using System; using System.Collections.Generic; class Program { static void Main(string[] args) { // 1. 创建背包 var backpack = new BackpackManager(); // 2. 创建条件管理器 var conditionManager = new ConditionManager(backpack); // 3. 注册“双果冻双红宝石”条件 var condition = new ItemCondition { ConditionName = "双果冻双红宝石", RequiredItems = new Dictionary<ItemType, int> { { ItemType.Jelly, 2 }, { ItemType.Ruby, 2 } } }; conditionManager.AddCondition(condition); // 4. 模拟玩家拾取道具 Console.WriteLine("=== 模拟拾取过程 ==="); backpack.AddItem(ItemType.Jelly, 1); backpack.AddItem(ItemType.Ruby, 1); backpack.AddItem(ItemType.Jelly, 1); backpack.AddItem(ItemType.Ruby, 1); // 此时果冻=2，红宝石=2，条件应当第一次达成 Console.WriteLine("\n=== 模拟使用道具导致条件不满足 ==="); backpack.RemoveItem(ItemType.Jelly, 1); // 此时果冻=1，红宝石=2，条件不满足 Console.WriteLine("\n=== 再次收集到双果冻双红宝石 ==="); backpack.AddItem(ItemType.Jelly, 1); // 此时果冻=2，红宝石=2，条件第二次达成 Console.WriteLine("\n=== 清理 ==="); conditionManager.Clear(); } }

预期输出结果如下：

=== 模拟拾取过程 === [条件达成] 双果冻双红宝石 === 模拟使用道具导致条件不满足 === [条件失效] 双果冻双红宝石 === 再次收集到双果冻双红宝石 === [条件达成] 双果冻双红宝石 === 清理 ===

从输出可以看到，条件在第一次达成时触发一次，在中间失去条件时触发失效，再次达成时又可以重新触发。这正是实际项目中比较合理的行为。

5. Unity 场景中的实战改造

控制台示例验证了核心逻辑，接下来把它接入 Unity 项目。下面这份脚本演示了如何在场景中挂载检测组件，并用 UI 文本显示检测状态。

5.1 挂载脚本

// 文件路径：Assets/Scripts/DoubleJellyRubyDetector.cs using UnityEngine; using UnityEngine.UI; using System.Collections.Generic; public class DoubleJellyRubyDetector : MonoBehaviour { [Header("背包")] public BackpackManager backpack; [Header("UI")] public Text statusText; private ConditionManager _conditionManager; private void Start() { if (backpack == null) { backpack = gameObject.AddComponent<BackpackManager>(); } _conditionManager = new ConditionManager(backpack); var condition = new ItemCondition { ConditionName = "双果冻双红宝石", RequiredItems = new Dictionary<ItemType, int> { { ItemType.Jelly, 2 }, { ItemType.Ruby, 2 } } }; _conditionManager.AddCondition(condition); UpdateStatus(); } public void AddJelly() { backpack.AddItem(ItemType.Jelly, 1); UpdateStatus(); } public void AddRuby() { backpack.AddItem(ItemType.Ruby, 1); UpdateStatus(); } private void UpdateStatus() { if (statusText != null) { statusText.text = $"果冻:{backpack.GetCount(ItemType.Jelly)} 红宝石:{backpack.GetCount(ItemType.Ruby)}"; } } private void OnDestroy() { _conditionManager?.Clear(); } }

在 Unity 编辑器中新建两个 Button，分别绑定AddJelly和AddRuby方法，再拖一个 UI Text 到statusText字段，运行后点击按钮就能看到数量和条件触发的日志。

5.2 为什么要在 OnDestroy 中清理

Unity 脚本销毁时，如果不取消事件订阅，这个脚本持有的ConditionManager可能仍然被背包对象引用，导致内存泄漏。尤其是场景切换时，静态单例和跨场景对象最容易踩这个坑。

在实际项目中，如果有更复杂的依赖注入框架，也应该在对象销毁或者模块卸载时统一回收所有事件订阅。

6. 常见问题与排查思路

下面整理了实现“双果冻双红宝石”检测功能时最容易遇到的几个问题，以及排查方向。

排查时建议先看日志中物品数量变化是否正常，再确认OnItemChanged是否被触发，最后检查组合检测器是否进入了“已触发”状态。

7. 工程建议与扩展方向

7.1 把条件配置做成可配置数据

演示代码中条件写在Start方法里，方便理解。真正的项目里，更推荐把条件放在 ScriptableObject、Excel 表或 JSON 配置中，方便策划调整，不需要频繁改代码。

例如 JSON 配置：

{ "conditionName": "双果冻双红宝石", "requiredItems": { "Jelly": 2, "Ruby": 2 } }

运行时读取后，转成ItemCondition对象注册到ConditionManager。这样新增玩法条件时，只需要配置表加一行。

7.2 事件驱动与业务解耦

组合检测器只负责“判断条件是否满足”，至于满足后触发什么效果，应该由外部事件订阅方处理。这样可以将成就、任务、掉落、音效、动画等不同系统解耦。

在本文代码中，ConditionManager的回调只是打日志。实际项目里可以在这个方法中调用任务系统的CompleteTask，或者把消息推送给 UI 层播放特效。

7.3 性能优化建议

如果条件数量很多，但背包物品种类有限，最简单的优化方法是：每个物品类型维护一个监听该类型变化的条件列表，减少无效遍历。

例如Dictionary<ItemType, List<CombinationDetector>>，当Jelly变化时，只遍历关注Jelly的检测器。这个优化带来的效果会随着条件数量增加而变明显。

7.4 日志标记与可观测性

排错时最怕“为什么没触发”。建议为每个条件增加唯一 ID，并在触发和失效时输出带 ID 的日志，例如：

[Condition] 10001 - 双果冻双红宝石 state=matched

这样线上环境出现异常时，可以快速定位是“数据没到”还是“检测器状态错误”。

7.5 注意存档与初始化

如果游戏支持存档，初始化背包数据时，需要先恢复存档中的物品数量，再注册条件检测器。顺序错了，可能导致初始状态被判定成“条件从无到有”，引发多余的奖励发放。

7.6 避免在事件回调中做耗时操作

OnConditionMatched触发时，不要在里面直接加载大型资源、播放过场动画、执行 UI 重建。正确做法是先把事件放入消息队列，由主循环统一处理，避免在物品拾取瞬间引发卡顿。

8. 总结

“检测到双果冻双红宝石”这个需求，实际考验的是数据变更驱动的事件检测设计能力。它不只是一个if数量判断，而是一套可以复用的组合条件检测模型。

今天我带你从零实现了一个完整的检测流程，包括：

• 背包数据管理
• 组合条件的数据结构表示
• 条件检测器的边界状态处理
• 事件驱动接入方式
• Unity 场景挂载示例
• 常见问题排查思路

下一步你可以继续探索这些方向：把条件检测和 ScriptableObject 配置打通、加入异步事件队列、在项目里实现一个更通用的“多条件组合成就系统”。动手把文章里的控制台示例跑一遍，再尝试改成你想实现的任何组合条件，例如“三红宝石一水晶”，加深对整套流程的理解。

如果你在接入项目时遇到了其他问题，欢迎在评论区分享你遇到的具体数据和现象，我会基于实际经验继续更新排错思路。