게임 프로그래밍 길찾기 오류와 내비게이션 메시 복구법
캐릭터가 목적지를 눈앞에 두고 제자리에서 돌거나, 열린 문을 통과하지 못하거나, 계단 아래에서 멈춘다면 이동 속도부터 조정하고 싶어집니다. 하지만 이런 증상의 상당수는 애니메이션이나 조향 문제가 아니라 길찾기 데이터와 실제 게임 공간이 서로 다르게 해석되는 데서 시작합니다.
길찾기 오류는 겉으로 비슷해 보여도 원인이 다양합니다. 내비게이션 메시 생성 조건, 에이전트 크기, 좌표계, A* 비용 계산, 동적 장애물 갱신을 순서대로 분리해서 확인해야 수정한 문제가 다른 장소에서 다시 나타나는 일을 막을 수 있습니다.
목적지 앞에서 멈추는 경로부터 해부하기
도착 판정과 실제 이동 가능 영역의 불일치
클릭한 지점이 바닥처럼 보여도 그 좌표가 항상 내비게이션 메시 위에 있는 것은 아닙니다. 벽과 가까운 지점, 소품 콜라이더 내부, 메시 경계 바깥을 목적지로 전달하면 탐색기는 가장 가까운 유효 지점까지만 경로를 만들 수 있습니다. 그런데 이동 코드는 원래 클릭 좌표까지의 거리로 도착 여부를 판단하므로 캐릭터가 마지막 코너에서 계속 회전하게 됩니다.
먼저 입력 좌표를 그대로 사용하지 말고 일정 반경 안에서 가장 가까운 이동 가능 지점으로 투영해야 합니다. 투영에 실패했을 때는 이전 목적지를 유지하지 말고 요청 자체를 거부하십시오. 성공한 경우에도 최종 경로 점과 투영된 목적지 사이의 거리를 기록하면 데이터 단절인지 단순한 허용 오차 문제인지 빠르게 구분할 수 있습니다.
- 클릭 좌표와 내비게이션 메시 투영 좌표를 서로 다른 색의 점으로 표시합니다.
- 경로의 마지막 점에서 실제 목적지까지 선을 그어 오차를 확인합니다.
- 도착 반경은 에이전트 반지름과 감속 거리를 고려해 정합니다.
- 경로 상태를 완전, 부분, 실패로 나누고 로그에 남깁니다.
- 부분 경로에서는 무한 재탐색 대신 일정 시간 후 요청을 종료합니다.
경로는 정상인데 캐릭터만 흔들리는 경우
경로 선이 매끄러운데 모델만 좌우로 떨린다면 다음 경로 점을 통과한 뒤에도 계속 추적하고 있을 가능성이 큽니다. 점과 정확히 일치해야 인덱스를 넘기는 코드는 프레임마다 위치가 조금씩 달라지는 실제 이동에서 안정적으로 작동하지 않습니다. 현재 속도에 비례한 통과 반경을 두고, 이동 방향과 다음 점을 향한 벡터의 내적까지 확인하면 지나친 점을 확실히 버릴 수 있습니다.
진단 팁: 캐릭터 모델을 숨기고 에이전트의 논리 위치, 목표 속도, 현재 경로 점만 그려 보십시오. 애니메이션의 시각적 흔들림과 경로 추적 코드의 진동을 혼동하지 않게 됩니다.
좁은 문과 계단에서 끊긴 내비게이션 메시 복구
에이전트 반지름과 베이크 해상도 점검
문 폭이 캐릭터보다 넓어 보이는데도 통과하지 못한다면 시각 모델의 폭이 아니라 내비게이션 에이전트 반지름을 확인해야 합니다. 메시를 생성할 때는 벽으로부터 반지름만큼 안전거리를 잘라냅니다. 문 양쪽에서 이 여백을 빼고 남은 폭이 부족하면 통로가 사라지며, 베이크 해상도가 거칠수록 얇은 연결부가 더 쉽게 끊깁니다.
해상도를 무조건 높이는 방법은 생성 시간과 메모리를 함께 늘립니다. 먼저 문제가 발생한 문 주변만 타일 경계, 보행 가능 폴리곤, 제거된 영역으로 나눠 시각화하십시오. 작은 에이전트용 메시와 큰 에이전트용 메시가 필요하다면 하나의 설정을 억지로 공유하기보다 크기별 내비게이션 데이터를 분리하는 편이 예측 가능합니다.
- 문 통과 실패: 에이전트 지름, 문 콜라이더의 실제 폭, 벽 여백을 비교합니다.
- 낮은 턱 단절: 최대 오르기 높이가 계단 한 단보다 작은지 확인합니다.
- 급경사 누락: 경사 제한이 렌더링 메시의 노멀과 맞는지 살펴봅니다.
- 얇은 다리 단절: 셀 크기와 타일 경계에서 연결 폴리곤이 보존되는지 확인합니다.
- 천장이 낮은 구간: 에이전트 높이와 실제 충돌체 간격을 대조합니다.
렌더링 지형과 충돌 지형의 차이 찾기
내비게이션 메시가 어떤 원본 데이터를 사용하는지도 중요합니다. 화면에는 평평한 바닥이 보이지만 베이크에는 숨겨진 충돌체가 포함될 수 있고, 반대로 절벽 난간을 장식 메시로만 만들어 이동 가능 영역에 구멍이 없을 수도 있습니다. 개발용 화면에 베이크 입력 콜라이더만 따로 표시하면 이런 차이가 즉시 드러납니다.
아티스트와 기획자가 이동 가능 구역을 같은 용어로 이해하도록 규칙도 문서화해야 합니다. 역할 간 요구사항 전달이 자주 어긋난다면 게임 기획자의 업무 범위에 관한 설명을 참고해 레벨 설계 조건과 프로그래밍 제약을 구분해 적는 것도 도움이 됩니다. 문 폭, 턱 높이, 경사 한계처럼 검증 가능한 수치가 있어야 새 맵에서도 같은 오류가 반복되지 않습니다.
동적 장애물과 재탐색 폭주를 안정시키기
문이 열렸는데도 길이 생기지 않는 원인
정적인 내비게이션 메시 위에서 문이나 상자를 움직이면 화면의 공간과 탐색 데이터가 즉시 어긋납니다. 문이 열려도 기존 메시가 계속 막힌 상태라면 새 경로를 요청해도 결과는 달라지지 않습니다. 반대로 장애물을 단순히 무시하면 캐릭터가 닫힌 문을 뚫으려 하므로 로컬 회피와 전역 경로 갱신의 책임을 나눠야 합니다.
잠깐 움직이는 캐릭터나 작은 물체는 로컬 회피로 처리하고, 문처럼 통로 연결 상태를 바꾸는 물체는 내비게이션 장애물 또는 타일 갱신 대상으로 다루는 것이 좋습니다. 장애물이 이동하는 매 프레임 타일을 다시 만들면 CPU 사용량이 급증하므로, 이동이 끝났거나 통행 상태가 실제로 바뀐 순간에만 갱신 요청을 큐에 넣으십시오.
- 문이 닫히기 시작하면 해당 통로의 비용을 높이거나 임시 차단 상태로 표시합니다.
- 애니메이션이 끝나면 영향받은 타일만 다시 생성합니다.
- 같은 타일의 중복 갱신 요청은 하나로 합칩니다.
- 현재 경로가 변경 타일을 지나는 에이전트만 재탐색 대상으로 선정합니다.
- 재탐색 시점을 여러 프레임에 분산해 순간적인 프레임 저하를 줄입니다.
모든 에이전트가 동시에 경로를 다시 찾는 현상
플레이어가 문 하나를 열었는데 수백 개 에이전트가 같은 프레임에 A* 탐색을 요청하면 평소에는 보이지 않던 지연이 발생합니다. 실패한 에이전트가 다음 프레임에 다시 요청하는 구조라면 부하는 더 커집니다. 요청마다 짧은 무작위 지연을 주고, 우선순위 큐에서 플레이어 근처나 화면 안의 에이전트를 먼저 처리하면 체감 품질을 유지할 수 있습니다.
경로 탐색에는 명시적인 시간 예산을 두십시오. 프레임당 최대 요청 수만 제한하면 긴 경로 하나가 예산을 모두 소비할 수 있으므로 확장한 노드 수와 실제 처리 시간을 함께 측정하는 편이 안전합니다. 기능별 비용을 계획 단계에서 배분하는 관점은 계획예산 제도의 개념처럼 목표와 자원을 연결하는 방식으로 이해할 수 있습니다.
- 경로 요청 횟수와 성공·부분·실패 비율을 프레임별로 기록합니다.
- 평균값뿐 아니라 가장 느린 탐색 시간과 상위 지연 구간을 확인합니다.
- 목적지가 거의 변하지 않았다면 기존 경로를 재사용합니다.
- 실패 재시도에는 점진적으로 늘어나는 대기 시간을 적용합니다.
- 먼 거리의 비활성 에이전트는 간단한 구역 경로만 계산합니다.
운영 팁: 경로 탐색 성능은 에디터의 빈 장면보다 실제 전투 인원과 문 상태를 재현한 테스트에서 측정해야 합니다. 디버그 선을 그리는 비용도 별도 항목으로 분리하십시오.
맵 규모와 팀 상황에 맞춘 길찾기 선택
작은 맵에서는 관찰 가능한 단순함을 우선하기
방과 복도가 몇 개뿐인 게임이라면 복잡한 계층형 탐색보다 내비게이션 메시와 기본 A* 조합이 관리하기 쉽습니다. 대신 에이전트 반지름, 경사, 턱 높이, 도착 오차를 런타임 화면에서 바로 확인할 수 있게 만드십시오. 간단한 구조에서는 알고리즘을 바꾸는 것보다 실패 상태가 눈에 보이는 진단 도구가 개발 시간을 더 크게 줄입니다.
테스트 장면에는 정상적인 넓은 문만 두지 말고 한계 조건을 의도적으로 넣어야 합니다. 통과 가능한 최소 폭의 문, 허용치와 같은 높이의 턱, 타일 경계를 가로지르는 계단, 열리고 닫히는 통로를 한곳에 배치하십시오. 이런 작은 회귀 테스트 맵은 레벨 전체를 매번 돌아다니지 않고도 설정 변경의 부작용을 확인하게 해 줍니다.
- 소규모 실내 맵은 단일 메시와 부분 타일 갱신부터 적용합니다.
- 플레이어 동료처럼 수가 적은 에이전트는 정밀 경로와 빈번한 장애물 검사를 허용합니다.
- 목적지 투영 실패와 부분 경로를 사용자 행동별로 기록합니다.
- 맵 빌드 과정에 끊긴 영역과 고립된 폴리곤 검사를 추가합니다.
대규모 월드에서는 경로의 정밀도를 단계화하기
넓은 오픈 월드나 대규모 유닛 게임에서는 모든 이동을 같은 정밀도로 계산할 필요가 없습니다. 먼 거리에서는 구역 그래프나 포털 연결로 큰 방향만 정하고, 에이전트가 활성 구역에 들어왔을 때 세부 폴리곤 경로를 구하는 계층형 구성이 효율적입니다. 여러 유닛이 같은 목적지로 이동한다면 개별 A*를 반복하는 대신 흐름장이나 공유 경로 복도를 검토할 수 있습니다.
기술 선택을 소개하고 팀의 실험 결과를 공유할 때는 업계 발표 사례도 좋은 기준점이 됩니다. GDC의 성격과 역할을 이해한 뒤 경로 탐색 발표 자료를 찾아보면 완성된 알고리즘보다 어떤 규모의 문제를 어떤 측정값으로 해결했는지에 집중하기 좋습니다. 다만 유명한 구조라는 이유만으로 도입하지 말고 현재 맵 크기, 동시 에이전트 수, 갱신 빈도를 먼저 재현해야 합니다.
- 대표 맵에서 최장 경로 길이와 동시 요청 수를 측정합니다.
- 정적 지형과 자주 변하는 지형을 타일 또는 구역 단위로 분리합니다.
- 화면 밖 에이전트의 경로 정밀도와 갱신 주기를 낮춥니다.
- 공유 목적지가 많은 전투에서는 경로 복도 재사용률을 확인합니다.
- 알고리즘 변경 전후를 같은 시나리오와 동일한 시간 예산으로 비교합니다.
혼자 작은 액션 게임을 만드는 독자라면 기본 내비게이션 메시를 유지하면서 투영 좌표, 부분 경로, 타일 경계를 보여 주는 디버그 화면부터 갖추는 편을 권합니다. 반면 다수의 NPC가 넓은 월드를 이동하는 팀이라면 계층형 구역 그래프와 요청 스케줄러를 먼저 만들고, 가까운 에이전트에만 정밀 탐색을 배정하는 구성이 더 안정적입니다.

- 다음글게임 수학 쿼터니언으로 회전을 구현해봤더니 달라진 것 26.08.17
등록된 댓글이 없습니다.
