RIT-B01 | RiteSeekers — Reference 구조 분석과 적용·확장

RiteSeekers를 시작할 때는 D1 프로젝트를 따라가며 전체 Gameplay 흐름을 익혔습니다.

이후 Lyra Starter Game Source를 다시 확인하면서 Experience, PawnData, ASC, AbilitySet이 실제로 어떤 역할을 하고 서로 어떻게 이어지는지 따라가 봤습니다.

처음에는 비슷한 기능을 구현하는 것 자체에 더 집중했습니다.

Source를 다시 보기 시작한 뒤에는 기능이 동작한다는 결과보다 왜 이 기능이 이 위치에 있고, 다음 시스템으로 어떤 상태가 넘어가는지를 더 많이 보게 됐습니다.

RiteSeekers에서는 이렇게 이해한 구조를 현재 프로젝트에 적용했고, Combat 쪽에서는 필요한 Runtime 영역을 직접 확장했습니다.

참고한 구조와 적용 범위

RiteSeekers의 출발점은 Reference 프로젝트였습니다.

D1에서는 전체 Gameplay 흐름을 처음 접했고, 이후 Lyra Starter Game Source에서 그 구조가 실제로 어떻게 구현되어 있는지 다시 확인했습니다.

현재 프로젝트에서는 Reference의 기능을 그대로 재현하는 데서 끝내지 않고, 실제 RiteSeekers의 Equipment, Ability, Combat 흐름에 연결해 봤습니다.

D1
→ 전체 Gameplay 흐름을 처음 익힌 Reference
 
Lyra Starter Game
→ Experience / PawnData / ASC / AbilitySet 구조를 다시 확인한 Source
 
RiteSeekers
→ 이해한 구조를 적용하고 필요한 Gameplay 영역을 확장한 프로젝트

Reference에서 배운 구조와 RiteSeekers에서 직접 추가한 부분은 구분해서 보고 있습니다.

기반 Gameplay Framework 전체를 제가 처음부터 설계했다는 의미로 설명하지 않습니다.

Reference를 따라간 이유

Unreal Gameplay Framework를 처음 볼 때는 Character를 중심으로 기능을 생각하기 쉬웠습니다.

그런데 실제 Source에서는 하나의 Character Class 안에서 모든 과정이 끝나지 않았습니다.

플레이어가 실제 Gameplay에 참여하기까지 여러 데이터와 Runtime 상태가 이어졌습니다.

제가 처음 많이 따라간 흐름은 다음과 같습니다.

Experience
→ PawnData
→ ASC Setup
→ AbilitySet Grant
→ Gameplay Ability
→ Gameplay Event

처음에는 각각의 Class가 무슨 일을 하는지 따로 외우려고 했습니다.

하지만 Source를 계속 보다 보니 앞 단계에서 결정한 정보가 다음 단계에서 어떻게 사용되는지를 아는 편이 훨씬 중요했습니다.

Experience에서 Player 구성을 결정하고, PawnData가 필요한 데이터를 제공하고, AbilitySet이 ASC에 Grant되면서 실제 Ability Runtime 상태가 만들어지는 식입니다.

이 연결을 알고 나니 이후 Equipment나 Combat Source를 볼 때도 어디에서부터 따라가야 할지 조금씩 보이기 시작했습니다.

처음에는 화면의 결과를 먼저 봤다

처음 프로젝트를 따라갈 때는 기능이 눈에 보이는 대로 동작하는지를 가장 먼저 확인했습니다.

Ability가 실행되는가?
 
Equipment가 변경되는가?
 
공격했을 때 Combat 결과가 나오는가?

기능을 처음 익힐 때는 이 방식도 도움이 됐습니다.

문제는 프로젝트가 커진 뒤였습니다.

같은 결과가 화면에 나오더라도 어떤 Data와 Runtime State를 거쳐 그 결과가 만들어졌는지를 모르면 문제가 생겼을 때 다시 Source를 찾기가 어려웠습니다.

그래서 기능 자체보다 그 앞뒤 연결을 다시 보기 시작했습니다.

Source를 다시 보면서 중간 상태가 보이기 시작했다

Ability 하나만 보더라도 실행되기 전까지 여러 상태가 이어집니다.

PawnData
→ AbilitySet
→ ASC
→ AbilitySpec
→ Gameplay Ability

Equipment도 비슷했습니다.

Item
→ Equipment
→ AbilitySet
→ ASC
→ Gameplay Ability

처음에는 마지막에 Ability가 실행되거나 Weapon이 바뀌는지만 봤습니다.

지금은 그 결과가 나오기 전에 중간 상태가 실제로 만들어졌는지도 같이 확인합니다.

이 차이가 이후 B05의 Equipment와 B06의 Ability Activation을 볼 때도 그대로 이어졌습니다.

Character Spawn과 Gameplay Ready는 같은 시점이 아니었다

