DX11-B00 | DX11-SpongeBob-BFBB — DirectX11로 게임 클라이언트의 Runtime을 끝까지 따라가 본 프로젝트

한 줄 결론

기존 DirectX11 Custom Framework의 구조를 Source에서 읽고, 그 위에 Gameplay / Tooling / Persistence / Map Runtime을 확장한 뒤 입력과 데이터가 실제 Runtime State를 바꾸고 최종 화면까지 이어지는 경로를 Source와 실행 결과로 확인한 프로젝트입니다.

Project Snapshot

DX11-SpongeBob-BFBB에서 가장 중요하게 본 것은 기능의 개수가 아니라 Runtime이 실제로 어디에서 시작되고, 어떤 State가 바뀌며, 그 결과가 어디까지 전달되는가였습니다.

입력과 데이터
→ Runtime Object의 State 변경
→ Update / Render / Persistence
→ Player-visible Result

따라서 이 글의 기준은 단순합니다.

Framework를 읽는다
→ State Owner / Writer / Reader를 구분한다
→ 실제 Runtime 결과까지 따라간다
→ Source Exists와 Runtime Verified를 같은 말로 쓰지 않는다

즉 “코드가 존재한다”에서 끝내지 않고, Source에서 읽은 구조가 실제 Client Runtime과 화면 결과로 어떻게 이어지는지 확인하는 것이 프로젝트 정리의 기준이었습니다.

📸 Screenshot 1. 실제 Gameplay가 동작하는 Client Runtime

파일: DX11-B00_Screenshot_01_Runtime_Hero_Playable_Client.png

Client.exe에서 SpongeBob, 3D World, HUD가 함께 보이는 대표 Gameplay 장면입니다.

Source 정리에 머무르지 않고 실제 플레이 가능한 DirectX11 Client까지 이어졌다는 점을 보여주는 B00의 첫 화면입니다.

이 프로젝트는 Unreal보다 먼저 만들었습니다

제 게임개발 학습은 Unreal Engine에서 시작하지 않았습니다.

WinAPI
→ MFC
→ DirectX9
→ DirectX11 3D Client
→ Unreal Engine

그래서 DX11-SpongeBob-BFBB는 Unreal을 공부한 뒤 Engine 내부가 궁금해서 만든 프로젝트가 아닙니다.

오히려 DirectX11에서 먼저 다음 Runtime 흐름을 따라가 본 경험이 있었습니다.

• Object 생성
• Component 연결
• Layer
• Collision
• Rendering
• Resource
• Tooling
• Save / Load

이후 Unreal의 Actor / Component / Gameplay Framework를 볼 때도 **“이 State는 누가 가지고 있고, 실제 Runtime에서는 어디에서 바뀌는가?”**를 먼저 생각하는 기준이 됐습니다.

RiteSeekers에서 Unreal / GAS 구조를 볼 때도 같은 관점이 이어졌습니다.

Engine이 달라도 Runtime을 볼 때 계속 확인한 질문은 비슷했습니다.

🎥 Video 1. Client.exe 실행부터 Gameplay까지 이어지는 Runtime Baseline

파일: DX11-B00_Video_01_Runtime_Baseline_ClientBoot_To_Gameplay.mkv

Client.exe 실행 → Loading → Gameplay 진입 → 이동 → 회전 → 점프 → 착지 → Camera까지 이어지는 기본 Runtime Sequence를 보여줍니다.

B00에서는 이 영상이 **“실제로 돌아가는 프로젝트인가?”**에 대한 가장 직접적인 Evidence입니다.

왜 이 구분이 중요한가?

포트폴리오에서 기술 범위를 넓게 보이게 만드는 것보다, 기존 Framework와 제가 확장한 Client 영역의 경계를 정확히 설명할 수 있는 것이 더 중요하다고 봤습니다.

Framework 전체를 제가 만들었다고 설명하지 않습니다

프로젝트 기반에는 학습 과정에서 사용한 DirectX11 Custom Framework가 있습니다.

따라서 다음 구조 전체를 제가 처음부터 설계했다고 주장하지 않습니다.

• CBase
• CGameObject / CComponent
• Prototype / Clone / Layer
• CGameInstance / Manager 구조
• 기본 Renderer / Target / Shader
• Assimp Model / Animation
• DirectX11 Device / Context / SwapChain
• Engine DLL + Client EXE

제가 가져가는 경험은 이 구조를 Source에서 읽고 실제 Runtime 책임을 이해한 뒤, 그 위에서 Client 기능을 확장하고 연결한 부분입니다.

