README.md · Soap/GameplayAbilitySystem_Aura

# GameplayAbilitySystem_Aura
## GameplayEffect.h中Tags组下面属性相关文档
### GameplayEffectAssetTag
- "GameplayEffectAssetTag（InheritableGameplayEffectTags）：标记了GE拥有的标签，而不是给予给角色。GameplayEffect（游戏效果）的标签是指该游戏效果所具有的标签，而不是给予给角色。换句话说，GameplayEffect的标签是用来描述游戏效果本身的，而不是将这些标签应用于角色或实体。"
- 数据类型：FInheritedTagContainer InheritableGameplayEffectTags：通过这种结构，可以安全地将父级蓝图和子级蓝图中的标签进行组合，以便在游戏开发中使用。这样做可以确保正确地继承和组合标签，避免冲突或意外的行为发生。
    1. FGameplayTagContainer CombinedTags：它表示将继承的标签和自己添加的标签相加，然后减去自己删除的标签。这样的计算可以得到一个综合考虑继承和修改的标签集合。
    2. FGameplayTagContainer Added：我拥有的标签，除了继承自父级的标签之外，并且这些标签是在父级标签的基础上额外添加的。
    3. FGameplayTagContainer Removed：如一个对象、角色或实例）的父级拥有某些标签时，应该将这些标签从个体中移除。
- GrantedTags（InheritableOwnedTagsContainer）：这些标签被应用于我所应用的角色（Actor），一些标签被应用于当前操作的角色（Actor）。这些标签可能是通过某种机制或方法将它们与角色相关联，以便在游戏中进行特定的处理或逻辑判断。通过应用这些标签，可以对角色进行标识、分类或定义其特定的属性、行为或其他特征。这样的应用可以使开发人员或游戏系统能够根据标签的存在与否来触发相应的事件、效果或行为。
    1. FGameplayTagContainer CombinedTags：它表示将继承的标签和自己添加的标签相加，然后减去自己删除的标签。这样的计算可以得到一个综合考虑继承和修改的标签集合。
    2. FGameplayTagContainer Added：我拥有的标签，除了继承自父级的标签之外，并且这些标签是在父级标签的基础上额外添加的。
    3. FGameplayTagContainer Removed：如一个对象、角色或实例）的父级拥有某些标签时，应该将这些标签从个体中移除。
- GrantedBlockedAbilityTags（InheritableBlockedAbilityTagsContainer）：这些被阻止的技能标签被应用于我所应用的角色（Actor），一些被阻止的技能标签被应用于当前操作的角色（Actor）。这些标签可能用于标识、分类或定义一些被禁用或阻止的特定技能，以便在游戏中进行相应的处理或逻辑判断。通过应用这些被阻止的技能标签，可以限制角色在游戏中使用或执行特定的技能或能力。这可以用于实现游戏中的技能系统、规则或平衡性控制，以确保角色在特定情况下不能使用特定的技能。
    1. FGameplayTagContainer CombinedTags：它表示将继承的标签和自己添加的标签相加，然后减去自己删除的标签。这样的计算可以得到一个综合考虑继承和修改的标签集合。
    2. FGameplayTagContainer Added：我拥有的标签，除了继承自父级的标签之外，并且这些标签是在父级标签的基础上额外添加的。
    3. FGameplayTagContainer Removed：如一个对象、角色或实例）的父级拥有某些标签时，应该将这些标签从个体中移除。
- OngoingTagRequirementsCategory（OngoingTagRequirements）：一旦应用，这些标签要求将用于确定游戏效果（GameplayEffect）是“开启”还是“关闭”。一个游戏效果可以处于关闭状态并且不产生任何效果，但仍然被应用。其中标签要求用于决定游戏效果是否处于激活状态。游戏效果可以被应用到角色或对象上，但根据标签要求的满足程度，游戏效果可能会被设置为“开启”或“关闭”。当游戏效果处于关闭状态时，即使它已经被应用到角色或对象上，它也不会产生任何效果。这种机制可以用于实现特定条件下的游戏效果控制，例如基于标签要求的条件判断，来决定游戏效果是否应该生效。
- 数据类型：FGameplayTagRequirements：封装要求（Require）和忽略（Ignore）标签。在游戏开发中，封装要求和忽略标签是一种将相关标签进行组合和定义的方式。通过封装，可以将一组标签作为要求，以确定是否满足一定的条件，或者将一组标签作为忽略，以排除某些特定的情况。封装要求标签可以用于指定必需的标签集合，以便在特定条件下触发或应用游戏效果。只有当目标对象具有满足要求标签的所有标签时，相应的游戏效果才会生效。封装忽略标签可以用于指定需要排除的标签集合，以防止在特定情况下触发或应用游戏效果。如果目标对象具有任何被忽略标签中的标签，相应的游戏效果将不会被触发或应用。
    1. FGameplayTagContainer RequireTags：所有这些标签必须同时存在。一组标签必须同时存在，才能满足特定条件或触发某些行为。要求所有这些标签同时存在可以用于定义复杂的条件或规则。只有当目标对象具有全部指定的标签时，才会满足条件或触发相应的行为。如果其中任何一个标签缺失，将无法满足要求或触发特定的逻辑。
    2. FGameplayTagContainer IgnoreTags：这些标签中不能有任何一个存在。一组标签不能同时存在，即这些标签是互斥的。在游戏开发中，禁止这些标签同时存在可以用于定义排斥性的条件或规则。如果目标对象具有任何一个被禁止的标签，将不满足条件或触发特定的行为。这种机制可以用于实现标签的排他性，确保在特定情况下不能同时具有多个指定的标签。
