장애물 주위에 많은 무리를 짓는 적을 효율적으로 길 찾기


20

게임의 적을 위해 길 찾기를 개선하려고 노력하고 있습니다. 현재, 그들은 기본적으로 자신과 플레이어 사이의 각도를 계산하고 그 방향으로 움직여서 플레이어의 정확한 위치를 향해 끊임없이 움직입니다. 또한 적들이 서로 쌓이는 것을 방지하는 플록 킹 알고리즘이 있으므로 서로 클립하는 대신 그룹으로 구성됩니다.

그러나 이제 타일 기반지도를 추가 했으므로 적과 같은 장애물과 벽 주위를 통과 할 수 있어야합니다. 나는 처음에는 "걸을 수없는"타일에 분리 값을 추가하여 플로킹 알고리즘이 벽과 장애물을 멀어 질 물체로 간주하도록했습니다. 내 초기 테스트에서 보행이 불가능한 타일이없는 보이지 않는 "벽"을 치는 적들을 보여 주었기 때문에 아직 실현할 수 없는지 아직 밝혀지지 않았지만, 어떤 이유로 든, 그들은 그것을 때리고 튀어 나오기 시작합니다.

A *를 사용하여 플레이어의 경로를 계산하고 덩어리 알고리즘을 사용하여 덩어리를 방지하기에는 성능이 너무 높을 지 궁금합니다. 원래 내 게임은 웨이브 기반 슈팅 게임 이었지만, 대신 Hotline Miami의 정맥에서 레벨 기반으로하기로 결정했습니다. 따라서 가끔 무리와 함께 적이 적을 것입니다. 강해

이것이 실용적인 솔루션입니까? Slick2D와 함께 Java를 게임 엔진으로 사용하고 있습니다. 아니면이 두 가지 문제를 모두 해결하는 더 나은 솔루션 / 알고리즘이 있습니까?


7
편집에서 설명했듯이 "너무 무겁습니다"는 프로파일 러에게 물어볼 질문입니다. 구현, 대상 하드웨어, 성능 예산 및 게임의 상황에 따라 달라지기 때문입니다. 친밀하지만 인터넷 낯선 사람은하지 않습니다. 플록 길 찾기를 효율적으로 수행하려면이를 도와주는 전략을 제안 할 수 있지만, 자신의 프로파일 링만으로 귀하의 요구에 맞는 효율적인 답변을 얻을 수 있습니다. 특정 성능 문제를 프로파일 링하고 식별하면 해당 문제를 해결하는 방법을 찾도록 도와 줄 수도 있습니다.
DMGregory

1
구현 방법은 성능에 영향을줍니다. 예를 들어, 리더에게 A * 만 실행하고 팔로어를 위해 몰려 듭니다.
Pikalek

게임이 주로이 적과 싸우는 것에 기반을 둔다면, 여러분이 취하는 알고리즘은 게임의 느낌에 큰 영향을 미칩니다. 따라서 당신은 다른 접근 방식을 시도해야합니다. 예를 들어 적들은 플레이어의 레벨과 위치를 항상 완벽하게 알고 있고 완전히 알고있는 AI의 지시에 따라 그를 추적하는 것처럼 느껴 집니까? -다른 접근법은 적들이 플레이어에게 소음을 낸 일반적인 방향으로 뛰게하고 직접 시선으로 만 그를 향해 달려가거나 플레이어가있는 곳에서 다른 적을 외치며 알리는 것입니다.
Falco

@Falco 게임이 더 이상 웨이브 기반이 아니고 레벨 기반이기 때문에 적들이 좀비이기 때문에 ... 나는 당신을 보거나 소음을 내서 당신을 찾을 수 있도록 만드는 것을 고려하고있었습니다. 시끄러운 무기를 사용한다면? 범위 내에서 소리를 내고 범위 내 모든 적들이 방출되는 소리의 위치를 ​​향한 후 그 지역을 무작위로 돌립니다.
Darin Beaudreau

답변:


49

플로우 필드의 사용 사례처럼 들립니다.

이 기술에서는 플레이어 개체에서 바깥쪽으로 단일 경로 찾기 쿼리를 수행하여 도달 한 셀과 마주 치는 각 셀을 표시합니다.

