Як з'єднати машину з кінцевим станом в архітектуру на основі компонентів? [зачинено]

Державні машини, схоже, викликають шкідливі залежності в компонентних архітектурах.

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

Де я:

• Я новачок в компонентних архітектурах.
• Я роблю бойову гру, хоча не думаю, що це має мати значення. Я припускаю, що моя державна машина використовується для перемикання станів, таких як "скручування", "дрімота", "блокування" тощо.
• Я знайшов цю техніку управління державою найбільш природною системою для архітектури, що базується на компонентах, але вона конфліктує з прийомами, про які я читав: Динамічна компонентна система об'єктів ігор для персонажів, що змінюються. самі, постійно перевіряючи умову активації.
• Я думаю, що такі дії, як "біг" або "ходьба", мають сенс як держави, що суперечить прийнятій тут відповіді: /gamedev//a/7934

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

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

  B. Державна машина залежить від компонентів:
  Компонент стан машини отримує посилання на всі компоненти, які він контролює. Він запитує їх getState()методи, щоб побачити, де вони.

  C. Деяка абстракція між ними
  Використовуйте центр подій? Шаблон команди?

  D. Використовуються окремі об'єкти стану, які використовують еталонний
  зразок State Pattern. Створюються окремі об'єкти стану, які активують / деактивують набір компонентів. Державна машина перемикається між об'єктами стану.

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

Огляд досить легкий, але ознайомтеся з цими слайдами з презентації, яку я робив для New Game Conf в минулому році:

https://docs.google.com/presentation/d/110MxOqut_y7KOW1pNwIdcccisIA3ooJwVR-xm-ecuc4/view

(див. відповідні зображення нижче)

Суть методики полягає в поєднанні структури списку дій (пояснюється - дещо погано - на слайдах) з машинами поведінкового стану, що діють на ігрову сутність на основі компонентів.

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

Моя улюблена частина цієї конкретної гри полягала в тому, як ми могли створити абсолютно нові типи ворогів, просто вибравши зі списку заздалегідь написані поведінки, помістивши їх у список дій для ігрового об’єкта (що мешкає в BrainComponent) у потрібному порядку пріоритет, і все просто працювало. За допомогою списку дій, що дозволяє виконувати дії "Блокування / неблокування", це може зробити дуже цікаві речі, незважаючи на те, як просто це реалізувати.

Навіть поведінки на кшталт "оглушення", де насправді просто StunBehaviorAction висунулося на верхню частину списку дій; якщо поведінка оглушення активізується (помітивши, що EarsComponent ігрового об'єкта почув приголомшливу атаку ударної хвилі), то він встановив свій внутрішній стан на оглушення, сказав AnimationComponent відтворити анімацію оглушення і встановив стан дії на Blocking, а його таймер на тайм-аут оглушення, витягнутий з ігрового об’єкта EnemyParametersComponent. Оскільки це було Блокування та знаходиться у верхній частині списку дій, ніхто з інших BehaviorAction у списку дій не отримає виклик свого методу оновлення, тож вони по суті були б вимкнені. Коли час закінчення закінчився, StunBehaviorAction повертає його стан у режим очікування, а стан дії - на NonBlocking.

Інші способи поведінки, які ми реалізували, були майже всі реалізовані за допомогою єдиної внутрішньої державної машини. Єдиними двома, які не мали державних машин, насправді, були PatrolPathBehaviorAction (це би підштовхнуло серію PathAction до списку дій, якщо воно не працює, що в свою чергу підштовхнуло MoveAction) та GuardHomeBehaviorAction (завжди внизу список дій, і завжди буде просто відштовхнути PathAction назад до домашнього місця противника). Кожна інша поведінка була державною машиною.

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

Компонент AI має підкомпоненти, які він може створювати та знищувати на льоту, виходячи з того, який тип дій він виконував. Наприклад, якщо він блукав, він може створити блукаючий підкомпонент і оновити цей кадр під час блукання, а потім, якщо aggro'd під час блукання закриє цей підкомпонент і відкриє атакову підкомпонент. Компонент AI повинен бути незалежним від усіх інших компонентів об'єкта. Наприклад, у нас був вхідний компонент, який би просто запитував значення руху на одиниці. Запит, який він робив, відповідав на те, як люди, так і AI-об'єкти. Це дозволило компоненту AI просто встановлювати значення руху на собі під час таких дій, як блукання, щоб вхідний компонент міг підхопитись так само, як компонент, керований людиною, встановив би значення, на які може входити компонент введення.

Трохи незрозуміло, що ви маєте на увазі під компонентами, оскільки ваші терміни дуже розпливчасті, без конкретних прикладів. Часто ігрові утворення будуються з використанням композиції, а не спадкування. Таким чином, ви можете перетворити їх на щось, що може завдати шкоди, додавши компонент здоров'я до сутності, або ви можете зробити їх анімованими, додавши анімаційний компонент. Можна також поставити ШІ в такий компонент. У вашому компоненті AI буде прийнята логіка прийняття рішень, і якщо ви стурбовані тим, що з'єднати з більшою частиною іншого коду в системі, ви можете зібрати інформацію на дошці, до якої логіці AI дозволяється лише доступ. Існує також питання залежності від виходу системи AI. В основному ваш інтелектуальний інтелект управляє сутністю, і для цього потрібен інтерфейс. Одна корисна концепція - це контролер або геймпад. Ваш AI може заповнити подібну структуру, яку б заповнив геймпад гравця (хоча він може мати кілька додаткових "кнопок" для конкретних здібностей). Тепер ця структура може бути передана вашому анімаційному компоненту, який би інтерпретував її та вибирав відповідну анімацію для відтворення. Різні підкомпоненти AI можуть навіть записуватись до різних полів структури або до тих же полів з різними пріоритетами. Прицілювання та ходьба, наприклад. Різні підкомпоненти AI можуть навіть записуватись до різних полів структури або до тих же полів з різними пріоритетами. Прицілювання та ходьба, наприклад. Різні підкомпоненти AI можуть навіть записуватись до різних полів структури або до тих же полів з різними пріоритетами. Прицілювання та ходьба, наприклад.