ШІ для ботів у інді-іграх: Які рішення використовують розробники?

У розробці ігор навіть прості боти потребують певного рівня штучного інтелекту (ШІ). Якщо великі AAA-компанії мають доступ до складних систем і команд спеціалістів, то інді-розробники та малі студії часто обирають простіші, але гнучкі рішення. У цьому пості хочу порушити кілька практичних питань та почути ваш досвід.

AI

Які типи ШІ ви використовуєте? Цікавить, який саме підхід ви застосовуєте для реалізації поведінки ботів:

  • Кінцевий автомат (Finite State Machine, FSM) — класичний підхід, зручний у простих сценаріях
  • Поведінкові дерева (Behavior Trees, BT) — популярні в Unity, часто використовуються для складніших шаблонів поведінки
  • Когнітивні моделі / GOAP — для динамічнішої поведінки та прийняття рішень на основі цілей

Чи створюєте ви все з нуля або використовуєте готові рішення або інструменти ігрового рушія (Unity, Unreal, Godot тощо)?

Чи маєте досвід роботи з комерційними рішеннями для ігрового ШІ? Наприклад:

  • Сторонні плагіни для Unity/Unreal
  • AI-сервіси з хмарною інтеграцією
  • Інструменти, які спрощують налаштування ШІ без потреби писати код

Цікаво дізнатися, що з цього дійсно працює, а що — марна трата часу.

На даний момент немає офіційних стандартів для реалізації ігрового ШІ, але можливо в спільноті вже склалися певні неофіційні чек-листи:

  • Адекватність реакції на гравця
  • Прогнозована, але не занадто шаблонна поведінка
  • Можливість розширення логіки
  • Легкість налагодження

Які критерії для «нормального ШІ» ви вважаєте ключовими?

Особливо цікавить досвід тих, хто реалізовує ШІ на JavaScript. Який підхід ви обрали і чому?

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

Буду радий почитати ваші коментарі.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Стейт машина дає повний контроль, але підходить для простих задач. Занадто складно її розширювати — налаштувати умови переходів, контролювати їхню правильність. Проте я спробував трохи інакший підхід до цього алгоритму — через ECS, якщо точніше юнітівський DOTS. Основа ЕЦС — це розділення функціоналу та даних. Таким чином, система збирає всі ентіті на сцені, які мають відповідні компоненти, і поведінка визначається наявністю/відсутністю набору компонентів. В результаті переходи зводяться до тривіального «додати систему, докинути компонент, ігнорувати його в усіх інших системах». Це трохи спростило задачу, а також було цікавою практикою)
Дефолтним юнітівським графом стейтів користуюся виключно для анімацій, з причин описаних вище. Для всього іншого легше перевикористати щось своє.

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

Гоап доволі часто є оверкіл рішенням. В 90% випадках бех трі буде достатньо. Але це рішення найбільш близьке до нейронок та доволі часто видає неочікувані результати. Не цікавився ринковими представниками реалізації, але власноруч було надзвичайно цікаво його робити. Далі проясню суть алгоритму, щоб всім було зрозуміло.
Існує агент — це сутність, яка хоче зробити дію.
У сутності є Beliefs — певні знання про власний стан та що відбувається в навколишньому середовищі (наприклад кількість здоров’я, позиція ворога тощо).
Агент має список Actions, дій. Дії мають два списка Beliefs. Перший відповідає за передумови, які необхідно задовільнити, щоб мати змогу виконати цю дію (наприклад дія «Відновити здоров’я» може бути виконана тільки якщо у агента хп нижче 15%). Другий відповідає за наслідки цієї дії — як зміниться стан агенту чи світу після виконання (на тому ж прикладі з відновленням здоров’я: агент впевнений, що після виконання дії він поповнить здоров’я до 75%).
І останнє, агент має Goals — цілі, які він повинен виконувати. По суті своїй цілі — це обгортка над Beliefs, так як вони описують очікуваний стан агента чи світу, плюс задають приоритет цих станів.
На основі цих складових агент обирає найбільш приоритетну ціль та проходиться по всім діям, підбираючи їхні наслідки так, щоб вони задовільняли стан цілі та передумови попередніх дій.
Так, в цьому було не легко розібратися😅 Найцікавіше почалося, коли я вирішив розбити алгоритм на паралельні розрахунки використовуючи Compute Shaders. Можливо колись напишу про свої поневіряння в цій темі, але такого поганого коду я ще в житті не писав))

Остання тема, з якою я вже працював, але не приміняв конкретно для розробки ігор — використання повноцінних нейронок. Важезне рішення, яке навіть не варте часу (в контексті ігор), якщо не має прям жорсткої необхідності. Вивчав я це діло на Unity ML Agents. Це хороша система, але використання в фінальному продукті я ще ні разу не перевіряв. Колись обов’язково дойду до цього.

О, дякую за таку розгорнуту відповідь)
Зараз працюю над вдосконаленням ШІ для ботів/монстрів у грі(усе пишеться на JS), і якраз повстало питання а де треба зупинится у вдосконаленні коду — щоб не перевантажувати зайвими речами саму гру але щоб і грати було цікаво і монстри були «адекватні», а не просто тупі «овочі».

Beh Tree завжди найкращий варіант, імо😅 Це чисто мій улюбленець. Удачі Вам на проєкті)

О, це цікава тема і був етап в розробці, коли мені довелося спробувати все перелічене. Зараз я використовую FSM і GOAP. FSM в якийсь момент став громіздким, але лишився в проекті, більше для станів анімації. GOAP виглядає елегантним рішенням і часто дивує своєю гнучкістю — він просто працює. x.com/...​tatus/1710253660054122929

гірше всього той бот, який пише на доу тексти після ШІ,
Цей текст цілком міг бути написаний людиною, але існують ознаки, що вказують на ймовірне використання ШІ або принаймні сильну редакторську допомогу ШІ

Дякую за реакцію)
Але якщо буде бажання дати відповіді на поставлені запитання стосовно ШІ, який використовують для ботів у інді-іграх — буду щиро вдячний.

Розумієте як )
Яке питання така й відповідь.

Дуже мало вводних. Бо від того яка задача буде і відповідь.

Для стратегій і досі FSM я б обрав для простої логіки юнітів. ...Але там є «Сценарний Директор» (глобальна аішка яка роздає команди між ігровими системами), який вже може і GOP свій мати надбудовою який і буде керувати не одиночними юнітами і загальною «стратегією» поведінки.

Для РПГ / Шутерів — бехевіор трі звучить як найбільш документований спосіб реалізації. Тобто глях який кудись приведе.

З приводу «кодінгу» стрілочками в блупрінтах — це грусть-пічаль, шо в великих ААА проектах які я бачив, шо в Юніті, шо в Анрилі, все досить повільно і правити так само важко як і код після того як стане багато логіки.

Створював і підтримую кастомний варіант дерев поведінки (Behavior Trees) у 4х стратегії. Сам аі менше обирає конкретний варіант поведінки, а більше за допомогою вагів, випадково обирає дію, яку він буде робити, і далі вже Behavior Template реалізує логіку самої дії. На більш складний підхід не вистачає ресурсів, хоч його було б легше балансувати. Але для гравця боти роблять багато екшену, і геймплей виходить дуже веселий. )

Дякую, за відповідь.
Буду вдячний якщо напишете в особисті трішки більше подробиць.
Бо, як писав вище у топіку — найбільше цікавить самостійна реалізація ШІ, а особливо на JavaScript.

А ще цікавить чи використовуєте якісь рівні вкладеності параметрів ШІ чи ні.

Підписатись на коментарі