모든 타일 / 가장자리의 순회 비용이 동일한 경우 간단한 너비 우선 검색을 사용할 수 있습니다. 그렇지 않으면 Dijkstra의 알고리즘 (목표 / 휴리스틱이없는 A *와 같은)이 작동합니다.

플로우 필드 : 각 셀을 해당 위치에서 가장 가까운 플레이어 오브젝트를 향한 다음 단계와 연결하는 찾아보기 테이블을 작성합니다.

이제 적들은 각각 자신의 길 찾기 쿼리를 수행하지 않고도 흐름 필드에서 현재 위치를 찾아 가장 가까운 플레이어 객체에 대한 가장 짧은 장애물 회피 경로에서 다음 단계를 찾을 수 있습니다.

이것은 당신이 당신의 무리에있는 적을 더 많이 확장합니다. 단일 적의 경우 전체지도를 검색하므로 A *보다 비쌉니다 (모든 길 찾기 요원에 도달하면 조기에 종료 할 수 있음). 그러나 적을 더 추가할수록 공유 경로 세그먼트를 한 번 이상 계산하지 않고 계산하여 점점 더 많은 경로 찾기 비용을 공유하게됩니다. 또한 BFS / Dijkdtra가 A *보다 간단하고 일반적으로 검사 된 셀당 평가 비용이 저렴하다는 사실에서 우위를 점합니다.

개별 A *가 더 저렴하고 메모가 더 저렴하여 A *까지 손익 분기점이 정확히 발생하는 곳 (과거의 경로 찾기 쿼리에 대한 일부 결과를 재사용하여 다음 경로를 빠르게하는 경우) 저렴, 구현, 에이전트 수 및 맵 크기에 따라 다릅니다. 그러나 좁은 지역에서 여러 방향으로 다가오는 큰 무리의 적을 계획한다면, 하나의 유동장은 반복 A *보다 거의 저렴할 것입니다.

극단적 인 예로서, 20 000 명의 에이전트가 합리적으로 작은 그리드에서 동시에 길 찾기를하는 비디오를 볼 수 있습니다 .


이 기술은 정말 깔끔하게 들립니다. 확인해 볼게요
Darin Beaudreau

15
그것은 * 것을 반복 호출보다 더 많은지도의 검색없이 부분적인 흐름 필드를 구성하는 하이브리드 알고리즘을 사용하는 것이 가능 하고 결코 두 번 같은 위치를 검색합니다. 기본 아이디어는 임의의 적을 선택하고 플레이어에서 적을 향해 A * 검색을 시작하여 정상적인 흐름 장 생성에서와 같이 셀을 마주 칠 때 표시합니다. 검색에서 해당 적을 찾으면 다른 적 (아직 찾지 못한)을 대상으로 선택하고 새로운 휴리스틱에 따라 열린 세트를 다시 정렬 한 후 계속 검색하십시오. 모든 적을 발견하면 멈춰라.
Ilmari Karonen

1
충돌을 피하는 것은 어떻습니까? 그것은 OP에 언급되어 있습니다 (플레이어에게 도달 할 때 클리핑을 피함). 나에게 당신은 무엇이든 움직일 때마다 (또는 다른 논리를 추가 할 때마다) 전체 djikstras를 다시 실행해야 할 것 같습니다
Mars

2
@Mars OP는 무리에 대해 이야기하므로 모든 개인이 같은 속도로 움직일 수 있다고 가정합니다. 충돌이 문제가 될 수있는 유일한 장소는 병목 현상입니다. 병목 현상은 일부 무리가 멈추고 대기해야합니다. 그러나 실제로는 경로 찾기를 변경할 필요가 없습니다. 간단한 대기열은 대부분의 경우 충분히 잘 작동 할 수 있으며, 일부 경로 바이어스 (유사한 비용으로 대체 경로의 의사 임의 선택)가보다 자연스럽게 보이는 무리를 생성합니다. 또한 하나의 특정 단일 타일 갭을 통과하려는 전체 무리를 피하는 흐름 :)
Luaan

