GameplayAbility
개요
Gameplay Ability는 캐릭터나 액터가 수행할 수 있는 능력을 정의하는 핵심 클래스입니다. 주요 특징은 다음과 같습니다.
Ability Tasks
Ability Tasks는 Gameplay Ability의 실행 도중 비동기적으로 발생하는 작업입니다.
비동기 이벤트 처리: 특정 시간 동안 대기하거나 입력을 받을 때까지 작업을 중단하고 재개하는 등의 비동기적 로직을 처리합니다.
예제: 일정 시간 후 능력을 종료하거나 특정 키 입력을 대기합니다.
Gameplay Cues
Gameplay Cues는 능력 실행 중에 시각적/음향적 효과를 발생시키는 기능입니다.
클라이언트와 서버에 효과를 전파합니다.
효과 예시: 피격 시 붉은 이펙트, 스킬 사용 시 폭발 효과 등을 적용할 수 있습니다.
Gameplay Tags
태그는 어빌리티의 활성화, 취소, 차단 등을 제어하는 데 중요한 역할을 합니다.
Ability Tags : 해당 어빌리티 자체에 부여된 태그입니다. 이 태그를 통해 어빌리티를 분류하거나 검색할 수 있습니다.
Cancel Abilities with Tag : 특정 태그를 가진 다른 어빌리티를 취소시키는 데 사용됩니다. 예를 들어, "Player.Status.HitReact" 태그가 부여되었을 경우 주문을 취소합니다.
Block Abilities with Tag : 특정 태그를 가진 다른 어빌리티의 실행을 막습니다. 예를 들어, "Player.Status.Stun" 태그가 부여된 상태에서는 " Player.ability.attack" 태그를 가진 어빌리티를 사용하지 못하게 할 수 있습니다.
Activation Owned Tags : 어빌리티가 활성화되는 동안 어빌리티의 소유자 (보통 캐릭터)에게 부여되는 태그입니다. 어빌리티가 종료되면 이 태그는 제거됩니다.
Activation Required Tags : 어빌리티를 활성화하기 위해 어빌리티의 소유자가 반드시 가지고 있어야 하는 태그입니다. 예를 들어, "Player.Status.Rage" 태그가 있어야 " Rage.Attack" 어빌리티를 사용할 수 있도록 설정할 수 있습니다.
Activation Blocked Tags : 어빌리티의 소유자가 해당 태그를 가지고 있으면 어빌리티를 활성화할 수 없습니다. 예를 들어, "Player.Status.Stun" 태그가 있으면 어떤 어빌리티도 사용하지 못하게 할 수 있습니다.
Source Required Tags : 어빌리티를 발동시킨 주체 (소스)가 가지고 있어야 하는 태그입니다. 예를 들어, 특정 무기 ("무기.화염방사기")를 장착한 상태에서만 발동되는 어빌리티에 사용할 수 있습니다.
Source Blocked Tags : 어빌리티를 발동시킨 주체 (소스)가 해당 태그를 가지고 있으면 어빌리티를 발동할 수 없습니다.
Target Required Tags : 어빌리티의 대상 (타겟)이 가지고 있어야 하는 태그입니다. 예를 들어, "적.약점.불" 태그를 가진 적에게만 추가 피해를 주는 어빌리티에 사용할 수 있습니다.
Target Blocked Tags : 어빌리티의 대상 (타겟)이 해당 태그를 가지고 있으면 어빌리티가 적용되지 않습니다. 예를 들어, "상태.무적" 태그를 가진 대상에게는 어떤 공격 어빌리티도 효과가 없도록 설정할 수 있습니다.
고급 설정
Replication Policy
어빌리티의 실행 정보를 클라이언트와 서버 간에 어떻게 복제할지 결정합니다.
Do Not Replicate (복제 안 함): 어빌리티 실행 정보를 복제하지 않습니다. 로컬에서만 실행되는 어빌리티에 적합합니다. 예를 들어, 로컬 UI 업데이트나 간단한 클라이언트 측 효과 등에 사용될 수 있습니다.
Replicate (복제 함): 어빌리티 실행 정보를 복제합니다.
Instancing Policy
어빌리티 인스턴스를 어떻게 생성할지 결정합니다.
Non-Instanced (인스턴스 없음): 어빌리티는 싱글톤처럼 동작하며, 하나의 인스턴스만 존재합니다. 여러 번 실행해도 같은 인스턴스를 사용합니다.
Instanced Per Execution (실행마다 인스턴스): 어빌리티를 실행할 때마다 새로운 인스턴스를 생성합니다. 각 실행이 독립적인 상태를 가지도록 하기 위해 사용됩니다. 대부분의 어빌리티는 이 설정을 사용합니다.
Instanced Per Actor (액터마다 인스턴스): 액터당 하나의 어빌리티 인스턴스만 생성합니다. 액터의 상태에 따라 어빌리티의 동작이 달라져야 할 때 사용됩니다.
사용 사례
Non-Instanced: 단순하고 상태를 저장할 필요가 없는 어빌리티. 예: 단순한 공격 애니메이션 재생.
Instanced Per Execution: 여러 개의 개별 상태를 관리해야 하는 어빌리티. 예: 폭발, 충격파와 같은 효과.
Instanced Per Actor: 같은 액터에서 여러 번 사용되지만 데이터가 유지되어야 하는 어빌리티. 예: 버프, 지속 피해 효과.
퍼포먼스와 메모리 사용
Non-Instanced: 가장 효율적이지만 제약이 큼. 메모리 사용량이 가장 낮음.
Instanced Per Execution: 퍼포먼스 부담이 있지만 상태를 독립적으로 관리 가능.
Instanced Per Actor: 메모리 사용량이 증가하지만 효율적으로 데이터를 관리할 수 있음.
상태(State) 관리
Non-Instanced: 상태 저장 불가. 공유된 데이터를 기반으로 움직여야 함.
Instanced Per Execution: 매번 독립된 상태 생성. 충돌 위험 없음.
Instanced Per Actor: 동일 액터의 상태를 영구적으로 관리 가능. 이를 통해 액터 중심의 복합 로직 구현이 용이.
AbilityTask와의 연동 여부
Non-Instanced는 AbilityTask와 연결할 수 없으므로 비동기 로직을 다루기 어렵습니다.
Instanced Per Execution 및 Instanced Per Actor는 AbilityTask를 활용한 복잡한 로직 처리에 적합합니다.
사용하지 않는 것이 좋은 것들
Replication Policy
게임플레이 어빌리티는 이미 서버에서 소유 클라이언트로 복제됩니다. 즉, 별도로 복제 정책을 설정할 필요가 없습니다.
주의: 게임플레이 어빌리티는 시뮬레이트된 프록시(Simulated Proxies)에서는 실행되지 않습니다. (게임플레이 이펙트(Gameplay Effects, GE)와 게임플레이 큐(Gameplay Cues, GC)를 사용하세요.)
Server Respects Remote Ability Cancellation
이는 로컬 클라이언트의 어빌리티가 종료될 때 서버의 어빌리티도 종료됨을 의미합니다. 일반적으로 좋은 아이디어가 아닙니다. 중요한 것은 서버입니다, 클라이언트의 상태에 따라 서버의 어빌리티 실행이 영향을 받아서는 안 됩니다.
Replicate Input Directly
항상 입력 이벤트를 서버에 복제합니다. 입력을 직접 복제하는 방식은 불필요한 네트워크 트래픽을 유발하고 예측 기반의 부드러운 게임플레이를 방해할 수 있습니다.
요약
스킬 및 능력 구현
능력은 서버에서 부여되며, 클라이언트로 복제됩니다.
능력 실행 시 비용과 쿨다운을 관리할 수 있습니다.
비동기 작업 지원
Ability Task를 통해 능력 실행 도중 비동기 작업을 수행할 수 있습니다.
시각적/음향 효과 지원
GameplayCue를 통해 능력에 대한 시각적 효과(VFX)와 음향적 효과(SFX)를 손쉽게 추가할 수 있습니다.
네트워크 복제
서버-클라이언트 간 동기화로 멀티플레이어 환경에서도 안정적으로 동작합니다.