AI для переміщення космічних кораблів у формі особи (форма, що впливає на поведінку руху)


15

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

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

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

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

Я думаю, що такий підхід трохи нудний. Гравець не хоче возитися з моторами чи чим-небудь, ви просто хочете МУЖИТИ та Вбивати. Те, як я маю намір гравець давати накази цим кораблям, - це за призначенням і поворотом , і тоді AI обчислить правильну потужність гвинта, щоб досягти цього руху та обертання. Приведення в рух не повинно бути однаковим під час розрахунку всього повороту (після надання наказів), тому було б здорово, якби кораблі реагували під час руху, динамічно регулюючи потужність гвинтів для своїх потреб, але це може бути занадто складно реалізувати, і це не дуже потрібно для гри.

В обох випадках як AI вирішив, які гвинти активувати для найкращої (або принаймні не найгіршої) траєкторії, яку потрібно досягти?

Я хоч про деякі підходи:

  • Навчання AI: типи кораблів дізнаються про їх рух шляхом спроб та помилок, коригуючи свою поведінку з більшою кількістю застосувань і, нарешті, стають "розумними". Я не хочу втягуватися ТАК далеко в кодування AI, і я думаю, що це може неприємно для гравця (навіть якщо ви можете дозволити йому вчитися без гри.)
  • Попередньо обчислений рух кроку часу: Після створення корабля ВСІ можливі рухи обчислюються для кожної конфігурації гвинта та потужності для заданого дельта-часу. Пам'ять інтенсивна, потворна, погана.
  • Попередньо обчислені траєкторії: Те саме, що було зазначено вище, але не для кожної дельта-часу, а для всієї траєкторії, яка б потім була максимально встановлена. Потрібна фіксована конфігурація гвинта для всієї фази бою, і досі зберігає пам'ять, негарна та погана.
  • Безперервне грубе форсування: AI безперервно перевіряє ВСІ можливі конфігурації гвинта протягом усієї фази бою, заздалегідь обчислює кілька кроків за часом і вирішує, який на цій основі найкращий. Con: те, що зараз добре, може бути не таким хорошим пізніше, і це занадто інтенсивно, некрасиво і погано процесором.
  • Одномісний грубої форсування: Те саме, що вище, але тільки грубе форсування на початку моделювання, тому йому потрібна постійна конфігурація гвинта протягом усієї фази бою.
  • Безперервна перевірка кута: Це не повний метод руху, але, можливо, спосіб відкинути "тупі" конфігурації гвинта. Враховуючи нормальний вектор поточного гвинта і остаточний, ви можете наближати потужність, необхідну для гвинта, виходячи з кута. Ви повинні робити це безперервно протягом усієї фази бою. Я зрозумів це нещодавно, тому я не надто замислювався. Апріорі, у нього є і недолік "те, що зараз добре, може бути не так добре згодом", і це не хвилює інших гвинтів, які можуть діяти разом, щоб зробити кращу конфігурацію навішування.

Я справді застряг тут. Будь-які ідеї?


Ви переглядали рульове поведінку?
каменеметал

1
@stonemetal точно. Проблема тут полягає в тому, що поведінка рульового управління, як правило, моделюється, передбачаючи повний контроль над положенням і обертанням об'єкта та деякими обмеженнями (або принаймні це те, що я знайшов в Інтернеті.) ШІ тут не має повного контролю над сутністю , але тільки над речами (гвинти), які змушують сутність рухатися. У мене виникають проблеми, пов'язані з цим рульовим поведінкою і фактичним рухом космічного корабля.
kaoD

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

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

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

Відповіді:


4

Вибачте, у нас немає перевіреного рішення, але чи не можна це вирішити математично?

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

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

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

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

Це дуже зворотна конверта, але я не бачу жодних основних недоліків. Просто багато наполегливої ​​роботи та налаштування кількості. :)


Це те, що я шукав, математичне рішення ... дякую! Я сподіваюся, що це стає так просто, як це звучить.
якDo

7

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

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

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

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


Не зовсім те, що я шукав, але може зробити трюк, якщо мені справді потрібно. Оновлення ідеї :)
якD

0

У просторі форма не впливає на рух. Немає повітря для перетягування.

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


Ласкаво просимо на GD.SE! На це питання вже є прийнята відповідь, і його задали 2 роки тому - можливо, ви могли б відповісти на деякі новіші запитання на сайті.
Полярний

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

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

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

@kaoD Вибачте, якщо це виявилося трохи суворим - очевидно, багато SO додає значення пізніше. Я просто припускав, що він також може відповісти на нові запитання - чим більше відповідей на запитання, тим краще!
Полярний
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.