3인칭에서 탑뷰로 바꾼 결정

PallMark를 Unity로 옮기면서 결정을 번호 붙여 기록했다. 그중 시점에 관한 결정이 가장 많이 번복됐다. 결정 13에서 3인칭을 기본으로 정했고, 결정 16에서 탑뷰로 뒤집었고, 열흘 뒤에는 3인칭에 관한 코드를 전부 지웠다. 기록을 다시 읽으며 그 순서를 정리한다.

처음엔 둘 다 가지려 했다

원본 Godot 판은 아이소메트릭 시점이었다. 직교 카메라, 30도 아래로 기울이고 45도 돌린 전형적인 쿼터뷰다. Unity로 옮긴 다음 날인 8월 29일, 나는 여기에 어깨 뒤 3인칭을 더하기로 했다. 결정 13의 내용은 이랬다.

• 시점 두 가지: 어깨 뒤 액션 3인칭(기본)과 탑뷰(원본 아이소)
• X 키로 전환, 전환할 때 0.25초 보간
• 3인칭은 WASD 이동, 마우스로 바닥을 조준, 락온 없음

같은 날 보정이 붙었다. “어차피 3인칭으로만 사용할 거야.” 그래서 탑뷰 카메라를 다듬던 작업은 중단했다. 다만 한 줄을 남겼다. “탑뷰 코드 제거는 하지 마, 내가 탑뷰도 확인해볼 거야.” 이 한 줄이 다음 날 결정을 가능하게 했다.

3인칭이 부른 일들

3인칭을 기본으로 두자 바로 일이 늘었다. 8월 29일 밤 빌드를 직접 해 보니 캐릭터가 마을의 수레와 울타리를 그대로 통과했다. 위에서 볼 때는 눈에 안 띄던 것이 어깨 뒤에서는 거슬렸다. 원본의 마을 소품은 장식 전용이라 충돌이 없었기 때문에, 시뮬레이션에 걷기 격자를 새로 넣는 결정 15가 생겼다.

카메라 쪽 작업도 쌓였다. 벽에 부딪히면 카메라를 당기는 처리, 천장을 뚫지 않게 하는 처리, 실제 화면에서 캐릭터가 얼마나 가려지는지 세는 계수기까지 만들었다. 8월 30일 새벽 0시 47분 커밋에는 “3인칭 카메라 최소 프레이밍 거리·빈 시야각 탐색·실화면 가림 계수기”가 들어 있다. 카메라 하나를 위해 측정 도구부터 만들고 있었다.

결정 16: 탑뷰로 확정

그리고 8월 30일 아침, 결정 16을 적었다. “주 시점 = 탑뷰(디아블로형) 확정. 3인칭은 X 토글 코드 유지.” 조건이 하나 붙어 있었다. 던전 생성 품질, 즉 방이 줄줄이 이어진 구조를 디아블로처럼 연속된 평면으로 바꾸는 일이 해결돼야 한다는 것이다. 같은 커밋에서 결정 17로 층 생성기를 새로 만들기로 했다.

솔직히 적자면 결정 기록에는 “디아블로형”이라는 말 외에 긴 이유가 없다. 되짚어 보면 전날 밤 쌓인 일들이 이유였다. 3인칭은 카메라와 충돌과 가림을 계속 새로 풀어야 했고, 내가 원래 만들고 싶던 것은 화면 가득 몰려오는 적을 한 번에 쓸어내는 사냥이었다. 그 장면은 위에서 내려다볼 때 가장 잘 보인다.

탑뷰로 정하자 숫자를 다시 맞춰야 했다. 그날 밤 결정 19에서 카메라를 45도로 기울이고 FOV 32로 좁혔다. 이전 값인 55도·거리 9는 머리 바로 위에서 보는 느낌이었고, 디아블로는 45도 안팎이었다. 같은 결정에서 캐릭터 표현 배율을 0.5로 줄였다. 키 1.8유닛인 캐릭터가 3미터 벽의 2.4배로 거인처럼 보였기 때문이다. 이틀 뒤 결정 21에서는 이동을 마우스 좌클릭으로 바꿨다. 탑뷰에서 WASD는 어색했다.

