Компонент / об'єктний дизайн + дерева поведінки => як інтегруватися?

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

Отже, я отримав (трохи розширені) сутності , які в основному є intідентифікатором, людиною, що читається ім'ям, std::mapкомпонентів та long"індикатором типу", який використовується для показу, які компоненти є (у мене є потужність дві enumдля всіх компонентів типів і кожного разу, коли компонент додається до Entity, я автоматично змінюю це протягом бітових операцій, порівнюю цю відповідь ).

Потім є компоненти , також досить прості: intID, enumяк тип компонента, вказівник батьківської сутності та std::mapвсі властивості цього компонента.

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

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

Тепер я хотів би також ввести дерева поведінки (на базі AiGameDev BTSK ) у цей проект, але я не впевнений, чи потрібно їх пов’язати з уже існуючими компонентами або як інтегрувати ці проекти в цілому.

На думку приходить декілька пов'язаних ідей / точок / питань:

1. Мої BT будуть прочитані з файлів (знову). В даний час мені важко бачити, як я б найкраще встановити зв’язок між BT Actionтим деревом і фактичним кодуванням у своїй програмі. Чи слід створити якусь карту між іменами дій, що використовуються у файлах BT, та функціональним вказівником на фактичну логічну реалізацію? Який звичайний підхід для вирішення цього питання?

2. Я припускаю, що мені доведеться створити БТ для всіх моїх різних Entityтипів (тому для кожної ігрової логіки / AI-відповідного поєднання компонентів, як зазначено в моїх багаторазових згадуваних довгих "індикаторах типу"). Як результат, не має сенсу розміщувати BT Actionреалізацію в компонентах, оскільки, швидше за все, за кожну дію буде задіяно багато компонентів, чи не так?

3. Тож чи повинна BT Actionлогіка сидіти в / декількох окремих системах (на методи яких вказує карта від ідеї №1)? Потім система перевірить за моїм long"індикатором типу", чи Entityдійсно дозволено виконувати певну дію (= метод у системі), для якої вказано BT (чи є необхідні компоненти). Але тоді, як ні (тому що, наприклад, BT-творець ігнорував конкретну ситуацію, коли необхідний компонент більше не може бути приєднаний до Entity під час виконання), нічого не відбудеться.

Запитання:

• Чи є перевірені концепції для такої інтеграції?
• Як ви оцінюєте мої 3 пункти вище?
• Будь-які інші речі, які виникають на увазі, також стосовно мого компонента / базованого дизайну взагалі?

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

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

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

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

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