Пошук можливих рухів для суб’єкта у 2-х грядовій грі


10

У мене виникають проблеми, присвячені конкретному пошуковому терміну для цього, але як би йти на пошук можливих кроків у 2D покроковій стратегічній грі (тобто FF: Тактика, Емблема вогню, Попередні війни).

введіть тут опис зображення

Я не так сильно думаю про місцевість (або навіть зіткнення) на даний момент. Мені просто цікаво, який алгоритм я можу використати, щоб зрозуміти, що сутність X може переміщувати 5 плиток і атакувати 2 далі плитки.

Я знаю, що можу використати щось на зразок Дікстра, щоб знайти відстань між двома точками. Можлива реалізація - це починатись з місця гравців, а потім відгалужуватися звідти, поки відстань, повернута Dijkstra, не перевищить кількість ходу.

Мені цікаво, чи хтось міг би спрямувати мене в правильному напрямку (тобто назва алгоритмів, техніки, статей тощо).


Я думаю, це називається пошук шляху для пошукового терміна? Якщо ви використовуєте пошук шляху, то у вас можуть бути лічильники для обробки того, що вам потрібно
Exikle

Це по суті частина пошуку шляху (обчислення метаданих для витрат на рух). Ви визначаєте лише місця, які знаходяться в межах, але ви не обов'язково визначаєте маршрут, який ви також проходите.
Маріо

1
Це не в режимі реального часу (RTS), якщо це покрокова à la FFTactics. : p
Алайрік

У 2д ви можете скористатися розрахунком таксабіка / Манхеттена en.wikipedia.org/wiki/Taxicab_geometry
Гербен Джейкобс

Відповіді:


5

Я думаю, що обмежена Dijkstra - це саме те, що ви хочете використовувати. Дійкстра знаходить відстань між двома точками - це відображення відстані до кожного вузла від початкового вузла, а потім "вибір" найкоротшого шляху з цієї карти відстані. Ви хочете зробити практично те ж саме, за винятком того, що ви хочете графік вузла відстані, який він створює як вихід, а не шлях до будь-якої конкретної точки.

Ви хочете внести одну з модифікацій - пропустити обчислення відстані від вузлів, які вже перевищили максимальний діапазон руху. Тоді ви будете мати графік вузлів усіх вузлів, до яких може подорожувати одиниця, а також рамку, тому просто виріжте вузли, які мають відстань, більша за припуск руху.

Віола.

Іншими словами, майже все, що ви описали у своєму запитанні, це те, що вам потрібно зробити. Він також має вигоду від того, що зможе використовувати вихідний сигнал для проходження маршруту, не потребуючи додаткових обчислень.


Я думаю, що Діккстра в цьому випадку надмірний. ОП не потребує шляху до всіх можливих напрямків руху, лише відповідь "так / ні" про те, чи може агент потрапити туди. Він може обчислити шлях пізніше, коли користувач обрав його.
Михайло Кристофік

Вартість використання алгоритму Dijkstra для обчислення шляху після того, як було визначено місце призначення, майже точно така ж, як і його використання наперед (якщо ви не використовуєте евристичний підхід, як A * для просування маршруту). Якщо це зробити не вперед, це просто створює зайву роботу, оскільки Дайкстра відповів би і на питання "куди я можу поїхати", і "як я можу туди потрапити?". Це також дозволяє додавати ускладнення до навколишнього середовища, які змінюють вартість руху, хоча це може бути непотрібним для програми. Далі, підхід добре задокументований, що є корисним для виконавця.
TASagent

1
Переглядаючи відповідь Маріо, він насправді описує алгоритм Дейкстри, за винятком того, що він перевертає відстань, і не згадує, що це Дейкстра.
TASagent

1
Не скажу, що це Dijkstra, тому що ти не дуже шукаєш найкоротший маршрут і не намагаєшся досягти певної точки. Це, по суті, перша частина Алгоритму Дейкстри, хоча це правда. Проблема з вашим формулюванням, використовуючи Dijkstra, може ввести в оману, і я вважаю, що це також бентежить Майкла. Ймовірно, він думав, що ви запропонували використовувати Dijkstra один раз для кожного поля / клітини.
Маріо

1
Закінчивши, використовуючи цей підхід, оскільки він працював добре і його дуже просто розібрати для перешкод.
NRaf

12

Найпростіший (і, мабуть, найбільш наївний) підхід, про який я зараз можу придумати:

  • Почніть зі свого персонажа і позначте всі навколишні поля як steps - 1.
  • Повторіть всі новопозначені поля та ще раз позначте їх навколишні поля як місце, steps - 1де stepsбуло б крокове число поточного поля, якщо тільки нове поле не має вже більшого числа.
  • Повторіть останній крок, поки не закінчитеся.

1
Цей алгоритм має назву: Flood Fill .
Михайло Кристофік

6
@MichaelKristofik: Я б назвав це широтою першого пошуку . Заливна заливка не відстежує відстані.
BlueRaja - Danny Pflughoeft

2

Я думаю, що те, що ти шукає, може бути відстань на Манхеттені . Не допускаючи перешкод, можна сказати, що квадрат доступний просто, якщо:

| toX-fromX | + | toY-fromY | <maxMoveDistance

Цей алгоритм може бути не правильним напрямком руху, якщо у вас пізніше будуть перешкоди; Один з можливих способів її адаптації може включати наявність перешкод, що відкидають «тіні», та повторну оцінку з найближчої точки.

EDIT (Оскільки у мене зараз трохи більше вільного часу):

Під "тінями" я маю на увазі щось подібне, якщо 0 - це досяжний квадрат, C - символ, а X - перешкода:

 012345678
0    0
1   00
2  000X
3 000C000
4  00000
5   000
6    0
 012345678

Оскільки (5, 2) є перешкодою, ви починаєте з припущення, що з x> = 5 AND y <= 2 ви не можете дійти ні до чого. Потім можна перерахувати з іншого квадрата; якщо ви хочете перейти до (5, 1), ви можете обчислити відстань на Манхеттені від (4, 1) і побачити, чи це + відстань від символу до (4, 1) менше відстані руху гравця.

Це досить тривіальний приклад, але якщо у вас є кілька перешкод та / або трохи більший діапазон руху, він повинен мати можливість впоратися зі складністю.

Чи це насправді було б краще, ніж просто заповнення, будь то в області складності програмування чи ефективності виконання, я не маю поняття. Просто здавалося більш цікавим способом вирішення проблеми.


Що ви маєте на увазі під киданням тіней?
NRaf

1
Відредаговано для уточнення.
Tin Man
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.