- ApplicationTagRequirementsCategory（ApplicationTagRequirements）：这个游戏效果（GameplayEffect）的标签要求是应用于目标的条件。这是在应用时进行的一次性判断。如果条件不满足，该游戏效果将无法应用。在应用游戏效果之前，对目标对象的标签要求进行判断。这些标签要求是在游戏效果应用时进行的条件判断，如果条件不满足，则该游戏效果无法被应用到目标对象上。标签要求的判断是一种通过对目标对象的标签进行比较来决定游戏效果是否能够应用的机制。如果目标对象的标签满足了游戏效果的标签要求，那么游戏效果将被成功应用；反之，如果标签要求未被满足，则游戏效果无法应用。这种机制可以用于实现对游戏效果的条件限制，确保只有在满足特定标签要求的情况下才能应用该游戏效果。
    1. FGameplayTagContainer RequireTags：所有这些标签必须同时存在。一组标签必须同时存在，才能满足特定条件或触发某些行为。要求所有这些标签同时存在可以用于定义复杂的条件或规则。只有当目标对象具有全部指定的标签时，才会满足条件或触发相应的行为。如果其中任何一个标签缺失，将无法满足要求或触发特定的逻辑。
    2. FGameplayTagContainer IgnoreTags：这些标签中不能有任何一个存在。一组标签不能同时存在，即这些标签是互斥的。在游戏开发中，禁止这些标签同时存在可以用于定义排斥性的条件或规则。如果目标对象具有任何一个被禁止的标签，将不满足条件或触发特定的行为。这种机制可以用于实现标签的排他性，确保在特定情况下不能同时具有多个指定的标签。
- ApplicationTagRequirementsCategory（RemovalTagRequirements）：满足的标签要求将会移除该效果，并阻止效果的应用。当满足特定的标签要求时，将会移除该效果并阻止其应用。通过定义标签要求，可以设置特定条件，当目标对象的标签满足这些条件时，该效果将被移除并阻止其应用。这种机制可以用于实现一些限制或条件下的效果控制，确保只有在符合特定条件的情况下才能应用或保持效果。
    1. FGameplayTagContainer RequireTags：所有这些标签必须同时存在。一组标签必须同时存在，才能满足特定条件或触发某些行为。要求所有这些标签同时存在可以用于定义复杂的条件或规则。只有当目标对象具有全部指定的标签时，才会满足条件或触发相应的行为。如果其中任何一个标签缺失，将无法满足要求或触发特定的逻辑。
    2. FGameplayTagContainer IgnoreTags：这些标签中不能有任何一个存在。一组标签不能同时存在，即这些标签是互斥的。在游戏开发中，禁止这些标签同时存在可以用于定义排斥性的条件或规则。如果目标对象具有任何一个被禁止的标签，将不满足条件或触发特定的行为。这种机制可以用于实现标签的排他性，确保在特定情况下不能同时具有多个指定的标签。
- RemoveTagRequirementsCategory：当游戏效果（GameplayEffect）在此容器中具有标签时，将在效果应用时清除。一个容器，其中包含了一些标签。当游戏效果具有与容器中的标签匹配的标签时，在游戏效果应用时，它们将被清除。这种机制可以用于在特定条件下清除具有特定标签的游戏效果。当游戏效果被应用时，如果它们具有与容器中标签匹配的标签，那么这些标签将被清除，从而影响游戏效果的行为或状态。
    1. FGameplayTagContainer CombinedTags：它表示将继承的标签和自己添加的标签相加，然后减去自己删除的标签。这样的计算可以得到一个综合考虑继承和修改的标签集合。
    2. FGameplayTagContainer Added：我拥有的标签，除了继承自父级的标签之外，并且这些标签是在父级标签的基础上额外添加的。
    3. FGameplayTagContainer Removed：如一个对象、角色或实例）的父级拥有某些标签时，应该将这些标签从个体中移除。