3
@Luaan 타일 기반 게임에서는 충돌이 얼마나 자주 발생하는지 놀랄 것입니다. 개인적으로, "queuing"옵션이 최적보다 낮습니다. 또한, 유닛이 서로를 통과 할 수없는 경우, 유닛이 최종 위치에 도달하기 시작하고 다른 많은 경우에 다시 계산해야합니다. 무리는 어렵다;)
화성

8

A *는 성능이 높지 않습니다. 알고리즘을 변경 하여이 상황에 접근합니다. 때때로 A *를 수행하여 다음 단계가 자유롭게 진행되는지 또는 회피가 필요한지 확인하십시오.

예를 들어, A * 목표 위치에서 플레이어 거리를 추적합니다. 임계 값을 초과하는 경우 a *를 다시 계산 한 다음 업데이트 움직임 만 수행하십시오. 대부분의 게임은 경로 찾기를위한 단순화 된 그리드와 레이 캐스트를 사용하는 회피 조향 알고리즘으로 웨이 포인트 간의 이동을 처리하는 로직과 같은 웨이 포인트 조합을 사용합니다. 요원들은 근접한 장애물을 움직여 먼 웨이 포인트로 달려가는 것이 제 생각에 가장 좋은 방법입니다.

여기에서 유한 상태 머신으로 작업하고 Mat Buckland의 "Programming Game AI By Example"책을 읽는 것이 가장 좋습니다. 이 책은 문제에 대한 검증 된 기술을 제공하고 필요한 수학을 자세히 설명합니다. 이 책의 소스 코드는 웹에서 구할 수 있습니다. 이 책은 C ++로되어 있지만 일부 번역 (Java 포함)이 있습니다.


2
자주 업데이트되지 않는 A * 접근 방식을 사용하면 업데이트를 지연시켜 단일 프레임에서 얼마나 많은 적을 재경로 할 수 있는지에 대한 예산을 유지하는 것이 도움이 될 수 있습니다. 이렇게하면 프레임 당 최대 경로 찾기 비용을 유지하고 여러 프레임에서 총 비용을 상각하여 많은 AI 경로를보다 강력하게 처리 할 수 ​​있습니다. 프레임 예산이 초과되었을 때 한 두 프레임에 오래된 경로를 사용하는 AI 또는 가까운 경우 데드 레 코닝으로 넘어 가면 일반적으로 방해가되지 않습니다.
DMGregory

2
아마도 여기에 분명한 내용이 있지만 주어진 프레임에서 일부 경로 만 업데이트 하려는 경우 플레이어까지의 거리를 기준으로 우선 순위 시스템을 원할 수 있습니다. 플레이어 근처의 적들이 경로를 업데이트하는 것이 더 중요 할 수 있으며, 멀리 떨어진 적들이 오래된 경로를 사용하는 것이 좋습니다.
AC

4

그것은 실현 가능할뿐만 아니라 90 년대의 Battle-Zone (1998)의 상용 게임에서 이루어 졌다고 생각합니다.

이 게임에는 무료 비타 일 기반 움직임과 타일 기반 기본 구성의 3D 장치가있었습니다.

이것이 작동하는 것처럼 보입니다.

첫째, A * 또는 이와 유사한 것 (경로를 찾을 수있는 시간에 대한 제한이있는 A *의 변형 일 수 있으므로 실행하는 데 너무 많은 리소스가 필요하지는 않지만 목적지까지가는 경로를 항상 찾지는 않습니다) 타일 ​​기반 장애물에 갇히지 않고 호버 탱크가 목적지로 향하는 길을 찾는 데 사용됩니다.

그런 다음 탱크는 마치 경로의 근처 타일의 중심으로 끌려 가서 장애물, 다른 인근 탱크 등으로 격퇴되는 것처럼 공간이 확보 될 때까지 날아갔습니다.


1
그렇다면 경로를 따라 처리하는 좋은 방법은 무엇입니까? 키드 코너링을 허용하면 적들이 장애물 코너와 충돌하는 것을 막을 수 있어야합니다. 적과 장애물 모두에 대해 무리를 짓고 그러한 상황을 처리하기 위해 A *를 추가해야합니까?
Darin Beaudreau
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.