MFC-B04 | MFC-Crazy-Arcade — WinAPI에서 MFC를 거쳐 Editor 기반 제작 흐름을 이해하기까지

이 글에서 확인할 내용

MFC-Crazy-Arcade를 지금 다시 보면, 가장 크게 남은 변화는 맵과 오브젝트를 배치하는 방식을 보는 관점이 달라졌다는 점입니다.

이전 WinAPI-Isaac에서는 타일이나 오브젝트를 코드와 좌표값으로 직접 맞춰가며 배치했습니다.

처음 게임을 만들던 단계에서는 그 방식도 충분했습니다.

우선 화면에 결과를 만드는 것이 더 중요했고, 좌표를 직접 수정하는 방식이 가장 빠르게 이해할 수 있는 방법이기도 했습니다.

하지만 배치를 조금만 수정하려고 해도 코드를 고치고, 다시 실행하고, 화면을 확인하는 과정을 반복해야 했습니다.

MFC-Crazy-Arcade에서는 그 다음 단계로 Tool에서 타일을 선택하고 배치하는 흐름을 경험했습니다.

이 글에서는 WinAPI의 하드코딩 배치에서 MFC의 Tool 기반 배치로 넘어가며 무엇이 달라졌는지, 그리고 이 경험이 이후 DirectX와 Unreal의 Editor / Data / Runtime 흐름을 이해하는 데 어떻게 이어졌는지 정리합니다.

WinAPI에서는 좌표를 직접 맞췄습니다

WinAPI-Isaac에서는 타일이나 오브젝트 위치를 직접 코드로 조정하는 경우가 많았습니다.

원하는 위치에 보이도록 좌표를 바꾸고 실행한 뒤, 결과를 보면서 다시 조정했습니다.

좌표 수정
↓
프로그램 실행
↓
화면 확인
↓
다시 수정

처음에는 크게 문제라고 생각하지 않았습니다.

작은 프로젝트에서는 직접 값을 고치는 방식도 빠르게 결과를 만들 수 있기 때문입니다.

오히려 처음 게임 루프와 Object, Input, Update / Render 흐름을 배우는 단계에서는 코드 안의 값이 화면 결과로 어떻게 이어지는지 직접 확인할 수 있다는 장점도 있었습니다.

문제는 수정이 반복될 때였습니다.

배치를 조금 바꾸는 일도 코드 수정과 실행을 계속 반복해야 했고, 화면을 보면서 바로 조정하기 어려웠습니다.

이때는 아직 "Editor가 왜 필요한가"를 명확하게 이해하지 못했습니다.

그냥 반복 작업이 불편하다는 정도로 느끼고 있었습니다.

MFC에서는 배치 방식이 달라졌습니다

MFC-Crazy-Arcade에서는 Tool 화면에서 타일을 선택하고 맵 위에 배치하는 흐름을 경험했습니다.

제가 맡은 중심 역할도 타일 배치와 맵 구성 흐름이었습니다.

방식은 이전과 달랐습니다.

사용할 타일 선택
↓
맵 위에 배치
↓
배치 결과 확인
↓
필요하면 다시 수정

코드 안의 좌표를 직접 고치는 것이 아니라, 제작 화면에서 결과를 보면서 배치할 수 있다는 점이 가장 크게 달랐습니다.

지금 보면 단순한 변화처럼 보일 수 있습니다.

하지만 당시에는 의미가 컸습니다.

게임에서 맵을 만든다는 것이 단순히 값을 한 번 정해놓는 일이 아니라, 계속 수정하고 확인하는 작업이라는 점을 처음 체감했기 때문입니다.

"하드코딩이 나쁘다"는 의미는 아닙니다

지금 다시 보면 WinAPI에서 좌표를 직접 수정했던 방식과 MFC의 Tool 기반 방식을 단순히 좋고 나쁜 것으로 나누고 싶지는 않습니다.

처음 학습 단계에서는 직접 값을 바꾸면서 화면 결과를 확인하는 방식이 구조를 이해하는 데 도움이 됐습니다.

다만 프로젝트가 커지고 반복 수정이 많아질수록, 같은 작업을 계속 코드 수정으로 처리하는 방식에는 한계가 있었습니다.

제가 느낀 차이는 다음에 가까웠습니다.

하드코딩 배치
→ 값을 직접 바꾸며 구조를 이해하기 좋음
 
Tool 기반 배치
→ 반복 수정과 배치 작업을 더 빠르게 처리하기 좋음