## MatchesTag：案例代码
```c++
bool MatchesTag(const FString& TagToCheck)
{
    // 步骤1：检查TagToCheck是否有效
    if (TagToCheck.IsEmpty())
    {
        return false;
    }
    // 步骤2：检查TagToCheck是否与当前标签完全相等
    if (TagToCheck == CurrentTag)
    {
        return true;
    }
    // 步骤3：检查当前标签是否具有父标签
    TArray<FString> ParentTags = CurrentTag.GetParentTags();
    if (!ParentTags.IsEmpty())
    {
        // 步骤4：递归地遍历每个父标签
        for (const FString& ParentTag : ParentTags)
        {
            // 步骤5：将父标签与TagToCheck进行比较
            if (TagToCheck.StartsWith(ParentTag + "."))
            {
                return true;
            }
        }
    }
    // 步骤6：如果没有父标签与TagToCheck匹配，则返回false
    return false;
}
```
## 函数指针
### 是指向函数的指针变量。它可以存储和调用函数的地址，允许在程序运行时动态的选择要调用的函数
1、定义函数指针类型：
```c++
typedef ReturnType (*FunctionPtrType)(ParameterTypes...);
```
或者使用using关键字：
```c++
using FunctionPtrType = ReturnType (*)(ParameterTypes...);
```
其中，ReturnType 是函数的返回类型，ParameterTypes 是函数的参数类型。
2、声明函数指针变量并将其指向相应的函数：
```c++
FunctionPtrType ptr = &functionName;
```
其中，ptr 是函数指针变量，functionName 是函数的名称。
3、通过函数指针调用函数：
```c++
ReturnType result = (*ptr)(arguments);
```
```c++
ReturnType result = ptr(arguments);
```
函数指针可以作为函数的参数传递，或者存储在数据结构中。通过函数指针，可以在运行时根据需要动态选择不同的函数进行调用，从而实现灵活的函数调用机制。
## GameplayAbility.h源码解释：技能标签
### Ability Tags
- 标签是用于对能力进行分类、组织和识别的关键词或标识符。它们可以用来表示能力的属性、类型、效果、目标等方面。通过为能力添加标签，可以更方便地对其进行管理和使用。
  标签可以根据具体的需求和设计进行定义和使用。它们可以用于筛选、过滤和匹配能力，以便根据不同的情景和条件在游戏中触发相应的能力。
  例如，一些常见的能力标签可能包括：攻击、防御、治疗、移动、范围、持续时间等。通过使用这些标签，可以对能力进行更细致的分类和管理，以实现游戏中不同类型和效果的能力。
### CancelAbilitiesWithTag
- 当执行这个能力时，具有这些标签的能力将被取消。描述：这个能力在执行时会取消具有特定标签的其他能力。这意味着，当这个能力被激活时，具有指定标签的其他能力将被中断或终止。
### BlockAbilitiesWithTag
- 当这个能力处于激活状态时，具有这些标签的其他能力将被阻止。描述：
  这个能力在激活期间会阻止具有特定标签的其他能力。这意味着，当这个能力处于激活状态时，具有指定标签的其他能力将无法执行或生效。
### ActivationOwnedTags
- 在这个能力处于激活状态时，应用于激活所有者的标签。如果在 AbilitySystemGlobals 中启用了 ReplicateActivationOwnedTags，这些标签将进行复制。描述：
  在这个能力激活期间，可以将特定的标签应用于激活该能力的所有者。这些标签可以用于标识和区分处于激活状态的所有者角色或实体。
  如果在 AbilitySystemGlobals 中启用了 ReplicateActivationOwnedTags（复制激活所有者标签），那么这些标签将在网络同步时进行复制。这意味着在多人游戏中，其他玩家将能够看到并获取到激活所有者的标签信息。
### ActivationRequiredTags
- 只有当激活的角色/组件具有所有这些标签时，才能激活这个能力。描述：
  这个能力只能在满足所有指定标签的激活角色/组件下才能被激活。这意味着，只有当激活者具备了所有指定的标签时，才能使用该能力。
### ActivationBlockedTags
- 如果激活的角色/组件具有任何一个指定的标签，那么这个能力将被阻止。描述：
  当激活的角色/组件具有指定的任何一个标签时，这个能力将无法被激活。这意味着，只要激活者具备指定的任何一个标签，就无法使用该能力。
### SourceRequiredTags
- 只有当源角色/组件具有所有这些标签时，才能激活这个能力。描述：
  这个能力只能在满足所有指定标签的源角色/组件下才能被激活。这意味着，只有当源角色/组件具备了所有指定的标签时，才能使用该能力。
### SourceBlockedTags
- 如果源角色/组件具有任何一个指定的标签，那么这个能力将被阻止。描述：
  当源角色/组件具有指定的任何一个标签时，这个能力将无法被激活。这意味着，只要源角色/组件具备指定的任何一个标签，就无法使用该能力。
