RIT-B11 | RiteSeekers — 무기에 따라 Animation과 Camera 표현을 나눈 과정

RiteSeekers에서 무기를 바꿨을 때 가장 먼저 눈에 들어오는 차이는 공격 모션이었습니다.

One Hand Sword와 Staff가 같은 자세와 같은 공격 Animation을 사용하면 Weapon Mesh는 바뀌어도 플레이할 때 느껴지는 차이는 크지 않았습니다.

Skill도 비슷했습니다. Sword Skill에서는 순간적으로 시점을 가까이 가져오고, Shield Skill에서는 방패로 찍는 타격 순간 CameraShake를 사용했습니다.

처음에는 이런 표현도 Ability 안에서 필요할 때 직접 바꾸면 된다고 생각했습니다.

프로젝트를 계속 따라가다 보니 실제 Gameplay와 화면에 보이는 표현을 조금 나눠서 보게 됐습니다.

Gameplay
→ 실제로 무엇이 실행됐는가
 
Animation / Camera
→ 그 상태를 플레이어에게 어떻게 보여줄 것인가

화면에서는 공격과 Camera가 한꺼번에 움직이지만, 문제가 생겼을 때는 이 둘을 같은 것으로 보면 원인을 찾기 어려웠습니다.

공격 Animation은 정상인데 실제 Hit이 나오지 않을 수도 있고, Damage는 정상인데 Camera 표현만 이상할 수도 있었기 때문입니다.

그래서 B11에서는 Weapon이나 Skill State가 어떤 Animation과 Camera 표현으로 이어지는지, 그리고 그 표현과 실제 Combat 결과는 어디에서 갈리는지를 중심으로 정리했습니다.

Weapon에 따라 Animation Layer를 나눴다

장비 변경을 Weapon Mesh 교체로만 보면 실제 플레이에서 느껴지는 차이를 놓치기 쉽습니다.

현재 사용하는 Weapon이 달라지면 공격할 때 사용할 Animation 표현도 달라져야 했습니다.

RiteSeekers에는 무기별 Animation Layer Asset이 나뉘어 있습니다.

ABP_RiteSeeker_AnimLayers_Base
ABP_RiteSeeker_AnimLayers_OneHandSword
ABP_RiteSeeker_AnimLayers_TwoHandSword
ABP_RiteSeeker_AnimLayers_Staff

이 구조를 따라가면서 Weapon 변경을 세 가지 정도로 나눠서 보게 됐습니다.

Equipment
→ 지금 어떤 Weapon을 사용하고 있는가
 
Gameplay
→ 그 Weapon에서 어떤 Ability를 사용할 수 있는가
 
Animation
→ 그 Weapon을 어떤 움직임으로 보여줄 것인가

셋은 연결되어 있지만 같은 상태는 아니었습니다.

예를 들어 Weapon이 One Hand Sword로 바뀌었다고 해서 단순히 Mesh만 교체되는 것으로 끝나는 게 아니라, 그 Weapon에 맞는 공격 표현도 함께 바뀌어야 실제 플레이에서 무기를 바꿨다는 느낌이 납니다.

📸 Screenshot 1. ABP_RiteSeeker_AnimLayers_OneHandSword에서 One Hand Sword에 사용할 Animation Layer를 구성한 모습.

모든 Weapon의 Animation Blueprint를 하나씩 보여주지는 않았습니다.

Asset이 여러 개 있다는 사실 자체보다, 대표적인 One Hand Sword Layer를 하나 보여주고 뒤의 Runtime 영상에서 실제 Weapon에 따라 공격 모션이 달라지는 모습을 확인하는 편이 더 이해하기 쉬웠기 때문입니다.

Runtime에서 실제 공격 모션도 달라지는지 확인했다

Animation Layer Asset이 나뉘어 있다는 것과 실제 Character에 적용되는 것은 또 다른 문제였습니다.

그래서 Weapon을 바꾼 뒤 공격했을 때 실제 Animation도 같이 달라지는지 확인했습니다.

One Hand Sword
→ One Hand Sword 공격 Animation
 
다른 Weapon
→ 해당 Weapon의 공격 Animation

🎥 Video 1. Weapon을 변경한 뒤 공격했을 때 각 Weapon에 맞는 서로 다른 공격 Animation이 실제 Runtime에 적용되는 모습.

영상에서는 최소한:

One Hand Sword 장착
→ 공격
 
다른 Weapon 장착
→ 공격

이 이어지도록 두었습니다.

여기서 확인하려는 것은 공격 Damage가 몇이 들어갔는지가 아니라, 현재 Weapon State가 실제 공격 표현까지 바꾸고 있는가입니다.

B05에서는 Weapon 변경이 Equipment와 ASC의 Gameplay State까지 이어지는지를 봤습니다.

여기서는 같은 장비 변경이 실제 공격 표현에도 반영되는지를 Runtime 영상으로 확인했습니다.

즉 같은 Weapon 변경을 보더라도:

B05
→ Gameplay State가 바뀌었는가
 
B11
→ 그 State가 실제 Animation 표현까지 이어졌는가

로 확인하는 지점이 달랐습니다.

Animation이 정상이어도 Hit은 따로 봤다

캐릭터가 검을 정상적으로 휘두르면 공격도 정상적으로 처리된 것처럼 보이기 쉽습니다.

하지만 Animation이 재생되는 것과 실제 Target을 맞추는 것은 다른 결과였습니다.

Animation 재생
→ 공격 동작 표현
 
실제 Hit
→ Trace가 Target을 찾고 HitResult를 만든 결과

근접 공격에서는 대략 다음 흐름으로 이어집니다.

Montage / Notify
→ Trace
→ TargetData / HitResult
→ HitConfirmed
→ Damage

Animation과 Montage는 공격 동작과 Timing을 표현하지만 실제 Target이 맞았는지는 이후 Trace 결과에서 결정됩니다.

그래서 Character가 정상적으로 공격 Animation을 재생하는데 적의 Health가 줄지 않는다면 Animation만 계속 확인하지는 않았습니다.

먼저:

Animation 문제인가
 
Trace가 Target을 찾지 못한 것인가
 
HitResult 이후 Combat 흐름이 끊긴 것인가

를 나눠서 봤습니다.

B04에서는 Damage 흐름을, B10에서는 실제 Target / HitResult 이후 HitConfirmed가 만들어지는 부분을 따로 확인했습니다.

B11의 Animation 영상은 현재 Weapon에 맞는 공격 표현이 실제 Runtime에 적용됐다는 것까지만 보여줍니다.

이렇게 Evidence의 범위를 나눠둔 이유도 화면에서 공격이 정상적으로 보인다는 것만으로 Combat 전체가 정상이라고 설명하지 않기 위해서였습니다.

기본 Camera는 CM_RiteSeeker에서 시작한다

Animation 다음으로 따라간 것은 Camera였습니다.

PawnData_RiteSeeker에는 기본 CameraMode로 CM_RiteSeeker가 연결되어 있습니다.

PawnData 자체와 CM_RiteSeeker의 연결은 B02에서 이미 확인했기 때문에 B11에서는 같은 Screenshot을 다시 넣지 않았습니다.

여기서는 그 연결을 다시 증명하기보다, 기본 Camera가 Skill 실행 중 실제로 어떻게 달라지는지를 보는 쪽에 집중했습니다.

Camera Source와 Asset을 보면서 제가 이해한 역할은 이 정도였습니다.

PawnData
→ 기본 CameraMode 지정
 
CameraMode
→ 현재 시점의 FOV / 위치 / View 계산
 
CameraModeStack
→ CameraMode 사이의 전환과 Blend

조금 더 실제 플레이 기준으로 보면:

CM_RiteSeeker
→ 평상시 플레이 시점
 
Skill CameraMode
→ 특정 Skill 동안 사용할 시점
 
CameraModeStack
→ 두 CameraMode 사이 전환과 Blend

에 가깝습니다.

📸 Screenshot 2. Skill을 사용하지 않은 평상시 Runtime 화면. B02에서 확인한 기본 CameraMode가 실제 플레이에서는 어떤 시점으로 보이는지 확인했습니다.

이 화면을 먼저 기준으로 잡아두면, 뒤에서 보는 Skill Camera의 RuntimeOut / RuntimeIn이 평상시 시점과 어떻게 달라지는지 비교하기 쉬웠습니다.

여기서는 CM_RiteSeeker의 내부 Details나 VC_RiteSeeker까지 별도 Screenshot으로 늘리지는 않았습니다.

