DX9-B04 | DX9 Cat Quest — Sprite와 Terrain을 실제 게임 화면에 연결하기

이 글에서 확인할 내용

DX9 Cat Quest에서는 Gameplay 코드뿐 아니라 캐릭터와 Monster가 실제 화면에 보이기 위한 Sprite Resource 정리도 많이 맡았습니다.

처음에는 이미지 작업과 코드 작업을 서로 다른 일처럼 생각했습니다.

하지만 프로젝트를 진행하면서 Resource가 준비되어 있어도 GameObject의 상태와 연결되지 않으면 실제 게임에서는 사용할 수 없다는 것을 직접 경험했습니다.

이 글에서는 상태별 Sprite 정리 → Texture Resource 적용 → GameObject 상태와 연결 → Runtime 출력 흐름과, Texture Index를 기준으로 Tile Terrain을 구성했던 경험을 정리합니다.

Player는 한 장의 Sprite로 끝나지 않았다

Player는 장비 상태에 따라 모습이 달라져야 했습니다.

맨몸
투구
투구 + 갑옷
무기
마법봉
마법사 의상

원본 Resource는 머리, 몸통, 팔, 다리처럼 여러 파츠로 나뉘어 있었습니다.

그래서 포토샵에서 각 파츠의 위치를 맞추고, 장비 조합별로 실제 게임에서 사용할 수 있는 Sprite 형태로 정리했습니다.

단순히 이미지를 준비하는 것만으로는 끝나지 않았습니다.

Player가 현재 어떤 방향을 보고 있는지, 어떤 장비 상태인지에 따라 코드에서 맞는 Texture를 선택하고 실제 Runtime에서 올바른 Sprite가 출력되어야 했습니다.

Player 상태
↓
방향 / 장비 상태 확인
↓
현재 상태에 맞는 Sprite 선택
↓
Runtime Render

이 과정을 반복하면서 Gameplay State와 화면 표현은 따로 떨어진 것이 아니라 같이 움직여야 한다는 점을 많이 느꼈습니다.

Resource를 실제 Runtime에서 사용할 수 있게 연결했다

Sprite 파일이 준비되어 있다고 해서 바로 게임에서 사용할 수 있는 것은 아니었습니다.

실제 실행 과정에서는 Resource가 Texture로 등록되고, GameObject가 현재 상태에 맞는 Texture를 선택해야 했습니다.

Resource 정리
↓
Texture 등록
↓
GameObject 상태와 연결
↓
현재 상태에 맞는 Resource 선택
↓
Runtime 화면 출력

당시에는 지금처럼 Data Asset이나 Editor 기반 설정을 사용한 것은 아니었고, 필요한 Resource와 상태를 직접 연결하는 방식이 많았습니다.

그래도 이 과정을 통해 Resource는 폴더 안에 존재하는 파일이 아니라 Runtime 상태와 연결되어 실제 화면 결과로 사용될 때 의미가 있다는 것을 배웠습니다.

Monster와 Dragon도 필요한 Sprite를 직접 정리했다

Monster 쪽에서도 같은 작업이 필요했습니다.

FireFox, ThunderRam, Dragon처럼 역할이 다른 Monster는 각자 필요한 방향과 동작 표현이 있었고, 그에 맞는 Sprite Resource가 준비되어야 했습니다.

Dragon과 여러 Monster도 원본 파츠를 정리해 실제 게임에서 사용할 수 있는 형태로 맞췄습니다.

Monster Resource 정리
↓
Texture 등록
↓
Monster Object와 연결
↓
이동 / 공격 상태에 맞는 Sprite 출력

Monster가 C++ 코드에서 Player를 추적하고 공격 Object를 생성하더라도, 화면에서 그 상태가 제대로 표현되지 않으면 Gameplay 결과를 확인하기 어렵습니다.

그래서 이 프로젝트에서는 Gameplay 구현과 Resource 적용을 완전히 다른 작업으로 보기보다 하나의 Runtime 결과를 만드는 과정으로 같이 다뤘습니다.

Terrain은 Texture Index를 기준으로 Tile을 구성했다

Terrain은 하나의 큰 배경 이미지를 그대로 띄우는 방식이 아니었습니다.

texture_indices.txt에 저장된 값을 읽고, 각 Tile에서 어떤 Texture를 사용할지 결정한 뒤 CTerrain에서 Render하는 방식이었습니다.

texture_indices.txt
↓
Tile별 Texture Index 확인
↓
Texture 선택
↓
CTerrain Render
↓
Runtime Terrain 구성