### TargetRequiredTags
- 只有当目标角色/组件具有所有这些标签时，才能激活这个能力。描述：
  这个能力只能在目标角色/组件满足所有指定标签的情况下才能被激活。这意味着，只有当目标角色/组件具备了所有指定的标签时，才能使用该能力。
### TargetBlockedTags
- 如果目标角色/组件具有任何一个指定的标签，那么这个能力将被阻止。描述：
  当目标角色/组件具有指定的任何一个标签时，这个能力将无法被激活。这意味着，只要目标角色/组件具备指定的任何一个标签，就无法使用该能力。
### bReplicateInputDirectly
- 如果设置为 true，该能力将始终将输入按下/释放事件复制到服务器。描述：
  当将该属性设置为 true 时，该能力将始终将输入按下/释放事件复制到服务器。这意味着，无论是玩家本地输入还是服务器上的输入，都将被复制并同步到其他玩家或客户端。
  这种复制输入事件的机制可以用于多人游戏中确保玩家在不同客户端上的输入行为保持同步。通过将输入事件复制到服务器，其他玩家将能够看到并响应该事件，从而实现多人游戏的协同和互动。
### InstancingPolicy 
- 当执行时，能力是如何实例化的会限制其在实现中可以做什么。描述：
  能力在执行时的实例化方式会限制其在实现中的功能。实例化是指能力在游戏中创建和执行的方式。
  - 以下是与能力实例化相关的几个关键方面：
    1. 初始化：当一个能力被激活时，它通常需要进行初始化。这可能涉及到为能力分配必要的资源、设置初始状态或建立与其他组件的连接。实例化时的初始化过程对于能力的功能和行为起着关键的作用。
    2. 上下文：能力实例化时的上下文包括执行能力的环境和相关信息。这可能包括执行能力的角色、目标、位置、时间等。能力可能会受限于可用的上下文信息，以决定其可执行的操作和效果。
    3. 资源管理：能力的实例化可能会受到游戏中的资源管理机制的限制。这包括内存、计算资源、网络带宽等。能力的实现需要考虑到可用资源的限制，以确保其在游戏中的执行效率和可靠性。
    4. 规则和限制：能力的实例化可能受到游戏规则和设计的限制。这些规则和限制可以是基于平衡性、游戏性或其他设计考虑因素。能力的实现必须遵守这些规则和限制，以确保游戏的整体体验和公平性。
- EGameplayAbilityReplicationPolicy
  - NonInstanced
    这个能力永远不会被实例化。执行该能力的任何操作都是在类的默认对象（CDO）上操作。
    CDO是类的一个特殊实例，它代表了该类的默认状态和行为。在这种情况下，能力的执行操作直接作用于CDO，而不是通过创建和操作具体的能力实例。
    1. 状态共享：由于所有操作都在CDO上执行，所以状态信息将在所有执行操作之间共享。这意味着所有的操作都可能受到同一份状态数据的影响。
    2. 个性化定制：由于缺少具体的实例，可能无法针对特定的实例进行个性化的定制或配置。
    3. 并发性和互动性：由于所有操作都在CDO上执行，可能会出现并发访问和互动的问题。多个执行操作可能会相互干扰或覆盖对CDO的操作。
  - InstancedPerActor
    每个角色都会获得自己的能力实例。状态可以被保存，复制也是可能的。描述：
    每个角色都会获得自己的能力实例，这意味着每个角色都有独立的能力状态和行为。这样，每个角色都可以单独管理和操作他们自己的能力，而不会与其他角色的能力产生冲突或干扰。
    1. 状态保存：每个能力实例都可以保存自己的状态，包括变量、属性和其他相关数据。这样，角色可以在不同的时间点保存和恢复能力的状态，以实现持久化和进度管理。
    2. 复制和同步：由于每个角色都有自己的能力实例，能力的复制和同步变得可能。能力状态的变化可以复制到其他角色的实例中，以实现在多个角色之间的同步和共享。
    3. 个性化定制：每个能力实例可以独立进行个性化的定制和配置。不同的角色可以根据自己的需求和特点，对能力进行不同的设置和调整。
  - InstancedPerExecution
    我们在每次执行时实例化这个能力。复制是可能的，但不推荐使用。描述：
    每次执行该能力时，我们都会创建一个新的能力实例。这意味着每次能力被激活时，都会生成一个独立的能力实例，用于执行该能力的操作。
    尽管复制能力实例是可能的，但这里提到不建议使用复制。这可能是因为复制能力实例可能引入一些问题或复杂性，例如状态同步、网络传输和冲突解决等。