그래서 MFC-Crazy-Arcade에서 배운 것은 "무조건 Tool을 써야 한다"가 아니었습니다.

반복적으로 바뀌는 데이터를 어떤 방식으로 다루는 것이 더 적합한가를 처음 생각하게 된 프로젝트였습니다.

왜 Tool이 필요한지 알게 된 지점

이 프로젝트를 통해 Tool을 단순한 편의 기능으로 보지 않게 됐습니다.

맵 제작에는 반복 작업이 많습니다.

배치
→ 확인
→ 수정
→ 다시 확인

이 과정을 코드 수정만으로 처리하면 작은 변경에도 개발자가 직접 값을 바꾸고 다시 실행해야 합니다.

반대로 Tool이 있으면 화면에서 결과를 보면서 반복적으로 수정할 수 있습니다.

제가 MFC-Crazy-Arcade에서 처음 느낀 Tool의 역할은 거창한 것이 아니었습니다.

반복해서 바뀌는 데이터를 코드에 직접 박아 넣지 않고, 제작 과정에서 수정하기 쉽게 다루는 것이었습니다.

이 경험 이후 Editor나 Tool을 볼 때도 단순히 "편하게 배치하는 화면"이 아니라, 제작 과정에서 반복되는 비용을 줄이는 장치라고 생각하게 됐습니다.

Tool에서 끝나지 않는다는 점도 배웠습니다

MFC-Crazy-Arcade를 다시 보면서 한 가지를 더 알게 됐습니다.

Tool에서 타일을 잘 배치했다고 해서 모든 작업이 끝나는 것은 아니었습니다.

배치 결과가 데이터로 남고, Client에서 다시 읽혀 실제 게임 화면에 사용되어야 했습니다.

Tool에서 배치
↓
Tile / Map Data
↓
Client에서 Load
↓
Runtime 화면

이 흐름을 경험하면서 Editor 화면과 실제 Runtime 화면을 따로 보게 됐습니다.

제작 도구에서 원하는 모습이 나오는 것과, 저장된 데이터를 실제 게임이 정상적으로 사용하는 것은 서로 다른 단계였습니다.

즉 Tool은 단순히 "보여주는 화면"이 아니라, Runtime이 사용할 데이터를 만드는 제작 단계와 연결되어 있었습니다.

이 기준은 이후 프로젝트에서도 계속 이어졌습니다.

MFC에서는 처음으로 Tool과 Data의 관계를 봤습니다

MFC-Crazy-Arcade에서 제가 경험한 흐름을 지금 기준으로 단순화하면 다음과 같습니다.

Tool
→ Tile 선택 / 배치
 
Data
→ TILE / Map Data
 
Client
→ 저장된 데이터 Load
 
Runtime
→ Terrain Render

당시에는 각 Class와 세부 구조를 지금처럼 설명하지 못했습니다.

하지만 중요한 경험은 남았습니다.

화면에서 편집한 결과
↓
Data로 남음
↓
다른 프로그램에서 다시 사용됨

이 경험 이후부터는 Editor에서 값을 바꾸는 것과 실제 Runtime에서 그 값이 사용되는 과정을 하나의 흐름으로 보려고 하게 됐습니다.

다음 DX9에서는 Runtime Gameplay 경험이 넓어졌습니다

MFC-Crazy-Arcade 다음에는 DX9-Cat-Quest를 진행했습니다.

이 프로젝트에서는 캐릭터, 몬스터, 스킬, 상호작용 같은 3D Runtime Gameplay 기능을 더 많이 다뤘습니다.

MFC에서는 Tool과 타일 배치, 첫 팀 프로젝트 경험이 중심이었다면, DX9에서는 게임 플레이 중 실제로 동작하는 기능의 범위가 더 넓어졌습니다.

MFC-Crazy-Arcade
→ Tool / Tile / Team Workflow 경험
 
DX9-Cat-Quest
→ Character / Monster / Skill / Interaction
→ Runtime Gameplay 경험 확장

즉 MFC에서 얻은 경험이 바로 고도화된 Editor 구현으로 이어진 것은 아닙니다.

중간에 DX9 프로젝트를 거치면서 Runtime Gameplay와 팀 프로젝트 경험을 더 넓혔고, 그 다음 DX11에서 다시 Tool과 Save / Load 흐름을 더 구체적으로 다루게 됐습니다.

DX11에서는 Tool 경험이 더 구체적으로 이어졌습니다

DX11-SpongeBob-BFBB에서는 MFC 때보다 Tool의 역할을 더 직접적으로 다루게 됐습니다.