대표적으로 다음 영역을 다뤘습니다.

이 프로젝트를 **“독자 엔진을 처음부터 만들었다”**고 설명하기보다, **“기존 C++ Framework를 분석하고 실제 Client Runtime까지 연결해 확장했다”**고 설명하는 것이 정확합니다.

외부 Library도 같은 기준으로 구분합니다.

Library 자체를 직접 구현했다고 설명하지 않고, 이 도구들을 이용해 프로젝트 안에서 어떤 Runtime 기능과 Client Flow를 구성했는지를 제 작업 범위로 설명합니다.

📸 Screenshot 2A~2C. Engine DLL과 Client EXE의 경계

Engine / Client Boundary는 한 화면에 억지로 몰아넣지 않고, Solution → Engine DLL → Client EXE의 세 장으로 나눠 읽습니다.

Screenshot 2A — Solution 전체 경계

파일: DX11-B00_Screenshot_02_Source_Engine_Client_Boundary_Raw_01_Solution.png

Framework.sln 안에서 Engine과 Client가 분리되어 있는 전체 Solution 구조를 먼저 보여줍니다.

Framework.sln
→ Engine
→ Client

Screenshot 2B — Engine DLL

파일: DX11-B00_Screenshot_02_Source_Engine_Client_Boundary_Raw_02_Engine_DLL.png

Engine 쪽이 DLL 경계로 구성되어 있다는 점을 보여주는 Source Evidence입니다.

Engine
→ Framework / Runtime 기반 구조
→ DLL

Screenshot 2C — Client EXE

파일: DX11-B00_Screenshot_02_Source_Engine_Client_Boundary_Raw_03_Client_EXE.png

실제 Gameplay / Tooling / Map Runtime이 올라가는 Client 실행 단위를 보여줍니다.

Client
→ Gameplay / Tooling / Map Runtime
→ EXE

세 장을 순서대로 보면 다음 관계를 빠르게 읽을 수 있습니다.

Framework.sln
├─ Engine DLL
└─ Client EXE

프로젝트 기반에는 학습 과정에서 사용한 DirectX11 Custom Framework가 있고, 제가 가져가는 경험은 그 구조를 읽고 실제 Client Runtime 기능을 확장·연결한 부분입니다.

면접에서 한 문장으로

“Engine / Client 경계를 제가 처음부터 새로 설계했다고 주장하는 프로젝트가 아니라, 기존 Framework의 Runtime 구조를 분석한 뒤 Client Gameplay와 Tooling을 실제 실행 단위까지 연결한 프로젝트입니다.”

Class보다 Runtime Flow를 먼저 봤습니다

Class 이름부터 보면 구조가 금방 복잡해집니다.

그래서 프로젝트를 볼 때는 먼저 다음 흐름을 따라갔습니다.

Resource / Prototype 준비
→ Runtime Object 생성
→ Component 연결
→ Layer 편입
→ Update
→ Collision / Interaction
→ State Change
→ Render Group 등록
→ Render Pass
→ Player-visible Result

여기서 각 단계는 같은 의미가 아닙니다.

문제가 생겼을 때도 마지막 결과만 보고 추측하기보다:

Trigger
→ State Change
→ Runtime Result
→ 확인

순서로 보는 기준을 만들었습니다.

이 사고방식이 B01부터 B05까지 이어집니다.

🔡 Source 3A~3B. Loading 단계에서 Prototype을 준비하는 Source Anchor

이 두 장은 B00에서 **Runtime Flow의 첫 단계인 “Prototype 준비”**만 확인하는 Source Anchor입니다.

Prototype → Clone → Layer → Render 전체를 이 화면만으로 설명하지 않고, 실제 Runtime Clone / Layer / Render Handoff는 B01에서 이어서 다룹니다.

SourceCode 3A — Component Prototype 준비

파일: DX11-B00_Screenshot_03_Source_Runtime_Flow_Anchor0_Loader_ComponentPrototype.png

Loading 단계에서 Runtime Object가 나중에 사용할 수 있도록 Component Prototype을 먼저 준비하는 경계를 보여줍니다.

Loading
→ Component Prototype 등록
→ 이후 Runtime Clone / Binding에서 사용

SourceCode 3B — GameObject Prototype 준비

파일: DX11-B00_Screenshot_03_Source_Runtime_Flow_Anchor0_Loader_GameObjectPrototype.png