대신 평상시 Runtime 화면을 하나 기준으로 두고, 뒤에서 Skill Camera의 RuntimeOut / RuntimeIn과 실제 View가 어떻게 달라지는지를 비교했습니다.

B11에서 확인하려는 것은 Camera Framework 내부의 모든 구성 요소가 아니라, 기본 Camera와 Skill Camera가 실제 플레이에서 어떤 표현 차이를 만드는지이기 때문입니다.

중요한 건 CameraModeStack이라는 Framework 자체를 제가 처음부터 만든 것은 아니라는 점입니다.

Reference 구조를 따라 Camera 흐름을 이해하고, RiteSeekers에서 필요한 CameraMode Asset을 실제 Gameplay 표현에 연결한 범위입니다.

Skill에서는 평상시와 다른 CameraMode를 사용했다

평상시 Camera를 모든 Skill에서 그대로 사용하는 것보다 Skill의 성격에 따라 시점을 조금 다르게 주고 싶었습니다.

RiteSeekers에서는 Sword Skill을 사용할 때 순간적으로 시점이 가까워지는 표현을 Runtime에서 확인했습니다.

기본 CameraMode
→ Skill 실행
→ Skill CameraMode
→ CameraModeStack Blend
→ Skill에 맞는 시점
→ 종료 후 기본 Camera로 복귀

프로젝트 안에는 여러 CM_Skill_* Asset이 있습니다.

그렇다고 공개 글에 CameraMode Asset을 전부 나열하거나 Details 화면을 여러 장 넣지는 않았습니다.

실제 플레이에서 Camera가 어떻게 달라지는지 보는 것이 더 직관적이라고 생각했습니다.

앞에서 평상시 CM_RiteSeeker의 Runtime 시점을 먼저 확인했습니다.

여기서는 같은 Sword Skill 안에서 Camera 표현이 어떻게 달라지는지 보기 위해 RuntimeOut과 RuntimeIn 상태를 각각 정지시켜 비교했습니다.

Skill Camera — RuntimeOut

📸 Screenshot 3-A. Sword Skill의 RuntimeOut 상태에서 Character와 주변을 비교적 넓게 보여주는 Camera 시점을 확인한 화면.

Skill Camera — RuntimeIn

📸 Screenshot 3-B. 같은 Sword Skill에서 Camera가 Character 쪽으로 가까워진 RuntimeIn 상태를 확인한 화면.

두 장을 따로 둔 이유는 Camera 변화가 영상에서는 자연스럽게 지나가기 때문에, 시점 차이를 한눈에 비교하기 어렵기 때문입니다.

같은 Runtime 흐름에서 뽑은 두 화면을 나란히 보면:

RuntimeOut
→ Character와 주변을 비교적 넓게 보여주는 시점
 
RuntimeIn
→ Character 쪽으로 가까워진 시점

의 차이를 바로 확인할 수 있습니다.

앞의 CM_RiteSeeker 기본 Runtime 화면까지 같이 보면, 평상시 Camera와 Skill 중 Camera 표현을 각각 분리해서 비교할 수 있습니다.

이 두 화면만 보고 특정 FOV 수치나 CameraMode 내부 설정까지 설명하려고 하지는 않았습니다.

여기서는 Skill이 실행될 때 실제 플레이 화면의 시점이 달라진다는 것까지만 확인했습니다.

Camera가 실제로 전환되는 과정과 Skill 종료 후 시점이 돌아오는 모습은 뒤의 Runtime 영상에서 따로 확인했습니다.

CameraMode와 CameraShake는 다르게 봤다

처음에는 둘 다 화면이 움직이는 효과라서 비슷한 기능처럼 느껴졌습니다.

Runtime에서 직접 비교해보니 역할은 꽤 달랐습니다.

CameraMode
→ 시점 자체를 구성
→ FOV / 위치 / View
 
CameraModeStack
→ CameraMode 사이의 전환과 Blend
 
CameraShake
→ 현재 시점 위에 짧은 흔들림을 추가

RiteSeekers에서 실제 표현으로 보면 차이가 더 쉬웠습니다.

Sword Skill
→ 순간적으로 시점이 가까워짐
→ CameraMode
 
Shield Skill
→ 방패로 찍는 타격 순간 화면이 흔들림
→ CameraShake

하나는 플레이어가 보고 있는 시점 자체를 바꾸는 쪽이고, 다른 하나는 현재 시점 위에 짧은 충격을 더하는 쪽에 가까웠습니다.

