1. 項目概述為什么我們需要EntityX的事件模塊如果你用C寫過游戲或者任何需要處理大量動態(tài)交互的復雜應用肯定對“事件驅動”這個詞不陌生。想象一下你的游戲里有成百上千個實體Entity比如玩家、怪物、子彈、道具。當一個怪物被子彈擊中時它需要扣血、播放受傷動畫、可能還要掉落物品同時UI可能需要更新連擊數(shù)音效系統(tǒng)要播放“擊中”音效成就系統(tǒng)要檢查是否解鎖了“百發(fā)百中”的成就。如果讓子彈的代碼直接去調用怪物、UI、音效、成就系統(tǒng)的函數(shù)代碼很快就會變成一團亂麻耦合度高到難以維護。這就是事件系統(tǒng)要解決的問題解耦。EntityX作為一個輕量級的C實體組件系統(tǒng)ECS框架其事件模塊正是為了優(yōu)雅地處理這種“某事發(fā)生了通知所有關心此事的對象”的場景而設計的。它不依賴于龐大的游戲引擎你可以把它嵌入到你的C項目中快速構建起清晰的事件通信機制。今天我們就來深入它的內(nèi)部看看這個事件模塊是如何工作的以及如何在你的項目中高效地使用它。2. EntityX事件模塊核心設計解析EntityX的事件系統(tǒng)采用了經(jīng)典的觀察者模式Observer Pattern但在此基礎上做了適合ECS范式的優(yōu)化。其核心思想是事件的發(fā)送者Emitter不需要知道接收者Receiver是誰只需要聲明“某某事件發(fā)生了”而接收者則向系統(tǒng)注冊自己對某類事件的興趣并提供處理函數(shù)。系統(tǒng)負責在事件發(fā)生時將事件分發(fā)給所有注冊過的接收者。2.1 核心類與它們的關系整個事件模塊圍繞幾個核心類展開理解它們的關系是讀懂代碼的關鍵。EventManager事件系統(tǒng)的中樞和大腦。它負責三件事1) 維護一個事件類型到接收者列表的映射表2) 提供接口供接收者訂閱subscribe特定事件3) 提供接口供發(fā)送者發(fā)射emit事件并由它負責調用所有訂閱者的處理函數(shù)。每個EntityX實例都擁有一個唯一的EventManager。ReceiverTEvent事件接收者的模板類。這是一個CRTP奇特的遞歸模板模式基類你需要讓希望接收某類事件的自定義類例如PhysicsSystem,UISystem繼承自Receiver具體事件類型。繼承后你的類必須實現(xiàn)一個receive(const 具體事件類型)方法。Receiver內(nèi)部會持有指向EventManager的指針并在構造和析構時自動完成訂閱和取消訂閱這是利用RAII資源獲取即初始化原則避免資源泄漏的經(jīng)典做法。事件類型Event Types在EntityX中事件就是普通的C結構體struct或類class。沒有任何基類要求你可以自由定義任何數(shù)據(jù)成員。例如你可以定義一個CollisionEvent { Entity a, Entity b; }或者一個KeyPressedEvent { int keyCode; }。這種設計極其靈活類型安全由模板系統(tǒng)保證。它們的工作流程可以概括為系統(tǒng)初始化時各個系統(tǒng)如RenderSystem,SoundSystem的實例被創(chuàng)建它們繼承自對應的ReceiverXxxEvent。在系統(tǒng)構造函數(shù)中基類ReceiverXxxEvent會向EventManager注冊自己。游戲運行時任何代碼通常是某個系統(tǒng)都可以通過EventManager::emitXxxEvent(event)來發(fā)射一個事件。EventManager查找所有訂閱了XxxEvent的Receiver并同步地、依次調用它們的receive方法。當系統(tǒng)被銷毀時Receiver的析構函數(shù)會自動從EventManager中注銷自己。2.2 同步 vs 異步事件分發(fā)EntityX 的事件分發(fā)是同步的。這意味著當emit被調用時所有訂閱者的receive方法會在當前線程中立即被依次調用直到所有處理函數(shù)都執(zhí)行完畢emit函數(shù)才會返回。這種設計簡單、直接、可預測對于絕大多數(shù)游戲邏輯事件如碰撞、攻擊、拾取道具來說是完全合適的因為你通常希望這些邏輯在同一個幀內(nèi)被處理完畢。但是同步分發(fā)也帶來一個潛在問題如果某個接收者的receive方法執(zhí)行了非常耗時的操作比如同步加載一個大資源它會阻塞所有后續(xù)接收者以及事件發(fā)射者的執(zhí)行。因此在定義事件和處理事件時一個重要的經(jīng)驗法則是事件處理函數(shù)應該盡可能快只做必要的狀態(tài)更新和輕量級操作將耗時任務排隊到其他線程或系統(tǒng)去處理。如果你確實需要異步事件EntityX 本身并未直接提供支持但你可以很容易地在它之上構建。例如你可以在事件處理函數(shù)中將任務推入一個線程池隊列或者發(fā)射另一個專門用于異步處理的事件。3. 從零開始使用事件模塊一個完整示例理論說再多不如看代碼。讓我們通過一個簡單的“太空射擊游戲”片段來看看如何定義、發(fā)射和接收事件。3.1 第一步定義你的事件類型首先我們定義游戲中可能需要的幾種事件。這些就是普通的C結構體。// 事件定義 struct CollisionEvent { Entity entityA; Entity entityB; // 可以添加碰撞點、法向量等更多信息 }; struct DamageEvent { Entity target; // 承受傷害的實體 Entity source; // 傷害來源實體可能是Entity()表示環(huán)境傷害 int amount; // 傷害值 }; struct EnemyDestroyedEvent { Entity enemy; int scoreValue; // 擊毀該敵人獲得的分數(shù) }; struct PlayerHealthChangedEvent { Entity player; int currentHealth; int maxHealth; };3.2 第二步創(chuàng)建接收事件的系統(tǒng)接著我們創(chuàng)建兩個系統(tǒng)PhysicsSystem負責檢測碰撞并發(fā)射事件CombatSystem和UISystem負責接收并處理事件。#include entityx/entityx.h using namespace entityx; // 物理系統(tǒng)檢測碰撞并發(fā)射 CollisionEvent class PhysicsSystem : public SystemPhysicsSystem { public: void update(EntityManager es, EventManager events, TimeDelta dt) override { // 簡化的碰撞檢測偽代碼 es.eachCollisionBox, Position([events](Entity entityA, CollisionBox boxA, Position posA) { es.eachCollisionBox, Position([entityA, boxA, posA, events](Entity entityB, CollisionBox boxB, Position posB) { if (entityA ! entityB checkCollision(boxA, posA, boxB, posB)) { // 關鍵發(fā)射碰撞事件 events.emitCollisionEvent(CollisionEvent{entityA, entityB}); } }); }); } private: bool checkCollision(const CollisionBox a, const Position pa, const CollisionBox b, const Position pb) { // 實際的碰撞檢測邏輯... return false; } }; // 戰(zhàn)斗系統(tǒng)接收碰撞事件判斷傷害并發(fā)射傷害和摧毀事件 class CombatSystem : public SystemCombatSystem, public ReceiverCombatSystem { // 繼承Receiver public: // 必須的配置方法告訴EventManager這個系統(tǒng)訂閱了哪些事件 void configure(EventManager events) override { events.subscribeCollisionEvent(*this); events.subscribeDamageEvent(*this); } // 接收并處理 CollisionEvent void receive(const CollisionEvent collision) { auto es *entities; // 從System基類獲取EntityManager // 假設我們有一個簡單的規(guī)則如果碰撞雙方都有Health組件則互相造成傷害 if (es.has_componentHealth(collision.entityA) es.has_componentHealth(collision.entityB)) { // 發(fā)射傷害事件 events-emitDamageEvent(DamageEvent{collision.entityB, collision.entityA, 10}); events-emitDamageEvent(DamageEvent{collision.entityA, collision.entityB, 10}); } // 更復雜的邏輯子彈 vs 敵人玩家 vs 墻壁等... } // 接收并處理 DamageEvent void receive(const DamageEvent damage) { if (auto health entities-componentHealth(damage.target)) { health-current - damage.amount; if (health-current 0) { // 實體死亡可能發(fā)射摧毀事件 if (damage.target.has_componentEnemy()) { events-emitEnemyDestroyedEvent(EnemyDestroyedEvent{damage.target, 100}); } // 銷毀實體 damage.target.destroy(); } // 通知UI更新血條 events-emitPlayerHealthChangedEvent( PlayerHealthChangedEvent{damage.target, health-current, health-max} ); } } }; // UI系統(tǒng)接收游戲狀態(tài)事件并更新界面 class UISystem : public SystemUISystem, public ReceiverUISystem { public: void configure(EventManager events) override { events.subscribePlayerHealthChangedEvent(*this); events.subscribeEnemyDestroyedEvent(*this); } void receive(const PlayerHealthChangedEvent healthEvent) { // 更新屏幕上的血條UI std::cout Player Health: healthEvent.currentHealth / healthEvent.maxHealth std::endl; } void receive(const EnemyDestroyedEvent destroyedEvent) { // 更新分數(shù)顯示 std::cout Enemy Destroyed! Score destroyedEvent.scoreValue std::endl; } };3.3 第三步組裝系統(tǒng)并運行世界最后我們將所有系統(tǒng)組裝起來并運行游戲主循環(huán)。int main() { EntityX ex; // 默認創(chuàng)建了 EntityManager, EventManager, SystemManager // 獲取系統(tǒng)管理器并添加系統(tǒng) auto systems ex.systems; systems.addPhysicsSystem(); systems.addCombatSystem(); systems.addUISystem(); systems.configure(); // 這會調用所有系統(tǒng)的 configure() 方法完成事件訂閱 // 創(chuàng)建一些測試實體玩家、敵人... Entity player ex.entities.create(); player.assignHealth(100, 100); player.assignPosition(0, 0); player.assignCollisionBox(10, 10); Entity enemy ex.entities.create(); enemy.assignHealth(50, 50); enemy.assignPosition(5, 5); enemy.assignCollisionBox(8, 8); enemy.assignEnemy(); // 簡化的游戲主循環(huán) for (int i 0; i 100; i) { // 1. 更新所有系統(tǒng)。PhysicsSystem會在update中檢測碰撞并發(fā)射事件。 systems.update_all(1.0f / 60.0f); // 假設60幀 // 2. EventManager會在emit時同步調用CombatSystem和UISystem的receive方法。 // 3. 事件處理鏈碰撞 - 傷害 - 血條更新/分數(shù)更新/實體銷毀。 } return 0; }通過這個例子你可以清晰地看到事件如何像鏈條一樣將不同的系統(tǒng)連接起來PhysicsSystem只管碰撞檢測和發(fā)射事件完全不知道后面誰會處理CombatSystem訂閱碰撞事件處理游戲邏輯并發(fā)射新的事件UISystem訂閱游戲狀態(tài)事件負責顯示更新。每個系統(tǒng)職責單一耦合度極低。4. 深入源碼事件模塊是如何實現(xiàn)的理解了如何使用我們再來窺探一下EntityX事件模塊的內(nèi)部實現(xiàn)這能幫助我們更好地使用它并在遇到問題時進行調試。我們主要關注event.h和event.cc這兩個文件。4.1 EventManager 的內(nèi)部容器EventManager的核心是一個存儲訂閱關系的數(shù)據(jù)結構。它使用std::unordered_map將事件類型映射到一個接收者列表。// 簡化后的內(nèi)部結構示意 class EventManager { private: // 類型擦除的基類指針用于存儲任意類型的 Receiver 實例 struct ReceiverBase { virtual ~ReceiverBase() default; }; // 針對特定事件類型的 Receiver 包裝器 template typename Event struct ReceiverWrapper : ReceiverBase { ReceiverEvent *receiver; explicit ReceiverWrapper(ReceiverEvent *receiver) : receiver(receiver) {} }; // 關鍵數(shù)據(jù)結構事件類型ID - 該類型事件的接收者列表 std::unordered_mapTypeId, std::vectorstd::unique_ptrReceiverBase receivers_; };這里用到了一個關鍵技巧類型擦除Type Erasure。因為ReceiverCollisionEvent和ReceiverDamageEvent是不同的類型無法直接放在同一個vector里。EntityX 通過一個非模板的基類ReceiverBase和模板派生類ReceiverWrapperEvent來解決這個問題。ReceiverWrapper存儲了具體ReceiverEvent的指針而receivers_存儲的是ReceiverBase的智能指針從而實現(xiàn)了異構容器。TypeId是 EntityX 內(nèi)部用于唯一標識類型的一個整數(shù)值通常通過type_idEvent()函數(shù)獲取這個函數(shù)會對每種類型返回一個編譯期確定的常量。4.2 訂閱subscribe過程剖析當CombatSystem在configure中調用events.subscribeCollisionEvent(*this)時發(fā)生了什么template typename Event void EventManager::subscribe(ReceiverEvent receiver) { const auto type_id type_idEvent(); auto receivers receivers_[type_id]; // 獲取或創(chuàng)建該事件類型的接收者列表 // 檢查是否已經(jīng)訂閱過避免重復 auto it std::find_if(receivers.begin(), receivers.end(), [receiver](const std::unique_ptrReceiverBase base) { auto *wrapper static_castReceiverWrapperEvent*(base.get()); return wrapper-receiver receiver; }); if (it receivers.end()) { // 創(chuàng)建包裝器并存入列表 receivers.emplace_back(std::make_uniqueReceiverWrapperEvent(receiver)); } }這個過程是線程不安全的。EntityX 的事件系統(tǒng)設計假設訂閱發(fā)生在初始化階段configure此時通常是單線程的。4.3 發(fā)射emit與分發(fā)過程剖析發(fā)射事件的過程是同步遍歷調用。template typename Event, typename ...Args void EventManager::emit(Args ... args) { const auto type_id type_idEvent(); auto it receivers_.find(type_id); if (it ! receivers_.end()) { // 臨時創(chuàng)建事件對象。Args... 允許直接傳遞構造參數(shù)給Event。 Event event(std::forwardArgs(args)...); auto receivers it-second; // 遍歷所有訂閱了此事件的接收者 for (auto base : receivers) { // 關鍵的一步將基類指針安全地向下轉型為具體的Wrapper auto *wrapper static_castReceiverWrapperEvent*(base.get()); // 調用接收者的 receive 方法 wrapper-receiver-receive(event); } } }這里有幾個值得注意的點事件對象生命周期事件對象在emit函數(shù)棧上創(chuàng)建。對于每個接收者傳遞的都是這個對象的const引用。這意味著所有接收者處理的是同一個事件對象。因此絕對不要在receive方法中修改事件對象除非你明確知道所有接收者都期望這種修改并且順序是確定的這通常是個壞主意。異常安全如果某個接收者的receive方法拋出異常這個異常會傳播到emit調用處并中斷后續(xù)接收者的調用。你需要確保事件處理函數(shù)是異常安全的或者在外層捕獲異常。性能考量遍歷vector并調用虛函數(shù)receive是通過Receiver基類接口調用的是有開銷的。對于每幀發(fā)射成千上萬次的高頻事件比如每個實體的PositionUpdatedEvent這種開銷可能成為瓶頸。對于這種情況更好的模式是使用數(shù)據(jù)組件如Position組件并通過系統(tǒng)查詢來處理而不是事件。4.4 Receiver 的自動生命周期管理Receiver類的實現(xiàn)巧妙地利用了構造函數(shù)和析構函數(shù)來自動管理訂閱關系。template typename Events class Receiver { public: virtual ~Receiver() { if (event_manager_) { event_manager_-unsubscribeEvents(*this); } } // ... private: EventManager *event_manager_ nullptr; // 友元聲明允許 EventManager 調用 configure_receiver template typename, typename friend class EventManager; };當一個系統(tǒng)如CombatSystem繼承Receiver時它通常會在構造函數(shù)中或通過EventManager的configure方法設置event_manager_指針。當系統(tǒng)被銷毀時Receiver的析構函數(shù)會自動調用unsubscribe將自己從所有事件列表中移除完美避免了“野指針”回調導致崩潰的問題。這是C RAII理念的絕佳實踐。5. 高級用法與性能優(yōu)化實戰(zhàn)了解了基本原理后我們來看看如何在實際項目中更高效、更安全地使用EntityX事件模塊。5.1 使用事件類繼承與類型過濾有時你希望一個接收者能處理一類相似的事件。EntityX本身不支持基于基類的事件分發(fā)但你可以通過組合方式實現(xiàn)。// 定義一個基礎事件 struct BaseGameEvent { Entity sourceEntity; TimePoint timestamp; }; // 派生具體事件 struct DamageEvent : public BaseGameEvent { int amount; DamageType type; }; struct HealEvent : public BaseGameEvent { int amount; }; // 日志系統(tǒng)希望記錄所有游戲事件 class LoggingSystem : public SystemLoggingSystem { public: void configure(EventManager events) { events.subscribeDamageEvent(*this); events.subscribeHealEvent(*this); // ... 訂閱所有BaseGameEvent的派生類 } // 需要為每種事件寫一個receive內(nèi)部可以調用一個公共處理函數(shù) void receive(const DamageEvent e) { logEvent(Damage, e); } void receive(const HealEvent e) { logEvent(Heal, e); } private: void logEvent(const std::string type, const BaseGameEvent e) { std::cout [ e.timestamp ] type from Entity e.sourceEntity.id() std::endl; } };雖然需要為每個派生事件寫一個receive轉發(fā)函數(shù)但這保證了類型安全并且模式很清晰。切記不要嘗試將EventManager::subscribe與基類類型一起使用因為模板機制會將其視為完全不同的類型。5.2 高頻事件的優(yōu)化策略事件隊列與批量處理對于像PositionChangedEvent這樣的高頻事件每幀為每個移動的實體都emit一次是不可接受的。解決方案是使用事件隊列進行批處理。// 1. 定義一個批量事件 struct BatchPositionEvents { std::vectorstd::pairEntity, Vector2 updates; }; // 2. 在移動系統(tǒng)中不再立即emit而是收集到臨時容器 class MovementSystem : public SystemMovementSystem { public: void update(EntityManager es, EventManager events, TimeDelta dt) override { std::vectorstd::pairEntity, Vector2 frameUpdates; es.eachPosition, Velocity([frameUpdates, dt](Entity e, Position pos, Velocity vel) { pos.x vel.dx * dt; pos.y vel.dy * dt; // 收集而不是發(fā)射 frameUpdates.emplace_back(e, Vector2{pos.x, pos.y}); }); // 在update的最后一次性發(fā)射一個批量事件 if (!frameUpdates.empty()) { events.emitBatchPositionEvents(BatchPositionEvents{std::move(frameUpdates)}); } } }; // 3. 其他系統(tǒng)如渲染插值系統(tǒng)、網(wǎng)絡同步系統(tǒng)訂閱這個批量事件 class InterpolationSystem : public SystemInterpolationSystem, public ReceiverInterpolationSystem { public: void configure(EventManager events) override { events.subscribeBatchPositionEvents(*this); } void receive(const BatchPositionEvents batch) { for (const auto [entity, newPos] : batch.updates) { // 平滑插值到新位置 // ... } } };這種方法將 O(N) 次的事件發(fā)射和分發(fā)調用減少到 O(1) 次極大地提升了性能。代價是增加了少量內(nèi)存用于收集數(shù)據(jù)并引入了一幀的延遲事件在本幀末收集下一幀初被處理。對于大多數(shù)情況這是完全可以接受的。5.3 確保事件處理函數(shù)的線程安全EntityX 的事件系統(tǒng)本身不是線程安全的。subscribe,unsubscribe,emit操作如果從多個線程調用會導致數(shù)據(jù)競爭。通常的實踐是訂閱/取消訂閱只在主線程初始化階段configure或系統(tǒng)創(chuàng)建/銷毀時進行。發(fā)射事件盡量只在主線程的游戲邏輯循環(huán)中發(fā)射。如果其他工作線程如網(wǎng)絡線程、資源加載線程需要通知主線程應該通過線程安全的隊列將事件對象傳遞到主線程由主線程在下一幀統(tǒng)一emit。// 一個簡單的線程間事件傳遞方案 class ThreadSafeEventQueue { public: template typename Event void pushFromWorkerThread(Event event) { std::lock_guardstd::mutex lock(mutex_); // 需要使用類型擦除來存儲任意事件這里簡化表示 queue_.push_back(std::make_anyEvent(std::forwardEvent(event))); } void processInMainThread(EventManager mainEventManager) { std::lock_guardstd::mutex lock(mutex_); for (auto eventAny : queue_) { // 這里需要根據(jù) eventAny 中存儲的類型信息調用對應的 mainEventManager.emit // 實際實現(xiàn)需要更復雜的類型映射此處為概念展示 } queue_.clear(); } private: std::mutex mutex_; std::vectorstd::any queue_; }; // 在主循環(huán)中 int main() { EntityX ex; ThreadSafeEventQueue crossThreadQueue; // ... 初始化系統(tǒng) while (gameRunning) { // 1. 處理從其他線程過來的事件 crossThreadQueue.processInMainThread(ex.events); // 2. 正常更新系統(tǒng)可能會emit事件 systems.update_all(dt); // ... 其他主循環(huán)邏輯 } }6. 常見陷阱、調試技巧與最佳實踐在實際使用中我踩過不少坑也總結出一些讓代碼更健壯的經(jīng)驗。6.1 陷阱一在事件處理函數(shù)中發(fā)射同一事件這會導致無限遞歸和棧溢出。void receive(const SomeEvent e) { // 錯誤這會導致直接或間接的無限循環(huán)。 events-emitSomeEvent(e); }解決方案仔細審查事件處理邏輯。如果確實需要“重新觸發(fā)”或“廣播放大”一個事件考慮發(fā)射一個不同但相關的事件或者使用一個標志位來防止重入。6.2 陷阱二事件處理函數(shù)修改了實體組件影響了迭代器這是一個非常隱蔽的錯誤。假設你在一個es.each循環(huán)中發(fā)射了一個事件而某個事件處理函數(shù)銷毀了正在被迭代的實體或者創(chuàng)建了新的符合迭代條件的實體這會導致迭代器失效可能引發(fā)崩潰或未定義行為。// 在 PhysicsSystem 的 update 中 es.eachHealth([events](Entity e, Health h) { if (h.current 0) { events.emitEntityDiedEvent(EntityDiedEvent{e}); // 危險 } }); // 在另一個系統(tǒng)的 receive 中 void receive(const EntityDiedEvent e) { e.entity.destroy(); // 如果 e.entity 正好是 PhysicsSystem 正在迭代的那個就出問題了。 }解決方案將“銷毀實體”這類操作延遲到所有系統(tǒng)update完成之后。常見的模式是發(fā)射一個EntityDestroyRequestEvent由一個專門的DestroySystem在所有其他系統(tǒng)更新完畢后統(tǒng)一處理銷毀請求。class DestroySystem : public SystemDestroySystem, public ReceiverDestroySystem { public: void configure(EventManager events) override { events.subscribeEntityDestroyRequestEvent(*this); } void receive(const EntityDestroyRequestEvent e) { pendingDestroys_.push_back(e.entity); } // 在所有其他系統(tǒng)update之后被調用 void update(EntityManager es, EventManager events, TimeDelta dt) override { for (Entity e : pendingDestroys_) { e.destroy(); } pendingDestroys_.clear(); } private: std::vectorEntity pendingDestroys_; };6.3 調試技巧可視化事件流當事件系統(tǒng)復雜后調試“為什么這個事件沒被處理”或“這個事件被誰處理了”會很頭疼?？梢詣?chuàng)建一個簡單的EventDebugSystem。class EventDebugSystem : public ReceiverEventDebugSystem { public: // 使用可變參數(shù)模板來訂閱所有事件這是一個高級技巧。 template typename Event void subscribeTo(EventManager events) { events.subscribeEvent(*this); } // 一個通用的 receive 模板捕獲所有事件 template typename Event void receive(const Event e) { std::cout [EventDebug] Type: typeid(Event).name() , Address: e std::endl; // 可以在這里打印事件內(nèi)容或者記錄到文件 } }; // 在配置時手動或通過反射注冊需要調試的事件類型 debugSystem.subscribeToCollisionEvent(events); debugSystem.subscribeToDamageEvent(events); // ...6.4 最佳實踐清單根據(jù)我的項目經(jīng)驗遵循以下實踐能讓基于EntityX事件系統(tǒng)的代碼更清晰、更健壯事件即數(shù)據(jù)保持輕量事件結構體應只包含必要的數(shù)據(jù)避免包含智能指針、大型容器或復雜對象。優(yōu)先傳遞ID、索引或簡單值類型。明確命名事件名使用名詞或名詞短語清晰表達“發(fā)生了什么”如PlayerJumped,InventoryItemAdded,AchievementUnlocked。單一職責一個事件應只代表一件事。不要創(chuàng)建PlayerActionEvent這種包含enum ActionType的“萬能事件”而是拆分成PlayerMovedEvent,PlayerAttackedEvent等。區(qū)分命令與事件RequestPlayerMove命令和PlayerMoved事件是不同的。命令是“希望做某事”事件是“某事已經(jīng)發(fā)生”。避免混淆。文檔化事件契約在事件結構體的定義處用注釋說明誰在什么情況下發(fā)射這個事件事件中的數(shù)據(jù)代表什么含義哪些系統(tǒng)可能會監(jiān)聽它控制事件粒度不要過度使用事件。對于每幀都發(fā)生的、數(shù)據(jù)驅動的狀態(tài)同步如位置、旋轉使用組件和系統(tǒng)查詢通常比事件更高效。性能熱點監(jiān)控在性能分析工具如tracy、easy_profiler中標記emit調用監(jiān)控高頻事件的性能消耗。