Gameplay에서 실제 Runtime Instance를 만들기 전에 GameObject Prototype을 등록해 두는 단계를 보여줍니다.

Loading
→ GameObject Prototype 등록
→ 이후 Spawn Request
→ Runtime Clone

두 Screenshot을 함께 보면 B01의 시작점이 더 명확해집니다.

B00
Prototype을 "준비"하는 단계
 
↓ 다음 글
 
B01
준비된 Prototype이 실제 Runtime Clone이 되어
Layer / Update / Render 경로로 들어가는 단계

즉 B00에서는 Class를 많이 나열하기보다 **“실행 전에 무엇을 준비하는가?”**까지만 Source로 확인하고, 실제 Object Lifetime은 B01로 넘깁니다.

B00 이후 글을 읽는 순서

아래부터는 B01~B05의 역할을 B00 관점에서 짧게 연결합니다. 각 글은 별도로 읽어도 이해되도록 독립적으로 구성합니다.

B01 — Prototype에서 실제 Runtime Object가 되기까지

첫 번째로 정리한 것은 Object Lifecycle입니다.

Prototype
→ Clone
→ Initialize / Component Binding
→ Layer
→ Update / Late_Update
→ Render Group
→ Draw

Prototype이 있다는 것과 실제 게임 안에서 Object가 Update되고 화면에 보이는 것은 다른 단계입니다.

B01에서는 Object가 언제 Runtime Instance가 되고, Component와 Layer가 어떤 역할을 하며, 언제 이번 Frame의 Render 대상이 되는지를 따라갑니다.

Object가 보이지 않을 때도 마지막 Shader부터 추측하지 않고:

Prototype 등록?
→ Clone 성공?
→ Component Binding?
→ Layer 삽입?
→ Update / Late_Update?
→ Render Group 등록?
→ Render Pass?

순서로 앞에서부터 확인할 수 있게 정리했습니다.

B02 — Object가 Buffer를 거쳐 최종 화면이 되기까지

Rendering도 “Shader를 썼다”는 기능 목록으로 보지 않았습니다.

대표적인 불투명 World Object는 다음 흐름을 거칩니다.

Late_Update
→ Render Group
→ Geometry Pass
→ GBuffer
→ Lighting
→ LightAcc
→ Deferred Composite
→ Blend / UI / Presentation
→ Present

Shadow용 LightDepth는 같은 GBuffer에 섞는 것이 아니라 별도의 Shadow Pass에서 작성된 뒤 Deferred에서 다시 읽는 경로로 구분합니다.

화면이 이상할 때도 “Shader 문제”로 한 번에 묶기보다 어느 Pass까지 정상이고 어느 Buffer부터 값이 달라지는지를 먼저 봅니다.

Renderer 구조 전체를 제가 처음부터 만든 것은 아니지만, CPU Runtime State가 Render Group과 Buffer를 거쳐 최종 Pixel로 이어지는 경로를 Source와 Runtime Debug View로 연결해서 이해한 경험을 B02에 정리했습니다.

B03 — Tool에서 바꾼 값도 실제 Runtime State로 이어져야 했습니다

Runtime Tooling에서는 ImGui 창 자체보다 State Ownership을 중요하게 봤습니다.

프로젝트에는 크게 두 Authoring 흐름이 있습니다.

Scene Object

Prototype / Layer
→ Picking
→ Runtime Spawn
→ Position / Scale / Rotation
→ ObjectsSaved.txt
→ 기존 Runtime Spawn Path로 재구성

UI Layout

Direct Mouse Edit
→ Existing Runtime UI State
→ UiLayout.txt
→ Existing Runtime UI Update

두 Save / Load는 이름은 비슷하지만 의미가 다릅니다.

Scene Object 쪽은 Pointer를 저장해 되살리는 방식이 아니라 다시 생성할 수 있는 Identity와 Transform State를 저장하고, Load 시 기존 Runtime Spawn Path를 다시 사용합니다.

UI Layout도 별도의 Editor Transform을 만드는 것이 아니라 Runtime UI가 State Owner이고 Editor가 Writer, Render / Hit Test가 Reader인 관계를 유지합니다.

Tool을 게임 밖의 별도 시스템처럼 만들기보다, 실제 Runtime State와 생성 경로를 Tool이 다시 사용하는 구조를 중요하게 봤습니다.

B04 — 화면에 보이는 마지막 증상부터 수정하지 않았습니다

프로젝트에서 가장 강하게 설명할 수 있는 Debug Story 중 하나는 Map Transition입니다.