예를 들어 Sword Skill의 Camera는 Skill이 진행되는 동안 Character를 보는 거리 자체가 달라집니다.

반면 Shield Skill에서는 방패로 찍는 타격 순간 CameraShake를 사용했습니다. 기본 시점 자체를 다른 Camera로 바꾸기보다, Impact가 발생하는 순간 현재 화면에 짧은 흔들림을 더하는 쪽에 가깝습니다.

예전에는 둘 다 그냥 Camera 효과라고 묶어서 생각했는데, 지금은 어떤 표현을 만들고 싶은지에 따라 둘을 따로 보게 됐습니다.

Runtime에서 Camera 차이를 확인했다

Camera Asset도 Editor에 존재한다는 것만으로 실제 플레이에 적용됐다고 볼 수는 없습니다.

앞에서는 평상시 CM_RiteSeeker Runtime 화면을 기준으로 두고, RuntimeOut / RuntimeIn 두 장을 통해 Skill Camera의 View 차이를 비교했습니다.

영상에서는 정지 화면만으로 보기 어려운 실제 Camera 전환 과정과 CameraShake를 확인했습니다.

🎥 Video 2. Sword Skill에서는 평상시와 다른 Camera 시점으로 전환됐다가 다시 돌아오고, Shield Skill에서는 방패로 찍는 타격 순간 CameraShake가 적용되는 Runtime 결과.

영상에서는 긴 설명보다 두 표현의 차이가 바로 보이도록 했습니다.

Sword Skill
→ Camera 시점 변화
→ Skill 종료 후 기본 시점 복귀
 
Shield Skill
→ 방패 찍기 / CameraShake

RIT-B11_CAM_Skill_Zoom_RuntimeOut.png과 RIT-B11_CAM_Skill_Zoom_RuntimeIn.png은 Sword Skill의 RuntimeOut / RuntimeIn 상태에서 달라지는 View 차이를 정지 화면으로 비교하기 위한 자료이고,

Video 2는 Camera가 실제로 전환되는 과정과 순간적인 CameraShake를 보기 위한 자료입니다.

정지 화면으로는 CameraShake의 시간 흐름을 보여주기 어렵기 때문에 이 부분은 영상이 더 적합했습니다.

Camera가 잘 나왔다고 Combat까지 끝난 것은 아니었다

Camera도 Animation과 비슷했습니다.

Skill Camera가 정상적으로 전환됐다고 실제 Combat 결과까지 정상이라는 의미는 아닙니다.

CameraMode 변화
→ 플레이어에게 보이는 시점
 
CameraShake
→ 순간적인 Impact 표현
 
Hit / Damage
→ 실제 Gameplay 결과

예를 들어 Camera는 정상적으로 가까워졌지만 Trace가 Target을 찾지 못할 수도 있습니다.

반대로 Damage는 정상적으로 들어갔는데 CameraMode 전환만 잘못되어 화면 표현이 어색할 수도 있습니다.

이 차이를 구분하지 않으면:

화면이 이상하다
→ Ability 문제인가?
→ Animation 문제인가?
→ Camera 문제인가?
→ Hit 문제인가?

를 다시 처음부터 따라가야 합니다.

그래서 Animation이나 Camera가 이상하면 표현 쪽을 보고, Hit이나 Damage가 이상하면 Combat Runtime State를 따로 확인했습니다.

화면에서 동시에 보인다고 해서 같은 문제는 아니었습니다.

현재 프로젝트에서 확인한 범위

RiteSeekers에서 실제로 확인한 범위는 다음 정도입니다.

PawnData_RiteSeeker
→ CM_RiteSeeker 연결
 
Weapon별 Animation Layer
→ Asset 구성
 
Weapon 변경
→ 서로 다른 공격 Animation Runtime 적용
 
Sword Skill
→ CameraMode 기반 시점 변화
 
Shield Skill
→ 타격 순간 CameraShake

Animation Layer와 CameraMode / CameraModeStack의 기반 Framework를 제가 처음부터 만든 것은 아닙니다.

현재 프로젝트에서는 Reference 구조를 따라 역할을 확인하고, 그 위에 Weapon과 Skill에 필요한 Asset을 구성해서 실제 Runtime 표현으로 연결했습니다.

그리고 공개 글에 넣을 확인 자료도 실제로 확인한 범위에 맞춰 골랐습니다.