### bServerRespectsRemoteAbilityCancellation
- 如果设置了这个选项，客户端的能力版本可以取消服务器端的版本。而服务器端的版本始终可以取消客户端的版本。描述：
  如果设置了这个选项，意味着客户端的能力版本有权取消服务器端的版本。这意味着客户端可以通过发送相应的请求或命令，取消服务器端正在执行的能力。
  同时，服务器端的版本始终具有最终的权威性，可以取消客户端的版本。这意味着服务器端可以通过相应的控制机制，终止客户端正在执行的能力操作，并确保服务器端的状态和逻辑的一致性。
  这种能力版本之间的取消和控制机制可以用于确保服务器端和客户端之间的数据同步和一致性。客户端可以取消服务器端的版本，以便纠正错误或取消不必要的操作。服务器端则具有最终决策的权威性，可以终止客户端的版本，以确保游戏的整体逻辑和公平性。
### bRetriggerInstancedAbility
- 如果设置为True，并且尝试激活一个已经处于活动状态的实例化能力，那么会结束该能力并重新触发它。描述：
  如果设置为True，表示当尝试激活一个已经处于活动状态的能力实例时，会先结束当前的实例化能力，然后重新触发它，相当于重新执行该能力。
  这种行为可以用于处理重复激活能力的情况。当一个能力实例已经在执行时，如果再次尝试激活相同的能力实例，系统会先终止当前的能力实例，然后重新启动一个新的实例，以确保能力的状态和逻辑被正确处理。
### NetExecutionPolicy
- 能力在网络上的执行方式取决于特定系统的架构和设计选择。以下是三种常见的方式：
- ask and predict
1. "询问并预测"：在这种方式中，客户端向服务器发送请求，询问是否可以执行某个能力。服务器接收到请求后，会预测能力的结果，并将结果返回给客户端。客户端在等待服务器响应的同时，可能会使用本地的预测结果进行展示或处理。这种方式可以减少网络延迟，提供更快速的反馈，但可能存在与服务器预测不一致的情况。
- ask and wait
2. "询问并等待"：在这种方式中，客户端向服务器发送请求，询问是否可以执行某个能力。服务器接收到请求后，会进行相应的处理并返回结果给客户端。客户端在收到服务器响应之前会一直等待。这种方式可以确保客户端和服务器的结果保持一致，但可能会引入较长的网络延迟。
- don't ask (just do it)
3. "不询问（直接执行）"：在这种方式中，客户端直接执行能力操作，而无需向服务器发送请求。客户端可能已经具备执行能力所需的相关数据和权限。这种方式可以减少与服务器的通信，提供更快速的执行，但可能会导致客户端和服务器之间的状态不一致。
- EGameplayAbilityNetExecutionPolicy
  - mLocalPredicted
    - 如果存在本地客户端，部分能力会在本地客户端上进行预测性执行。描述：
      在某些情况下，如果有本地客户端，一部分能力的执行可以在本地客户端上进行预测性执行。
      这意味着客户端可以根据当前的状态和输入，在本地预测能力的执行结果，而无需依赖于服务器的响应。客户端可以使用本地的数据和算法来模拟能力的执行，以便提供即时的反馈和用户体验。
      预测性执行在客户端上进行，可以减少网络延迟并提高响应速度。客户端可以在等待服务器响应时，使用本地的预测结果来更新界面和展示效果，以给用户一种即时的反馈。
      然而，预测性执行也可能存在一定的风险和不准确性。由于客户端只能基于本地的数据进行预测，可能会与服务器端的实际执行结果存在差异。因此，在最终结果确定之前，通常需要与服务器进行数据同步和校验，以确保客户端和服务器的状态一致性。
  - LocalOnly 
    - 这个能力只会在具有本地控制权的客户端或服务器上运行。描述：
      这种设置表示该能力只在具有本地控制权的客户端或服务器上执行。这意味着只有拥有能力的主体（客户端或服务器）才能触发和执行该能力，其他主体无法直接操作或执行该能力。
      这种设置通常用于限制能力的执行范围，以确保只有特定的主体可以执行该能力。例如，在多人游戏中，某些能力可能只由本地玩家控制，而其他玩家无法直接执行这些能力。
      这种设置可以用于确保游戏的公平性和平衡性，以及限制能力的使用范围。它还可以提供对能力执行的更好控制，避免不必要的冲突和混乱。
  - ServerInitiated 
    - 这个能力由服务器发起，但如果存在本地客户端，也会在本地客户端上运行。描述：
      在这种情况下，能力的发起是由服务器控制的，服务器发出指令或请求来启动该能力。然而，如果存在本地客户端，服务器可以将一部分或全部能力的执行委托给本地客户端。
      当服务器发起能力时，它可以将相关数据和指令发送给本地客户端，以便在本地执行能力的一部分或全部过程。这样做的目的是减轻服务器负载并提高响应速度，同时提供更好的用户体验。
      本地客户端可以根据服务器的指令和数据，在本地执行能力的相关操作，并将执行结果返回给服务器。这种方式可以减少与服务器的通信延迟，并提供更快速的反馈。
      需要注意的是，本地客户端上的能力执行可能会受到一些限制，以确保游戏的安全性和公平性。服务器可能会对本地客户端的执行结果进行验证和校验，以确保能力的合法性和正确性。
  - ServerOnly
    - 这个能力只会在服务器上运行。描述：
      这种设置表示该能力只会在服务器上执行，而不会在客户端上执行。在这种情况下，服务器是唯一负责发起和执行该能力的主体。
      这种设置通常用于确保游戏逻辑和数据的一致性。通过将能力的执行限制在服务器上，可以避免客户端的潜在作弊和不一致的状态。
      在这种设置下，客户端可以向服务器发送请求或操作，以触发服务器上的能力执行。服务器收到请求后，会根据游戏逻辑和规则进行相应的处理，并将结果返回给客户端。
      需要注意的是，由于能力的执行发生在服务器上，可能会引入一定的网络延迟。客户端在等待服务器响应的过程中，可能需要显示适当的加载状态或等待界面，以提供良好的用户体验。