복잡한 Terrain System을 만든 것은 아니었지만, 이 과정에서 지형도 단순한 이미지가 아니라 데이터를 읽고 그 데이터에 따라 화면을 구성하는 Runtime Object라는 감각을 얻었습니다.

이 경험은 이후 DX11 프로젝트에서 Terrain Picking, Navigation, Editor Save / Load처럼 더 복잡한 구조를 접할 때도 자연스럽게 이어졌습니다.

반복 작업이 많아질수록 Tool이 필요해졌다

장비 조합이 늘어날수록 Sprite를 직접 맞추는 작업도 계속 늘어났습니다.

예를 들어 새로운 장비 상태가 추가되면 방향별 Sprite를 다시 준비하고, 해당 Resource가 코드에서 올바르게 선택되는지도 확인해야 했습니다.

당시에는 프로젝트를 완성하는 것이 우선이라 필요한 조합을 직접 하나씩 정리했습니다.

하지만 지금 다시 만든다면 먼저 아래 방향을 고민할 것 같습니다.

Sprite 제작 규칙 정의
↓
장비 조합 데이터화
↓
반복 Resource 연결 자동화
↓
수작업 감소

직접 반복 작업을 많이 해봤기 때문에 이후 프로젝트에서는 자연스럽게 이런 질문을 하게 됐습니다.

이 작업을 계속 사람이 직접 해야 하는가?
 
반복되는 값은 Data로 뺄 수 없는가?
 
Editor나 Tool로 줄일 수 없는가?

DX11-SpongeBob-BFBB에서 Runtime Tooling, Object 배치, Save / Load 같은 작업을 더 의식하게 된 데에도 이런 경험이 이어졌습니다.

코드와 Resource를 함께 다룬 경험이 남았다

DX9 Cat Quest를 만들 당시에는 역할을 세밀하게 구분하기보다 “게임이 실제로 실행되고 화면에 보여야 한다”는 목표가 더 컸습니다.

그래서 Player 이동이나 Monster 공격만 구현하고 끝내지 않았습니다.

Gameplay Logic
+
Sprite / Texture Resource
+
Runtime State 연결
+
화면 출력

이 네 가지가 실제 결과로 이어지는 과정까지 직접 확인했습니다.

지금 기준으로 보면 수작업이 많고 더 좋은 구조로 바꿀 수 있는 부분도 분명합니다.

하지만 초기 프로젝트에서 코드와 Resource 사이의 연결을 직접 많이 다뤄본 경험 덕분에 이후에는 새로운 기능을 볼 때도 코드만 동작하는가가 아니라 실제 Resource와 Runtime 결과까지 연결되는가를 같이 보게 됐습니다.

Runtime

아래 영상에서는 장비 상태별 Player Sprite, Monster와 Dragon Resource, Tile 기반 Terrain이 실제 Gameplay 화면에 적용된 결과를 확인할 수 있습니다.

DirectX9 C++ Cat Quest — YouTube

영상에서 보이는 Sprite와 Terrain은 단순히 Resource 폴더에 존재하는 이미지가 아니라, GameObject 상태와 연결되어 Runtime에서 선택되고 출력된 결과입니다.

다음 단계로 이어진 경험

DX9 Cat Quest는 지금 기준으로 보면 작은 2D 팀 프로젝트입니다.

하지만 이 프로젝트에서 Gameplay 코드와 Resource 적용을 함께 맡으면서, 게임은 코드를 작성하는 것만으로 끝나는 것이 아니라 실제 화면에 결과가 나오기까지 연결되어야 한다는 것을 배웠습니다.

DX9 Cat Quest
→ 2D Gameplay / Sprite / Terrain Runtime 연결
 
DX11-SpongeBob-BFBB
→ 3D Client / Rendering / Picking / Navigation / Tooling
 
Unreal
→ Gameplay Framework / Ability / Equipment / Animation / UI

DX9에서는 Resource와 상태를 직접 연결하는 경험을 했고,

DX11에서는 3D Object와 Rendering, Picking, Navigation, Tooling으로 범위가 넓어졌으며,

Unreal에서는 Gameplay Framework와 Ability, Equipment, Animation, UI가 더 큰 구조 안에서 어떻게 연결되는지를 보게 됐습니다.

지금 다시 보면 DX9 Cat Quest의 Resource 작업은 단순한 이미지 편집 경험보다, Data와 Resource가 Runtime State를 거쳐 실제 게임 화면으로 이어지는 과정을 처음 끝까지 경험한 단계였다는 점에서 가장 의미가 있습니다.