ImGui Editor에서 오브젝트를 선택하고 배치한 뒤, 배치 결과를 ObjectsSaved.txt로 저장하고 다시 불러오는 흐름을 다뤘습니다.

MFC-Crazy-Arcade
→ 타일 선택과 배치
→ Map Data
 
DX11-SpongeBob-BFBB
→ Object 선택과 배치
→ Save / Load
→ Runtime 배치 검증

대상은 2D Tile에서 3D Object로 달라졌습니다.

하지만 공통적으로 다음 흐름이 있었습니다.

편집
↓
저장
↓
다시 불러오기
↓
Runtime에서 확인

MFC 프로젝트에서 처음 느꼈던 "배치와 수정에는 Tool이 필요하다"는 감각이, DX11에서는 실제 Editor와 Save / Load를 더 구체적으로 다루는 경험으로 이어졌습니다.

DX11에서는 Runtime 검증까지 더 중요하게 보게 됐습니다

MFC에서는 Tool에서 배치한 결과가 Client 화면으로 이어지는 흐름을 경험했습니다.

DX11에서는 여기서 한 단계 더 나아가, 저장한 오브젝트가 실제 Runtime에서 원하는 위치와 상태로 복원되는지를 더 의식하게 됐습니다.

Editor에서 정상
 
!=
 
Runtime에서도 정상

이 차이는 직접 Save / Load와 Runtime 배치를 다루면서 더 분명해졌습니다.

그래서 이후 프로젝트에서는 Editor에서 값이 잘 보이는 것만으로 끝내지 않고, 실제 실행 결과까지 확인하는 기준을 갖게 됐습니다.

Unreal Editor를 볼 때도 같은 기준이 남았습니다

Unreal Engine으로 넘어간 뒤에는 훨씬 많은 기능이 Editor 안에 준비되어 있었습니다.

Actor를 배치하고, DataAsset을 연결하고, Animation이나 Gameplay 설정을 조정하는 과정이 자연스럽게 Editor 중심으로 이루어졌습니다.

처음 Unreal을 접했다면 이런 환경을 그냥 당연한 기능으로 받아들였을 수도 있습니다.

하지만 이전 프로젝트에서 직접 좌표를 수정하고, MFC Tool을 거쳐 배치하고, 저장 데이터를 Runtime에서 다시 사용하는 과정을 경험한 뒤였기 때문에 왜 이런 제작 환경이 필요한지 조금 더 자연스럽게 이해할 수 있었습니다.

코드에서 직접 수정
↓
Tool에서 데이터 편집
↓
Save / Load로 Runtime 연결
↓
Editor 중심 제작 Workflow

제가 이 성장 흐름에서 중요하게 보는 것도 바로 이 변화입니다.

Unreal에서는 "누가 이 데이터를 사용하는가"를 더 보게 됐습니다

Unreal Editor에서는 단순히 값을 입력하는 화면만 보는 것으로 끝나지 않았습니다.

예를 들어 DataAsset이나 Gameplay 설정을 사용할 때도 다음을 함께 보려고 했습니다.

Editor에서 어떤 값을 설정하는가?
 
그 데이터는 어디에 저장되는가?
 
Runtime에서 누가 읽는가?
 
어느 시점에 적용되는가?

이 질문은 MFC-Crazy-Arcade에서 Tool과 Client를 따로 보기 시작했던 경험과 연결됩니다.

MFC에서는 Tool과 Client가 서로 다른 프로그램이었고, 같은 Map Data를 기준으로 이어졌습니다.

Unreal에서는 하나의 Engine과 Editor 안에서 더 복잡한 시스템이 연결되지만, Editor에서 설정한 값과 Runtime에서 실제 사용하는 흐름을 구분해서 본다는 기준은 그대로 남았습니다.

기술 단계보다 제작 관점이 바뀐 프로젝트였습니다

MFC-Crazy-Arcade를 포트폴리오에서 크게 보이게 만들고 싶지는 않습니다.

현재 제 대표 기술 프로젝트는 RiteSeekers, DX11-SpongeBob-BFBB, ImitationTrigger입니다.

MFC-Crazy-Arcade의 역할은 다릅니다.

이 프로젝트에서 중요한 것은 복잡한 시스템을 설계했다는 점이 아니라, 게임을 만드는 과정에서 Tool과 Data가 왜 필요한지 처음 이해하기 시작했다는 점입니다.

WinAPI
→ 화면에 결과를 만드는 데 집중
 
