Team Identity and GAS Integration
This page describes what Team Identity, ProjectPolicy, and GAS integration extension points may change and where their responsibility ends. For the feature model, setup, and fields, see Team Identity and Project Policy, Integrate Team Identity and Affiliation, and Team Identity and Debugging Reference.
Responsibility boundary
Team/Policy answers which side an Actor belongs to, where TeamId is read and written, and the relationship between two Actors. Command owns command targets, requirement tags, execution entry points, and failure reporting. Ability/GAS owns skill effects, costs, cooldowns, GameplayEffects, GameplayEvents, and prediction semantics.
Do not make TeamPolicy trigger Abilities or make an Ability own a second affiliation truth. An Ability may read TeamId as effect-rule input; a Command may trigger an Ability in its execution layer; failure reasons return through the Command or Ability result channel.
UGAIS_ProjectPolicy
When a project already has its own affiliation system, customize UGAIS_ProjectPolicy first. Override its team query and write methods so GAIS reads TeamId and TeamAttitude through the project source of truth. Policy runs as a CDO and must remain stateless: do not cache runtime Actor or Component references.
UGAIS_TeamAgentComponent
Use TeamAgent when GAIS itself supplies affiliation truth. Override OnTeamIdChanged or observe OnTeamIdChangedEvent for UI, diagnostics, and project-mirror synchronization.
Ability / GAS
GAIS depends on GameplayAbilities, but does not make AbilitySystem an independent central module. The Command layer owns targets, intent, and organization; project GAS owns skills, effects, cooldowns, costs, and GameplayEvents.
IGAIS_CommandAbilityInterface and GAIS_AbilitySystemExtensionLibrary are the Command-to-Ability seam. Let Command Definition decide when an Ability is triggered and let the Ability decide its concrete effect. Do not duplicate project skill implementation in GAIS documents or assets.
A verifiable integration has this path:
- An attack Command validates that its target is hostile and returns a Command reason on failure rather than silently skipping Ability activation.
- Its execution layer triggers a project Ability; the Ability owns cost, cooldown, hit, GameplayEffect, and completion.
- Ability completion reports success, failure, or cancellation to Command execution; CommandSystem then releases Current or advances Queue.
- GameplayDebugger TeamSource, Command LastResult, Queue completion, and Ability logs explain the same outcome.