Godot 고급 팁 — 성능, 소리, 입력 오류를 재현하고 검증하는 방법

기능을 하나 넣고 나서 게임이 이상해지면, 저는 예전에 바로 코드부터 뒤졌습니다. 텍스처를 줄이고, 적 수를 줄이고, 그림자를 껐습니다. 그러고 나면 좀 나아진 것 같기는 한데 뭐가 효과가 있었는지는 끝내 모릅니다.

고칠 코드보다 같은 문제를 다시 만드는 조건을 먼저 찾아야 합니다. 아래는 제 프로젝트들에서 실제로 데인 자리를 순서로 정리한 것입니다. 글에 적힌 수치는 그때 잰 값이고, 새 기기에서 다시 재어 본 결과는 아닙니다.

1. 느리다는 말을 장면과 시간으로 바꿉니다

"게임이 느립니다"만 가지고 텍스처를 줄이면, 고쳐졌는지 알 길이 없습니다. 먼저 아래를 못 박아 두십시오.

전원 상태가 의외로 큽니다. 충전 중과 배터리 20%일 때가 다른 게임이 됩니다.

평균 FPS만 보면 짧은 멈춤을 놓칩니다. 저는 평균 13ms인데 "뚝뚝 끊긴다"는 제보를 계속 받은 적이 있습니다. 평균은 멀쩡했고 가끔 한 프레임이 길게 튀고 있었습니다. 같은 장면에서 프레임 시간이 튀는 순간과 그때 무슨 일이 있었는지를 같이 적으십시오.

해상도만 낮춰 좋아지는지, 적 수만 줄여 좋아지는지 나눠 보십시오. 한 번에 둘을 바꾸면 어느 쪽이 효과였는지 영영 모릅니다.

2. 검사에서 0이 나왔을 때 대조군을 둡니다

FPS Arena 소리 끊김 사례에서 소리 재생 자리를 늘리고 빈 자리부터 쓰도록 바꿨습니다. 로그에 실제로 끊은 횟수 0과, 예전 방식이었다면 끊겼을 횟수 6을 같이 찍게 했습니다.

가져다 쓸 것은 32라는 자리 수가 아닙니다. 검사가 문제 상황을 실제로 만들어 냈는지를 같이 찍는 방식입니다. 동시에 몇 개가 필요한지는 무기와 적 수와 소리 길이에 따라 달라서 남의 숫자를 베껴도 소용이 없습니다.

그래서 검증표에는 "오류 없음" 옆에 관찰 횟수를 적습니다. 발사가 아예 없어서 소리 오류가 0인 실행과, 발사가 수십 번 있었는데 0인 실행은 전혀 다른 이야기입니다. 앞의 것은 검사가 돌지 않은 것이고, 저는 그걸 통과로 읽은 적이 여러 번 있습니다.

3. 로직 검사와 화면 검사를 나눕니다

입력과 그리기 없이 점수와 충돌 규칙만 보는 검사는 빠르고 몇 번이고 돌릴 수 있습니다. 대신 그 검사는 잘린 버튼도, 깨진 한글도, 안 보이는 효과도 못 봅니다.

블록 퍼즐 개발 기록에 규칙 검사가 그리기 코드를 아예 로드하지 않는다는 한계를 적어 두었습니다. 검사를 늘릴 때는 개수가 아니라 범위를 보십시오. "어떤 파일과 기능이 이 검사에 안 들어오는가"를 같이 적어 두면 초록색 통과 표시를 과신하지 않게 됩니다.

실제로는 네 층으로 나눠 봅니다.

1. 규칙 검사 — 같은 입력에 점수와 상태가 예상대로 바뀌는가
2. 실행 검사 — 내보낸 파일이 기기에서 켜지기는 하는가
3. 화면 검사 — 대표 해상도에서 글자·버튼·효과가 보이는가
4. 체험 검사 — 소리와 터치, 앱을 껐다 돌아오는 동작을 직접 해 본다

2번이 자주 빠집니다. 소스에서는 멀쩡하고 내보낸 파일에서만 부서지는 것들이 따로 있습니다.

4. 방향은 축마다 따로 확인합니다

총소리 방향 사례에서는 좌우와 앞뒤를 따로 봅니다. 앞으로 잘 간다는 사실은 오른쪽 입력이 오른쪽으로 간다는 증명이 아닙니다. 부호가 뒤집혀도 전후진은 멀쩡해서, 정면만 보는 시험에서는 끝까지 안 걸립니다.

정면·오른쪽·뒤·왼쪽에 목표물을 하나씩 세워 두십시오. 카메라가 도는 게임이라면 카메라를 돌린 뒤에 같은 검사를 한 번 더 합니다. 화면 좌표와 월드 좌표가 섞이는 문제는 그때만 드러납니다.

5. 화면 크기보다 사용 가능한 영역을 확인합니다

폰 화면 전체가 게임이 쓸 수 있는 자리는 아닙니다. 시스템 바, 컷아웃, 키보드, 광고가 들어오면 실제로 쓸 수 있는 넓이가 달라집니다.

전체화면과 하단 배너 사례에 적었듯, 배너가 없을 때 맞던 설정이 배너를 붙이는 순간 틀린 설정이 됩니다. 코드는 한 줄도 안 바뀌는데요. 그러니 배너가 없는 상태와 있는 상태를 따로 검사하십시오.

그 글의 해결책을 엔진·플러그인 조합이 다른 데에 그대로 옮기지는 마십시오. 제 쪽에서 통한 것이고, 본인 앱에서 실제 사용 영역과 버튼 자리를 직접 재야 합니다.

6. 배포본과 검사한 파일이 같은지 남깁니다

Windows에서는 해시를 적어 둘 수 있습니다. 아래 파일 이름은 설명용이니 실제 경로로 바꿔 쓰십시오.

Get-FileHash -Algorithm SHA256 .\build\mygame-release.aab

같은 이름으로 다시 빌드하면 내용은 달라집니다. 파일 해시와 버전 코드, 소스 버전을 검사 결과 옆에 같이 남기면 나중에 "그때 검사한 게 이번에 올린 그 파일인가"를 확인할 수 있습니다. 저는 이 확인 때문에 "배포했다"고 잘못 보고할 뻔한 것을 여러 번 막았습니다.

해시가 같다는 것은 파일이 같다는 증거이지 기능이 멀쩡하다는 증거가 아닙니다. 둘을 섞으면 안 됩니다.

바로 가져다 쓸 검증 기록 형식

앱 버전 / 버전 코드:
소스 버전 / 배포 파일 SHA-256:
기기 / OS / 화면 방향:
실행 순서:
기대한 결과:
실제 결과:
문제가 발생한 횟수 / 관찰한 횟수:
수정한 한 가지:
같은 조건으로 다시 확인한 결과:
이번 검사에서 확인하지 못한 것:

마지막 두 줄이 핵심입니다. 수정은 한 번에 하나만 하고, 확인 못 한 것을 적어 두는 것. 저는 이 두 줄을 비워 두고 넘어간 날에 거의 항상 같은 문제로 다시 돌아왔습니다.

이어서 읽을 것

재는 것부터 시작하려면 입문 과정으로 작은 게임을 하나 끝내고, 안드로이드 내보내기로 실기기에 올려 보십시오. 거기서 나오는 문제를 위 양식에 적으면 됩니다. 검사를 믿었다가 데인 기록은 게임은 멀쩡했고 내 테스트가 틀렸다에 세 번 연속으로 적어 두었습니다.