Experience에서 Player Gameplay가 준비되는 흐름을 따라가면서 처음 크게 구분하게 된 부분이 있었습니다.

Experience
→ PawnData
→ ASC Setup
→ AbilitySet Grant
→ Input Setup
→ Gameplay Ready

Character가 World에 Spawn됐다고 해서 바로 모든 Gameplay 기능을 사용할 수 있는 것은 아니었습니다.

Character Spawn
!=
Gameplay Ready

PawnData가 정해지고 ASC와 AbilitySet, Input 구성이 이어진 뒤 실제 Gameplay에 필요한 상태가 준비됩니다.

📸 Screenshot 1. B_Experience_RiteCombatGame에서 PawnData_RiteSeeker를 기본 PawnData로 연결한 설정.

여기서는 Experience에서 PawnData로 이어지는 시작점만 보여주고, 실제 Gameplay Ready까지의 세부 흐름은 B02에서 따로 따라갔습니다.

ItemTemplate과 Fragment를 따라가며 Item을 보는 방식도 달라졌다

Reference를 보면서 특히 흥미로웠던 부분 중 하나가 Item과 Equipment가 Ability까지 이어지는 구조였습니다.

Item 쪽에서는 하나의 Item Class 안에 모든 특성을 고정해서 넣기보다 필요한 설정을 Fragment 단위로 나눠 ItemTemplate에 조합할 수 있었습니다.

처음에는 Fragment가 ActorComponent와 비슷한 개념처럼 느껴졌습니다.

하지만 현재 RiteSeekers에서는 조금 다르게 이해하고 있습니다.

ActorComponent가 Actor에 붙어 Runtime 기능이나 상태를 담당한다면, Item Fragment는 ItemTemplate에서 필요한 아이템 특성과 설정을 기능별로 나누어 조합하는 쪽에 가깝습니다.

제가 Fragment를 이해할 때는 일반 권총에 일회용이라는 특성을 추가한다고 생각하는 것이 쉬웠습니다.

매번 새로운 Item Class를 하나 더 만드는 대신, 필요한 특성을 하나의 기능 단위로 나눠 ItemTemplate에 넣는 방식입니다.

ItemTemplate
→ 필요한 Fragment 조합
→ Equipment / Item 기능 구성
→ AbilitySet
→ ASC AbilitySpec
→ Gameplay Ability

이건 Fragment 구조를 이해하기 위해 든 예시입니다.

RiteSeekers에 실제로 일회용 권총 기능이 구현되어 있다는 뜻은 아닙니다.

📸 Screenshot 2. B_ItemTemplate_OneHandSword_001에서 Equipable / Weapon Fragment를 조합한 ItemTemplate 설정.

Equipment에서는 화면 표현과 Gameplay 구성이 같이 이어졌다

ItemTemplate에서 Equipable / Weapon 특성을 구성한 뒤 실제 Equipment에는 현재 Weapon을 어떻게 보여줄지에 필요한 설정이 따로 있었습니다.

📸 Screenshot 3. One Hand Sword의 Socket, Montage, Animation Layer가 연결된 Equipment 설정.

WeaponHandType과 AttachSocket은 Weapon을 어느 손과 Socket에 붙일지 정하고, Equip / Hit / Idle Montage는 장착 상태에서 사용할 Animation과 연결됩니다.

AnimInstanceClass에는 ABP_RiteSeeker_AnimLayers_OneHandSword가 연결되어 있어 One Hand Sword에서 사용할 Animation Layer도 확인할 수 있었습니다.

실제 Runtime에서도 Weapon을 변경했을 때 서로 다른 공격 Animation이 적용되는 것을 확인했습니다.

그런데 화면에 Weapon이 제대로 보이는 것만으로 Equipment 작업이 끝난 것은 아니었습니다.

전투에 필요한 Ability가 있다면 AbilitySet을 통해 ASC의 Runtime 상태까지 이어져야 합니다.

[5.AbilitySet_OneHandSword(LyraAbilitySet)3.png]

📸 Screenshot 4. AbilitySet_OneHandSword에 One Hand Sword 전투에 필요한 Gameplay Ability가 구성된 설정.

이 설정들을 같이 보면서 Equipment 상태를 크게 두 가지로 나눠서 이해하게 됐습니다.

Visual State
= Mesh / Socket / Montage / Animation Layer
 
Gameplay State
= AbilitySet / ASC AbilitySpec / Gameplay Ability

화면에서 Weapon이 정상적으로 장착되고 Animation이 바뀌었다고 해서 ASC의 Gameplay Ability까지 정상적으로 구성됐다고 바로 판단하지는 않습니다.

B05에서는 이 흐름을 ItemData → ItemTemplate → ItemInstance → Equipment → ASC까지 더 내려가서 확인했습니다.

Combat 쪽에서는 필요한 영역을 직접 확장했다

