1. 為什么ARPG戰(zhàn)斗要押注GAS而不是自己寫狀態(tài)機(jī)1.1 先說(shuō)說(shuō)我自己踩過(guò)的狀態(tài)機(jī)深坑今年初接了一個(gè)ARPG項(xiàng)目戰(zhàn)斗玩法不算特別復(fù)雜輕擊、重?fù)?、閃避、受擊硬直、霸體、處決外加敵人AI的一套攻擊邏輯。最初版本是團(tuán)隊(duì)前同事手寫的狀態(tài)機(jī)角色身上掛了個(gè)ECombatState枚舉從Idle到Attacking、Rolling、HitStun、Dying每個(gè)狀態(tài)在Tick里一堆switch判斷遇到攻擊中能否閃避受擊硬直中能不能被處決觸發(fā)這類組合條件就得在狀態(tài)轉(zhuǎn)換函數(shù)里疊好幾個(gè)if (bIsAttacking !bIsHitStun ...)。功能倒是都能跑但加需求的時(shí)候特別痛苦加一個(gè)重攻擊蓄力就要?jiǎng)用杜e、動(dòng)轉(zhuǎn)換表、動(dòng)動(dòng)畫藍(lán)圖稍不留神就漏掉某個(gè)邊界條件。后來(lái)我下決心把這套東西推翻用GAS重寫。選擇GAS不是因?yàn)樗鼤r(shí)髦是因?yàn)榭粗辛怂暮诵乃悸钒鸭寄軓慕巧a里徹底拆出來(lái)變成一個(gè)獨(dú)立的對(duì)象把狀態(tài)從布爾變量換成GameplayTag把數(shù)值變化全部收斂到GameplayEffect里走統(tǒng)一通道。這套思路天然適合ARPG——因?yàn)锳RPG戰(zhàn)斗本質(zhì)上就是大量技能攻擊動(dòng)作、閃避、Buff在各種狀態(tài)條件能否釋放、能否打斷下被觸發(fā)并在命中后產(chǎn)生一系列數(shù)值變化和表現(xiàn)反饋的過(guò)程。1.2 ARPG戰(zhàn)斗框架到底需要什么做ARPG戰(zhàn)斗框架落到實(shí)現(xiàn)層面需求其實(shí)很明確一是連招系統(tǒng)輕擊重?fù)裟芘缮?、能取消輸入窗口要接得住二是閃避和受擊這類瞬時(shí)狀態(tài)需要在正確時(shí)機(jī)給無(wú)敵幀或硬直三是傷害數(shù)值要一套統(tǒng)一的結(jié)算路徑不能讓每個(gè)技能自己寫一套扣血邏輯四是Buff和Debuff系統(tǒng)比如燃燒、減速、霸體、破防五是表現(xiàn)層反饋受擊特效、震屏、擊打停頓這些不能和邏輯強(qiáng)耦合。GAS恰好覆蓋了大部分Ability管技能行為、Task管異步流程、Tag管狀態(tài)條件、Effect管數(shù)值和Buff、Cue管表現(xiàn)反饋。但它也明確不覆蓋手感調(diào)校和動(dòng)畫融合這部分還是得用輸入系統(tǒng)、動(dòng)畫藍(lán)圖、移動(dòng)組件自己處理。所以我的建議是GAS負(fù)責(zé)戰(zhàn)斗的邏輯骨架手感相關(guān)的東西仍然在外部配合——它不會(huì)替你做好ARPG但能讓你不再被狀態(tài)機(jī)的復(fù)雜度拖死。2. 頂層骨架怎么搭A(yù)SC掛載、AttributeSet與Tag體系2.1 AbilitySystemComponent該掛在誰(shuí)身上GAS最核心的組件是UAbilitySystemComponent后面統(tǒng)一叫ASC所有Ability、Effect、Attribute都通過(guò)它來(lái)運(yùn)轉(zhuǎn)。我的做法是玩家角色、敵人角色、甚至場(chǎng)景里的可破壞物只要參與戰(zhàn)斗或者會(huì)被戰(zhàn)斗影響都在Character上掛一個(gè)ASC。掛Character而不掛Controller是因?yàn)閿橙薃I也經(jīng)常切換Controller比如Boss戰(zhàn)切AI、處決時(shí)切玩家控制掛在Character上生命周期穩(wěn)定。初始化時(shí)機(jī)是個(gè)大坑。ASC必須在PossessedBy之后調(diào)用InitAbilityActorInfo不能在BeginPlay里就初始化——因?yàn)樾枰狝vatarActor和OwnerActor都正確設(shè)置。玩家這邊我在APlayerController::OnPossess里調(diào)敵人那邊在AIController的OnPossess里調(diào)。初始化之后第二步是GiveAbility把角色的基礎(chǔ)技能輕擊、重?fù)簟㈤W避、處決通過(guò)FGameplayAbilitySpec給進(jìn)ASC這一步可以在初始化同一個(gè)函數(shù)里做也可以用UGameplayAbilityDataAsset做配置化批量賦予。偽代碼示意 void AMyCharacter::InitGAS() { AbilitySystemComponent-InitAbilityActorInfo(this, this); FGameplayAbilitySpec Spec(MyComboAbilityClass, 1, INDEX_NONE, this); AbilitySystemComponent-GiveAbility(Spec); }有個(gè)細(xì)節(jié)值得注意GiveAbility返回FGameplayAbilitySpecHandle如果技能后續(xù)要移除或者做冷卻查詢這個(gè)Handle要存下來(lái)。但大部分情況技能是常駐的不用特意存用Tag查詢FindAbilitySpecFromInputTags或者TryActivateAbilitiesByTag會(huì)更方便。2.2 AttributeSet設(shè)計(jì)血量、精力、霸體UAttributeSet承擔(dān)所有戰(zhàn)斗數(shù)值的存儲(chǔ)。我項(xiàng)目里自定義了一個(gè)UMyAttributeSet主要屬性包括Health、MaxHealth、Stamina、MaxStamina、Poise霸體值、MaxPoise外加一個(gè)Meta屬性Damage。按GAS慣例Attribute只存當(dāng)前值變化邏輯不寫在AttributeSet的業(yè)務(wù)代碼里——玩家回血、敵人扣血都通過(guò)GameplayEffect去改數(shù)值A(chǔ)ttributeSet只負(fù)責(zé)在屬性被改之后做收尾工作。Damage這個(gè)Meta屬性是個(gè)經(jīng)典用法攻擊方的Effect不直接扣Health而是往Damage上加一個(gè)數(shù)值然后在目標(biāo)AttributeSet的PostGameplayEffectExecute里統(tǒng)一做防御減免計(jì)算再真正扣Health。這樣所有傷害都走同一條結(jié)算路徑物理攻擊、魔法攻擊、真實(shí)傷害的區(qū)別只是改了不同系數(shù)。void UMyAttributeSet::PostGameplayEffectExecute(const FGameplayEffectModCallbackData Data) { Super::PostGameplayEffectExecute(Data); if (Data.EvaluatedData.Attribute GetDamageAttribute()) { const float Damage GetDamage(); SetDamage(0.f); const float FinalDamage FMath::Max(0.f, Damage - GetArmor()); SetHealth(FMath::Clamp(GetHealth() - FinalDamage, 0.f, GetMaxHealth())); // 這里廣播血條更新事件并且當(dāng) Health 0 時(shí)添加死亡Tag if (GetHealth() 0.f !Data.Target.HasMatchingTag(StateTag::Dying)) { Data.Target.AddLooseGameplayTag(StateTag::Dying); } } }另外所有需要網(wǎng)絡(luò)同步的Attribute都必須標(biāo)記FOnRep并做屬性復(fù)制否則聯(lián)機(jī)時(shí)客戶端看到的是客戶端本地預(yù)測(cè)值回包一校準(zhǔn)就跳變。單機(jī)項(xiàng)目可以偷懶但一旦要加聯(lián)機(jī)這塊一個(gè)都不能漏。2.3 GameplayTag用標(biāo)簽替代布爾狀態(tài)我把角色所有戰(zhàn)斗狀態(tài)全部Tag化替代原本的布爾變量。比如State.Attacking.Light、State.Attacking.Heavy、State.Rolling、State.HitStun、State.Invincible、State.Dying、State.CanCombo。用Tag最大的好處是技能激活條件可以直接聲明不用在代碼里寫一串if (bAttacking !bHitStun)。具體做法是在UGameplayAbility的子類上配置ActivationBlockedTags被哪些Tag擋住就不能激活和ActivationRequiredTags必須有哪些Tag才能激活。以閃避為例ActivationBlockedTags里放State.Dying、State.HitStunActivationRequiredTags放State.CanMove這樣角色倒地時(shí)技能系統(tǒng)自己會(huì)拒絕激活閃避完全不用我在輸入回調(diào)里手動(dòng)判狀態(tài)。Tag還有個(gè)隱藏價(jià)值它天然是多標(biāo)簽并存的。一個(gè)角色可以同時(shí)處于State.Attacking.Light和State.CanCombo布爾變量這種組合狀態(tài)管理起來(lái)極其痛苦Tag集合卻毫無(wú)壓力。Debug的時(shí)候開GAS自帶調(diào)試器或者打印AbilitySystemComponent-GetLooseGameplayTags()一眼能看全角色當(dāng)前狀態(tài)。3. 技能層拆解Ability、Task、Effect、Cue各司其職3.1 GameplayAbility的實(shí)例化策略怎么選UGameplayAbility有三種實(shí)例化策略選錯(cuò)會(huì)在奇怪的地方出Bug。我項(xiàng)目里90%的技能用InstancedPerActor也就是技能實(shí)例在角色身上存一份跨多次激活復(fù)用。連招技能必須用它因?yàn)檫B招計(jì)數(shù)、當(dāng)前命中列表、蓄力狀態(tài)這些中間變量要保存在實(shí)例里技能結(jié)束不銷毀下次激活再接著讀。InstancedPerExecution用于一次性技能比如投擲物、召喚物每次激活生成新實(shí)例激活結(jié)束就銷毀。好處是并發(fā)安全——如果同一個(gè)技能可以在短時(shí)間內(nèi)觸發(fā)多次連發(fā)子彈每次觸發(fā)互不干擾。代價(jià)是每次都付出構(gòu)造開銷以及你不能在實(shí)例里留跨觸發(fā)狀態(tài)。NonInstanced最省性能但限制極大整個(gè)技能不能有任何成員變量所有數(shù)據(jù)都得從外部傳入。我基本不用ARPG技能普遍有狀態(tài)強(qiáng)行NonInstanced會(huì)讓代碼丑到?jīng)]法維護(hù)。非要說(shuō)什么時(shí)候用大概是那些純函數(shù)式的輔助技能比如一個(gè)只負(fù)責(zé)施加某個(gè)Buff的觸發(fā)器但這種場(chǎng)景我也更愿意用Effect本身來(lái)實(shí)現(xiàn)不繞一層Ability。3.2 AbilityTask串聯(lián)異步流程技能里大量的等待邏輯等動(dòng)畫播到某個(gè)Notify、等玩家按下輸入、等延遲結(jié)束。GAS把這套封裝成了AbilityTask最常用的幾個(gè)是PlayMontageAndWait播放技能蒙太奇并等待結(jié)束/被打斷WaitInputPressWithTiming在時(shí)間窗口內(nèi)等待輸入按下WaitGameplayEvent等待任意處廣播的GameplayEventWaitDelay單純等時(shí)間連招的實(shí)現(xiàn)就是靠Task串聯(lián)起來(lái)的。一個(gè)輕擊技能激活后先播放一段蒙太奇蒙太奇分好幾個(gè)SectionAttack_1、Attack_2、Attack_3。在第一段攻擊的收尾階段技能里掛一個(gè)WaitInputPressWithTiming如果玩家在窗口期內(nèi)按下輕擊就往Attack_2Section跳沒按就等蒙太奇播完自然結(jié)束。void UGA_ComboLightAttack::ActivateAbility(...) { Super::ActivateAbility(...); MontageTask UAbilityTask_PlayMontageAndWait::PlayMontageAndWait( this, NAME_None, ComboMontage, FGameplayTagContainer(), 1.0f, NAME_None, true); MontageTask-OnCompleted.AddDynamic(this, ThisClass::OnMontageCompleted); MontageTask-OnInterrupted.AddDynamic(this, ThisClass::OnMontageInterrupted); MontageTask-ReadyForActivation(); WaitInputTask UAbilityTask_WaitInputPressWithTiming::WaitInputPressWithTiming(this); WaitInputTask-OnPress.AddDynamic(this, ThisClass::OnComboInputPressed); WaitInputTask-ReadyForActivation(); }Task是所有異步控制的骨架但它也有個(gè)麻煩的點(diǎn)生命周期。Task是Ability的附屬對(duì)象Ability結(jié)束時(shí)Task通常會(huì)跟著清理但如果你在Task回調(diào)里調(diào)用EndAbility而Ability其實(shí)已經(jīng)被外部End了就會(huì)Assert崩潰。后面第五章我會(huì)把這類坑集中講。3.3 GameplayEffect傷害結(jié)算與Buff統(tǒng)一入口GAS里所有數(shù)值變化都走UGameplayEffect。按DurationPolicy分三類Instant瞬時(shí)生效傷害、回血、Infinite持續(xù)生效直到被移除增益Buff、霸體狀態(tài)、HasDuration定時(shí)結(jié)束中毒、燃燒、減速。傷害Effect我配了一個(gè)基礎(chǔ)模板Modifier部分往目標(biāo)的Damage屬性加一個(gè)數(shù)值這個(gè)數(shù)值來(lái)自技能數(shù)據(jù)資產(chǎn)傳入的攻擊力。Buff類Effect就五花八門了燃燒是HasDuration的Effect每秒通過(guò)PeriodicExecution執(zhí)行一次傷害霸體是InfiniteEffectModifier修改目標(biāo)Poise屬性上限或每秒回滿目標(biāo)有霸體Effect時(shí)收到的攻擊硬直Tag就被技能系統(tǒng)的Tag條件過(guò)濾掉減速是InfiniteEffectModifier修改移動(dòng)速度。字段里有個(gè)容易被忽略的TargetTags配置它控制這個(gè)Effect能不能作用在目標(biāo)身上。我這個(gè)項(xiàng)目里處決處決技能就是一個(gè)特殊的傷害Effect要求目標(biāo)帶有State.ExecutionableTag才能應(yīng)用否則直接不生效。這種比在代碼里寫if (Target-HasTag(...))要規(guī)整得多因?yàn)榕卸ㄖ苯訉懺谂渲美锊邉澑钠饋?lái)不用碰代碼。3.4 GameplayCue把表現(xiàn)層從邏輯層剝離開UGameplayCue專門處理表現(xiàn)反饋命中火花、受擊音效、擊打停頓、震屏、飄字。它和GameplayEffect最大的區(qū)別是——Cue不改變?nèi)魏螖?shù)值只負(fù)責(zé)看起來(lái)發(fā)生了什么。我的做法是在命中確認(rèn)后攻擊方Execute一個(gè)Cue.HitImpact帶上命中點(diǎn)、命中方向、是否暴擊等上下文數(shù)據(jù)。Cue本身是個(gè)藍(lán)圖類里面根據(jù)上下文決定播放哪個(gè)粒子、是否觸發(fā)HitStop、是否推動(dòng)相機(jī)震動(dòng)。這樣傷害邏輯和表現(xiàn)完全解耦換一套特效風(fēng)格不用動(dòng)任何C代碼只替換Cue資產(chǎn)。Cue的類型要注意選對(duì)純特效音效用Static需要跟隨目標(biāo)Actor的貼花/持續(xù)特效用Actor聯(lián)機(jī)里需要本地預(yù)測(cè)表現(xiàn)比如自己受擊時(shí)的屏幕紅框用Local。表現(xiàn)事務(wù)不要過(guò)度設(shè)計(jì)Cue只做表現(xiàn)別在Cue里寫傷害計(jì)算否則調(diào)試會(huì)成為噩夢(mèng)。4. 一條輕擊連招的完整鏈路從按鍵到傷害結(jié)算4.1 輸入處理與Ability激活UE5推薦用Enhanced Input。我在PlayerController里監(jiān)聽輕擊的IA_LightAttack動(dòng)作觸發(fā)后直接調(diào)用AbilitySystemComponent-TryActivateAbilitiesByTag傳入Input.Attack.Light這個(gè)Tag。為什么用Tag而不用Handle因?yàn)檩p擊技能可能多段每一段都是一個(gè)獨(dú)立Ability我用的是多Ability方案而不是單Ability跳Section方案下面細(xì)說(shuō)用Tag激活能自動(dòng)匹配到當(dāng)前連擊階段對(duì)應(yīng)的那個(gè)Ability。ASC內(nèi)部會(huì)先檢查這個(gè)Ability的ActivationBlockedTags、ActivationRequiredTags、是否在冷卻中等條件全部通過(guò)才真正激活。輸入回調(diào)里不需要判斷角色當(dāng)前能不能攻擊這個(gè)判斷全部下沉到Ability身上代碼會(huì)干凈非常多。實(shí)際暴力實(shí)現(xiàn)void AMyPlayerController::OnLightAttack(const FInputActionValue Value) { if (UAbilitySystemComponent* ASC GetPawn()-FindComponentByClassUAbilitySystemComponent()) { FGameplayTagContainer TagContainer; TagContainer.AddTag(InputTag::Attack_Light); ASC-TryActivateAbilitiesByTag(TagContainer); } }多段實(shí)現(xiàn)我最后選了每個(gè)攻擊段一個(gè)Ability子類GA_Attack01、GA_Attack02、GA_Attack03。它們共用一套父類邏輯只是蒙太奇Section、傷害倍率、攻擊范圍各有DataAsset配置。連擊計(jì)數(shù)存在角色ASC上的一個(gè)自定義FGameplayTag上Combo.Index.2表示當(dāng)前第二段。GA_Attack02的ActivationRequiredTags要求有Combo.Index.1而GA_Attack01要求無(wú)連擊Tag或連擊已過(guò)期。這套方案比單個(gè)Ability內(nèi)部跳Section更清晰因?yàn)槊恳欢味际仟?dú)立資源冷卻、消耗、預(yù)測(cè)策略各配各的后面擴(kuò)展重?fù)舴种Щ蛘咛囟ǘ慰尚盍Χ疾挥脛?dòng)其他段。4.2 連段派生與輸入窗口管理實(shí)際手感上連招最難調(diào)的是輸入窗口玩家必須在第一段攻擊的后半段或落地瞬間按下一次輕擊第二段才會(huì)銜接上否則回到待機(jī)。窗口太短像便秘太長(zhǎng)像無(wú)腦連點(diǎn)。我在每段攻擊的Montage里在收招動(dòng)作的合適時(shí)間點(diǎn)放一個(gè)Notify這個(gè)Notify觸發(fā)時(shí)Send一個(gè)Event.ComboWindow.Open給ASC。Ability用WaitGameplayEvent接收這個(gè)事件事件到來(lái)后才真正激活下一段的WaitInput。用事件方式而不是固定WaitDelay是為了讓窗口時(shí)機(jī)和動(dòng)畫幀完全對(duì)齊——不同武器的攻擊動(dòng)畫可能有快有慢但窗口邏輯代碼完全不用改。窗口窄一些反而手感更實(shí)。我調(diào)參的經(jīng)驗(yàn)是窗口開放時(shí)間設(shè)0.2秒左右但輸入輸入本身要Enable Move Cancel否則玩家連招中想移動(dòng)會(huì)被卡在攻擊動(dòng)作里等完整個(gè)蒙太奇特別難受。移動(dòng)取消的邏輯也是Tag方案攻擊段Ability的Montage被打斷時(shí)會(huì)清理State.AttackingTag并EndAbility移動(dòng)能力有ActivationRequiredTags包含State.CanMove所以攻擊中它不會(huì)被激活一旦攻擊Tag移除移動(dòng)立刻恢復(fù)這個(gè)過(guò)渡是實(shí)時(shí)的。4.3 傷害判定武器拖尾還是球形掃描傷害判定這塊我試過(guò)兩種方案。第一種是武器碰撞體物理檢測(cè)武器掛個(gè)Collision Box動(dòng)畫里開啟碰撞、關(guān)閉碰撞。這套的優(yōu)點(diǎn)是判定貼合武器模型砍中哪就是哪缺點(diǎn)是物理引擎介入性能開銷大而且容易誤觸發(fā)靜態(tài)環(huán)境碰撞。最終我選了球形掃描在Montage的命中幀Notify里從武器Socket位置打一條SphereTraceMulti半徑根據(jù)武器長(zhǎng)度配置短劍60、大劍100起點(diǎn)是武器Socket終點(diǎn)是Socket往前加一個(gè)武器長(zhǎng)度的向量。命中后拿Hit的Actor檢查對(duì)方有沒有ASC有就用ApplyGameplayEffectSpecToTarget把預(yù)制的傷害EffectSpec打過(guò)去。// 在攻擊Notify里觸發(fā) void UMyAbilityTask_TraceHit::DoTrace() { TArrayFHitResult Hits; const FVector Start WeaponComp-GetSocketLocation(Socket_Blade); const FVector End Start GetOwnerActor()-GetActorForwardVector() * WeaponLength; FCollisionQueryParams Params; Params.AddIgnoredActor(GetAvatarActor()); GetWorld()-SweepMultiByChannel(Hits, Start, End, FQuat::Identity, ECC_GameTraceChannel1, FCollisionShape::MakeSphere(TraceRadius), Params); for (const FHitResult Hit : Hits) { AActor* HitActor Hit.GetActor(); if (HitActors.Contains(HitActor)) continue; HitActors.Add(HitActor); if (UAbilitySystemComponent* TargetASC UAbilitySystemBlueprintLibrary::GetAbilitySystemComponent(HitActor)) { ApplyDamageEffect(TargetASC); ExecuteHitCue(Hit); } } }仔細(xì)看上面這段HitActors數(shù)組就是為了防止同一次攻擊的多個(gè)Substep如果一刀有多個(gè)判定幀重復(fù)命中同一個(gè)怪。連段結(jié)束后清空數(shù)組下一段攻擊重新收集。這個(gè)細(xì)節(jié)如果你不處理就會(huì)出現(xiàn)一刀跳三次傷害的經(jīng)典Bug。4.4 命中反饋的完整鏈路每次命中從攻擊方角度到受擊方角度鏈路是這樣的攻擊方的TraceTask檢測(cè)到目標(biāo)跑一遍HitActors去重攻擊方生成傷害GE Spec調(diào)用ApplyGameplayEffectSpecToTarget把Spec發(fā)給目標(biāo)ASC目標(biāo)ASC收到按GE里配置的Modifier往目標(biāo)的DamageMeta屬性上加值目標(biāo)AttributeSet觸發(fā)PostGameplayEffectExecute算出減免后的真實(shí)傷害扣Health目標(biāo)ASC檢測(cè)到Health變化廣播OnHealthChanged委托如果血?dú)w零給自身添加State.DyingTag攻擊方同時(shí)Execute一個(gè)GameplayCue播命中特效、震屏、HitStop擊打停頓目標(biāo)如果處于可受擊狀態(tài)沒有霸體Tag給它加一個(gè)State.HitStunTag目標(biāo)的動(dòng)畫藍(lán)圖監(jiān)聽這個(gè)Tag播受擊動(dòng)畫我非常推薦把受擊硬直的處理放在受擊方自己的ASC和動(dòng)畫藍(lán)圖里而不是讓攻擊方直接調(diào)目標(biāo)播放受擊動(dòng)畫。原因很簡(jiǎn)單以后加一個(gè)BossBoss可能對(duì)特殊攻擊免疫受擊或者受擊動(dòng)畫有自己的一套規(guī)則如果攻擊方直接控制目標(biāo)表現(xiàn)這些差異就得寫在一堆if (EnemyType Boss)里完全沒有擴(kuò)展性。Tag 各方自行響應(yīng)才是合理的解耦方式。5. 避坑清單幀率、Montage與網(wǎng)絡(luò)同步5.1 AbilityTask的取消與崩潰這套框架跑起來(lái)后我遇到的第一個(gè)頑固Bug是技能已經(jīng)因?yàn)槭軗舯淮驍嗟皰斓腡ask還在回調(diào)回調(diào)里又去訪問(wèn)已經(jīng)釋放的資源直接Assert。根因是Ability End時(shí)Task不一定自動(dòng)回收或者說(shuō)Task的回調(diào)委托還掛在事件源上。我的統(tǒng)一處理是寫了一個(gè)基類UMyGameplayAbility在EndAbility里統(tǒng)一做這幾件事void UMyGameplayAbility::EndAbility(...) { // 先取消所有子Task防止異步回調(diào) UAbilitySystemComponent* ASC GetAbilitySystemComponentFromActorInfo(); if (ASC) { ASC-CancelAbilities(GetCurrentAbilitySpec()-Ability-AbilityTags); } Super::EndAbility(...); }同時(shí)任何Task回調(diào)尤其是WaitGameplayEvent里如果要結(jié)束技能都先判IsEndAbilityValid()if (IsEndAbilityValid()) { EndAbility(CurrentSpecHandle, CurrentActorInfo, CurrentActivationInfo, true, false); }另外一個(gè)常見崩潰是Montage被打斷PlayMontageAndWait的OnInterrupted和OnBlendOut都會(huì)觸發(fā)但這時(shí)Ability可能已經(jīng)End了或者M(jìn)ontage所在的AnimInstance已經(jīng)被切換。我的做法是這三個(gè)回調(diào)都走同一個(gè)收口函數(shù)收口函數(shù)里統(tǒng)一檢查IsEndAbilityValid()再做對(duì)應(yīng)處理不要各寫各的邏輯。5.2 Montage與AbilityTask的節(jié)奏同步Montage的Rate Scale播放速度是個(gè)隱蔽的大坑。技能里我做了個(gè)子彈時(shí)間功能處決動(dòng)畫時(shí)全局時(shí)間放慢用UGameplayStatics::SetGlobalTimeDilation實(shí)現(xiàn)。但問(wèn)題來(lái)了——Montage的播放是受全局時(shí)間膨脹影響的而AbilityTask里的WaitDelay用的是真實(shí)時(shí)間兩者會(huì)錯(cuò)開。同樣Montage的Notify觸發(fā)也會(huì)受Rate Scale影響。所以我的判定幀Notify是放在Montage里的它有動(dòng)畫綁定Rate Scale變化時(shí)依然和動(dòng)畫畫面對(duì)齊。但依靠等幾秒后執(zhí)行的Task邏輯比如連段輸入窗口關(guān)閉我用的是GameplayEvent來(lái)自Montage Notify而不是純WaitDelay確保所有邏輯節(jié)奏都綁定動(dòng)畫而不是綁定時(shí)鐘。順手提一句RootMotion攻擊技能里如果帶位移比如前沖斬我建議蒙太奇啟用RootMotion from Montage能力但移動(dòng)組件要配合設(shè)置否則經(jīng)常出現(xiàn)動(dòng)畫往左砍角色原地不動(dòng)的詭異手感。這塊當(dāng)初調(diào)了整整兩天其實(shí)核心就是檢查UCharacterMovementComponent的bAllowPhysicsRotationDuringAnimRootMotion和Montage里RootMotion Track是否設(shè)置正確。5.3 網(wǎng)絡(luò)同步與預(yù)測(cè)策略如果是純單機(jī)ARPG這節(jié)可以跳過(guò)。但凡你有任何聯(lián)機(jī)計(jì)劃包括以后可能加合作模式框架設(shè)計(jì)就得提前考慮網(wǎng)絡(luò)。GAS的基本網(wǎng)絡(luò)模型是ASC是Server權(quán)威的GameplayEffect對(duì)屬性的修改必須在Server上執(zhí)行客戶端變更只是預(yù)測(cè)。預(yù)測(cè)最常見的是客戶端按下技能ASC立刻激活A(yù)bility并播放MontageServer幾幀后才確認(rèn)如果Server判定不能激活比如技能還在冷卻客戶端本地會(huì)回滾。這個(gè)回滾機(jī)制GAS自帶但你要付出的代價(jià)是任何客戶端預(yù)測(cè)執(zhí)行期間修改的數(shù)據(jù)都必須在預(yù)測(cè)Key的管理下否則回滾時(shí)會(huì)發(fā)現(xiàn)狀態(tài)沒法還原。實(shí)戰(zhàn)里我遇到最多的是傷害重復(fù)客戶端預(yù)測(cè)了一次傷害Server又處理了一次目標(biāo)被扣了兩遍血。解決方案很簡(jiǎn)單——傷害的GE應(yīng)用只在Server端做判斷HasAuthority()后在Server執(zhí)行客戶端只跑Cue表現(xiàn)和Montage。蒙太奇播放可以是本地的性能也更好但最終血量變化以Server為準(zhǔn)血條靠Attribute復(fù)制回到客戶端。還有GameplayCue的網(wǎng)絡(luò)分類Static和Actor類Cue默認(rèn)只在Server執(zhí)行再多播Local類Cue可以客戶端自己預(yù)測(cè)執(zhí)行。像自己角色受擊屏幕震動(dòng)這種用Local類型不然聯(lián)機(jī)時(shí)受擊反饋會(huì)有你無(wú)法忍受的延遲。5.4 調(diào)試工具與DataAsset組織最后給兩個(gè)效率建議。第一個(gè)是強(qiáng)烈建議開啟GAS調(diào)試器控制臺(tái)執(zhí)行AbilitySystem.Debug等命令可以實(shí)時(shí)查看每個(gè)角色身上的Ability列表、Tag集合、Attribute數(shù)值、冷卻進(jìn)度。當(dāng)年我在看一個(gè)技能明明給了但激活不了的Bug時(shí)就是靠調(diào)試器看到ActivationBlockedTags里混進(jìn)了一個(gè)不該有的Tag一眼定位。第二個(gè)是技能數(shù)據(jù)全部DataAsset化。我為每個(gè)技能建了一個(gè)UMyGameplayAbilityData里面存Montage引用、傷害倍率、攻擊范圍、消耗精力值、技能Tag集合。Ability從DataAsset讀取參數(shù)C里沒有硬編碼的數(shù)值。策劃調(diào)平衡時(shí)只改資產(chǎn)不動(dòng)代碼。這套Battle Monster、Lyra都在用確實(shí)是GAS項(xiàng)目里組織數(shù)據(jù)的主流方案。6. 若干實(shí)戰(zhàn)經(jīng)驗(yàn)以及這套框架后續(xù)還能怎么擴(kuò)展6.1 實(shí)測(cè)下來(lái)最值得堅(jiān)持的三個(gè)決定這套框架跑完整個(gè)Demo后我回頭總結(jié)有三個(gè)決定是最值得堅(jiān)持的。第一是把受擊硬直、霸體這類被動(dòng)反饋全部收斂到Tag和Effect主力代碼里幾乎看不到if (bHit)這種分支第二是傷害路徑強(qiáng)制走GE Meta Attribute哪怕是一個(gè)只有5點(diǎn)傷害的彈幕子彈也走同一套結(jié)算原因很簡(jiǎn)單——以后要加暴擊、免傷、護(hù)盾、吸血全部能在結(jié)算通道里統(tǒng)一處理逐個(gè)技能去改的苦我受過(guò)不打算再受第三是每一段攻擊都做成獨(dú)立Ability配合DataAsset配置雖然資產(chǎn)數(shù)量多了但擴(kuò)展新的連段分支幾乎零成本。6.2 踩過(guò)幾次坑之后的幾個(gè)小提醒這里幾條是我掏心窩子的話寫給正準(zhǔn)備上GAS的同行ASC的InitAbilityActorInfo時(shí)機(jī)千萬(wàn)別放在BeginPlay之前AttributeSet的所有屬性記得標(biāo)記復(fù)制游戲跑起來(lái)發(fā)現(xiàn)聯(lián)機(jī)血條亂跳再回頭補(bǔ)是最痛苦的Enemy和Player別共享同一個(gè)AttributeSet類實(shí)例各給各的否則Boss戰(zhàn)你改敵人血量時(shí)不小心把玩家血量也改了。調(diào)試期建議一上來(lái)就把GameplayTag命名規(guī)范定好State.、Event.、Input.、Cue.前綴區(qū)分清楚。Tag命名亂了的項(xiàng)目后期搜索都搜不明白比代碼亂還可怕。6.3 這套框架后續(xù)可以怎么擴(kuò)展框架穩(wěn)定后往幾個(gè)方向擴(kuò)展都挺順暢。想做武器系統(tǒng)給每種武器一套獨(dú)立的Montage和傷害范圍配置換武器就是換DataAsset和Tag集合想做元素反應(yīng)給傷害GE加GameplayTagContainer屬性用Tag匹配來(lái)做元素附著再掛定期Effect想做敵人AI技能把Boss的每個(gè)招式配成一個(gè)Ability由BehaviorTree在合適時(shí)機(jī)TryActivateAbilitiesByTagAI和玩家都走同一套底層省掉兩套邏輯維護(hù)的成本。GAS這套框架學(xué)起來(lái)確實(shí)有門檻它的概念密度比大部分UE子系統(tǒng)都高但一旦骨架搭對(duì)ARPG戰(zhàn)斗的復(fù)雜度會(huì)從狀態(tài)機(jī)地獄變成配置資產(chǎn)拆分技能的良性結(jié)構(gòu)。如果你正在糾結(jié)要不要用我的建議是別猶豫上但把精力集中在Tag設(shè)計(jì)和Ability拆分上那才是這套框架真正的命門。