문제 상황에서는 목적지 Map 자체는 정상적으로 바뀌었지만 다음 Gameplay State가 기대와 다르게 이어지는 경우가 있었습니다.

• Player 위치
• Camera
• Navigation 관계
• Gameplay Resume

처음부터 Camera나 Animation을 수정하지 않고 앞쪽부터 확인했습니다.

MapCard
→ Destination
→ Map-scoped Content
→ Transition Request
→ Spawn Resolution
→ Player Relocation
→ Navigation
→ Camera Restore
→ Gameplay Resume

MapCard, Destination, Map Content까지 정상 범위를 닫은 뒤 Spawn Resolution에서 Request / Resolver Semantic을 다시 확인해야 하는 경계까지 좁혔습니다.

여기서 중요한 것은 특정 문자열 하나보다:

• 어디까지 정상인가?
• 다음 단계에서는 어떤 State를 읽는가?
• 처음 다시 확인해야 할 경계는 어디인가?
• 뒤쪽 증상은 원인인가 Downstream인가?

를 순서대로 나눠 본 과정이었습니다.

Player는 Map마다 새로 Clone하는 구조가 아니라 Persistent Instance를 유지하고, 목적지 기준으로 Relocate한 뒤 Camera와 Gameplay State가 이어집니다.

과거 Debug 과정을 복기한 내용도 Current Source에서 직접 확인된 내용과 구분해서 정리했습니다.

B05 — 여러 시스템을 하나의 Player Flow로 닫았습니다

프로젝트 마지막에는 개별 기능을 따로 보여주기보다 하나의 Player-visible Flow로 연결했습니다.

Production 경로는 BikiniCity의 BusStop에서 시작합니다.

BusStop 접근
→ [E] OPEN MAP
→ Map Selection
→ Destination 선택
→ Bus Presentation
→ Bus Full Exit
→ Canonical Map Transition
→ Destination Restore
→ Gameplay Resume

같은 Destination을 선택하면 불필요한 Travel을 만들지 않습니다.

Same Destination
→ UI Close
→ NO Bus
→ NO Reload
→ NO Transition
→ Gameplay Continue

또 Bus는 Map Transition System 자체가 아닙니다.

Bus는 Player에게 보이는 Presentation을 담당하고, Presentation이 끝난 시점에 기존 Canonical Transition으로 책임을 넘깁니다.

제가 이 Vertical Slice에서 중요하게 본 것은 Bus Animation 자체보다 World Interaction → UI / Input → Destination State → Presentation → Persistent Player → Map Runtime → Restore 사이의 책임을 하나의 플레이 경험으로 연결한 부분입니다.

Gameplay도 화면 변화만 보지 않았습니다

Gameplay 기능도 “적이 공격한다”, “HP가 줄어든다”는 결과만 따로 보지 않았습니다.

대표적으로 Chomper와 Player HP 흐름은:

Enemy Interaction / Collision
→ Player Damage
→ HP State Change
→ UnderWear UI
→ Player-visible Result

로 이어집니다.

화면에서 HP가 5에서 4로 줄어드는 것은 최종 결과이고, Source에서는 그 앞에서 어떤 State가 변경되고 UI가 무엇을 읽는지 따로 확인할 수 있습니다.

이 작은 흐름도 프로젝트 전체에서 사용한 기준과 같습니다.

Trigger
→ State Change
→ Runtime Result

B00에서는 이 Gameplay 예시를 설명만 하고, HP 영상이나 Before / After Screenshot은 굳이 추가하지 않습니다.

세부 Evidence는 해당 글이나 면접 Backup에서 사용하는 편이 B00의 밀도가 더 좋습니다.

Source에서 확인한 구조와 실제 실행 결과는 구분해서 기록했습니다

예전 프로젝트를 다시 정리하면서 특히 조심한 부분입니다.

그래서 과거에 수동으로 확인했던 Runtime 결과와 현재 Source에서 다시 확인한 구조를 구분해서 정리했습니다.

최신 실행으로 다시 확인하지 않은 기능은 Source만 보고 “이번에도 Runtime에서 검증했다”고 쓰지 않습니다.

반대로 Gameplay 영상이나 Screenshot이 있어도 그 화면 하나만으로 내부 Owner나 State Flow 전체를 단정하지 않습니다.

자료 역할은 다음처럼 나눕니다.

공개 블로그에는 꼭 필요한 것만 사용하고, 더 깊은 Debugger / Watch / Git / Build 자료는 질문이 들어왔을 때 꺼낼 수 있도록 따로 보관합니다.

