* Алгоритм тактичних RPG?

Я заплутався з написанням дійсно поганої тактичної RPG в C ++. Поки що у мене є 2D карта плиток, і щойно я отримав алгоритм A *, який працює на основі псевдокоду у вікіпедії .

Але справжні тактичні РПГ не просто знаходять найкращий шлях на плоскій площині і рухаються туди. Зазвичай вони мають обмежений діапазон переміщення і повинні підніматися вгору або вниз. Якщо ви коли-небудь грали у Final Fantasy Tactics, на них впливали б статистики Move and Jump. Тут я заблукаю. Як я можу змінити алгоритм A *, щоб він знайшов найкращий шлях до цілі, але шлях має лише стільки плиток? Як слід брати до уваги перепади висоти та статистику стрибків? Як здійснити стрибки через проміжок?

Якщо це допомагає, зараз моя карта представлена ​​вектором об'єктів плитки. Кожна плитка має вказівники на плитку Північ, Південь, Схід та Захід, які встановлюються на нульптр, якщо там немає жодної плитки, наприклад, уздовж краю карти або якщо плитка встановлена ​​на непрохідний.

Підйом і прогалини - це лише різні функції витрат. Для одиниці, яка може стрибнути, розрив має нормальну (?) Вартість, тоді як для одиниці, що не стрибає, вона має довільно високу вартість. Скелелазіння коштує додатково, як і складний ландшафт тощо. Алгоритм A * добре впорається з функціями витрат, тому якщо ваша реалізація вже не робить цього, просто google про те, як реалізувати A * з функцією витрат.

Сказавши це, однак, я не думаю, що A * є особливо хорошим підходом для тактичної RPG. Або точніше, це не повна історія. Ви не хочете, щоб ваші підрозділи сліпо блукали до своєї мети, ви хочете, щоб вони позиціонували себе, щоб використовувати прикриття, високі місця, що завгодно, одночасно просуваючись до кінцевої мети і прагнучи вбік противників і так далі. Тож тактичне значення кінцевої точки кожного кроку має величезне значення, а не лише наскільки близька до мети. Це вимагає більш поглибленого вирішення проблем, ніж просто простеження.

Коли вам потрібні всі можливі варіанти руху одиниці, використовуйте Алгоритм Дікстра .

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

Отже, коли ви просто хочете найкоротший шлях від точки А до точки В, то A * - це хороший вибір. Але якщо ви хочете отримати всі можливі варіанти руху та найкоротший шлях до кожного з них, то Dijkstra - саме те, що ви хочете.

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

Щодо стрибків: вони можуть бути представлені як ще один край як в A *, так і в Dijkstra. Вони можуть мати таку саму вартість, як і для переходу звичайного краю або іншого. Ви також можете передати параметр "jump_height" алгоритму, який вказує алгоритму ігнорувати перехідні краї, які перевищують задану висоту.

Інші відповіді мають хорошу інформацію, тому обов'язково прочитайте їх.

Однак, щоб відповісти на ваше запитання: виходячи з псевдокоду, з яким ви пов’язані, у вас є якась функція, heuristic_cost_estimateде ви підраховуєте вартість від tileA до tileB (якщо вважати, що вони суміжні). Замість того, щоб використовувати квартиру (1) для цієї вартості, вам доведеться скоригувати її, щоб вона включала статистику плитки та одиницю статистики, а можливо, і крайню статистику.

Наприклад:

if (edge == JUMP && !unit.canJump()) 
    return INF;
if (tile.Type == Forest && unit.moveType == HORSE) 
    return 2;
//Other cases here
//-----
else 
    return 1;

Це дасть вам свій шлях. Тоді ви просто перемістіть одиницю по їх шляху, витрачаючи точки руху, і зупиніть їх, залишившись пунктами <edgeCost. Зауважте, що це може бути не зовсім оптимальним, якщо ви закінчите залишилися точки = 1, але це повинно бути досить добре для практичної RPG. Насправді ви хотіли б більше тактичних, як зазначив Джек Едлі!

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

Скелелазіння та розриви досить тривіальні, оскільки вони лише змінюють вартість. Pathfinding (і більшість тактичних AI) - це підведення підсумків витрат на всі відвідувані вузли та мінімізація цього. Непрохідна скеля матиме нескінченну (дуже, дуже високу) вартість, схили матимуть більшу вартість, ніж звичайна тощо.

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

Хороші симуляції свідомо не знаходять найкращого шляху. Набагато кращим алгоритмом може бути ієрархічне наведення маршрутів - якщо нічого іншого, намалювавши пряму лінію на карті та зробивши 4-5 точкових точок, а потім простежити шлях від однієї точки до іншої, враховуючи лише ваги вузлів, які є поки що відомо, і встановлення всіх інших вузлів важить на "байдужих". Крім того, ви можете запустити A * на більш грубій сітці спочатку, а потім знайти шлях від одного великого вузла до другого (але я здогадуюсь, що малювання лінії на карті теж добре).

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