문맥
Old Lucas Arts (ScummVM 시대) 포인트 앤 클릭 그래픽 어드벤처 게임은 사전 계산 된 길 찾기를 사용했습니다. 기술의 대략적인 개요는 다음과 같습니다.
1 단계
각 방의 바닥은 "워크 박스 (walk box)"로 나뉘어 졌는데, 이것은 네비게이션 메쉬의 노드와 거의 같지만 사다리꼴 모양으로 제한되었습니다. 예 :
______ _____ _________ _____
\ A | B | C | D \
\_____| | |_______\
|_____| |
|_________|
2 단계
오프라인 알고리즘 (예 : Dijkstra 또는 A *)은 각 노드 쌍 사이의 최단 경로를 계산하고 경로 의 첫 번째 단계를 2D 매트릭스에 저장하며 사용 된 시작 및 끝 노드에 의해 각 차원에서 색인화됩니다. 예 : 위의 도보 상자 사용 :
___ ___ ___ ___
| A | B | C | D | <- Start Node
___|___|___|___|___|
| A | A | A | B | C | ---
|___|___|___|___|___| |
| B | B | B | B | C | |
|___|___|___|___|___| |-- Next node in shortest path
| C | B | C | C | C | | from Start to End
|___|___|___|___|___| |
| D | B | C | D | D | ---
|___|___|___|___|___|
^
|
End Node
짐작할 수 있듯이, 노드 수가 증가함에 따라 메모리 요구 사항이 빠르게 증가합니다 (N ^ 2). short는 일반적으로 각 항목을 매트릭스에 저장하기에 충분히 크므로 300 개의 노드로 구성된 복잡한 맵을 사용하면 추가 저장이 가능합니다.
300^2 * sizeof(short) = 176 kilobytes3 단계
반면에, 두 노드 사이의 최단 경로를 계산하는 것은 행렬에 대한 일련의 조회만으로 매우 빠르고 사소한 작업이었습니다. 다음과 같은 것 :
// Find shortest path from Start to End
Path = {Start}
Current = Start
WHILE Current != End
Current = LookUp[Current, End]
Path.Add(Current)
ENDWHILE
이 간단한 알고리즘을 적용하여 C에서 A까지의 최단 경로를 찾습니다.
1) Path = { C }, Current = C
2) Path = { C, B }, Current = B
3) Path = { C, B, A }, Current = A, Exit
질문
오늘날의 강력한 하드웨어와 모든 수준 에서이 작업을 수행하는 데 필요한 메모리 요구 사항과 함께이 기술 한 번의 이점은 이제 런타임에 단순히 A *를 수행하여 가중치를 초과한다고 생각합니다.
또한 현재 메모리 조회가 일반 계산보다 느릴 수 있다고 들었습니다. 따라서 사인 및 코사인 조회 테이블을 만드는 것이 더 이상 인기가없는 이유입니다.
그러나 저수준의 하드웨어 효율성에 대한 지식이 아직 충분하지 않다는 점을 인정해야하므로이 기회를 통해 해당 주제에 대해 더 잘 알고있는 사람들의 의견을 묻습니다.
내 엔진에서는 런타임에 그래프에 노드를 동적으로 추가하고 제거하는 기능이 필요했습니다 (이 참조 ). 사전 계산 된 경로로 인해 작업이 더 복잡해 졌으므로 스크랩했습니다 (런타임 A * 솔루션이 이미 완벽하게 실행되고 있음은 말할 것도 없습니다) ). 아직도, 나는 궁금하게 남아 있었다 ...
요컨대, 이 기술은 오늘날 어떤 시나리오에서도 여전히 관련이 있습니까?