本節內容繼續上一節教程的內容（如果沒有看過前面的教程，請前往學習），不會講太難的新東西，而是繼續探究技能標簽（Abiilty Tags）的內容。先來一道開胃菜。

第1.1步：

將上一次的召喚冰龍中的CancelAbilitiesWithTags清空，表示這個技能不會打斷任何其他技能。在“阻塞技能列表”BlockAbilitiesWithTags中配置Magic.Fire。

第1.2步：冰龍的激活邏輯修改為下圖所示，表示它也是耗時的技能。

第1.3步：運行，先釋放烈焰之鳥後釋放冰龍，從打印中可以看出：BlockAbilitesWithTags不會打斷烈焰之鳥。

先釋放冰龍，後釋放烈焰之鳥，從打印看出：烈焰之鳥在冰龍釋放的過程中不能釋放。

（這個圖可能說明不了什麽，請您自己動手實驗看看）

總結：某個Ability（A）中的BlockAbilitesWithTags（B）規定了“當A釋放時，B類技能無法釋放”。

下一組探究實驗（技能Buff和技能前置狀態）：

第2.1步：在ProjectSettings-GameplayTags中新加Buff.Fire這個Tag（其它的Buff我隨意添上了，不要緊）。

規定：在我這裏的例子中，Buff是給英雄（Character）用的，雖然結構本質上和AbilityTag一樣，但是意義上不是AbilityTag。

第2.2步：配置烈焰之鳥的“釋放者獲得標簽列表”（ActivationOwnedTags

烈焰之鳥的激活邏輯不改。

爆炎鳳凰的“釋放前置標簽列表”（ActivationRequiredTags）中添加Buff.Fire，表示爆炎鳳凰要求Character具有Buff.Fire標簽（從遊戲中說就是需要Buff狀態）。

第2.3步：在character的myabilities數組中加入爆炎鳳凰，並為它綁定釋放事件：

第2.4步：保存編譯運行。

實驗驗證：只有在烈焰之鳥釋放後，烈焰之鳥使Character具有Buff.Fire標簽，爆炎鳳凰才能夠釋放。

延伸知識：

·同樣，不做實驗地，介紹一個屬性：“釋放受阻標簽列表”ActivationBlockedTags

下一組實驗是官方給的一個例子。

第3.1步：聲明一個Ability，然後藍圖編輯如下。

第3.2步：概念說明：其中的OwnerActor表示此技能的擁有者（釋放者）。

第3.3步：在Character中綁這個Ability（綁在MyAbilities數組上即可，不過為什麽綁上去了就可以呢？原因是因為代碼裏有初始化，請見前面的教程），綁定輸入事件，這裏不給出圖片了。然後編譯運行。

第3.4步：效果如下圖：

這個例子中的targetdata如何自定義呢？目前還不清楚。

下一個概念是GameplayTasks，寫在GameplayAbility中的事件稱為GameplayTask，即

接下來是討論GameplayEffect，在藍圖處建立GameplayEffect：

查看其中的屬性：

先貼一段理論介紹（本文源於https://wiki.unrealengine.com/GameplayAbilities_and_You#GameplayTasks）：

Notable Variables

顯著的變量

Due to the unusual nature of Gameplay Effect blueprint classes, most of their variables are either simple values, other direct class references or just tags. There are too many to list and after explaining how abilities and their tags work, it should be fairly self-explanatory what most tags are used for, or do. It should however be noted that Gameplay Effects have 3 containers for each type of tag, one that is not directly editable, one that describes tags added on top of tags potentially owned from a parent and tags that are removed from a potential parent. Basically, this tag inheritance setup is one of relatively few reasons why Gameplay Effects are full-fledged UObject classes in the first place. Some of the more notable variables are:

由於遊戲效果藍圖類的特殊性質，它們的大部分變量都是簡單的值，其他直接的類引用或者僅僅是標記。有太多的東西要列出，在解釋了能力和標簽的工作原理之後，應該相當清楚地說明大多數標簽是用來做什麽的，或者是做什麽的。但是，應該註意的是，對於每種類型的標簽，遊戲效果有三個容器，一個不是直接可編輯的，一個是描述標簽上添加的標簽的標簽，這些標簽可能是來自一個潛在的父類和標簽的。基本上，這個標簽繼承設置是一個相對較少的原因，為什麽遊戲效果是一個成熟的UObject類。一些更值得註意的變量是:

Duration Policy: Is the effect instant, does it have a fixed duration, or does it go on infinitely? Do note that instant effects turn modifiers into permanent stat changes, and executions will be triggered immediately.

持續時間策略:效果是即時的，它有固定的持續時間，還是無限延伸?請註意，即時效果會將修改器變成永久性的屬性更改，並且會立即觸發執行。

Modifiers: Stat changes in all shapes and forms. Whether you want to add a flat amount to a stat, multiply a stat, divide, override with a fixed value or do any of these things in relation to other stats.

修飾詞:所有形狀和形式的變化。無論你是想要在一個數據中添加一個平量，還是要用一個固定值乘以一個固定值，或者用一個固定值來做這些事情。

Executions: Executions are an interesting case: They are essentially the functions the gameplay effect itself can‘t have (due to being meant to be as data-only as possible). An Execution takes a GameplayEffectExecutionCalculation as parameter, a class that is set up to define attributes to capture from both target and source, and to do things with them that would be considered too complex with modifiers alone. They are more or less meant to do as they please, however they cannot listen to events and such like abilities can do and pretty much only run in fixed, predefined intervals on timed GameplayEffects (and optionally once on application), or immediately on application in the case of instant GameplayEffects. They‘re your go-to for complex damage calculation and the likes. More on that later.

執行:執行是一個有趣的例子:它們本質上是遊戲效果本身不具備的功能(由於被認為是盡可能的數據)。執行GameplayEffectExecutionCalculation作為參數,設置定義的類屬性捕獲目標和源,並與他們做事情,會被認為太復雜修飾符。他們或多或少都是想按他們的意願去做，但是他們不能去聽事件，而且他們也只能在固定的、預先確定的時間間隔上運行遊戲效果(或者在應用程序上)，或者在即時遊戲效果的情況下立即應用。它們是你對復雜的損傷計算和喜好的首選。稍後將進行更詳細的討論。

Stacking: You know how in some games certain buffs/debuffs of one kind can stack on a target? This behaviour is managed here. By default all GameplayEffects of the same type will act and tick down independently (though requesting the amount of stacks of a gameplay effect will usually still show the total amount of effect instances of this type). There are options to make them all go on the same timer, removing one stack each time duration runs out, removing all of them once the timer runs out once, if application of a new stack refreshes the current duration or if there is a cap on stacks. You can get quite creative with these.

堆疊:你知道在一些遊戲中，某一種類的緩沖/ debuffs能在目標上疊加嗎?這種行為是在這裏管理的。默認情況下，相同類型的所有遊戲效果都是獨立運行的(盡管要求遊戲效果的堆棧的數量通常仍然顯示這種類型的效果實例的總數)。有一些選項可以讓它們都在相同的計時器上，每次刪除一個堆棧的時間持續時間，如果一個新堆棧的應用程序刷新當前的持續時間，或者如果在堆棧上有一個上限，那麽在計時器運行一次之後刪除所有的堆棧。你可以用這些來很有創意。

Overflow: Adding up on stacks, overflow effects are essentially effects that the affected actor will be affected by when the max amount of stacks of this gameplay event has been reached. If you get cold enough you freeze, breathe enough poison gas to get heavily poisoned, whatever, you get it.

溢出:在堆棧上加起來，溢出效應實際上是影響到受影響的參與者將會受到影響，當這個遊戲的最大數量的堆棧到達時。如果你變冷了，你會凍死，呼吸足夠的毒氣來毒死，無論如何，你都會得到它。