게임 클라이언트 관점에서 이 프로젝트가 보여주는 것

이 프로젝트에서 강조하고 싶은 것은 DirectX11 API 이름 자체가 아닙니다.

Native C++ 환경에서 다음 질문을 실제 Source와 Runtime 결과로 연결해 본 경험입니다.

Object는 언제 살아나는가?
→ B01
 
한 Frame은 어떤 Pass와 Buffer로 조립되는가?
→ B02
 
Tool에서 바꾼 State는 어떻게 저장되고 다시 Runtime으로 돌아오는가?
→ B03
 
Map이 바뀐 뒤 Player / Navigation / Camera는 어떻게 이어지는가?
→ B04
 
여러 Client System은 어디에서 다음 Owner에게 책임을 넘기는가?
→ B05

결국 이 프로젝트에서 반복해서 사용한 기준은 같습니다.

Owner를 찾고 → State가 바뀌는 경계를 찾고 → Runtime 결과까지 확인한다.

이 기준은 Engine이나 Framework가 바뀌어도 게임 클라이언트 문제를 좁힐 때 계속 사용할 수 있는 사고방식이라고 봤습니다.

최종 공개 시리즈

DX11-SpongeBob-BFBB 공개 글은 여섯 편으로 정리했습니다.

B00에서는 이 프로젝트에서 무엇을 했는지 큰 흐름을 보여주고, B01~B05에서는 각 흐름을 실제 Source / Runtime 기준으로 더 깊게 따라갑니다.

B00 Evidence Map — 각 자료가 맡는 질문

B00은 Overview 글이므로 같은 내용을 여러 화면으로 반복하지 않습니다.

실제 파일은 7개지만 역할은 네 가지로 정리됩니다.

Runtime Hero
Runtime Sequence
Engine / Client Boundary
Prototype Preparation Anchor

각 Evidence는 하나의 질문만 담당하게 배치합니다.

Screenshot 1
→ 실제 결과
 
Video 1
→ Runtime Sequence
 
Screenshot 2A~2C
→ Engine / Client Boundary
 
Source 3A~3B
→ Prototype Preparation Anchor

B01~B05에서 다시 깊게 다룰 MapTool, Deferred Buffer, Canonical Restore, Bus Travel의 세부 Evidence는 B00에서 중복 소비하지 않습니다. 각 증거는 해당 글에서 자신의 Claim을 닫도록 배치합니다.

면접에서 30초로 설명한다면

“DX11-SpongeBob-BFBB는 기존 DirectX11 Custom Framework를 기반으로 만든 Native C++ 3D 게임 클라이언트 프로젝트입니다. Framework 전체를 처음부터 만들었다고 설명하기보다, Engine / Client 경계를 읽고 그 위에 Gameplay, Rendering 연동, Runtime Tooling, Persistence, Map Runtime과 Presentation을 확장했습니다. 프로젝트를 정리할 때는 Class 이름보다 State Owner → Writer / Reader → Runtime Result 흐름을 먼저 봤고, B01부터 B05까지 Object Lifetime, Deferred Rendering, Save / Load, Map Restore, Bus Travel을 Source와 실행 결과로 연결해 설명할 수 있도록 구성했습니다.”

30초 답변에서도 핵심은 기능 개수보다 다음 흐름입니다.

기존 Framework 이해
→ Client 기능 확장
→ Runtime State 추적
→ Source / Runtime Evidence 분리
→ Player-visible Result까지 연결

정리

DX11-SpongeBob-BFBB를 통해 보여주고 싶은 것은 스폰지밥 게임을 얼마나 비슷하게 만들었는지가 아닙니다.

제가 이 프로젝트에서 가져간 핵심은:

기존 C++ Framework를 읽고
→ Runtime Object의 Lifetime을 따라가고
→ State Owner와 Writer / Reader를 구분하고
→ Rendering과 Persistence 경계를 이해하고
→ 여러 Client System을 하나의 Flow로 연결하고
→ 문제가 생겼을 때 의미를 다시 확인해야 할 경계까지 내려가 본 경험

입니다.

RiteSeekers가 Unreal / GAS 위에서 Gameplay Architecture를 보여주는 프로젝트라면, DX11-SpongeBob-BFBB는 DirectX11 API를 직접 사용하는 Engine / Client 구조에 더 가까운 Native C++ 환경에서 게임 클라이언트의 Runtime이 실제로 어떻게 이어지는지를 보여주는 프로젝트입니다.