항목	3인칭 시절 (결정 13)	탑뷰 확정 이후
기본 시점	어깨 뒤 원근 카메라	45도 탑뷰, FOV 32
이동	WASD	마우스 좌클릭
스킬 창	K	S
캐릭터 배율	1.0	0.5 (시뮬레이션 좌표는 그대로)
벽 처리	카메라 충돌·당기기	카메라 쪽 벽을 그리지 않음

탑뷰가 불러온 두 번째 결정들

시점을 바꾸면 끝날 줄 알았는데, 탑뷰는 탑뷰대로 새 결정을 요구했다.

9월 5일 밤에는 복층을 포기했다. 조사해 보니 시뮬레이션은 이미 한 층 안에 여러 높이의 바닥을 다룰 수 있었다. 문제는 카메라였다. 위층 바닥이 아래층을 덮으면 플레이어가 자기 캐릭터를 못 본다. 그 방을 살리려면 카메라가 계속 돌아야 하는데, 그럴 거면 시점을 바꿔야 한다. 그래서 “같은 자리에 바닥을 두 겹 두지 않는다, 계단은 허용한다”로 정했다. 못 해서가 아니라 안 하기로 한 것이다.

복층 조사 때 찍은 도서관 방. 위에서 보면 높이가 다른 바닥이 서로를 가린다

9월 6일 밤에는 카메라 쪽 벽을 반투명하게 만드는 대신 아예 그리지 않기로 했다. 반투명 처리는 태그가 붙은 벽만 골라냈는데, 던전 조각을 새 팩으로 바꾸면서 새 벽에 태그가 빠졌고 한 녹화에서 1,860프레임, 전체의 87% 동안 캐릭터가 벽에 가렸다. 카메라 방향이 고정이니 어느 벽이 카메라 쪽인지는 방마다 한 번만 정하면 된다. 매 프레임 계산하던 것이 한 번의 판정으로 바뀌었다.

남겨 두던 것을 지운 날

결정 16 이후에도 3인칭 코드는 남아 있었다. 9월 1일에는 출시 차수를 나눠서 “1차는 탑다운 디아블로 라이크, 2차는 어깨 뒤 3인칭”으로 정했고, 적을 띄워 공중에서 추가타를 넣는 공중 콤보도 2차 몫으로 넘겼다. 그래서 3인칭 카메라, X 토글, 시뮬레이션의 공중 상태 값, 복층 코드는 “2차의 자산”이라는 이름으로 지우지 않고 들고 있었다.

9월 7일 밤, 그걸 전부 지웠다. 2차는 다른 에셋으로 아예 새 프로젝트로 만들 것이고, 이 프로젝트를 참고는 하되 자산을 넘기지 않는다. 그렇다면 1차에 쓰지 않는 것을 들고 있을 이유가 없었다. 공중 띄우기는 시뮬레이션 규칙이라 원본 적합성 벡터가 깨지는데, 기대값을 고치지 않고 C# 사본을 따로 두는 방식으로 처리했다(결정론 포팅 글에서 말한 방식이다). 그날 23시 43분 커밋 메시지는 “탑뷰 단일 시점 적용”이었다.

지금의 시점. 적 무리와 보스의 공격 범위가 한 화면에 들어온다

9월 18일에는 마을과 탑의 카메라 값을 모두 같은 값(9.2, 기울기 45도, FOV 32)으로 고정했다. 부활한 뒤 카메라가 확대되는 문제를 고치다 존마다 다르게 두는 이유가 없다는 걸 알았기 때문이다.

돌아보며

3인칭을 하루 기본으로 둔 비용은 작지 않았다. 마을 걷기 격자, 카메라 충돌, 가림 계수기가 그때 생겼다. 다만 소품 통과를 막는 걷기 격자처럼 시점과 상관없이 남은 것도 있으니 전부 버린 것은 아니다. 가장 도움이 된 것은 “탑뷰 코드는 지우지 마”라는 한 줄이었다. 되돌아갈 길을 남겨 두었기 때문에 다음 날 바로 방향을 틀 수 있었다. 그리고 필요 없다고 판단한 순간에는 남겨 두던 것도 지웠다. 지금 PallMark가 어떤 화면으로 플레이되는지는 PallMark 소개 페이지의 스크린샷에서 볼 수 있다.