DX9-B00 | DX9 Cat Quest — 첫 DirectX9 팀 프로젝트에서 Gameplay 흐름을 익히다
이 글에서 확인할 내용
DX9 Cat Quest는 게임 개발을 배우던 초기에 진행한 DirectX9 / C++ 기반 4인 팀 2D 액션 프로젝트입니다.
프로젝트 기간은 2024.04.16 ~ 2024.05.28입니다.
당시에는 구조를 잘 설명하는 것보다 먼저 게임이 실제로 움직이게 만드는 데 집중했습니다.
Player가 입력에 따라 이동하고, Monster가 따라오거나 공격하고, Skill이 충돌한 뒤 Damage 결과가 화면에 보이도록 하나씩 기능을 붙였습니다.
지금 다시 보면 이 프로젝트에서 가장 많이 배운 것은 특정 기술 하나보다, Player / Monster / Skill / UI / Resource가 Runtime에서 서로 연결되어야 실제 Gameplay가 완성된다는 점이었습니다.
내가 맡았던 부분
제가 주로 맡았거나 깊게 다룬 범위는 Gameplay 구현과 Resource 적용이었습니다.
Gameplay 쪽에서는 다음 흐름을 다뤘습니다.
- Player 이동과 방향 상태 변화
- 기본 공격과 Skill
- Monster 이동과 추적
- Monster 공격 Object 생성
- Dragon 계열 문지기 보스
- Collider 기반 Damage 처리
- HUD / Inventory / Pickup
- NPC 상호작용
- WorldNumber를 통한 결과 피드백
Resource 쪽에서는 캐릭터의 장비 상태에 맞는 Sprite와 Dragon을 포함한 Monster Sprite를 정리해 실제 Runtime에서 사용할 수 있도록 연결했습니다.
처음부터 Framework 전체를 제가 설계한 프로젝트는 아닙니다.
기존 GameObject / Component / Layer 구조 위에서 필요한 Gameplay Object를 만들고 연결하면서, 실제 화면에 결과가 나오기까지의 흐름을 경험한 프로젝트에 가깝습니다.
기능 하나보다 연결 흐름을 많이 배웠다
처음에는 Player, Monster, Skill, UI를 각각 따로 봤습니다.
하지만 게임을 만들다 보니 결국 아래처럼 이어져야 했습니다.
Text
Player 입력
↓
이동 / 공격
↓
Monster 반응
↓
Collision / Damage
↓
Status 변화
↓
HUD / WorldNumber
↓
화면에서 결과 확인예를 들어 공격 Effect가 화면에 보인다고 해서 공격이 끝난 것은 아니었습니다.
실제 Collider 판정이 일어나고, 대상의 Status가 바뀌고, Damage Number가 표시되어야 플레이어가 공격 결과를 알 수 있었습니다.
이런 흐름을 직접 연결해보면서 게임 클라이언트에서는 기능이 존재하는 것보다 그 기능이 다음 상태와 결과로 제대로 이어지는지가 중요하다는 감각을 처음 얻었습니다.
코드와 Resource를 함께 다뤘다
이 프로젝트에서는 코드 구현과 Resource 적용을 완전히 다른 작업으로 보지 않았습니다.
Player가 움직이려면 입력과 Transform 처리가 필요했지만, 방향과 장비 상태에 맞는 Sprite도 필요했습니다.
Monster가 추적하고 공격 Object를 만들어도 실제 화면에 보일 Resource가 준비되어 있지 않으면 Gameplay 결과를 확인할 수 없었습니다.
그래서 당시에는 필요한 기능을 구현한 뒤 끝내기보다, 실제로 실행했을 때 화면에서 결과가 보이는 지점까지 연결하는 것을 중요하게 생각했습니다.
지금 다시 만든다면 반복되는 Sprite 작업이나 장비 조합은 데이터화하거나 Tool로 줄이는 방향을 먼저 고민할 것 같습니다.
이 경험은 이후 프로젝트에서 반복 작업을 줄이는 Pipeline과 Tooling을 더 의식하게 된 계기가 됐습니다.
팀 프로젝트에서 처음 부딪힌 문제
일정이 촉박해지면서 빠르게 기능을 추가하다 보니 공용 Framework에 하드코딩된 부분이 늘어난 적도 있었습니다.
저는 이후 수정이 더 어려워질 수 있다고 생각해 리팩터링이 필요하다는 의견을 냈습니다.
다만 이미 팀원이 많은 시간을 들여 만든 구조를 제 판단만으로 크게 바꾸는 것도 좋은 선택은 아니라고 생각했습니다.
그래서 먼저 어떤 부분이 실제 유지보수에 영향을 주는지와 남은 일정을 함께 확인했습니다.
전체 Framework를 다시 만드는 대신 제출 전에 문제가 될 가능성이 높은 부분만 수정하고, 기존 구현은 최대한 유지하는 방향으로 범위를 줄였습니다.
변경이 필요한 이유와 영향 범위를 설명하고 구현한 팀원의 의견도 들은 뒤, 동의를 받아 진행했습니다.
이 경험 이후에는 협업에서 좋은 구조만 주장하기보다 일정, 위험도, 기존 작업량을 함께 보고 수정 범위를 정하는 것도 중요하다고 생각하게 됐습니다.
Runtime
아래 영상에서는 Player 이동과 방향별 Sprite 변화, 기본 공격, Damage Number, Monster 공격, Dragon, HUD / Inventory / Pickup, NPC 상호작용, Terrain과 Sprite 적용 결과를 확인할 수 있습니다.
DirectX9 C++ Cat Quest — YouTube
영상에서 보이는 결과들은 각각 따로 만든 기능이 아니라, Player / Monster / Skill / UI / Resource가 Runtime에서 연결된 결과입니다.
다음 단계로 이어진 경험
DX9 Cat Quest는 지금 포트폴리오에서 대표 프로젝트로 앞세우는 작업은 아닙니다.
하지만 이 프로젝트를 통해 Player, Monster, Skill, UI, Resource가 하나의 게임 화면으로 이어지는 과정을 처음 넓게 경험했습니다.
Text
WinAPI / MFC
↓
DX9 Cat Quest
↓
DX11-SpongeBob-BFBB
↓
Unreal Gameplay이후 DX11-SpongeBob-BFBB에서는 3D Client 구조와 Rendering, Picking, Navigation, Tooling을 더 깊게 다뤘고, Unreal 프로젝트에서는 Gameplay Framework, Ability, Equipment, Animation, UI 흐름을 더 큰 구조 안에서 보게 됐습니다.
DX9 Cat Quest에서 처음 가졌던 질문도 이후 프로젝트에서 계속 이어졌습니다.
Text
Object는 어디서 생성되는가?
누가 Update하는가?
상태는 어디에 저장되는가?
Collision은 어디서 판정되는가?
결과는 어떻게 화면에 보이는가?
Resource는 어떤 상태와 연결되는가?지금 다시 보면 부족한 부분도 많지만, 게임이 실제로 동작하는 전체 흐름을 팀 프로젝트 안에서 처음 끝까지 연결해본 단계였다는 점에서 가장 의미가 큰 프로젝트입니다.