1. 先搞清楚 Animation Notify 到底在游戲里扮演什么角色做 UE5 動畫系統(tǒng)的朋友大概率都經(jīng)歷過這樣的場景角色揮刀到某一幀需要觸發(fā)傷害判定腳步落地那一瞬間要播放音效和粒子蓄力動作到某個節(jié)點得讓角色進(jìn)入無敵狀態(tài)。這些“在動畫播放到特定時刻做特定事情”的需求就是 Animation Notify 要解決的問題。Animation Notify中文一般叫動畫通知是 UE5 動畫系統(tǒng)中一套事件觸發(fā)機(jī)制。它允許你在動畫序列的時間軸上打點當(dāng)動畫播放到這些點時引擎會回調(diào)你注冊的函數(shù)執(zhí)行自定義邏輯。Anim Notify State 則是它的進(jìn)階形態(tài)區(qū)別在于 Notify 是瞬時觸發(fā)而 Notify State 有持續(xù)區(qū)間帶進(jìn)入和退出兩個回調(diào)。這套機(jī)制看起來簡單但真正用起來尤其是項目規(guī)模上去之后問題就來了為什么我的 Notify 在客戶端不觸發(fā)為什么 Notify State 的 Begin 和 End 順序亂了為什么動畫藍(lán)圖里拿不到 Notify 的參數(shù)要回答這些問題光看文檔不夠得往源碼里鉆。這篇文章面向的是已經(jīng)會用 Notify 但想搞明白底層機(jī)制的中級開發(fā)者以及正在做動畫系統(tǒng)架構(gòu)、需要定制 Notify 流程的高級開發(fā)者。我會從源碼層面拆解 Notify 和 Notify State 的注冊、觸發(fā)、同步、生命周期管理把那些文檔里不會寫的細(xì)節(jié)和踩坑經(jīng)驗一并倒出來。全文基于 UE5 的動畫系統(tǒng)源碼結(jié)構(gòu)展開涉及的具體類名和函數(shù)名都來自引擎源碼你可以對照著看。2. 源碼結(jié)構(gòu)總覽Notify 體系的核心類與繼承關(guān)系2.1 從 UAnimNotify 到 UAnimNotifyState 的類族譜打開 UE5 源碼動畫通知相關(guān)的類主要集中在Engine/Source/Runtime/Engine/Classes/Animation/目錄下。核心類有這么幾個UAnimNotify瞬時通知的基類定義在AnimNotify.hUAnimNotifyState持續(xù)通知的基類定義在AnimNotifyState.hFAnimNotifyEvent動畫序列中一條通知記錄的運(yùn)行時數(shù)據(jù)結(jié)構(gòu)定義在AnimTypes.hFAnimNotifyEventReference通知事件的引用包裝用于在上下文之間傳遞UAnimNotifyQueue通知隊列負(fù)責(zé)在動畫更新時收集和分發(fā)通知繼承關(guān)系上UAnimNotify和UAnimNotifyState都直接繼承自UObject它們不是UAnimInstance的一部分而是獨立的資產(chǎn)對象。這一點很關(guān)鍵意味著 Notify 對象可以被多個動畫序列共享也可以被動畫藍(lán)圖引用。FAnimNotifyEvent則是另一條線它繼承自FAnimLinkableElement這個基類提供了與動畫時間軸鏈接的能力。FAnimNotifyEvent里存了通知的觸發(fā)時間、持續(xù)時間、關(guān)聯(lián)的 Notify 對象指針、觸發(fā)條件等信息。動畫序列在編譯時會把編輯器里配置的 Notify 數(shù)據(jù)轉(zhuǎn)換成FAnimNotifyEvent數(shù)組運(yùn)行時通過這個數(shù)組來驅(qū)動通知。2.2 FAnimNotifyEvent 里到底存了什么FAnimNotifyEvent的字段比較多挑幾個關(guān)鍵的看// 簡化后的結(jié)構(gòu)示意 struct FAnimNotifyEvent : public FAnimLinkableElement { float TriggerTime; // 觸發(fā)時間秒 float Duration; // 持續(xù)時間Notify State 用 float EndTriggerTime; // 結(jié)束觸發(fā)時間 FName NotifyName; // 通知名稱 UAnimNotify* Notify; // 瞬時通知對象 UAnimNotifyState* NotifyState; // 持續(xù)通知對象 FGuid Guid; // 唯一標(biāo)識 bool bTriggerOnDedicatedServer; // ... 還有一堆 };TriggerTime和Duration是核心。對于普通 NotifyDuration為 0只在TriggerTime觸發(fā)一次。對于 Notify StateDuration大于 0引擎會在TriggerTime調(diào)用NotifyBegin在TriggerTime Duration調(diào)用NotifyEnd。Guid這個字段容易被忽略但它在網(wǎng)絡(luò)同步和通知去重時非常重要。每個 Notify 事件在編輯器里創(chuàng)建時都會分配一個唯一 Guid運(yùn)行時通過 Guid 來識別“這條通知是否已經(jīng)觸發(fā)過”。2.3 通知隊列 UAnimNotifyQueue 的職責(zé)UAnimNotifyQueue是運(yùn)行時通知分發(fā)的核心。它的工作流程大致是動畫更新時FAnimInstanceProxy會調(diào)用UAnimNotifyQueue::AddAnimNotifies把當(dāng)前幀需要觸發(fā)的通知加入隊列隊列里存的是FAnimNotifyEventReference包含通知事件指針和來源上下文動畫更新結(jié)束后UAnimNotifyQueue::Flush被調(diào)用遍歷隊列逐個執(zhí)行通知的Notify或NotifyState回調(diào)這個設(shè)計的好處是解耦通知的收集和分發(fā)分開方便在網(wǎng)絡(luò)環(huán)境下做預(yù)測和回滾。壞處是如果你在Notify回調(diào)里做了重操作會阻塞整個動畫更新流程。注意UAnimNotifyQueue的 Flush 是在游戲線程執(zhí)行的不要在 Notify 回調(diào)里做耗時計算否則會拖慢整個動畫系統(tǒng)。3. Notify 的觸發(fā)流程從動畫更新到回調(diào)執(zhí)行3.1 動畫更新時通知是怎么被收集的動畫更新發(fā)生在FAnimInstanceProxy::UpdateAnimation里。具體到通知收集關(guān)鍵調(diào)用鏈?zhǔn)沁@樣的// 偽代碼示意 void FAnimInstanceProxy::UpdateAnimation(...) { // 1. 更新動畫節(jié)點樹 // 2. 收集通知 if (NotifyQueue) { // 遍歷當(dāng)前活躍的動畫序列 for (auto Sequence : ActiveSequences) { // 計算當(dāng)前幀時間區(qū)間 float PreviousTime ...; float CurrentTime ...; // 找出這個區(qū)間內(nèi)需要觸發(fā)的通知 for (auto NotifyEvent : Sequence-Notifies) { if (NotifyEvent.TriggerTime PreviousTime NotifyEvent.TriggerTime CurrentTime) { NotifyQueue-AddAnimNotify(NotifyEvent, ...); } } } } }這里有個細(xì)節(jié)時間區(qū)間的判斷用的是左閉右開[PreviousTime, CurrentTime)。這意味著如果動畫時間正好停在某個 Notify 的觸發(fā)點上它會在下一幀才觸發(fā)。這個設(shè)計是為了避免同一幀內(nèi)重復(fù)觸發(fā)但在做精確幀同步時要注意。3.2 Notify 回調(diào)的執(zhí)行順序與優(yōu)先級當(dāng)Flush被調(diào)用時隊列里的通知按什么順序執(zhí)行源碼里的邏輯是先按動畫序列的層級排序同一序列內(nèi)按TriggerTime排序。如果兩個 Notify 的TriggerTime相同則按它們在數(shù)組里的索引順序執(zhí)行。這個順序在大多數(shù)情況下夠用但如果你有多個動畫序列同時播放比如上半身和下半身分開跨序列的通知順序就不那么直觀了。實測下來引擎會先處理主序列的通知再處理疊加序列的。如果你的邏輯依賴特定順序最好在 Notify 里加顯式的優(yōu)先級判斷而不是依賴引擎的默認(rèn)排序。3.3 Notify State 的 Begin 和 End 是怎么配對的Notify State 的生命周期管理比普通 Notify 復(fù)雜。引擎需要跟蹤每個 Notify State 實例的狀態(tài)確保Begin和End正確配對。核心邏輯在FAnimInstanceProxy::TickAssetPlayer和UAnimNotifyQueue的交互里。大致流程是當(dāng)動畫時間進(jìn)入 Notify State 的[TriggerTime, EndTriggerTime)區(qū)間時如果該 State 還沒被標(biāo)記為“活躍”則調(diào)用NotifyBegin并把它加入活躍列表當(dāng)動畫時間離開這個區(qū)間時從活躍列表里移除調(diào)用NotifyEnd如果動畫被中斷比如切換狀態(tài)引擎會遍歷活躍列表對所有未結(jié)束的 State 調(diào)用NotifyEnd這里有個坑如果動畫被強(qiáng)制中斷NotifyEnd的調(diào)用時機(jī)是在下一幀的動畫更新開始時而不是立即。這意味著在中斷的那一幀State 可能還處于“活躍”狀態(tài)。如果你的邏輯依賴 State 的結(jié)束來清理資源要考慮到這個延遲。// NotifyState 生命周期管理的簡化示意 void FAnimInstanceProxy::UpdateNotifyStates(float DeltaTime) { // 檢查所有活躍的 NotifyState for (int32 i ActiveNotifyStates.Num() - 1; i 0; --i) { FActiveNotifyState State ActiveNotifyStates[i]; // 判斷是否應(yīng)該結(jié)束 if (!State.IsInRange(CurrentTime)) { State.NotifyState-NotifyEnd(this, ...); ActiveNotifyStates.RemoveAt(i); } } // 檢查是否有新的 NotifyState 應(yīng)該開始 for (auto NotifyEvent : CurrentSequence-Notifies) { if (NotifyEvent.NotifyState NotifyEvent.IsInRange(CurrentTime) !IsAlreadyActive(NotifyEvent)) { NotifyEvent.NotifyState-NotifyBegin(this, ...); ActiveNotifyStates.Add({NotifyEvent, ...}); } } }3.4 網(wǎng)絡(luò)環(huán)境下 Notify 的同步策略多人游戲里Notify 的同步是個大話題。UE5 的默認(rèn)策略是Notify 在服務(wù)器和客戶端都會觸發(fā)但觸發(fā)時機(jī)可能不同。服務(wù)器在動畫更新時觸發(fā)客戶端則依賴動畫同步。關(guān)鍵字段是bTriggerOnDedicatedServer。如果設(shè)為 false這個 Notify 只在客戶端觸發(fā)服務(wù)器不觸發(fā)。這個選項在純表現(xiàn)層的通知比如音效、粒子上很有用可以減輕服務(wù)器負(fù)擔(dān)。但要注意如果你的 Notify 涉及游戲邏輯比如傷害判定必須確保服務(wù)器和客戶端的觸發(fā)結(jié)果一致。常見做法是在 Notify 里調(diào)用一個 RPC由服務(wù)器來裁決。不要直接在客戶端 Notify 里改游戲狀態(tài)否則會出現(xiàn)不同步。實操心得我一般會把 Notify 分成兩類——表現(xiàn)類音效、特效、鏡頭震動和邏輯類傷害、狀態(tài)切換。表現(xiàn)類設(shè)bTriggerOnDedicatedServer false邏輯類保持 true并在回調(diào)里走服務(wù)器 RPC。這樣既省服務(wù)器性能又保證邏輯一致。4. 自定義 Notify 的完整實現(xiàn)流程4.1 創(chuàng)建自定義 Notify 類的正確姿勢在 UE5 里創(chuàng)建自定義 Notify有兩種方式C 和藍(lán)圖。C 方式更靈活適合復(fù)雜邏輯藍(lán)圖方式上手快適合簡單觸發(fā)。C 方式的步驟在項目里新建一個繼承自UAnimNotify的類重寫Notify函數(shù)在動畫序列編輯器里右鍵時間軸添加 Notify選擇你的自定義類// 自定義 Notify 示例 UCLASS() class MYGAME_API UMyDamageNotify : public UAnimNotify { GENERATED_BODY() public: virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { // 獲取擁有者 AActor* Owner MeshComp-GetOwner(); if (!Owner) return; // 只在服務(wù)器執(zhí)行傷害邏輯 if (Owner-HasAuthority()) { // 執(zhí)行傷害判定 ApplyDamage(Owner); } } // 可選重寫 GetNotifyName 來定制編輯器里顯示的名字 virtual FString GetNotifyName_Implementation() const override { return TEXT(傷害判定); } };藍(lán)圖方式更簡單在動畫序列編輯器里添加 Notify選擇“New Blueprint”創(chuàng)建然后在藍(lán)圖里實現(xiàn)Received_Notify事件。4.2 Notify 參數(shù)傳遞的幾種方式Notify 經(jīng)常需要參數(shù)比如傷害值、特效類型、音效資源。傳遞參數(shù)有幾種方式在 Notify 類里定義 UPROPERTY最直接在編輯器里配置運(yùn)行時讀取通過 EventReference 獲取上下文可以拿到動畫序列、播放位置等信息通過 MeshComp 獲取 Owner 和組件適合需要訪問角色狀態(tài)的場景UCLASS() class MYGAME_API UMyEffectNotify : public UAnimNotify { GENERATED_BODY() public: // 在編輯器里配置的特效資源 UPROPERTY(EditAnywhere, Category Effect) UParticleSystem* EffectTemplate; UPROPERTY(EditAnywhere, Category Effect) FName SocketName; virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { if (!EffectTemplate || !MeshComp) return; // 在指定插槽位置生成特效 UGameplayStatics::SpawnEmitterAttached( EffectTemplate, MeshComp, SocketName ); } };注意UPROPERTY 標(biāo)記的資源引用會參與序列化如果 Notify 被多個動畫共享改一處會影響所有引用。如果每個動畫需要不同的參數(shù)建議用 Notify State 或者在動畫藍(lán)圖里做映射。4.3 Notify State 的 Begin、Tick、End 三階段Notify State 有三個可重寫的函數(shù)NotifyBegin進(jìn)入?yún)^(qū)間時調(diào)用NotifyTick區(qū)間內(nèi)每幀調(diào)用NotifyEnd離開區(qū)間時調(diào)用UCLASS() class MYGAME_API UMyInvincibleState : public UAnimNotifyState { GENERATED_BODY() public: virtual void NotifyBegin(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float TotalDuration, const FAnimNotifyEventReference EventReference) override { // 進(jìn)入無敵狀態(tài) if (AActor* Owner MeshComp-GetOwner()) { Owner-SetInvincible(true); } } virtual void NotifyTick(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, float FrameDeltaTime, const FAnimNotifyEventReference EventReference) override { // 每幀檢查可以在這里做持續(xù)效果 } virtual void NotifyEnd(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation, const FAnimNotifyEventReference EventReference) override { // 退出無敵狀態(tài) if (AActor* Owner MeshComp-GetOwner()) { Owner-SetInvincible(false); } } };NotifyTick默認(rèn)不啟用需要在類里設(shè)置bTickNotify true或者在編輯器里勾選。啟用 Tick 會增加性能開銷只在確實需要每幀更新時開啟。4.4 在動畫藍(lán)圖里監(jiān)聽 Notify 事件除了在 Notify 類里直接處理邏輯還可以在動畫藍(lán)圖里監(jiān)聽 Notify 事件。方式是使用AnimNotify節(jié)點它會輸出一個執(zhí)行脈沖和 Notify 名稱。在動畫藍(lán)圖的 Event Graph 里添加AnimNotify節(jié)點連接Received_Notify事件通過NotifyName判斷是哪個通知執(zhí)行對應(yīng)邏輯這種方式的好處是邏輯集中在動畫藍(lán)圖里方便調(diào)試和修改。壞處是如果 Notify 很多事件圖會變得很亂。我的經(jīng)驗是簡單的表現(xiàn)層邏輯放動畫藍(lán)圖復(fù)雜的游戲邏輯放 C Notify 類。5. 常見問題與排查技巧實錄5.1 Notify 不觸發(fā)的排查清單Notify 不觸發(fā)是最常見的問題排查思路按優(yōu)先級排列排查項檢查方法常見原因動畫是否在播放看動畫藍(lán)圖的狀態(tài)機(jī)狀態(tài)機(jī)沒進(jìn)入該狀態(tài)Notify 是否在時間軸范圍內(nèi)檢查 TriggerTime時間軸被裁剪或 Notify 超出范圍是否被 Montage 覆蓋檢查 Montage 的 Notify 設(shè)置Montage 替換了序列的 Notify網(wǎng)絡(luò)角色是否正確檢查 bTriggerOnDedicatedServer服務(wù)器/客戶端設(shè)置反了動畫是否被中斷看中斷邏輯中斷導(dǎo)致 Notify 被跳過通知隊列是否被清空檢查 Flush 調(diào)用手動清空隊列導(dǎo)致丟失我踩過最坑的一次是Montage 里設(shè)置了bOverrideNotify把序列里的 Notify 全替換了但 Montage 本身沒配 Notify結(jié)果一個都不觸發(fā)。排查了半天才發(fā)現(xiàn)是 Montage 的覆蓋設(shè)置。5.2 Notify State 的 End 不執(zhí)行怎么辦Notify State 的NotifyEnd不執(zhí)行通常是因為動畫被強(qiáng)制中斷而中斷邏輯沒有正確處理活躍的 State。排查步驟確認(rèn)動畫是否正常播放到 EndTriggerTime如果動畫被中斷檢查中斷時是否調(diào)用了Montage_Stop或狀態(tài)切換在NotifyEnd里加日志確認(rèn)是否被調(diào)用檢查是否有多個 State 嵌套導(dǎo)致生命周期混亂一個實用的技巧在NotifyBegin里記錄狀態(tài)在NotifyEnd里清理。如果擔(dān)心 End 不執(zhí)行可以在角色 Tick 里加一個兜底檢查超時后強(qiáng)制清理。// 兜底清理示例 void AMyCharacter::Tick(float DeltaTime) { Super::Tick(DeltaTime); // 檢查無敵狀態(tài)是否超時 if (bIsInvincible InvincibleTimer MaxInvincibleTime) { SetInvincible(false); InvincibleTimer 0.0f; } }5.3 網(wǎng)絡(luò)同步下 Notify 重復(fù)觸發(fā)的處理多人游戲里Notify 重復(fù)觸發(fā)是個經(jīng)典問題。原因通常是服務(wù)器和客戶端都觸發(fā)了或者動畫回滾導(dǎo)致重復(fù)觸發(fā)。解決方案用 Guid 做去重在 Notify 回調(diào)里檢查該 Guid 是否已處理過邏輯類 Notify 只在服務(wù)器執(zhí)行客戶端通過屬性同步獲取結(jié)果表現(xiàn)類 Notify 用bTriggerOnDedicatedServer false只在客戶端觸發(fā)// 去重示例 void UMyNotify::Notify(...) { if (ProcessedGuids.Contains(EventReference.GetNotifyGuid())) { return; // 已處理過跳過 } ProcessedGuids.Add(EventReference.GetNotifyGuid()); // 執(zhí)行邏輯 }實操心得去重集合要定期清理否則會無限增長。我一般在動畫結(jié)束時清空或者用固定大小的環(huán)形緩沖。5.4 Notify 性能優(yōu)化的幾個切入點Notify 用多了會拖性能尤其是 Notify State 的 Tick。優(yōu)化方向關(guān)閉不必要的bTickNotify在 Notify 回調(diào)里避免復(fù)雜計算和內(nèi)存分配表現(xiàn)類 Notify 用對象池管理特效和音效批量處理相同類型的 Notify減少函數(shù)調(diào)用開銷實測數(shù)據(jù)一個角色身上同時有 20 個 Notify State 在 Tick每幀額外開銷約 0.3ms。如果場景里有 50 個角色就是 15ms直接吃掉一幀的預(yù)算。所以能不用 Tick 就不用。6. 從源碼看 Notify 系統(tǒng)的設(shè)計取舍6.1 為什么 Notify 是獨立 UObject 而不是結(jié)構(gòu)體把 Notify 設(shè)計成 UObject 而不是結(jié)構(gòu)體核心考慮是復(fù)用和引用。UObject 可以被多個動畫序列引用改一處配置所有引用處生效。如果做成結(jié)構(gòu)體每個動畫序列都要存一份數(shù)據(jù)改起來麻煩內(nèi)存也浪費(fèi)。但這也帶來了問題Notify 對象是共享的運(yùn)行時修改它的屬性會影響所有引用。所以 Notify 的屬性應(yīng)該是只讀的配置運(yùn)行時狀態(tài)要存在別的地方比如角色身上。6.2 通知隊列的延遲執(zhí)行設(shè)計前面提到Notify 的收集和分發(fā)是分開的。這個設(shè)計的好處是可以在收集階段做過濾和排序可以在分發(fā)前做網(wǎng)絡(luò)預(yù)測和回滾方便調(diào)試可以打印隊列內(nèi)容壞處是增加了延遲Notify 從觸發(fā)到執(zhí)行中間隔了一個 Flush 調(diào)用。在大多數(shù)情況下這個延遲可以忽略但在做精確幀同步時要注意。6.3 Notify State 的生命周期管理為什么容易出問題Notify State 的生命周期涉及多個狀態(tài)未激活、激活中、已結(jié)束。引擎用活躍列表來跟蹤但列表的維護(hù)依賴動畫時間的正確更新。如果動畫時間跳變比如快進(jìn)、回滾活躍列表可能和實際狀態(tài)不一致。源碼里的處理方式是每次更新時先檢查活躍列表里哪些應(yīng)該結(jié)束再檢查哪些應(yīng)該開始。這個順序很重要如果反過來可能出現(xiàn)同一個 State 被重復(fù) Begin。注意如果你的項目有動畫快進(jìn)或回滾需求要特別測試 Notify State 的行為。我遇到過回滾后 State 卡在激活狀態(tài)的問題最后是通過在回滾時強(qiáng)制清空活躍列表解決的。7. 幾個實戰(zhàn)中總結(jié)的避坑技巧7.1 Notify 命名規(guī)范與團(tuán)隊協(xié)作團(tuán)隊項目里Notify 命名要統(tǒng)一。我的建議是用前綴區(qū)分類型NS_表示 Notify StateN_表示普通 Notify用功能模塊做二級前綴N_Combat_Damage、NS_Movement_Invincible避免用中文或特殊字符雖然編輯器支持但跨平臺和版本管理容易出問題7.2 在編輯器里調(diào)試 Notify 的技巧UE5 編輯器提供了 Notify 調(diào)試工具在動畫序列編輯器里可以預(yù)覽 Notify 的觸發(fā)點在 PIE 里可以用ShowDebug Animation查看當(dāng)前活躍的 Notify在 Notify 回調(diào)里加UE_LOG輸出觸發(fā)時間和參數(shù)我習(xí)慣在開發(fā)階段給每個 Notify 加日志上線前用宏關(guān)掉。這樣排查問題時不用重新加代碼。7.3 Notify 與 GameplayAbility 的配合如果你的項目用了 GameplayAbilitySystemNotify 可以作為觸發(fā) Ability 的入口。常見做法是在 Notify 里調(diào)用TryActivateAbility把動畫和技能系統(tǒng)解耦。但要注意Ability 的激活有網(wǎng)絡(luò)延遲Notify 觸發(fā)時 Ability 可能還沒準(zhǔn)備好。我的做法是在 Notify 里發(fā)一個 GameplayEvent由 Ability 監(jiān)聽這個事件而不是直接激活 Ability。這樣更靈活也更好調(diào)試。7.4 版本升級時 Notify 的兼容性UE5 從 EA 到正式版Notify 的 API 有過幾次調(diào)整。比如Notify函數(shù)的參數(shù)從USkeletalMeshComponent*變成了帶FAnimNotifyEventReference的版本。升級引擎版本時要檢查自定義 Notify 的簽名是否匹配。另外Notify 資產(chǎn)的序列化格式也可能變化。升級前備份動畫資產(chǎn)升級后逐個檢查 Notify 是否正常。8. 從源碼延伸定制 Notify 系統(tǒng)的可能性8.1 自定義 Notify 的觸發(fā)條件引擎默認(rèn)的觸發(fā)條件是時間區(qū)間但你可以通過重寫FAnimNotifyEvent的相關(guān)函數(shù)來定制。比如基于角色狀態(tài)觸發(fā)只有在地面時才觸發(fā)基于輸入觸發(fā)只有玩家按下特定按鍵時才觸發(fā)基于概率觸發(fā)隨機(jī)決定是否觸發(fā)這些定制需要修改UAnimNotifyQueue的收集邏輯或者在 Notify 回調(diào)里做條件判斷。前者更徹底但改動大后者更簡單但每個 Notify 都要寫重復(fù)代碼。8.2 Notify 與動畫通知窗口的結(jié)合UE5 引入了動畫通知窗口Anim Notify Window允許在動畫藍(lán)圖的特定狀態(tài)下啟用或禁用 Notify。這個功能在源碼里是通過FAnimNotifyEvent::bEnabled和動畫藍(lán)圖的窗口狀態(tài)來控制的。如果你的項目有復(fù)雜的動畫狀態(tài)切換通知窗口可以幫你精確控制 Notify 的生效范圍。比如只在“攻擊”狀態(tài)下啟用傷害 Notify其他狀態(tài)下自動禁用。8.3 批量管理 Notify 的工具化思路項目大了之后Notify 數(shù)量會爆炸。手動管理不現(xiàn)實需要工具化寫一個編輯器工具掃描所有動畫序列列出 Notify 使用情況檢查重復(fù)的 Notify 配置合并冗余生成 Notify 使用報告方便 review這些工具可以用 Python 腳本或者 UE 的編輯器擴(kuò)展來實現(xiàn)。我寫過一個小工具能自動檢測未使用的 Notify 資源清理后項目體積小了不少。9. 我個人在實際項目中的幾點體會做動畫系統(tǒng)這些年Notify 是我用得最多也踩坑最多的模塊。最大的體會是不要把所有邏輯都塞進(jìn) Notify。Notify 適合做“動畫驅(qū)動的瞬時事件”不適合做“持續(xù)狀態(tài)管理”。狀態(tài)管理應(yīng)該交給 GameplayAbility 或者專門的組件Notify 只負(fù)責(zé)在正確的時機(jī)發(fā)出信號。另一個體會是網(wǎng)絡(luò)同步要提前設(shè)計。很多團(tuán)隊一開始不考慮多人等做到一半發(fā)現(xiàn) Notify 在客戶端和服務(wù)器行為不一致回頭改成本很高。我的建議是從第一個 Notify 開始就明確它是表現(xiàn)類還是邏輯類按不同的同步策略處理。最后分享一個小技巧在動畫序列編輯器里給重要的 Notify 加顏色標(biāo)記。UE5 支持自定義 Notify 的顯示顏色把傷害類標(biāo)紅、表現(xiàn)類標(biāo)藍(lán)、狀態(tài)類標(biāo)綠一眼就能看出動畫里有哪些關(guān)鍵節(jié)點。這個習(xí)慣幫我省了很多溝通成本美術(shù)和策劃也能看懂動畫里的邏輯分布。