Ситуаційна обізнаність у пошуку шляху

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

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

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

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

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

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

У кожній копії підземелля двері, які є прохідними, - це саме ті, які можна пропустити за допомогою відповідного набору предметів. Єдиний спосіб перейти з однієї копії підземелля до іншої - це стати на місці розташування предмета та забрати його.

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

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

Наприклад, припустимо, що у вашій підземеллі десять дверей та п’ять ключів. Тоді буде 2 * 10 + 5 = 25 значущих локацій та 2 ^ 5 = 32 можливі комбінації елементів, загалом 25 * 32 = 800 вузлів у повному просторі пошуку. Це дуже скромне число, особливо враховуючи, що значна частина пошукового простору, ймовірно, буде недосяжною.

З точки зору реального світу: Якби ви прямували від А до Б і виявили двері D на шляху, який був заблокований, ви зрозуміли, що вам потрібно знайти ключ D. Так що якщо ваш ШІ такий же невідомий, як типовий люд , це передбачало б розвідку ключа, який представляє собою набір крихітних кроків, що визначають самі по собі. З іншого боку, ви, можливо, хочете, щоб ваш AI знав, перш ніж спробувати шлях, що на цьому маршруті є зачинені двері, і в цьому випадку він, ймовірно, також знатиме, де знайти ключ.

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

Далі - карта вищого рівня, яка має більше топологічний, ніж топографічний характер. Це насправді не цікавить наземні деталі перешкод тощо, лише дбає про зв’язок між зонами. Ця топологічна карта несе з'єднання між рівними зонами, які в даний час мають між собою зачинені двері, оскільки вона показує ідеальну сполучуваність усіх зон у вашій підземеллі. У його краях - кожна, що представляє собою двері між зонами - він зберігає той ключ, який ще потрібен, якщо він є, щоб відкрити ці двері, інакше вона вважається відкритою. Отже, шукаючи цей графік для найкоротшого шляху, слід обмежити знайдений шлях лише маршрутами, які вже відкриті , перевіряючи дані в краях під час пошуку. Зв'язок тут не передбачає відкритості, а передбачає потенційну відкритість.

Коли ви хочете перейти до точки, яка потрапляє в окрему зону, спочатку шукайте карту вищого рівня, щоб знайти шлях. (На цьому рівні може використовуватися A * або будь-який інший алгоритм найкоротшого шляху.) Після того, як ви знайдете шлях, карта вищого рівня також повинна містити інформацію про те, які двері вам потрібно використовувати, щоб дістатися з вашої поточної зони до іншої зони. Тепер у локальній зоні ви можете зробити AI наземного рівня для навігації до цих дверей. Як тільки двері були досягнуті, ваш персонаж може пройти через ці двері / портал. Зараз він знаходиться в зоні B. Якщо це цільова зона, він може використовувати навігацію на наземному рівні, щоб перейти до ключа. Якщо це не так, вам потрібно повторити крок перший, поки ви не досягнете цільової зони.

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

PS. Якщо ви створюєте свою підземелля процедурно, тоді, як ви це робите, ви можете зберігати інформацію про впорядкування залежності, за умови, що ви вже знаєте вихідну позицію гравця.

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

По-перше, допустимий евристичний не повинен бути ідеальним. Це просто має бути недооціненою, і воно повинно бути краще, ніж нічого. З огляду на те, що ви працюєте з фактичними відстанями, мабуть, ймовірно, що A * принаймні допоможе, і навіть якби евристика не значно покращила пошук, це, мабуть, все-таки буде краще, ніж стандартний широта пошуку або подібне.

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

Однак правда, що ці ускладнення перейдуть A * із царств "дуже ефективного" в ", але це, мабуть, не в потрібному мені часовому масштабі". Який часовий графік вам потрібен? Насправді, навіщо вам це робити - чи справді вам потрібен найкоротший шлях, чи вистачить будь-якого розумного шляху?

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

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

Я б спробував, якщо можна послабити критерій "найкоротшого шляху", це:

• Створіть графік високого рівня, який містить лише важливі місця - ключові положення, положення дверей, позиції в межах замкнених ділянок та відзначте прямолінійні відстані між ними. Якщо ваша карта вже розділена на кімнати чи інші окремі місця, це чудово.
• Використовуйте A *, щоб знайти шлях через цей графік, від початку до кінця. Нормальна декартова евристична відстань повинна бути достатньою, щоб підтримувати її керованість.
• Тепер, за допомогою цього спрощеного шляху між цими точками, використовуйте A * ще раз, щоб побудувати шлях низького рівня від однієї точки до другої.
• Приєднуйтесь до цих контурів низького рівня разом, щоб формувати весь ваш шлях.

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

з наданою вами інформацією, я думаю, ви можете використовувати A * лише з невеликою модифікацією. у звичайному алгоритмі A * ви позначаєте кожен вузол, переходячи через них, щоб переконатися, що ви його більше ніколи не передасте. Саме ця частина створює проблеми з Елементами. Ключова зміна - пам’ятати, якими були ваші предмети, коли ви раніше переходили з вузла. ось код судо, що пояснює, що я маю на увазі:

if (nodestoCheck.notempty())
    newNode = nodeToCheck.first;
    if (notpassed(newNode.pos, newNode.items))
        if (room(newNode).containItem)
            add NewNode + room(NewNode).items 
        else
            do normal A* algorithm for new Node

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

Чому ви просто не використовуєте звичайні A * і не замикаєте двері як непрохідні регіони; Після того, як ви підберете ключ (ходите по ключовій плитці?), це змінює цю замкнуту двері в прохідну область.

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

Це здається мені досить розумним. Це не ідеально, але це просте рішення проблеми.