MFC
→ 결과를 반복해서 만들고 수정하는 방법을 경험
 
DX9
→ Runtime Gameplay 영역 확장
 
DX11
→ Editor / Save / Load / Runtime 검증으로 확장
 
Unreal
→ Editor / DataAsset / Gameplay Framework 기반 제작

이 흐름 안에서 MFC-Crazy-Arcade는 기술적으로 가장 깊은 프로젝트라기보다, 제작 방식에 대한 시야가 넓어진 중간 단계에 있습니다.

Runtime

당시 프로젝트의 결과는 아래 영상에서 확인할 수 있습니다.

MFC C++ Crazy Arcade

이 영상은 현재의 대표 프로젝트처럼 기술 깊이를 보여주기 위한 자료라기보다, 제가 처음으로 팀 프로젝트 안에서 Tool 기반 제작 흐름을 경험했던 당시 결과를 남긴 기록입니다.

영상에서는 MFC-Crazy-Arcade가 실제 게임 결과물로 동작했던 모습을 확인할 수 있습니다.

성장 흐름에서의 위치

MFC-Crazy-Arcade는 제 포트폴리오에서 최신 기술을 보여주는 대표 프로젝트는 아닙니다.

대신 앞뒤 프로젝트와 함께 보면 역할이 분명합니다.

WinAPI-Isaac
→ Game Loop / Input / Object 기초
→ 코드와 좌표값을 직접 수정하며 배치
 
MFC-Crazy-Arcade
→ 첫 팀 프로젝트
→ Tool에서 타일을 선택하고 배치
→ Tool / Data / Client 연결 경험
 
DX9-Cat-Quest
→ 4인 팀 프로젝트
→ 3D Runtime Gameplay 경험 확장
 
DX11-SpongeBob-BFBB
→ Native C++ / DX11 Client 심화
→ ImGui Editor / Save / Load / Runtime 배치 검증
 
Unreal Projects
→ Unreal Editor
→ DataAsset / Gameplay Framework
→ Runtime State와 Gameplay Architecture 이해

MFC-Crazy-Arcade는 이 흐름에서 하드코딩 중심의 배치 방식에서 Tool 기반 제작 방식으로 넘어간 중간 지점에 있습니다.

동시에 개인 프로젝트 중심의 경험에서 처음 팀 프로젝트로 넘어간 시점이기도 합니다.

지금 다시 보면

당시에는 “맵툴로 타일을 배치했다”는 정도로 생각했습니다.

지금 다시 보면 그 경험 안에는 다음 변화가 있었습니다.

값을 직접 수정한다
 
→ Tool에서 값을 선택하고 편집한다
 
→ 편집 결과를 Data로 남긴다
 
→ Runtime에서 다시 사용한다

그리고 이후 프로젝트를 거치면서 이 흐름은 점점 더 넓어졌습니다.

배치
→ 저장
→ Load
→ Runtime 검증
→ Gameplay Data / State 흐름 확인

그래서 MFC-Crazy-Arcade는 단순히 오래된 초기 프로젝트 하나가 아니라, 지금 제가 Editor와 Runtime Data Flow를 보는 기준이 처음 생기기 시작한 프로젝트로 정리하고 있습니다.

정리

WinAPI-Isaac에서는 타일과 오브젝트를 코드와 좌표값으로 직접 맞추며 배치했습니다.

MFC-Crazy-Arcade에서는 그 다음 단계로 Tool 화면에서 타일을 선택하고 배치하는 흐름을 경험했습니다.

이 과정에서 처음으로 맵 제작은 한 번 값을 정하고 끝나는 일이 아니라, 계속 수정하고 확인해야 하는 작업이라는 점을 체감했습니다.

그리고 반복되는 배치 작업을 코드에 직접 넣는 것보다, Tool을 통해 데이터를 만들고 수정하는 방식이 왜 필요한지도 이해하게 됐습니다.

MFC에서 경험한 Tool → Data → Client 흐름은 이후 DX9의 Runtime Gameplay 경험을 거쳐, DX11의 ImGui Editor와 Save / Load, Unreal의 Editor / DataAsset / Gameplay Framework 기반 제작 흐름을 이해하는 데 자연스럽게 이어졌습니다.

MFC-Crazy-Arcade는 제 성장 과정에서 하드코딩 중심의 제작 방식에서 Tool과 Editor를 활용하는 제작 흐름으로 시야를 넓히기 시작한 프로젝트로 정리하고 있습니다.