타일 편집기와 실제 게임의 충돌이 같아야 하는 이유

배경 그림과 걸어갈 수 있는 영역은 별도의 데이터다

배경에 길이 그려져 있다고 게임이 그곳을 길로 아는 것은 아닙니다. 던전즈 앤 나이츠는 배경 이미지와 그 위의 이동 가능 격자를 구분합니다. 지도에는 이미지 크기, 행과 열, 셀 상태, 시작 위치 같은 정보가 들어 있습니다. 관리 화면에서 막힌 칸과 열린 칸을 정한 결과가 실제 전투에서도 같은 의미를 가져야 합니다. 예쁜 배경이 그대로 보여도 모든 칸을 열린 기본 지도로 바꾸면 게임의 공간 규칙은 이미 달라진 것입니다.

셀은 단순한 통과·차단뿐 아니라 북서·북동·남동·남서 방향이 열린 대각선 상태도 갖습니다. 이는 그림을 작은 타일로 반복해서 그리는 방식과는 구분해야 합니다. 이 사례에서 중요한 것은 충돌과 경로 탐색에 쓰는 논리 격자입니다. MDN의 타일맵 설명에서도 시각적 지도와 충돌·경로 탐색용 논리 격자를 나누어 다룹니다.

저장 지도 로딩 실패를 다른 지도로 숨기지 않는다

실행 시에는 요청한 구간의 저장 지도를 가져오고 HTTP 상태, JSON 형식, 지도 구조와 구간 식별자를 확인합니다. fetch()는 서버가 404를 반환해도 응답 객체를 받을 수 있으므로 통신 함수의 예외만 기다려서는 실패를 놓칩니다. 현재 로더는 response.ok를 검사한 뒤 JSON을 검증하며, 요청한 구간과 다른 지도가 오면 거부합니다.

실패했을 때 임시 기본 지도로 전투를 시작하는 대신 로딩 오류를 표시하고 재시도할 수 있게 합니다. 성공한 지도만 실제 전투 초기 상태를 만드는 함수에 전달합니다. 늦게 끝난 이전 구간 요청도 현재 구간과 로딩 요청 번호를 확인하여 무시합니다. 이러한 경계 검사는 성능 수치를 높이는 기능이 아니라, 편집한 지도와 플레이 중인 지도가 달라지지 않게 하는 정확성 장치입니다.

1. 정상 응답에서 직접 칠한 blocked·대각선 셀과 시작 위치가 그대로 남는지 확인합니다.
2. 404·500, 잘못된 JSON, 구조가 빈 객체, 다른 구간의 지도와 네트워크 실패를 각각 시험합니다.
3. 실패 시 다른 지도로 진행하지 않는지, 재시도 성공 시 저장된 시작 위치로 들어가는지 확인합니다.

화면 픽셀이 아니라 공통 월드 좌표로 충돌을 검사한다

PC와 세로 화면에서 같은 벽의 충돌 위치가 달라지면 표시 배율이 게임 규칙에 섞였을 가능성이 있습니다. 현재 구현은 스테이지의 논리 좌표를 지도 이미지 좌표로 변환하고, 이미지 크기와 행·열로 계산한 셀 크기를 이용해 해당 칸과 칸 내부 위치를 찾습니다. 화면에 그릴 때 쓰는 배율과 지도 충돌의 기준 좌표를 분리하는 구조입니다.

특히 정사각형 셀만 가정하지 않도록 가로·세로 비율이 다른 지도도 검사합니다. 회귀 테스트는 이미지 2640×936, 격자 44열×18행의 사례에서 대각선 네 방향을 각각 구성하고, 막힌 삼각형은 통과하지 않으면서 열린 경계 방향으로 미끄러지는지 확인합니다. 공유 셀 경계에는 어느 쪽이 열린 영역인지 판단하는 규칙도 필요합니다. 좌표를 무조건 반올림하거나 한 셀만 선택하는 최적화가 기존 경계의 의미를 바꾸지 않는지 살펴야 합니다.

편집 도구부터 실제 이동 함수까지 한 번에 이어서 시험한다

검증은 충돌 함수 하나를 호출하는 데서 끝나지 않습니다. 실제 격자 편집 도구로 벽과 문을 칠한 뒤 JSON 직렬화·복원, 지도 validator, 전투 초기화와 stepCombat을 차례로 통과시킵니다. 운영 저장 파일에 시험 벽을 그리는 대신 메모리의 시험 지도에서 동일한 경계를 거치도록 구성했습니다. 이 흐름이면 편집기의 셀 표현과 런타임 해석이 어긋나는 문제도 잡을 수 있습니다.

한 테스트 지도에서는 같은 오른쪽 입력을 2초 적용했을 때 막힌 벽 앞의 x=718에서 멈추고, 벽이 없는 비교 지도에서는 x=1134까지 진행합니다. 벽을 따라 내려가 문에 맞춘 뒤에는 통과해야 합니다. 이 숫자는 해당 시험 지도의 좌표이며 모든 스테이지의 벽 위치가 아닙니다. 키보드와 아날로그 축 입력 모두 같은 규칙을 적용하고, PC·세로·가로 뷰포트 수치에서도 같은 월드 충돌 좌표가 나오는지 확인합니다. 이는 실제 휴대폰 전체에서 실행 성능을 측정했다는 뜻은 아닙니다.

1. 막힌 벽과 열린 비교 지도를 같은 시작 위치·입력·경과 시간으로 실행합니다.
2. 문을 남긴 벽에서는 문을 통한 진행을, 완전히 닫힌 벽에서는 플레이어와 몬스터 모두의 통과 금지를 확인합니다.
3. 같은 cells 배열을 제자리에서 수정한 뒤에도 충돌이 바뀌는지 검사해 오래된 이동 가능 캐시를 발견합니다.
4. 지도 파일을 변경하는 통합 검증이라면 시험용 사본을 사용하고, 원본 저장 데이터가 바뀌지 않았는지 전후 해시를 비교합니다.

최적화가 지켜야 할 계약을 먼저 적는다

이 사례에서 지켜야 할 계약은 저장된 지도를 사용한다는 것, 막힌 영역은 통과하지 않는다는 것, 열린 문과 대각선 경계에서는 이동할 수 있다는 것입니다. 데이터 구조를 캐시하거나 반복 계산을 줄이더라도 이 결과가 같아야 합니다. 계산량이 줄었다는 이유만으로 편집 결과를 무시하면 최적화가 아니라 규칙 변경입니다.

2026년 10월 7일 대조 시 관리자 지도 회귀 10개와 저장 지도 로딩 회귀 4개가 통과했습니다. 테스트가 보장하는 것은 명시된 입력과 지도의 결과입니다. 새 배경, 새 셀 유형 또는 다른 충돌 크기를 추가하면 그에 맞는 사례도 늘려야 합니다. 표시, 저장 데이터와 게임 규칙의 경계를 이렇게 고정해 두면 성능 작업을 하면서도 게임의 원래 형태를 유지하기 쉬워집니다.