Làm cách nào để tạo các tác nhân A * tránh các tác nhân khác?


19

Tôi đang triển khai thuật toán A * đa tác nhân trên bản đồ ô vuông. Các tác nhân chỉ di chuyển trong các trục X và Y. Tôi tránh va chạm giữa chúng bằng cách kiểm tra vị trí của những người khác khi tính toán đường dẫn.

Nó hoạt động tốt, ngoại trừ trường hợp các tác nhân phải vượt qua cùng một ô từ các hướng khác nhau. Trong những tình huống như thế này, một giải pháp tối ưu sẽ là cho một tác nhân chờ đợi người kia vượt qua:

Tình hình mẫu

Ngoài ra, nếu không có hành lang phía bắc, thì việc tìm đường thất bại.

Làm thế nào tôi có thể thực hiện một thuật toán như vậy?


2
Câu trả lời cho Cách xây dựng "AI lưu lượng truy cập"? có liên quan ở đây.
Anko

Một vài bình luận 1) Tôi nghĩ rằng tôi không đơn độc xem xét 100% ok rằng hai kẻ thù có thể bằng cách nào đó trùng nhau khi vượt qua. Chỉ khi bạn chọn một phong cách rất thực tế sẽ là kỳ quặc, nhưng ở phía bên kia, mọi thứ đều ổn với Zelda. 2) bạn có thể xem xét cho phép đường dẫn có độ phân giải bản đồ (* 2, * 2), vì vậy hai kẻ thù có thể đi qua trong một đường dẫn rộng 1 đơn vị. 3) Bạn cũng có thể thiết kế bản đồ của mình để luôn có sẵn một số đường dẫn (có thể là một ràng buộc thú vị, ai biết? :-)).
GameAlchemist

Câu trả lời:


18

Bạn có thể bắt đầu bằng cách để cho quá trình tìm đường thất bại. Khi thất bại, chọn một thời điểm ngẫu nhiên trong tương lai để thử lại tìm đường. Một số giao thức mạng cấp thấp hoạt động theo cách đó , và khá tốt. Những gì bạn phải làm là xây dựng từng đường dẫn một lần và đánh dấu là đã sử dụng tất cả các ô mà một tác nhân sẽ đi qua. Khi các đường dẫn tiếp theo thất bại, bộ đếm thời gian ngẫu nhiên để khởi động lại sẽ giúp trải đều các tìm kiếm đường dẫn mới và phá vỡ các lỗi lặp.

Phần thứ hai của vấn đề của bạn có thể được xử lý bằng cách trả về hai đường dẫn. Đường dẫn đầu tiên là sự trở lại thường xuyên, ngay cả khi nó bị lỗi từ một khối. Con đường thứ hai là một con đường hoàn toàn bỏ qua tất cả các tác nhân. Sau đó, bạn có thể sử dụng kiến ​​thức thu được từ hai con đường này để quyết định chờ đợi hay đi đường dài sẽ tốt hơn. Các heuristic cho quyết định đó sẽ mất một số công việc, nhưng tốt hơn là không thử bất cứ điều gì cả.

Trong trường hợp rất tệ khi các đại lý của bạn bị chặn rất nhiều bởi các hành lang có chiều rộng như thế này, bạn có thể phải thêm các điểm an toàn để đứng ở đó các đại lý có thể nhanh chóng di chuyển đến và chờ đường dẫn thực sự của họ mở ra (vì vậy đại lý không chỉ cần chờ và chặn một hành lang).


19

Thay vì giải quyết vấn đề của bạn, đây là một cách để lấy chanh và làm nước chanh.

Cách đây nhiều năm, một người bạn của tôi đã làm việc với một FPS rất nổi tiếng, có vấn đề chính xác mà bạn mô tả: một khu vực bị hạn chế sẽ có một số nhân vật AI có vị trí mong muốn đặc biệt và thuật toán tìm đường liên tục làm họ bối rối vào nhau. Cụ thể, người chơi sẽ ném một quả lựu đạn vào một căn phòng nhỏ đầy kẻ thù và các nhân vật AI trong khu vực sẽ cố gắng chạy đến lối thoát của họ, nhưng chạy vào nhau, và cuối cùng dừng lại, quay lại, đánh người khác, quay lại, và như vậy. Điều này có vẻ rất không thực tế.