### NetSecurityPolicy
- 如果该能力仅在服务器上运行，而客户端不参与执行过程，则需要采取一些保护措施和考虑事项，以确保能力的完整性和安全性：
  1. 服务器端验证：服务器应对客户端的请求进行验证和校验，以确保请求的合法性和有效性。这可以防止恶意客户端发送无效请求或试图绕过服务器的保护机制。
  2. 访问控制和权限管理：服务器应实施适当的访问控制和权限管理机制，以确保只有经过授权和合法的客户端才能发起能力的执行。这可以防止未经授权的客户端对能力进行滥用或非法操作。
  3. 数据保护和加密：服务器应采取适当的数据保护和加密措施，以保护能力执行过程中涉及的敏感数据。这可以防止数据泄露和未经授权的访问。
  4. 审计和日志记录：服务器应记录能力的执行过程和相关操作，以便进行审计和故障排除。这可以帮助检测和追踪潜在的安全问题或异常行为。
- 至于客户端是否允许请求更改能力的执行，这取决于具体的应用需求和安全考虑。一般情况下，服务器应该对客户端请求进行验证和控制，以确保请求的合法性和安全性。客户端可能会提供一些控制参数或选项，但最终的执行决策应由服务器进行处理。
- EGameplayAbilityNetSecurityPolicy
  - ClientOrServer
    - 如果没有特定的安全要求，并且客户端和服务器都可以自由地触发和终止这个能力，这意味着一个更开放和宽松的设置。在这种情况下，以下考虑因素可能适用：
      1. 客户端和服务器之间的信任：由于客户端和服务器都有触发能力的权限，它们之间应建立一定程度的信任。相互认证和安全通信协议可以帮助确保通信的完整性，并防止未经授权的访问。
      2. 同步和一致性：为了保持一致性和避免冲突，在客户端和服务器之间同步能力的状态和执行是重要的。这可能涉及交换相关数据和更新，以确保双方都具有相同的视图和执行结果。
      3. 错误处理和容错机制：由于能力的触发和终止是自由的，应考虑适当的错误处理和容错机制。这可以包括记录日志、处理异常情况和恢复能力的执行状态。
    - 需要注意的是，尽管没有明确的安全要求，但仍然应该考虑如何保护系统免受潜在的恶意行为和滥用。在设计和实现时，仍然需要采取一些基本的安全措施，如输入验证和防御措施，以防范可能的攻击和漏洞利用。
  - ServerOnlyExecution
    - 如果客户端请求执行该能力，服务器将会忽略该请求。但是，客户端仍然可以请求服务器取消或终止该能力。描述：
      在这种情况下，客户端发起的能力执行请求将被服务器忽略。这意味着服务器不会执行客户端请求来触发该能力的执行。
      然而，客户端仍然具有请求服务器取消或终止该能力的权限。客户端可以发送请求给服务器，要求服务器终止当前正在执行的能力。
      服务器会接收到客户端的请求，并根据请求的合法性和服务器的策略来决定是否终止该能力。服务器可能会进行验证和权限检查，以确保请求的合法性和安全性。如果请求被接受并满足服务器的条件，服务器将终止能力的执行。
  - ServerOnlyTermination
    - 如果客户端请求取消或终止该能力，服务器将会忽略该请求。但客户端仍然可以请求执行该能力。描述：
      在这种情况下，服务器会忽略客户端请求来取消或终止该能力的执行。这意味着服务器不会根据客户端的请求来中止当前正在执行的能力。
      然而，客户端仍然具有请求执行该能力的权限。客户端可以向服务器发送请求，要求服务器执行该能力。
      服务器会接收到客户端的请求，并根据请求的合法性和服务器的策略来决定是否执行该能力。服务器可能会进行验证和权限检查，以确保请求的合法性和安全性。如果请求被接受并满足服务器的条件，服务器将执行该能力。
  - ServerOnly
    - 服务器控制该能力的执行和终止。对于任何请求，服务器都会忽略客户端的请求。描述：
      在这种情况下，服务器完全控制该能力的执行和终止，并忽略客户端发起的任何请求。
      客户端无法直接触发或终止该能力的执行。服务器独立决定何时开始执行该能力，并在适当的时候终止执行。
      这种设置通常用于确保能力的一致性、安全性和控制性。服务器作为唯一的决策者，可以根据特定的逻辑和规则来管理能力的执行。客户端无法干扰或改变能力的执行过程。
      客户端仍然可以向服务器发送其他类型的请求，例如获取能力的状态或结果等。服务器可以根据策略和权限来处理这些请求，并返回相应的信息给客户端。
