DX9-B01 | DX9 Cat Quest — Player 입력에서 Damage 결과가 보이기까지

이 글에서 확인할 내용

DX9 Cat Quest에서 CPlayer는 단순히 화면 안에서 움직이는 캐릭터가 아니었습니다.

방향키 입력을 받아 위치를 바꾸고, 현재 방향과 상태에 맞는 Sprite를 선택하고, LMB 입력으로 기본 공격을 시작한 뒤 실제 Damage 결과가 화면에 보이기까지의 흐름이 Player를 중심으로 이어졌습니다.

처음 만들 당시에는 “방향키를 누르면 움직인다”, “마우스를 누르면 공격한다”는 결과를 만드는 데 더 집중했습니다.

하지만 지금 다시 코드를 따라가 보면 Player 하나가 움직이고 공격하기 위해서도 여러 단계가 연결되어 있었습니다.

Input
↓
Movement / Direction
↓
Sprite
↓
Attack Effect
↓
Collision
↓
Damage
↓
Feedback

이 글에서는 그중 Player 입력 → 이동 → 방향 상태 → 기본 공격 → Collider 판정 → Damage → WorldNumber 피드백 흐름을 정리합니다.

이동할 때 위치만 바꾸는 것은 아니었다

Player 이동은 방향키 입력을 CPlayer::Update에서 확인하고, CTransform을 통해 위치를 변경하는 방식이었습니다.

방향키 입력
↓
CPlayer::Update
↓
CTransform 위치 변경
↓
방향 상태 변경
↓
현재 상태에 맞는 Sprite 출력

2D 게임에서는 위치만 바뀐다고 캐릭터가 자연스럽게 보이지 않았습니다.

왼쪽으로 움직이면 왼쪽을 보는 Sprite가 필요했고, 오른쪽으로 움직이면 반대 방향의 Sprite가 필요했습니다.

여기에 장비 상태까지 들어가면서 같은 방향을 보고 있어도 맨몸인지, 투구를 썼는지, 무기를 들었는지에 따라 보여줘야 하는 모습이 달라졌습니다.

그래서 Player 이동은 단순히 좌표를 변경하는 작업이 아니라,

입력
→ 위치 변경
→ 방향 상태 변경
→ 현재 상태에 맞는 화면 표현

까지 함께 연결하는 작업이었습니다.

당시에는 필요한 조합을 직접 맞추는 방식이 많았지만, 이 과정에서 코드 안의 상태 변화와 실제 화면 표현이 함께 움직여야 한다는 점을 많이 체감했습니다.

기본 공격은 화면에 보이는 Effect부터 시작했다

LMB 입력이 들어오면 CSword_Effect가 생성되고 Slash Effect가 화면에 표시됐습니다.

LMB 입력
↓
CSword_Effect 생성
↓
Slash Effect 표시

게임을 플레이할 때 가장 먼저 보이는 것은 이 Slash Effect입니다.

처음에는 저도 “Slash가 나오면 공격이 된 것”처럼 생각하기 쉬웠습니다.

하지만 코드를 다시 보면 공격이 보이는 것과 실제로 Damage가 적용되는 것은 같은 흐름이 아니었습니다.

CSword_Effect는 공격이 나갔다는 시각적인 결과에 가까웠고, 실제 Damage 판정은 Player의 Collider를 기준으로 별도로 처리됐습니다.

실제 Damage는 Collider에서 판정했다

Player 기본 공격에서는 AttackAIO가 Layer_Monster에 있는 대상의 Collider를 확인했습니다.

LMB 입력
↓
Player Collider 기반 AttackAIO
↓
Layer_Monster 확인
↓
Collider overlap
↓
CStatus::Damaged

즉 공격 흐름을 역할 기준으로 나누면 다음과 같습니다.

보이는 공격
→ CSword_Effect
 
실제 Hit 판정
→ Player Collider / AttackAIO
 
Damage 결과
→ CStatus::Damaged

이 구분은 지금 보면 단순하지만, 당시에는 전투 기능을 직접 만들면서 처음 경험한 중요한 차이였습니다.

Effect가 재생됐다고 해서 Hit가 확정된 것은 아니고, Hit가 발생해야 실제 상태 변화가 일어납니다.

Damage가 적용된 뒤에도 한 단계가 더 필요했다

Monster의 CStatus에서 HP가 줄어들면 내부적으로는 Damage가 적용된 상태입니다.

하지만 플레이어 입장에서는 값이 바뀌었다는 사실을 바로 알기 어렵습니다.

그래서 Damage가 적용된 뒤에는 CWorldNumber를 통해 Damage Number를 화면에 표시했습니다.

Player 공격
↓
Monster Collider 확인
↓
CStatus::Damaged
↓
CWorldNumber
↓
Damage Number 표시

이 흐름까지 연결하고 나서야 플레이어가

내 공격이 나갔다.
↓
실제로 적에게 맞았다.
↓
Damage가 적용됐다.

는 결과를 화면에서 확인할 수 있었습니다.

지금은 자연스럽게 보이는 과정이지만, 당시에는 공격 하나를 만들면서도 입력 → 표현 → 판정 → 상태 변화 → 결과 표시가 모두 필요하다는 것을 직접 경험했습니다.

Player 공격을 다시 보면 세 단계로 나눌 수 있다

지금 기준으로 이 흐름을 가장 단순하게 정리하면 세 단계입니다.

1. 표현
CSword_Effect
 
2. 판정
Collider / AttackAIO
 
3. 결과
CStatus / CWorldNumber

처음 프로젝트를 만들 때는 이런 식으로 역할을 명확하게 나누어 설명하지 못했습니다.

그때는 캐릭터가 움직이고, 공격이 나오고, Monster HP가 줄어들면 된다고 생각했습니다.

하지만 지금 다시 보면 Visual State와 Hit 판정, Gameplay Result가 서로 다른 역할을 가진다는 점이 더 분명하게 보입니다.

이 구분은 이후 프로젝트에서 공격 구조를 볼 때도 계속 기준이 됐습니다.

지금 다시 보면

DX9 Cat Quest의 Player 구현은 복잡한 Combat Framework가 아니었습니다.

그래도 이 프로젝트에서 처음으로 아래 흐름을 처음부터 끝까지 직접 연결했습니다.

Player Input
↓
Movement / Direction
↓
Sprite State
↓
Attack Effect
↓
Collision Check
↓
Damage
↓
Feedback

이 경험 이후에는 전투 기능을 볼 때 단순히 Animation이나 Effect가 재생되는지만 보지 않게 됐습니다.

공격은 언제 시작되는가?
 
실제 Hit는 어디서 판정되는가?
 
Damage는 어디에 반영되는가?
 
그 결과를 Player는 어떻게 알 수 있는가?

를 나눠서 보게 됐습니다.

이후 Unreal에서 Montage, AnimNotify, Trace, GameplayEffect 같은 구조를 접했을 때도 구현 방식은 달랐지만, 보이는 공격과 실제 판정, 그리고 결과 반영을 구분해서 본다는 기준은 DX9 Cat Quest에서 먼저 경험한 흐름과 자연스럽게 이어졌습니다.

Runtime

아래 영상에서는 Player 이동과 방향별 Sprite 변화, 기본 공격, Monster 피격, Damage Number가 표시되는 결과를 확인할 수 있습니다.

DirectX9 C++ Cat Quest — YouTube

DX9 Cat Quest에서는 단순한 형태였지만, Player 입력이 실제 Gameplay 결과와 화면 피드백까지 이어지는 과정을 처음 직접 연결해본 경험이었습니다.