Nỗ lực xây dựng một thuật toán tìm đường tốt hơn có thể chạy thành công với ngân sách tính toán chặt chẽ đã thất bại. Vì vậy, thay vì giải quyết vấn đề tìm đường, bạn tôi đã thêm một kiểm tra rất rẻ vào AI: nếu một AI đã va vào AI khác hai lần trong một khoảng thời gian ngắn, hãy ngừng cố gắng tìm lối thoát và thay vào đó hãy che đậy. Vì vậy, bây giờ những gì xảy ra là, PC thùy lựu đạn và thấy một loạt kẻ thù chạy ra khỏi lối thoát hiểm. Những người va vào nhau, quay lại, và có vẻ như họ nhận ra rằng họ không thể thoát ra được, vì vậy họ cúi đầu và che đầu ngay trước khi họ nổ tung. Điều này là cả thực tế và rất hài lòng cho người chơi.

Có cách nào tương tự để bạn có thể biến nhược điểm của thuật toán tạo va chạm và biến nó thành lợi thế không?


1
+1 Tôi thích điều này, nó lật đổ và hoàn toàn hoạt động =)
Patrick Hughes

3

Tôi thường thấy tốt nhất là tăng đường dẫn A * bằng các hình thức tìm đường khác cho các kịch bản cục bộ khác; tránh đơn vị thường là một trong số họ, đặc biệt là trong một thế giới nơi có nhiều tác nhân di chuyển đồng thời và do đó tạo ra các trình chặn động).

Nói chung, một kỹ thuật cạnh sau có thể làm việc cho điều này. Khi bạn đang đi theo một con đường, một trình chặn không phải là một phần của tính toán đường dẫn ban đầu, về cơ bản, bạn chọn một hướng (theo chiều kim đồng hồ hoặc ngược chiều kim đồng hồ) và cố gắng vượt qua trình chặn bằng cách di chuyển xung quanh theo hướng đó. Nếu bạn không thể, bạn đợi trình chặn tự giải quyết (mặc dù điều này có thể dẫn đến bế tắc).

Bạn cũng có thể thực hiện khả năng cho các đơn vị đường dẫn hợp tác; nghĩa là, một đơn vị có thể yêu cầu một đơn vị khác di chuyển sang một bên một chút để nó có thể "vượt qua" đơn vị chặn. Tuy nhiên, điều này không hoạt động tốt trong trò chơi xếp gạch, nơi bạn bị hạn chế chuyển động dựa trên gạch, bởi vì bạn vẫn có thể bế tắc trong hành lang một chiều rộng như ví dụ của bạn. Trong trường hợp đó, bạn có thể cung cấp cho các đơn vị để yêu cầu nhau "chuyển địa điểm", điều này dẫn đến việc giải quyết hầu hết thời gian. Đôi khi, điều này dẫn đến các đơn vị nhảy vọt, mặc dù.

"Tránh đơn vị" là một chủ đề khá phổ biến khi thảo luận về tìm đường trong các trò chơi, có rất nhiều lượt truy cập cho nó. Cụ thể, bạn có thể muốn kiểm tra câu hỏi này trên đường dẫn "trường dòng chảy" được sử dụng trong Chỉ huy tối cao 2. Các RTS thường gặp vấn đề này rất nhiều và giải quyết nó theo đủ mọi cách thú vị.


Điều này chính xác - dường như có một nhận thức rất phổ biến rằng tìm đường có nghĩa là A *, và đó không phải là như vậy.
Steven Stadnicki

2

Nếu bạn có hệ thống chuyển động dựa trên lượt / đánh dấu lần lượt, bạn có thể tạo một biểu đồ 3D trong đó mỗi lần chuyển sẽ chuyển tác nhân vào hình dạng của bản đồ trong tương lai. Sau đó, mỗi đại lý tuyên bố gạch sẽ có trong thời điểm đó trong tương lai và đánh dấu chúng là không thể truy cập. Mỗi tác nhân sau đó có thêm một tùy chọn "aiting" cho dấu kiểm tiếp theo như là cách thứ 3 để chuyển qua biểu đồ. Điều này sẽ khó hơn trên hệ thống của bạn nhưng sẽ cho bạn kết quả tốt hơn là chờ đợi ngẫu nhiên. Thậm chí tốt hơn nếu bạn cho phép 2 đại lý giao tiếp với bt khi một trong số họ gửi tin nhắn "Tôi muốn vượt qua bạn" nếu đó là con đường ngắn nhất đi qua đại lý đó,


đây là một bài báo nói về khối thời gian đó: www0.cs.ucl.ac.uk/staff/D.Silver/web/Appluggest_files/ và đây là một triển khai: allecting-i.com/ASIPath
Rakka Rage

0

Khi sử dụng một thuật toán như A *, bạn có vĩ độ lớn nhất khi làm việc với heuristic chi phí.

