斯坦福课程 UE4 C++ ActionRoguelike游戏实例教程 0.绪论
概述
本篇文章对应Lecture 17 - GameplayTags， 67、67节。本文将会讲述UE4中GameplayTag的概念，并使用GameplayTag系统实现不同技能的互斥效果。
具体来说，本文将解决在使用技能的时候会被其他技能打断的问题（例如疾跑的同时发射魔法子弹，攻击未结束的时候还能继续攻击等）。
目录
- 认识GameplayTag
- 添加GamePlayTag
- 实现技能间的互斥
认识GamePlayTag
在上一节课实现的Action System（能力系统）中遗留了一个问题，就是技能在释放的过程中可以同时释放其他技能，例如，按住shift进行疾跑的时候，我们可以同时点击鼠标左键进行攻击。
虽然在某些玩法层面上好像没什么问题，但是对于程序员来说，这是不可控的。我们现在希望，在技能释放的时候，不允许其他技能同时释放。除此以外，我们还希望有更多的自由度，可以选择哪些技能可以被“柔化”。就像某些格斗游戏(例如DNF)一样，普通攻击可以被一些灵活的小技能打断，而施法时间长的技能你只能眼睁睁的看着技能释放完毕，期间的任何操作都不会被响应。
要实现这个功能，最简单的办法就是为你的角色添加一系列bool值，比如IsSprinting，IsAttacking之类的，在每次释放技能的时候检查是否正在释放其他技能。但是这个方法实在是过于原始，而且硬编码的方式也不适合将程序做大，当你有几十上百个技能时，处理每一个bool值的判断将会成为一个噩梦。
所幸，UE为我们提供了一套标签系统（GameplayTag），它是一种用于标记游戏对象属性信息的系统，这套系统可以在蓝图、代码和编辑器中使用。具体如何去使用标签系统，让我们边做边说。
课程中提到，在C++中，标签系统被叫做FGameplayTag（F开头表示是结构体），本质上是一个封装了FName的结构体，有以下几点特征：
-
FName wrapped in Struct： 用结构体封装的FName
-
Alternative for：bool，enum，FName： 用于替代bool、enum、FName等标识
-
created via Project Settings ：通过项目设置创建
-
Editor support to easily select GameplayTags： 从编辑器可以轻易处理GameplayTags
-
FGameplayTagContainer（Wrapped TArray of GameplayTags）：顾名思义，FGameplayTagContainer 是GameplayTag的容器，内部使用TArray实现，可以将其理解为GameplayTag的数组
-
Extensively used by GAS： 在GAS中被广泛使用
总的来说，GameplayTag是一个非常有用的东西，UE已经将其很好地封装，使用Tag我们可以轻易地获取对象的各种属性，并且处理这些属性之间的关系。
添加GamePlayTag
要开启GamePlayTag这个功能，首先我们到.Build.cs构建文件把GameplayTags模块包含到项目中，这样我们就能在C++中使用GameplayTags了。
接下来我们要对上节课实现的ActionComponent进行扩展。如果没有看过这方面的教程，可以参考我的上一篇文章。
在当初设计ActionComponent的时候，我们就将其定义为角色身上专门用于管理各种能力的组件。为了协调好各个能力的运行，我们自然得为其加上一个GameplayTagContainer，专门用来存放目前已激活的能力标签。
FGameplayTagContainer以F作为开头，表示它是一个结构体，其功能也很明确，封装了FGameplayTag的TArray，作为保存各种标签的容器。并且定义了一些列查找检索相关的函数，这里让它作为标签的容器自然是尽到了他的本职工作。
这里我们不使用指针，所以必须包含该结构体的头文件（编译器需要知道该变量的大小），如果是指针，其变量大小是固定的，就无需包含头文件。
//SurActionComponent.h
public:
//当前已拥有的Tag
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Tags")
FGameplayTagContainer ActiveGameplayTags;
FGameplayTagContainer中可以加是否正在冲刺、是否正在攻击、是否被击倒的这些标签。然后我们就可以从这个容器中获取到这些信息，得知角色目前在做什么，然后以此为依据去做决定。
接着为SurAction添加以下代码。
其中，最重要的部分就是GrantsTags和 BlockedTags两个FGameplayTagContainer。
GrantsTags保存了当前Action拥有的Tag，你也可以将其理解为Action的属性，当这个Action被激活时，会将GrantsTags加入到ActiveGameplayTags中；Action结束时移除。
BlockTags保存了与当前Action冲突的Tag，Action开始时必须保证ActiveGameplayTags中没有BlockedTags。
然后修改StartAction_Implementation和StopAction_Implementation，在Action启用时，我们把GrantTags中的所有Tag都放入ActiveGameplayTags中；停用时全部移出。
//SurAction.h
protected:
UFUNCTION(BlueprintCallable, Category = "Action")
USurActionComponent* GetOwningComponent() const;
//当这个Action被激活时，将GrantsTags加入到ActiveGameplayTags中；Action结束时移除
UPROPERTY(EditDefaultsOnly, Category = "Tags")
FGameplayTagContainer GrantsTags;
//Action开始时必须保证ActiveGameplayTags中没有BlockedTags，换句话来说就是和本Action冲突的Tag
UPROPERTY(EditAnywhere, Category = "Tags")
FGameplayTagContainer BlockedTags;
//.cpp
USurActionComponent* USurAction::GetOwningComponent() const
{
return Cast<USurActionComponent>(GetOuter());
}
void USurAction::StartAction_Implementation(AActor* Instigator)
{
UE_LOG(LogTemp, Log, TEXT("Running: %s"), *GetNameSafe(this));
USurActionComponent* Comp = GetOwningComponent();
ensure(Comp);
Comp->ActiveGameplayTags.AppendTags(GrantsTags);
}
void USurAction::StopAction_Implementation(AActor* Instigator)
{
UE_LOG(LogTemp, Log, TEXT("Stoping: %s"), *GetNameSafe(this));
USurActionComponent* Comp = GetOwningComponent();
ensure(Comp);
Comp->ActiveGameplayTags.RemoveTags(GrantsTags);
}
为了看到当前拥有那些Action，我们可以在SurActionComponent类中添加debug信息打印到屏幕上。
//SurActionComponent.cpp
void USurActionComponent::TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction)
{
Super::TickComponent(DeltaTime, TickType, ThisTickFunction);
FString DebugMsg = GetNameSafe(GetOwner()) + " : " + ActiveGameplayTags.ToStringSimple();
GEngine->AddOnScreenDebugMessage(-1, 0.f, FColor::White, DebugMsg);
}
编译完成后，进入UE编辑器，点开项目设置，可以看到有个GamePlayTags，进入后新建两个tag："Action.Sprinting"、"Action.Attacking" 。
可以看到，UE中的Tag是有分级的，每个级别用.隔开，这为我们分类和查找Tag提供了很大的便利，
接下来要让之前的技能应用到我们新建的标签。打开SprintAction，可以看到细节面板多了两个成员。将其修改如下：
可以看到，我们为SprintAction的GrantTags添加了Action.Sprinting，意思就是SprintAction拥有Action.Sprinting标签，正如每个人都或多或少地给别人贴过标签一样，你可以把这个标签理解为它自己的属性。
我们还未BlockedTags添加了Action.Attacking。在我们的设想中，当Sprint技能开始的时候，会先检查ActiveGameplayTags中有没有Action.Attacking标签（目前还没实现这部分逻辑），如果有，则不开始能力。如果没有，将Action.Sprinting标签加入到ActiveGameplayTags中，然后执行能力。
同样的，为我们的主要攻击（鼠标左键）修改相关标签。
进入游戏，可以看到左上角显示了刚才定义的Debug信息，当我们点击左键进行攻击时，由于Action.Attacking被添加进了ActiveGameplayTags中，这时Debug信息就会忠实地输出ActiveGameplayTags中的所有标签。
实现技能之间的冲突
前面实现了将GrantTags添加到ActiveGameplayTags的功能，现在我们每个能力都拥有了自己的标签。接下来我们要实现技能之间的互斥，也就是不能在疾跑的时候攻击，也不能在攻击的时候疾跑。
首先为Action基类添加一个CanStart函数，它会检索ActiveGameplayTags中是否有冲突的Tag（BlockedTags)。
注意这里使用了GameplayTagContainer的HasAny函数，只要ActiveGameplayTags含有BlockedTags中的任意一个Tag，都会返回true。顺带一提，之前提到Tag是FName的封装，底层实现还是hash，因此检索的效率是相当高的。
// SurAction.h
public:
UFUNCTION(BlueprintNativeEvent,Category = "Action")
bool CanStart(AActor* Instigator);
//,cpp
bool USurAction::CanStart_Implementation(AActor* Instigator)
{
USurActionComponent* Comp = GetOwningComponent();
if(Comp->ActiveGameplayTags.HasAny(BlockedTags))
{
return false;
}
return true;
}
修改USurActionComponent::StartActionByName，在每次试图运行能力时，都要判断当前能力能否运行。
//SurActionComponent.cpp
bool USurActionComponent::StartActionByName(AActor* Instigator, FName ActionName)
{
for(USurAction* Action:Actions)
{
if(Action && Action->ActionName == ActionName)
{
if(!Action->CanStart(Instigator))
{
//打印debug信息
FString FailedMsg = FString::Printf(TEXT("Failed to run: %s"), *ActionName.ToString());
GEngine->AddOnScreenDebugMessage(-1, 2.f, FColor::Red, FailedMsg);
//考虑到可能有同名能力，所以不使用break
continue;;
}
Action->StartAction(Instigator);
return true;
}
}
return false;
}
此处存在一个隐藏的BUG：如果存在不能开始的Action，比如说我们按下shift键，由于Action冲突，所以没有StartAction。但是松开shift键的时候，因为绑定了按键事件，我们还是会调用StopAction。但存在不能开始的Action的话，我们就没有添加过tag，执行stopAction移除tag会出现错误。总之，会出现一些无法预料到的问题。
所以我们在SurAction添加一个bool变量bIsRunning，和获取它的函数，用来判断这个Action是否正在运行：
//SurAction.cpp
void USurAction::StartAction_Implementation(AActor* Instigator)
{
...
bIsRunning = true;
}
void USurAction::StopAction_Implementation(AActor* Instigator)
{
UE_LOG(LogTemp, Log, TEXT("Stoping: %s"), *GetNameSafe(this));
//如果没有运行就stop，程序一定哪里出现了问题
ensureAlways(bIsRunning);
...
bIsRunning = false;
}
bool USurAction::IsRunning() const
{
return bIsRunning;
}
在StopActionByName处判断Action是否在运行，如果没有运行，则忽略不计。
//SurActionComponent,cpp
bool USurActionComponent::StopActionByName(AActor* Instigator, FName ActionName)
{
for(USurAction* Action:Actions)
{
if(Action && Action->ActionName == ActionName)
{
if(Action->IsRunning())
{
Action->StopAction(Instigator);
return true;
}
}
}
return false;
}
值得一提的是，我们不应该把判断是否在运行的逻辑 或者判断CanStart的逻辑写在USurAction::StopAction_Implementation和StartAction_Implementation里，因为这个函数是可以在蓝图中被重载的，在这种实现方法中，你每次重载函数，都不得不惦记着要判断Action是否在运行，这样无疑会加大程序员的心智负担和提高出现错误的概率。所以，在USurAction::StopAction的默认实现中，我们不需要做什么多余的操作，添加一个断言语句就可以了。
PS: 其实按这个思路， 前面Action的Comp->ActiveGameplayTags.AppendTags(GrantsTags)语句也应该加在StartActionByName中。也许是课程作者疏忽，也许是有其他考虑，这里为了保持统一，笔者保留了自己的意见，还是以课程为准。
如果你实在不清楚应该在哪写判断的逻辑，至少保证你的程序不会轻易的崩溃，在相关的地方全部加上一句判断（比如在Component和Action里都写上判断），虽然代码看着略有些繁琐，但是也少了很多担惊受怕。
进入游戏，现在就可以验证我们写好的技能互斥逻辑了。
还有一个BUG，当我们快速进行左键攻击的时候，编译器会在USurAction_ProjectileAttack::AttackDelay_Elapsed->StopAction处报错:
Rider编辑器指出错误的地方很奇怪，和视频教程里的并不一样，笔者在跟进调试的时候发现在某个地方传参出现了问题，目前无法理解这种情况，姑且认为是编辑器debug的问题。但是都有一个共同点，那就是在StopAction处出现了错误。测试发现，问题就出在前面我给StopAction_Implementation加上的一句断言上。当我把ensure去掉后，debug这里就不报错了。所以就认为是rider编辑器的bug吧。
不管上面出现的奇怪问题了。总之结论是一样的，都是在断言处出现了问题，也就是ensurealways(isRunning)处发生了中断。也就是说，当前还是有Action没有运行，但还是执行了StopAction的情况。
为什么会出现这个BUG呢？这得回到发射子弹这个技能的实现上来。我们使用了一个定时器，让这个技能有0.2s的释放时间。如果在这个0.2s期间，我们又使用了发射子弹这个功能，由于实现里每一个定时器都是独立的，那么就会再创建一个定时器。
现在创建了两个定时器，在定时器绑定的事件中，我们最后调用了StopAction。让我们沿着时间推进，现在第一个定时器时间到了，调用了StopAction，将bIsRunning置为false。又过去一段时间啊，第二个定时器时间到了，又调用了一次StopAction，由于当前的bIsRunning是false，因此触发断言，程序就报错了。
这个BUG很好理解，解决的办法很简单，就是在CanStart中添加一个判断即可。如果当前能力正在运行，就直接返回false。
bool USurAction::CanStart_Implementation(AActor* Instigator)
{
if(IsRunning())
{
return false;
}
...
}
进入游戏，查看实现的结果。可以看到，如果试图快速连点攻击，就会一直触发之前设置的Debug信息，表示不能运行能力。
不过笔者认为这并不是最好的解决办法，因为这在一定程度上降低了游戏设计的自由度，这样修改意味着我们再也无法实现能够自己打断自己的技能了，虽然很少有机会能设计这种技能，但是多多少少还是有一些遗憾的。
其实这个问题还有一个解决方法，就是将我们普通攻击本身作为一个block tag添加到BlockTags中，这样当试图再次普攻时，由于检测到激活的Tag中有BlockTags中的成员，所以本次攻击就不会触发了。
同样的思路可以用在黑洞攻击、瞬移攻击上，因为他们用的都是同一套攻击动作，用的也是同一个tag，我们又不希望在普攻的同时能够放出黑洞，那我们就将普攻的tag添加到BlockTags中即可。
最终效果&总结
最后看看最终结果，如图所示，我三个技能一顿乱按，由于技能释放的0.2s内是不允许使用其他技能的，左上角不断跳出能力运行失败的提示，但是每一个技能都完整地释放了出去。
在本篇文章中，我们使用GameplayTag系统优化了上节课实现的能力系统，做到了技能之间的互斥，并掌握了使用标签获取对象属性的技巧。在接下来的文章中，我会基于标签系统实现几个非常常见的功能。