MFC-B00 | MFC-Crazy-Arcade — 첫 팀 프로젝트와 Map Tool 경험

이 글에서 확인할 내용

MFC-Crazy-Arcade는 제가 처음으로 경험한 팀 프로젝트입니다.

이전 WinAPI-Isaac에서는 맵이나 오브젝트를 배치할 때 코드 안의 좌표값을 직접 수정하는 방식이 많았습니다. 처음 게임을 만들던 단계에서는 일단 원하는 위치에 결과를 보이게 만드는 것이 더 중요했기 때문에, 이 방식도 충분히 자연스러웠습니다.

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

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

여기서 타일은 맵을 구성하는 작은 바닥 조각이라고 보면 됩니다. 어떤 타일을 사용할지 고르고 원하는 위치에 배치하면, 그 선택이 실제 맵 데이터와 화면 결과로 이어지는 방식이었습니다.

이 글에서는 MFC 자체의 기능을 길게 설명하기보다, 첫 팀 프로젝트에서 제가 맡았던 타일 배치와 맵 구성 역할, 그리고 이 경험을 통해 왜 게임 제작에 Tool과 Editor가 필요한지 처음 체감했던 과정을 정리합니다.

프로젝트에서 맡은 역할

프로젝트 기간은 2024.03.17 ~ 2024.03.28이며, MFC / C++ 기반으로 진행한 팀 프로젝트입니다.

현재 포트폴리오에서는 대표 기술 프로젝트라기보다, WinAPI 이후 DirectX 프로젝트로 넘어가는 과정에서 무엇을 새롭게 경험했는지 보여주는 Growth Journey 프로젝트로 정리하고 있습니다.

팀 프로젝트였기 때문에 전체 기능을 제가 혼자 만든 것은 아닙니다.

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

당시에는 단순히 "맵에 타일을 배치한다" 정도로 생각했지만, 지금 다시 보면 하나의 타일이 화면에 반영되기까지 여러 단계가 연결되어 있었습니다.

Tool에서 타일 선택
↓
마우스 입력으로 배치 위치 지정
↓
Terrain의 TILE 데이터 변경
↓
main view / minimap에서 결과 확인

main view는 실제로 맵을 편집하는 화면이고, minimap은 같은 맵을 작게 축소해서 확인하는 화면입니다.

즉 화면에서 타일 하나를 고르는 것만으로 끝나는 것이 아니라, 선택한 값이 실제 맵 데이터에 들어가고 그 결과가 여러 화면에서 같은 맵으로 보여야 했습니다.

제가 직접 맡은 부분을 정리할 때도 Map Tool 전체를 혼자 설계했다고 보지는 않습니다.

팀 프로젝트 안에서 타일 배치 역할을 맡으며, Tool에서 선택한 값이 실제 데이터와 화면 결과로 이어지는 흐름을 경험한 프로젝트로 정리하고 있습니다.

왜 Tool이 필요하다고 느꼈는가

WinAPI-Isaac에서는 타일이나 오브젝트 위치를 코드 안에서 직접 맞추는 방식이 많았습니다.

처음에는 그 방식도 자연스러웠습니다.

게임을 처음 만들던 단계에서는 "일단 원하는 위치에 보이게 만드는 것"이 더 중요했기 때문입니다.

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

좌표 수정
↓
실행
↓
화면 확인
↓
다시 좌표 수정

맵을 조금씩 조정할수록 같은 과정을 계속 반복해야 했습니다.

예를 들어 오브젝트 하나의 위치를 조금 옮기고 싶어도 좌표값을 바꾸고 프로그램을 다시 실행해야 했습니다. 이런 방식은 작은 프로젝트에서는 가능하지만, 배치가 많아지고 수정 횟수가 늘어날수록 불편함도 함께 커졌습니다.

MFC-Crazy-Arcade에서는 Tool 화면에서 타일을 고르고, 원하는 위치에 배치한 뒤 결과를 바로 확인하는 흐름을 경험했습니다.

이때 처음으로 맵 제작에서 중요한 것은 단순히 데이터를 만드는 것만이 아니라, 그 데이터를 반복해서 수정하고 확인할 수 있는 제작 흐름이라는 점을 느꼈습니다.

지금은 Editor를 사용하는 것이 당연하게 느껴지지만, 당시에는 코드와 좌표값을 직접 수정하던 방식과 Tool 기반 배치의 차이를 직접 경험한 것이 꽤 큰 변화였습니다.

저에게는 이 시점부터 Tool이나 Editor가 단순히 편한 UI가 아니라, 반복되는 제작 작업을 줄이고 결과를 빠르게 확인하기 위한 도구로 보이기 시작했습니다.

Tool과 데이터가 연결되는 흐름

타일 배치에서 가장 기억에 남은 부분은 화면에서 선택한 값이 단순히 UI 안에서 끝나지 않았다는 점입니다.

프로젝트 코드를 다시 따라가 보면, 선택한 Tile ID가 Terrain의 TILE 데이터에 반영되고 화면 결과로 이어지는 구조였습니다.

여기서 Tile ID는 "어떤 타일을 사용할 것인지" 구분하기 위한 값이라고 이해하면 쉽습니다.

타일 선택
↓
입력 처리
↓
TILE 데이터 변경
↓
화면 결과

프로젝트에는 Tool에서 만든 맵 데이터를 저장하고, Client에서 다시 읽어 Terrain으로 사용하는 흐름도 있었습니다.

그래서 맵 편집 과정 전체를 조금 더 넓게 보면 다음과 같이 이어집니다.