Trong trường hợp cụ thể này, bạn có thể điều chỉnh heuristic để tăng chi phí cho các chuyển động có một tác nhân gần với một tác nhân khác, vấn đề là bạn có thể sẽ kết thúc bằng cả hai cố gắng đi đường trên và cuối cùng bạn có thể dao động với chúng qua lại giữa các đường dẫn khi chúng đóng vào nhau tùy thuộc vào thời gian chính xác.

Một khả năng khác là theo dõi các tuyến đường dự định của các đại lý và điều chỉnh chi phí đi lên dọc theo các đường dẫn dự định của các đại lý khác. Điều này cho phép các tác nhân phối hợp với nhau ở một mức độ hạn chế. Vấn đề chính ở đây là nếu tất cả các tuyến đường bị chặn tìm kiếm đường dẫn có thể tiếp tục thất bại cho bất kỳ tác nhân nào di chuyển cuối cùng.

Trong trường hợp chỉ có một con đường, thì việc tìm đường sẽ không thành công hoặc chúng sẽ tiến lên nhau cho đến khi chúng bế tắc.

Nếu cả hai đều không đủ tốt thì bạn cần bắt đầu theo dõi thời gian khi tính toán chi phí của mình. Chi phí cho đại lý thứ hai phải là khoảng thời gian để đại lý thứ nhất rõ ràng cộng với chi phí truyền tải thông thường, theo cách đó, đại lý của bạn sẽ có thể quyết định chính xác khi nào nên chờ so với đi theo con đường khác.

Việc sắp xếp thời gian phù hợp có thể là nỗ lực nhiều hơn đáng kể, vì vậy hầu hết mọi người giải quyết việc điều chỉnh bố cục cấp độ và giá trị chi phí cho đến khi mọi thứ đủ tốt.


0

Thông thường tôi sẽ khuyến khích bạn sử dụng các hành vi lái để giải quyết các vấn đề như thế này trong quá trình theo dõi đường dẫn. Và bạn vẫn có thể mất nhiều thời gian để có được cảm hứng cho hành vi nhóm. Nhưng unfortunatley nó không thực sự được áp dụng trực tiếp cho chuyển động dựa trên gạch đơn giản.

Vì bạn đã có một tránh va chạm làm việc trong hầu hết các tình huống, hãy tập trung vào tình huống cụ thể này. Tôi đoán bạn đang thực hiện lại việc tìm đường mỗi khi một đặc vụ muốn di chuyển, nếu không tôi không thể thấy cách họ phản ứng với những người khác di chuyển trong quá trình họ di chuyển. Thứ hai, tôi đoán những người đại diện thân thiện với nhau.

Bạn đề nghị một đại lý chờ đợi một đại lý khác và tôi sẽ khuyên bạn nên làm chính xác điều đó. Cung cấp cho các đặc vụ một cách để truy cập vào các đường dẫn của những người khác, tìm kiếm ô đầu tiên của đường dẫn của riêng bạn không phải là một phần của đường dẫn khác và đi đến đó. Các vấn đề với kỹ thuật này có thể là:

  1. Làm thế nào để bạn quyết định nếu có một cách khác có thể chấp nhận xung quanh các đại lý khác hay không? Bạn không muốn đợi người đại diện khác nếu có đủ không gian để đi xung quanh anh ta. Lỗi tìm đường khi xem xét tác nhân khác là một dấu hiệu rõ ràng về tình huống bạn muốn khắc phục, nhưng trong ví dụ bạn đưa ra sẽ không có lỗi tìm đường. Nhưng bạn có thể - với một chút tính toán - quyết định xem con đường thay thế A * cho bạn chỉ đi xung quanh các tác nhân khác trong một vòng tròn nhỏ hay sử dụng một con đường hoàn toàn khác như hành lang phía bắc.

  2. Tôi không biết một đại lý có thể đi được bao xa trong một vòng / hoạt động, nhưng nếu điều đó không đủ xa hoặc nếu tất cả các đại lý di chuyển song song, cả hai đại lý sẽ quyết định chờ ở đầu kia của con đường. Điều này có thể được khắc phục bằng cách báo hiệu cho các tác nhân khác rằng bạn giải phóng con đường của anh ta.


0

Một trong những giải pháp khả thi là vô hiệu hóa va chạm đơn vị ở những điểm chật hẹp như vậy.

Ví dụ: trong trò chơi Starcraft, các công nhân (SCV, Probes, Drone) không va chạm với nhau khi khai thác tinh thể.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.