### CostGameplayEffectClass
- 这个GameplayEffect代表了该能力的消耗（法力、耐力等），它将在能力被执行时应用。描述：
  这个GameplayEffect用于表示能力的消耗，如法力、耐力等。当能力被执行时（在能力被提交时），该效果将被应用。
  具体而言，当玩家决定使用该能力并确认提交时，消耗效果将生效。这可能导致玩家失去一定的法力值、耐力值或其他资源，以反映能力的消耗。
  消耗效果可以通过修改玩家的属性或状态来实现，例如降低法力值、增加耐力消耗速率等。这可以根据具体的游戏设计和规则来确定。
### AbilityTriggers
- 为了确定是否应该在事件发生时执行该能力，您可以使用触发器。触发器是条件或事件，当满足时，表示应该执行该能力。以下是一些常见的实现触发器的方法：
  1. 基于事件的触发器：使用事件来触发能力的执行。当特定的事件发生时，例如玩家按下特定的按键、敌人进入特定的区域或计时器达到特定值时，能力被触发执行。
  2. 条件触发器：使用条件来确定能力是否应该执行。在特定的条件下，例如玩家的生命值低于某个阈值、特定物体存在于场景中或特定状态被满足时，能力被触发执行。
  3. 环境触发器：根据环境中的情况来触发能力执行。例如，在特定天气条件下、特定地点或特定环境状态下，能力可以被触发执行。
### CooldownGameplayEffectClass
- 这个GameplayEffect用于表示能力的冷却时间。当能力被提交时（在能力被使用后），该效果将被应用，并开始计时冷却时间。
## 网络复制使用小技巧
- 复制策略:
  无用。不要使用它。请参考Epic的Ability System Questions中Epic的解释。
  Gameplay Abilities已从服务器复制到拥有的客户端。
  注意：Gameplay Abilities不在模拟代理上运行（使用GE和GC）。
- 服务器尊重远程能力取消:
  这意味着当本地客户端的能力结束时，服务器的能力也将结束。
  通常不是一个好主意；服务器版本才是重要的。
- 直接复制输入:
  始终将输入按下/释放事件直接复制到服务器。
  Epic不赞成这样做。
- 更多解释：
  1. Gameplay Abilities的复制：Gameplay Abilities是指在游戏中执行特定功能或技能的能力。这些能力在服务器上执行，然后通过复制从服务器传输到拥有该能力的客户端。这确保了所有玩家在执行相同的能力时具有一致的游戏体验。
  2. 模拟代理上的Gameplay Abilities：模拟代理是指在网络游戏中模拟其他玩家的代理实体。根据复制策略，Gameplay Abilities不会在模拟代理上执行。这是因为模拟代理通常只接收来自服务器的复制数据，而不需要执行自己的能力逻辑。
  3. 服务器尊重远程能力取消：当本地客户端结束或取消一个能力时，服务器也会相应地结束或取消该能力。这确保了能力在整个游戏中的一致性，并避免了不同客户端之间的不一致性。然而，这通常不是一个好主意，因为服务器版本是最终决定的版本。
  4. 直接复制输入：指将玩家的输入（按下/释放事件）直接复制到服务器，而不经过客户端的处理。这样做可以减少延迟并提高响应性，但Epic不推荐这种做法，因为它可能导致安全性和作弊问题。