Reference 구조를 따라간 뒤 Combat에서는 현재 프로젝트에 필요한 흐름을 추가했습니다.

처음에는 Blood나 Execution처럼 공격 뒤에 붙는 효과도 Melee 안에서 직접 처리할 수 있다고 생각했습니다.

하지만 Rule이 하나씩 늘어나면 Melee가 실제 공격뿐 아니라 각 Rule의 조건까지 모두 알아야 했습니다.

그래서 공격 결과와 후속 Combat Rule 사이를 나눴습니다.

Combat Result Pipeline
→ GameplayEvent.Combat.HitConfirmed
→ CombatAugment Runtime Layer

Melee는 실제 Target과 HitResult를 만들고, 후속 Rule이 사용할 수 있는 적중 결과가 만들어졌을 때 HitConfirmed를 전달합니다.

Blood와 Execution은 그 Event를 받아 각자의 조건을 판단합니다.

Melee와 후속 Rule의 역할을 나눴다

구조를 단순하게 보면 다음과 같습니다.

Melee Ability
→ 실제 공격 / 적중 결과
→ HitConfirmed
→ Blood / Execution

Melee가 Blood나 Execution을 직접 호출하지 않는 것이 제가 나누고 싶었던 부분이었습니다.

Melee
→ 실제로 무엇을 맞췄는가
 
Blood / Execution
→ 그 적중 결과를 어떤 Rule로 처리할 것인가

이렇게 나눈 뒤에는 새로운 Combat Rule이 추가되더라도 기본 Melee가 각 Rule의 세부 조건까지 알아야 하는 범위를 줄일 수 있었습니다.

Blood와 Execution의 실제 Runtime 동작은 B10에서 Grant, Trigger, Remove, Dead Target까지 다시 확인했습니다.

Reference에서 가져온 부분과 직접 추가한 부분

Reference에서 주로 이해하고 적용한 부분은 다음 구조입니다.

Experience / PawnData 기반 Gameplay 구성
 
ASC와 AbilitySet 연결
 
Equipment가 Gameplay State로 이어지는 흐름
 
GameplayEvent를 이용한 시스템 연결

RiteSeekers에서 Combat 쪽으로 직접 확장한 부분은 다음입니다.

Combat Result Pipeline
 
GameplayEvent.Combat.HitConfirmed 경계
 
CombatAugmentPassiveBase
 
FRSCombatAugmentDefinition
 
Blood Rule
 
Execution Rule
 
Runtime Snapshot / Verification

즉 Lyra의 Gameplay Framework 전체를 새로 만든 것이 아니라, Reference에서 이해한 구조 위에 RiteSeekers에서 필요했던 Combat Runtime 영역을 추가했습니다.

이 구분은 이후 글에서도 그대로 유지했습니다.

프로젝트를 진행하며 달라진 부분

RiteSeekers를 시작했을 때는 무엇을 만들었는가를 먼저 생각했습니다.

지금은 기능을 볼 때 그 기능이 프로젝트 안에서 어디에 연결되어 있는지도 같이 봅니다.

Equipment 하나를 보더라도:

ItemTemplate
→ Equipment
→ AbilitySet
→ ASC
→ Gameplay Ability

까지 같이 보고,

Combat Rule을 추가할 때도:

Melee
→ HitConfirmed
→ CombatAugment

처럼 기존 공격과 새로운 Rule을 어디에서 나눌지 먼저 생각하게 됐습니다.

RiteSeekers에서 가장 크게 얻은 건 특정 Framework Class 이름을 많이 외운 것이 아니었습니다.

Gameplay 기능들이 어떤 책임으로 연결되어 있는지를 Source와 Runtime에서 다시 따라가 본 경험이 이후 기능을 만들거나 문제를 찾을 때 더 많이 남았습니다.

정리

RiteSeekers는 D1을 따라가며 전체 Gameplay 흐름을 처음 익히는 것에서 시작했습니다.

이후 Lyra Starter Game Source를 다시 보면서 Experience, PawnData, ASC, AbilitySet 같은 기반 구조가 실제로 어떻게 이어지는지 확인했습니다.

그리고 이해한 구조를 현재 프로젝트에 적용한 뒤, Combat에서는 필요한 Runtime 영역을 직접 추가했습니다.

Reference로 Gameplay 흐름 이해
→ 실제 Source에서 연결 구조 확인
→ RiteSeekers에 적용
→ 필요한 Combat 영역 확장
→ Runtime에서 결과 확인

처음에는 Reference와 비슷한 기능을 구현하는 것이 목표에 가까웠습니다.

프로젝트를 진행하면서는 왜 이 구조가 이렇게 나뉘어 있고, 지금 만든 기능이 그중 어디에 놓여 있는지 설명할 수 있는 것이 더 중요하다고 생각하게 됐습니다.