Animation Layer는 대표 Asset 하나만 보여주고, 실제 Weapon별 차이는 Runtime 영상으로 확인했습니다.

Camera 역시 내부 Asset을 여러 장 나열하기보다 평상시 시점과 Sword Skill의 RuntimeOut / RuntimeIn을 실제 플레이 화면으로 비교하고, 전환 과정과 Shield Skill의 CameraShake는 영상으로 남겼습니다.

그래서 아래처럼 설명하지 않습니다.

Lyra Camera Framework 전체 직접 구현
 
CameraModeStack 직접 설계
 
Animation Layer Framework 전체 직접 구현

실제로 손댄 범위를 그대로 보여주는 게 더 맞다고 생각합니다.

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

처음에는 Weapon과 Skill 표현도 Ability 하나 안에서 생각했습니다.

Weapon이 바뀌면
→ 다른 Animation 재생
 
Skill을 쓰면
→ Camera 효과 실행

기능만 보면 틀린 말은 아닙니다.

하지만 Source와 Asset을 같이 보면서 조금 더 나눠서 보기 시작했습니다.

Weapon State
→ 어떤 Animation 표현을 사용할 것인가
 
Skill State
→ 어떤 CameraMode를 사용할 것인가
 
Impact
→ CameraShake로 어떤 Feedback을 줄 것인가
 
Combat
→ 실제 Hit과 Damage가 발생했는가

이렇게 나눠서 본 뒤에는 Weapon 표현이 이상하다고 무조건 Ability부터 열지 않게 됐습니다.

예를 들어:

Weapon은 바뀌었는데 공격 자세가 그대로다
→ Animation Layer 쪽 확인
 
Skill은 실행됐는데 Camera 변화가 없다
→ CameraMode 전환 쪽 확인
 
CameraShake는 나오는데 Target Health가 줄지 않는다
→ Camera가 아니라 Combat 쪽 확인

처럼 먼저 문제 범위를 나눌 수 있었습니다.

Animation 문제인지, Camera 전환 문제인지, 실제 Combat 문제인지부터 구분해서 볼 수 있게 된 것이 프로젝트를 진행하면서 가장 크게 달라진 부분 중 하나였습니다.

정리

RiteSeekers에서 Weapon Animation과 Skill Camera를 따라가면서 가장 크게 느낀 것은 화면에서 동시에 보이는 기능이라고 해서 같은 책임을 가지는 것은 아니라는 점이었습니다.

Weapon Animation은:

Active Weapon
→ Weapon-specific Animation Layer
→ 무기별 공격 표현

으로 이어집니다.

Camera는:

PawnData
→ Default CameraMode
 
Skill
→ Skill CameraMode
→ CameraModeStack
→ Blend

로 볼 수 있습니다.

짧은 타격 Feedback은:

Impact
→ CameraShake

로 따로 볼 수 있었습니다.

그리고 이 모든 화면 표현과 실제 Combat 결과도 다시 나눠서 봤습니다.

Animation / Camera
→ 플레이어가 어떻게 보고 느끼는가
 
Combat
→ 실제로 무엇이 Hit되고 어떤 결과가 발생했는가

처음에는 무기마다 Animation을 바꾸고 Skill에 Camera 효과를 넣었다는 결과만 봤습니다.

지금은 현재 Weapon이나 Skill State가 어떤 Animation과 Camera 표현으로 이어지는지, 그리고 그 표현과 실제 Combat 결과는 어디서 갈리는지까지 같이 설명할 수 있게 됐습니다.

화면에 보이는 결과만 확인하는 대신:

Weapon State
→ Animation
 
Skill State
→ CameraMode
 
Impact
→ CameraShake
 
Hit
→ Combat Result

로 책임을 나눠서 보게 되면서, 표현 문제와 Gameplay 문제를 같은 원인으로 묶지 않고 따라갈 수 있게 됐습니다.

결국 B11에서 확인하고 싶었던 것은 단순히 “Animation이 바뀌었다”, “Camera가 움직였다”가 아니었습니다.

지금은 현재 Weapon이나 Skill State가 실제 Runtime에서 어떤 Animation과 Camera 표현으로 이어지는지, 그리고 화면에 보이는 표현과 실제 Combat 결과를 어디에서 나눠서 봐야 하는지까지 같이 설명할 수 있게 됐습니다.