Tool에서 타일 배치
↓
Map Data에 결과 저장
↓
Client에서 저장된 데이터 사용
↓
실제 게임 화면에 Terrain 표시

제가 이 프로젝트에서 중요하게 보는 것은 세부 Class 이름 자체가 아닙니다.

Tool에서 편집한 결과가 데이터로 남고, 그 데이터가 실제 게임 화면에서 다시 사용될 수 있다는 흐름을 처음 접했다는 점입니다.

Tool에서 보기 좋은 결과를 만드는 것과, 그 결과가 저장된 뒤 실제 Client에서도 같은 맵으로 사용되는 것은 서로 다른 단계였습니다.

이후 프로젝트에서 Save / Load나 Runtime 배치 기능을 볼 때도 "Editor에서 보이는 결과"와 "Runtime에서 실제로 사용하는 데이터"를 따로 확인하게 된 출발점이었습니다.

첫 팀 프로젝트에서 달라진 점

혼자 프로젝트를 만들 때는 내가 만든 코드만 확인하면 됐습니다.

하지만 팀 프로젝트에서는 제가 맡은 기능도 다른 작업과 맞아야 했습니다.

타일 배치 역시 혼자 끝나는 기능이 아니었습니다.

Tool에서 선택한 값, Terrain 데이터, 저장된 맵, Client에서 보이는 결과가 서로 맞아야 하나의 결과물로 이어졌습니다.

이 과정을 겪으면서 처음으로 이런 생각을 하게 됐습니다.

기능을 만드는 것만큼
그 기능이 전체 결과물에서 어디에 연결되는지 확인하는 것이 중요하다.

당시에는 지금처럼 구조와 책임을 명확하게 설명하지 못했습니다.

그냥 제가 맡은 기능을 만들고, 다른 팀원의 작업과 합쳤을 때 결과가 맞는지 확인하면서 하나씩 배워가는 단계였습니다.

그래도 첫 팀 프로젝트를 진행하면서 역할을 나누고, 제가 맡은 결과가 다른 작업과 맞는지 확인하고, 하나의 프로젝트로 합쳐가는 과정을 처음 경험했습니다.

이 경험 이후에는 기능 하나를 볼 때도 "내 코드가 동작하는가?"에서 끝내기보다, 어떤 데이터와 연결되고 최종 화면에서는 어떻게 확인되는가를 함께 보려고 하게 됐습니다.

Runtime

프로젝트 결과는 아래 영상에 남겨두었습니다.

MFC C++ Crazy Arcade

이 영상은 현재의 대표 프로젝트처럼 기술 깊이를 보여주기 위한 자료라기보다, 당시 팀 프로젝트에서 실제 결과물을 만들었던 과정을 확인할 수 있는 기록으로 보고 있습니다.

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

다음 단계로 이어진 부분

MFC-Crazy-Arcade 이후에는 DirectX9 기반 팀 프로젝트인 DX9-Cat-Quest로 넘어가면서 캐릭터, 몬스터, 스킬, 상호작용처럼 Runtime Gameplay 영역을 더 많이 다루게 됐습니다.

그리고 이후 DX11-SpongeBob-BFBB에서는 ImGui Editor와 오브젝트 Save / Load를 직접 다루면서 Tool의 역할을 더 구체적으로 경험했습니다.

지금 다시 보면 흐름은 자연스럽게 이어집니다.

WinAPI-Isaac
→ 좌표를 직접 수정하며 배치
 
MFC-Crazy-Arcade
→ Tool 기반 타일 배치와 첫 팀 프로젝트 경험
 
DX9-Cat-Quest
→ 3D Runtime Gameplay 경험 확장
 
DX11-SpongeBob-BFBB
→ Editor / Save / Load / Runtime 배치 검증

더 이후 Unreal 프로젝트에서는 Unreal Editor와 DataAsset처럼 이미 잘 갖춰진 제작 환경을 사용하게 됐습니다.

이때도 Editor를 단순히 "편하게 배치하는 화면"으로 보기보다, 데이터를 만들고 수정하고 실제 Runtime 결과까지 이어주는 제작 환경이라는 관점으로 받아들이게 됐습니다.

MFC-Crazy-Arcade는 제 포트폴리오에서 가장 복잡한 기술을 보여주는 프로젝트는 아닙니다.

대신 혼자 코드를 수정하며 배치하던 단계에서 벗어나, 팀 안에서 역할을 맡고 Tool을 통해 데이터를 만들고 수정하는 제작 흐름을 처음 경험한 프로젝트라는 점에서 의미가 있습니다.

정리

MFC-Crazy-Arcade를 통해 처음으로 팀 프로젝트 안에서 타일 배치와 맵 구성 역할을 맡았습니다.

WinAPI-Isaac에서 좌표를 직접 수정하며 배치했던 경험 이후, Tool을 통해 타일을 선택하고 배치하면서 반복 수정과 데이터 관리에 왜 제작 도구가 필요한지 체감했습니다.

또한 제가 맡은 기능만 동작하면 끝나는 것이 아니라, 그 결과가 다른 데이터와 Client 화면까지 어떻게 이어지는지 함께 봐야 한다는 점도 처음 경험했습니다.

이 프로젝트는 이후 DirectX9의 Runtime Gameplay 경험과 DX11의 Editor / Save / Load 작업으로 넘어가기 전, 개인 구현에서 팀 제작과 Tool 기반 작업으로 시야를 넓히기 시작한 단계로 정리하고 있습니다.