모니터 한구석에 켜두고, 일하다가 가끔 쳐다보고, 생각나면 한 번 눌러서 보스를 때리는 게임. PIP 방치형 게임은 그런 작은 화면의 방치형 게임을 만들겠다는 생각에서 시작했다. 처음부터 지금 모습이었던 것은 아니다. 사람형 캐릭터도 그려 보고, 주식 API를 붙인 콘셉트도 거쳐 보고, 한 캐릭터 키우기와 다섯 캐릭터 교체 방식을 오갔다. 작은 화면이라는 조건 하나는 남았지만 게임의 모습은 여러 차례 바뀌었다.
이 글은 완성작 소개가 아니다. 어떤 선택이 실제 화면에서 통했고 무엇이 실패했는지, Godot로 구현하면서 어떤 검증이 필요했는지를 정리한 개발 중간 기록이다. 아래의 캐릭터·보스·배경 화면과 애니메이션 GIF는 모두 개발 과정의 임시 이미지다. 현재 디자인이나 출시 화면을 대표하지 않으며, 모든 장면이 현재 실행 파일에 동시에 들어 있다는 뜻도 아니다.
사람형 캐릭터를 포기하고 정령으로 돌아오기까지
초기에는 인간형 캐릭터 다섯 명에게 각각 대기·걷기·공격·피격·쓰러짐을 넣으려 했다. 디자인을 유지한 채 모든 프레임을 그리는 일이 생각보다 훨씬 어려웠다. 프레임 수를 늘려도 팔과 무기의 궤적이 어긋나면 동작은 부드러워지지 않았다. 얼굴이나 머리 크기가 조금씩 달라지는 것만으로도 캐릭터가 흔들리는 것처럼 보였다.
한때는 캐릭터 외형을 과감히 단순화하고, 주식 종목 아이콘을 얼굴에 올리는 방향도 시도했다. 하지만 로고 확보와 표시 품질에 게임의 정체성이 지나치게 묶였다. 결국 사람 형태 자체를 내려놓고, 실루엣을 읽기 쉬운 작은 정령으로 돌아왔다. 아래는 그 전환기 때의 다섯 정령을 담은 임시 이미지다.
작은 몸통과 큰 눈은 축소된 화면에서 식별하기 쉬웠다. 동시에 처음에는 정령의 몸보다 무기만 과하게 움직여 보이는 문제가 있었다. 캐릭터를 단순하게 만드는 것과 애니메이션을 대충 만들어도 된다는 것은 전혀 다른 이야기였다. 타격 때는 몸통의 반응, 공격 전에는 예비 동작, 공격 후에는 복귀가 필요했다.
다시 결정한 게임 화면의 크기
콘텐츠를 늘리기 전에 먼저 게임이 차지할 자리를 정해야 했다. 전투 화면을 크게 펼치면 도트가 보기 좋을 수는 있지만, 상시 켜두는 게임으로는 다른 작업을 가렸다. 반대로 너무 작게 줄이면 보스의 체력과 공격 결과를 알아볼 수 없었다. 여러 비율을 비교하면서 전투 화면은 작게 유지하고, 필요할 때만 관리 화면을 펼치는 구조로 정리했다.
아래 전투 장면은 배경·캐릭터·보스·체력 표시가 실제 크기에서 함께 읽히는지 보려고 만든 구도 시안이다. 멋진 원화 한 장보다 중요한 것은 게임 화면 안에서 누가 무엇을 때리는지가 읽히는지였다.
기획상 자동 공격은 계속 진행되고, 사용자의 클릭은 별도 공격 한 번으로 쌓인다. 이 감각을 고민할 때 원작 Tap Titans의 공식 게임 소개를 참고했다. 손으로 누르는 행위가 의미 있어야 하지만, 누르지 않는 동안에도 게임은 움직여야 한다. 다만 환생과 반복을 그대로 가져오는 대신, 이 게임은 환생 없이 성장·장비·스테이지를 오래 쌓아 가는 쪽으로 방향을 잡았다. 레퍼런스는 입력과 성장 루프를 이해하기 위한 것이지, 화면이나 콘텐츠를 복제하기 위한 도안이 아니다.
작은 도트 화면에서 디자인이 무너지는 순간
처음에는 캐릭터, 보스, 배경이 각각 보기 좋아도 한 화면에 놓으면 서로 다른 게임의 자산처럼 보였다. 도트 크기와 외곽선 밀도가 달랐고, 보스는 너무 작거나 정령보다 덜 눈에 띄기도 했다. 그래서 보스는 스테이지의 중심으로 크게 잡고, 정령은 작은 면적에서도 눈과 무기의 방향이 보이게 했다. 아래 연락시트는 보스 디자인을 게임 화면에서 검토하려고 모은 자료다.
분위기 면에서는 SANABI의 공식 Steam 페이지에서 볼 수 있는 선명한 픽셀 실루엣과 빛의 대비가 좋은 참고점이었다. 그렇다고 그 게임의 캐릭터나 장면을 옮겨 오지는 않았다. 여기서 필요한 것은 아주 작은 전투 영역에서도 앞·뒤 레이어가 분리되고, 광원이 게임의 장소감을 돕는 방식이었다. 도트를 그리는 과정에서는 Saint11의 픽셀 아트 자료와 SLYNYRD의 명암 설명도 참고했다.
장비 역시 확대된 시안에서만 예쁘면 소용이 없었다. 실제 게임 크기에 놓인 다섯 무기를 나란히 보며 손잡이, 끝점, 색 대비가 살아 있는지 확인했다.
프레임 수보다 중요한 자세의 연결
애니메이션에서 가장 여러 번 틀린 부분은 “프레임이 모자라니 더 넣자”는 접근이었다. 두 자세 사이에 손 위치가 뒤집혀 있거나 칼끝이 다른 궤적으로 향하면, 중간 프레임을 추가해도 순간이동이 촘촘해질 뿐이다. 검 공격을 다시 만들 때는 먼저 손·팔꿈치·어깨·칼끝의 이동 순서와 발 접지를 봤다. 그다음 예비 동작, 타격, 회복을 완전한 셀 프레임으로 나눴다.
위 GIF 역시 최종 공격 모션이 아닌 임시 애니메이션 이미지다. 정지 화면에서는 그럴듯해 보여도 정상 속도로 재생하면 몸통이 멈춘 채 검만 움직이거나, 복귀 프레임에서 외곽선이 바들거리는 문제가 드러났다. 그래서 프레임 연락시트와 정상 속도 GIF를 항상 같이 보게 됐다. 기술 검사가 “이미지 크기가 맞다”고 말해 줄 수는 있어도, 공격이 자연스러운지는 결국 재생해서 판단해야 한다.
타격 숫자도 같은 문제를 겪었다. 공격 속도가 높아지자 모든 피해를 같은 위치에 같은 간격으로 그리면 보스가 숫자에 묻혔다. MapleStory의 피해 숫자 연출 영상에서 참고한 것은 글꼴이나 스킨이 아니라 숫자가 생기고 겹치며 위로 떠오르는 시간적 흐름이다. 게임에서는 자동 공격과 직접 클릭한 공격의 색을 구분하고, 다단 타격은 ×2 한 줄이 아니라 별도의 숫자로 보여 주는 방향을 택했다.
Godot에서 ‘작은 게임 창’과 관리 화면을 같이 다루기
구현은 Godot로 진행했다. 프로젝트 설정의 논리 뷰포트는 256×188이다. 투명·테두리 없는 상시 표시 창 위에 작은 전투 화면을 두고, 관리가 필요할 때는 더 큰 패널을 연다. 이때 전투 화면 자체를 매번 확대하지 않도록 구분했다. 한 단계의 검수에서 관리 화면 외곽은 520×656, 전투/HUD 영역은 256×188로 유지했다. 이 숫자는 해당 시점의 구현·검수 기준이며, 앞으로의 UI 변경을 막는 영구 규격은 아니다.
Godot의 데스크톱 애플리케이션 안내와 다중 해상도 문서를 보면서 창 설정과 스케일 문제를 분리해 생각했다. 실제로는 최소화 버튼의 위치, 모서리 고정, 창 투명도, 펼친 관리창의 크기처럼 픽셀 아트와 무관해 보이는 요소가 사용감에 더 크게 영향을 주기도 했다.
관리 화면은 기능이 늘 때마다 설명 문장을 붙이다 보니 복잡해졌다. “이 수치는 무엇인가”를 알려 주려다 정작 레벨업 버튼과 수치 비교가 묻힌 것이다. 이후에는 기본 화면에는 현재값·다음값·비용을 남기고, 긴 설명은 필요한 곳의 툴팁으로 옮기는 방향을 잡았다. 영어와 한국어도 화면마다 문구를 따로 박아 넣기보다 데이터로 관리하도록 구조를 바꿨다.
전투 밖에서도 시간이 흐르도록: 광산과 성장
게임은 자동 공격만 켜 두는 구조에서 그치지 않게 했다. 현재 전투에 나가지 않는 정령은 광산에 배치하고, 광산의 성장에는 다른 재화를 쓰도록 나눴다. 모든 업그레이드가 골드 하나에만 묶이면 어느 순간 전투 보상만 기다리는 게임이 되기 쉬웠기 때문이다. 장비의 합성·강화·각인, 무기 교체, 정령 교체도 같은 성장 구조 안에서 연결했다.
광산 화면에서는 숫자만 오르는 것보다 실제로 일하는 모습이 있어야 설득력이 생겼다. 아래 화면과 곡괭이질 GIF도 동작 속도가 생산량 수치와 어떻게 연결되는지 확인하기 위한 임시 이미지다.
성장 수치도 공격력, 공격 속도, 치명타, 추가 타격을 모두 같은 방식으로 다룰 수 없었다. 특히 공격 속도가 높아지면 계산상 타격 수와 화면에서 인지할 수 있는 동작 수가 달라진다. 전투 계산과 시각 표현을 분리하고, 빠른 타격에서는 큰 피격 모션을 매번 재생하지 않도록 조정한 이유다. 수치가 빠르게 증가하는 방치 게임이라도 화면의 가독성까지 무한히 빨라질 수는 없었다.
200개 배경과 아직 끝나지 않은 빛의 검수
배경은 20개 지역 × 지역당 10개 장소, 총 200개 장소로 확장했다. 같은 지역을 여러 챕터에 걸쳐 여행하게 하고, 챕터마다 장소 하나를 쓰는 구성이다. 우선 모든 배경을 게임 화면에 연결하고, 캐릭터와 보스가 놓일 바닥 공간을 확인했다. 아래 이미지는 20개 지역의 대표 장면을 실제 전투 구성으로 모은 연락시트다.
그 뒤에야 “배경이 살아 있는가”라는 질문이 시작됐다. 처음 넣은 파티클은 어디에나 비슷하게 떠다녔다. 구름은 왕복 운동을 하고, 풀은 한 덩어리로 흔들리고, 햇빛은 구름에 가려져도 그대로였다. 실제 풍경을 흉내 내려면 움직임의 원인과 결과가 맞아야 했다. 예를 들면 구름이 해를 가리면 빛줄기와 화면 밝기도 달라져야 하고, 바닷물의 움직임이 바뀌면 반사광의 형태도 따라 변해야 한다.
초원 한 장에서는 풀잎을 독립적으로 흔드는 방식을 여러 번 고쳐 승인받았지만, 그것이 나머지 199개 장면의 움직임까지 승인됐다는 뜻은 아니다. 200개 배경의 제작·연결, 장면별 애니메이션 후보, 실제 플레이에서의 시각 승인은 서로 다른 단계로 관리하고 있다. 빛의 방향, 구름의 형태, 물의 속도처럼 눈으로 봐야 알 수 있는 문제는 아직 장면별로 남아 있다.
자동 테스트와 시각 검수의 간격
화면 크기, 누락된 파일, 프레임 수, 루프의 첫·끝 불일치, 게임 빌드에서의 로딩처럼 자동화할 수 있는 항목은 검사했다. 한 UI 작업에서는 집중 검사 1,456개, 배경 연결 작업에서는 집중 회귀 4,382개가 통과했다. 다만 그 수치는 각 작업 당시의 집중 검사 결과다. 전체 게임이 완성됐다거나, 모든 애니메이션의 시각 품질이 승인됐다는 근거로 쓰지 않는다.
실제로 이 프로젝트에서는 “테스트는 통과했는데 화면은 이상한” 순간이 여러 번 있었다. 무기의 도트가 원본 크기에서 깨져 보이고, 보스 피격이 공격 속도에 비해 지나치게 튀고, 구름과 풀의 움직임이 물리적으로 어색했다. 이런 문제는 숫자 검사 다음에 원본 크기 재생 → 게임 화면 캡처 → 정상 속도 확인 → 수정 범위 제한 순서로 봐야 했다. GIF 하나가 괜찮아 보여도 적용 화면이 다르면 다시 검토해야 한다.
다음에 해결할 일
이 프로젝트를 만들며 가장 크게 바뀐 생각은 “자산을 많이 만들면 게임이 완성된다”는 기대였다. 실제로는 각 자산이 같은 도트 밀도와 광원 규칙 안에서 함께 보이고, 동작이 입력·타격·성장 속도와 맞아야 했다. 앞으로는 모든 장면을 한 번에 손보겠다고 하기보다 대표 장면의 광원·애니메이션을 먼저 확정하고, 같은 규칙이 통하는 장소에만 확장하려 한다. UI와 밸런스도 숫자를 추가하는 것보다 현재 화면에서 읽히는지를 계속 확인할 계획이다.
작은 창으로 시작했지만, 작은 게임이 작은 작업은 아니었다. 그래도 화면 귀퉁이에서 정령이 보스를 때리고, 배경의 빛이 천천히 변하는 장면이 자연스럽게 이어질 때 이 방향을 계속 밀어 볼 이유가 생긴다. 다음 기록은 더 많은 이미지보다, 실제 게임 안에서 움직임과 빛이 얼마나 설득력 있게 보이는지로 남기고 싶다.