Display: You can define GameplayCues to use here. At their most basic, GameplayCues are essentially visual/audible effects that respond to a specialized tag they‘ve been assigned to. It needs to have "GameplayCue" as its parent tag, so an example tag could be "GameplayCue.DoT.Fire". You can call these directly in abilities too. They‘re a network-friendly way to spawn stuff like particle effects, cosmetic meshes and sound effects to provide your debuffs and skills with some eye candy. How they react to being called by the GameplayEffect/Ability is defined within the GameplayCue itself (there‘s 4 types of events a GameplayCue will respond to: On Applied (activates when applied), While Active (constantly triggers while active, presumably), Removed (when... well, removed) and Executed (this is interesting: When a GameplayEffect‘s execute classes run, this will play).

顯示:你可以在這裏定義遊戲提示。在最基本的情況下，遊戲提示基本上是視覺/聽覺效果，可以對被分配到的特殊標簽作出反應。它需要有“GameplayCue”作為它的父標簽，所以一個示例標簽可以是“GameplayCue.DoT.Fire”。你也可以直接把這些稱為能力。它們是一種網絡友好的方式來產生像粒子效應、化妝網和音效的東西，來為你的debuffs和技能提供一些eye candy。他們對被稱為遊戲效應/能力的反應是在遊戲提示本身中定義的(遊戲中有四種類型的事件:在應用時(激活時)，當激活時(大概是激活的時候)，被移除(當…好，刪除)和執行(這很有趣:當一個遊戲效果的執行類運行，這將會播放)。

GrantedAbilities: This has many uses. You may use a buff to temporarily provide an active ability as part of the buff(maybe a fire mage can give someone else a fire ability by igniting one of his allies? Heh, gotta love combat arson), but, more importantly, you can use these for effects that are too specific for modifiers but need to be permanently active in a way effect executions can‘t. If a gameplay effect is tagged to grant an actor an "OnFire" tag, you may have an ice buff with a passive ice ability granted listen for this event and remove the offending effect, as well as the ice buff itself (GameplayAbilities have a function just to allow them to remove the effect that granted them). Together with modifiers and executions, this allows you to do virtually anything with your effects.

天賦:這有很多用途。你可以用牛子暫時提供一個活躍的能力，作為牛子的一部分(也許一個火法師可以通過點燃他的一個盟友給其他人一個火的能力)。Heh，要熱愛戰鬥的縱火，但是，更重要的是，你可以使用這些效果，對於修飾語來說太具體了，但是需要在一個有效執行的方式中永遠保持活躍。如果一個遊戲效果是標記授予一個演員一個“OnFire”標簽,您可能有一個冰迷一個被動的冰能力授予監聽這個事件並刪除冒犯效果,以及冰迷本身(GameplayAbilities函數只是為了讓他們刪除授予他們的效果)。與修改器和執行一起，這使您可以對您的影響做任何事情。

It should be noted that most float values put into are not actually just plain float values, but rather a struct called FScalableFloat. You can use it just like any regular float, but there is an asset pointer to the right of the box where you‘d put the float value in. It may confuse you because there are no valid references to use, and there is no option to create a new one. This slot is reserved for a Curve Table, an asset you get by importing a csv, or file with a comparable table file format, into the project.

應該註意的是，大多數浮動值實際上並不是純浮點值，而是一個稱為FScalableFloat的struct。您可以像任何普通的浮點數一樣使用它，但是有一個資產指針指向方框的右邊，您可以將浮點值放入其中。它可能會使您感到迷惑，因為沒有有效的引用，也沒有創建新引用的選項。這個槽是為一個曲線表預留的，您可以通過導入一個csv文件或具有可比較的表文件格式的文件進入項目。

筆者的註釋，這裏的槽是指下圖紅框內容，使用時請無視此槽。

我稍微更改一下官方提供的GameplayEffect的例子，請隨筆者繼續探索：

第4.1步【建立一個GameplayEffect】：命名為GE_FireBuff，表示這個GE是火焰加成。

第4.2步【配置這個GE的時長】：雙擊打開，然後在ClassDefault中配置一下細節：

其中的DurationPolicy選擇HasDuration表示有時長限制，Scalable Float表示時長的相乘系數。在Period中配置時長。表示這個GE的長度是2.0*1.0 s的。

第4.3步【配置這個GE的天賦】：在Tags中看到“天賦加成列表”GrantedTags，在紅框位置添加Buff.Fire，在黃框部分將會被動地添加（不需要你手動寫上去）。

知識點：GrantedTags表示這個GE被施用在的那個角色上將會添加上這個Tag（Buff.Fire）。

延伸知識：你也能夠猜到，如果Added欄寫的是Buff，那麽Removed欄寫的是Debuff（消除某種Buff）。

理念強調：GameplayEffect是不寫事件的，它僅僅是一個數據儲存結構！

第4.4步【建立一個Ability】：命名為Abi_UseGEFire，然後寫上邏輯，其中重要的節點是ApplyGameplayEffectToOwner，表示施用這個GE給能力使用者。

第4.5步：請在Character中配置輸入事件，並且在MyAbilities數組上綁定這個Abi_UseGEFire，此處略圖。

第4.6步：運行。

實驗a：先嘗試釋放爆炎鳳凰，發現沒有釋放成功，因為人物沒有FireBuff（還記得嗎？前面需要釋放烈焰之鳥，使人物得到FireBuff之後才能夠釋放爆炎鳳凰），施用Abi_UseGEFire之後，再釋放爆炎鳳凰，是成功的。過了2s之後，沒有辦法釋放烈焰之鳥。

實驗b：將上面的scalable float更改為3，0，0.1,1000等數字查看一下效果，發現有點奇怪，好像不是相乘系數的意義。

實驗c：將上面的hasduration更改為instant，發現根本沒有辦法釋放爆炎鳳凰。

實驗d：將上面的hasduration更改為infinite，發現一直都可以釋放爆炎鳳凰。

實驗e：將上面的Added更改為Removed處填寫，然後釋放烈焰之鳥，之後釋放Abi_UseGEFire（此時是Debuff效果），然後釋放爆炎鳳凰，發現爆炎鳳凰還是能夠釋放出來（期望應該是不釋放的，實驗發現，這裏對removed有誤會，或者是有bug）。

下一組實驗是Cooldown冷卻（也就是CD）。

第5.1步：在GameplayTags面板中添加一個Tag稱為CD.Lieyanzhiniao

第5.2步：添加一個GameplayEffect，稱為CD_Lieyanzhiniao，你可以驚訝地發現，原來CD也是用GameplayEffect來實現的。

第5.3步：在CD_Lieyanzhiniao中配置Added標簽為CD.Lieyanzhiniao，有沒有很驚訝，因為這裏的天賦標簽竟然能夠也是CD的實現位置。

第5.4步：在CD_Lieyanzhiniao中配置CD的時長，這裏有兩個很令人困惑的數字，筆者發現更改上面的會有效果，建議兩個數字都寫成一樣的。這裏寫10表示10s中的冷卻時間。

第5.5步：在烈焰之鳥的Ability中更改：

其中白色框框裏面修改了“受阻標簽列表”，表示當人物具有CD.Lieyanzhiniao標簽的時候，此技能無法激活。

黃色框框是最重要的一個知識點了，CooldownGE規定了當此Ability被提交（commit ability）時，此GameplayEffect會被施用。在烈焰之鳥中添加如下一個CommitAbility的節點：

讓我們再來理清一下思路：

CD_Lieyanzhiniao（本質是GameplayEffect）規定了在施用時賦予給人物的便簽（CD.Lieyanzhiniao的標簽），施用烈焰之鳥時，立即提交Ability，然後烈焰之鳥中規定的CooldownGameplayEffect就會施用，使得人物得到CD.Lieyanzhiniao，然而Ability烈焰之鳥中受阻列表規定了CD.Lieyanzhiniao，所以烈焰之鳥將會在10s之內無法再次使用。

編譯運行，實驗結果正是如此。讓我們看看其描述：

下一節我們繼續學習屬性集AttributeSet。原創聲明：本文系小江村兒的文傑原創，若有參考的資料必在本文中給出。

——小江村兒的文傑 [email protected]

Unreal Engine 4（虛幻UE4）GameplayAbilities 插件入門教程（四）技能屏蔽和簡單的Buff等