```c++
	/** Direct Input state replication. These will be called if bReplicateInputDirectly is true on the ability and is generally not a good thing to use. (Instead, prefer to use Generic Replicated Events). */
	UFUNCTION(Server, reliable, WithValidation)
	void ServerSetInputPressed(FGameplayAbilitySpecHandle AbilityHandle);
```
- 直接输入状态复制。如果在能力上的bReplicateInputDirectly为true，将调用这些函数，但通常不是一个好的使用方式（相反，最好使用通用复制事件）。
  描述：
  直接输入状态复制是指在能力中直接复制玩家的输入状态。当能力的bReplicateInputDirectly属性设置为true时，这些函数会被调用以实现输入状态的复制。然而，Epic Games不推荐使用这种方式，而是更倾向于使用通用复制事件（Generic Replicated Events）。
  通用复制事件是一种更灵活和可扩展的方法，可以用于触发和同步各种游戏中的事件。相比直接复制输入状态，通用复制事件提供了更多的控制和定制选项，并且更适用于多种类型的事件，而不仅仅是输入状态。
  直接复制输入状态虽然可以减少延迟并提高响应性，但可能会导致安全性和作弊问题。直接复制输入状态可能会使玩家更容易修改和操纵输入数据，从而破坏游戏的公平性和竞争性。
# The Gameplay Effect Context 执行流程
入口MakeEffectContext();
# Custom Gameplay Effect Context 执行流程
# TStructOpsTypeTraitsBase2含义
```c++
        WithZeroConstructor            = false,                         // 结构体可以通过用零填充其内存空间来构造成一个有效的对象。
		WithNoInitConstructor          = false,                         // 结构体具有一个接受 EForceInit 参数的构造函数，该参数将强制构造函数执行初始化操作，而默认构造函数执行的是“未初始化”操作。
		WithNoDestructor               = false,                         // 当结构体被销毁时，它的析构函数不会被调用。
		WithCopy                       = !TIsPODType<CPPSTRUCT>::Value, // 结构体可以通过其复制赋值运算符进行复制。
		WithIdenticalViaEquality       = false,                         // 结构体可以通过其 operator== 进行比较。这与 WithIdentical 应该是互斥的。
		WithIdentical                  = false,                         // 结构体可以通过 Identical(const T* Other, uint32 PortFlags) 函数进行比较。这与 WithIdenticalViaEquality 应该是互斥的。
		WithExportTextItem             = false,                         // 结构体具有一个 ExportTextItem 函数，用于将其状态序列化为字符串。
		WithImportTextItem             = false,                         // 结构体具有一个 ImportTextItem 函数，用于将字符串反序列化为该类的对象。
		WithAddStructReferencedObjects = false,                         // 结构体具有一个 AddStructReferencedObjects 函数，允许它向垃圾回收器添加引用。
		WithSerializer                 = false,                         // 结构体具有一个 Serialize 函数，用于将其状态序列化到 FArchive。
		WithStructuredSerializer       = false,                         // 结构体具有一个 Serialize 函数，用于将其状态序列化到 FStructuredArchive。
		WithPostSerialize              = false,                         // 结构体具有一个 PostSerialize 函数，在其被序列化后调用。
		WithNetSerializer              = false,                         // 结构体具有一个 NetSerialize 函数，用于将其状态序列化到用于网络复制的 FArchive。
		WithNetDeltaSerializer         = false,                         // 结构体具有一个 NetDeltaSerialize 函数，用于序列化与先前的 NetSerialize 操作中状态的差异。
		WithSerializeFromMismatchedTag = false,                         // 结构体具有一个 SerializeFromMismatchedTag 函数，用于从其他属性标签进行转换。
		WithStructuredSerializeFromMismatchedTag = false,               // 结构体具有一个基于 FStructuredArchive 的 SerializeFromMismatchedTag 函数，用于从其他属性标签进行转换。
		WithPostScriptConstruct        = false,                         // 结构体具有一个 PostScriptConstruct 函数，在蓝图中构造完成后被调用。
		WithNetSharedSerialization     = false,                         // 结构体具有一个 NetSerialize 函数，它不需要包映射来序列化其状态。
		WithGetPreloadDependencies     = false,                         // 结构体具有一个 GetPreloadDependencies 函数，用于在加载时序列化该结构体时返回所有将进行 Preload() 操作的对象。
		WithPureVirtual                = false,                         // 结构体具有 PURE_VIRTUAL 函数，在 CHECK_PUREVIRTUALS 为 true 时无法进行构造。
		WithCanEditChange			   = false,							// 结构体具有一个仅在编辑器中有效的 CanEditChange 函数，可以在详细面板中有条件地将子属性设置为只读（与 UObject::CanEditChange 的概念相同）。
```
# GameplayCue
# 229-231集淡出Actor（角色镜头前有阻挡物是进行隐藏或者淡出）
# 在虚幻引擎中，委托（Delegate）是一种用于实现事件驱动编程的强大机制。委托允许您将函数绑定到特定事件，当该事件发生时，绑定的函数会被调用。这种机制使得代码可以更加模块化和灵活，同时也提高了代码的可维护性和可扩展性。委托在虚幻引擎中被广泛应用于处理用户输入、游戏事件、UI交互等各种场景。

Soap/GameplayAbilitySystem_Aura

简介

发行版

贡献者

近期动态

Soap/GameplayAbilitySystem_Aura .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

Soap/GameplayAbilitySystem_Aura