[UE5] 크리시 글자 애니메이션 구현, 메시지 구현, 인스턴싱 정책

1.

text 추가후 설정

 

2. 애니매이션 만들기

빨간색 핀꼽은후,

위치, 크기, 투명도를 저장하면됨.

 

3. 이벤트 그래프에서 노드연결

 

문제 : Text Block 메시지 바꿔야함

 

* 함수만들면됨 

기존거 복붙. 메시지만 set함

만든함수 연결

text set

Text Hit Message 색을 숫자색과 동일하게 변경 (만들어놓은 Text Color 이용)

정상작동

 

* 인스턴싱 정책

https://dev.epicgames.com/documentation/en-us/unreal-engine/gameplay-ability?application_version=4.27

인스턴싱 정책

게임플레이 능력이 실행되면 일반적으로 능력의 진행 상황을 추적하기 위해 새로운 객체(능력 유형)가 생성됩니다. 능력은 배틀 로얄, MOBA, MMO 또는 RTS 게임에서 100명 이상의 플레이어와 AI 캐릭터 간의 전투와 같이 어떤 경우에는 매우 자주 실행될 수 있으므로 능력 객체를 빠르게 생성하면 성능에 부정적인 영향을 미칠 수 있습니다. 이를 해결하기 위해 능력은 세 가지 다른 인스턴스화 정책 중에서 선택할 수 있으며, 효율성과 기능 간의 균형을 제공합니다. 지원되는 세 가지 인스턴싱 유형은 다음과 같습니다.

• 실행당 인스턴스화: 능력이 실행될 때마다 능력의 개체 사본이 생성됩니다. 이것의 장점은 블루프린트 그래프와 멤버 변수를 자유롭게 사용할 수 있고 모든 것이 실행 시작 시 기본값으로 초기화된다는 것입니다. 이것은 구현하기 가장 간단한 인스턴싱 정책이지만 더 큰 오버헤드가 발생하기 때문에 드물게 실행되는 능력에 이상적입니다. 예를 들어, MOBA의 "Ultimate"는 실행 사이에 긴 쿨다운(일반적으로 60-90초)이 있는 경향이 있고 이러한 능력을 전혀 사용할 수 있는 캐릭터가 몇 명(일반적으로 약 10명)에 불과하기 때문에 합리적인 사용 사례가 될 것입니다. 컴퓨터 제어 "미니언"이 사용하는 기본 공격 능력은 한 번에 수백 개가 있을 수 있고 각각이 기본 공격을 상당히 자주 가할 수 있으므로 새로운 개체의 빠른 생성(및 복제)을 유발할 수 있으므로 적합하지 않습니다.
• 액터당 인스턴스화: 각 액터는 Ability가 처음 실행될 때 이 Ability의 인스턴스를 하나 생성하고, 이후 실행에서 재사용합니다. 이렇게 하면 Ability 실행 사이에 멤버 변수를 정리해야 하지만, 여러 실행에 걸쳐 정보를 저장할 수도 있습니다. 액터당은 복제에 이상적입니다. Ability에는 변수 변경 및 RPC를 처리할 수 있는 복제된 개체가 있지만, 실행할 때마다 새 개체를 생성하여 네트워크 대역폭과 CPU 시간을 낭비하지 않기 때문입니다. 대규모 상황에서 이 정책은 Ability를 사용하는 많은 수의 액터(예: 대규모 전투)가 첫 번째 Ability 사용 시에만 개체를 ​​생성하기 때문에 좋은 성능을 발휘합니다.
• 인스턴스화되지 않음: 모든 범주에서 가장 효율적인 인스턴싱 정책입니다. 이 능력은 실행될 때 어떤 객체도 생성하지 않고 대신 클래스 기본 객체를 사용 합니다. 그러나 이러한 효율성은 몇 가지 제한을 도입합니다. 첫째, 이 정책은 블루프린트 그래프에 객체 인스턴스가 필요하기 때문에 능력을 전적으로 C++로 작성해야 한다는 고유 요구 사항이 있습니다. 인스턴스화되지 않은 능력의 블루프린트 클래스를 만들 수 있지만 노출된 속성의 기본값을 변경하기 위해서만 만들 수 있습니다. 또한 능력은 능력을 실행하는 동안 멤버 변수를 변경하거나 대리자를 바인딩해서는 안 됩니다. 또한 능력은 변수를 복제하거나 RPC를 처리할 수 없습니다. 이것은 내부 변수 저장소가 필요 없고(능력 사용자에게 속성을 설정하는 것은 가능하지만) 데이터를 복제할 필요가 없는 능력에만 사용해야 합니다. 특히 자주 실행되고 많은 캐릭터가 사용하는 능력, 예를 들어 대규모 RTS 또는 MOBA 타이틀에서 유닛이 사용하는 기본 공격에 적합합니다.

인스턴스화되지 않https://www.quodsoler.com/blog/learning-about-ability-instancing-policy-in-gas음

Learning about Ability Instancing Policy in GAS | Quod Soler

인스턴스화되지 않음

이것은 기본 인스턴싱 정책입니다. 능력이 인스턴스화되지 않은 경우, 이를 실행할 때 CDO (생성자 기본 개체)를 사용함을 의미합니다 .

이는 이 유형의 모든 기능이 동일한 UObject를 사용하여 실행된다는 것을 의미하는데, 여기에는 고려해야 할 몇 가지 부작용이 있습니다.

가장 중요한 점은 해당 유형의 모든 능력이 이 객체를 공유하기 때문에 능력에 어떤 상태도 저장할 수 없다는 것입니다.

우리는 또한 어떤 일을 기다리는 잠재적 행동을 가질 수 없습니다. 능력은 활성화되어야 하고, 일을 한 다음 같은 실행 흐름에서 끝나야 합니다.

( 정확히 이런 것은 아니고, 이것이 어떻게 작동하는지 알면 특정한 일을 할 수 있지만, 일종의 모범 사례가 될 것입니다.)

Actor당 인스턴스화됨

이건 제가 다양한 능력에 추천하는 인스턴싱 정책이에요.

능력이 액터마다 인스턴스화되면, 능력이 부여될 때 인스턴스가 생성되고 액터는 그것을 사용합니다.

이런 유형의 능력에서는 실행 중뿐만 아니라 실행 사이에도 상태를 저장할 수 있으므로 매우 유연한 인스턴싱 정책이 됩니다.

실행 당 인스턴스화

이름에서 알 수 있듯이, 이 인스턴싱 정책에서 능력은 부여될 때 인스턴스화되지 않고 대신 실행될 때마다 인스턴스화됩니다.

이 인스턴싱 정책에 데이터를 저장할 수 있지만 능력 실행 중에만 가능하며, 능력이 종료되면 사라집니다.

이 정책의 장점은 각각이 별도로 생성된 인스턴스이므로 동일한 유형의 여러 능력을 병렬로 실행할 수 있다는 것입니다. 액터당 인스턴스화를 사용하면 해당 능력을 다시 트리거하려면 취소해야 합니다.

실행당 인스턴스로 결정 

근거 : 가벼운 GE 효과임(사망시 녹음) && 확실히 Reaction 재생위해