"Ігровий об'єкт" - і на основі компонентів дизайн

Я працював над деякими хобі-проектами останні 3-4 роки. Просто прості 2d та 3d ігри. Але останнім часом я розпочав більший проект. Так, останні кілька місяців я намагався створити клас ігрових об'єктів, який може бути базою всіх моїх ігрових об'єктів. Тож після довгого тестування і тестування я звернувся до Google, який швидко вказав мені на деякі файли GDC та PowerPoints. А зараз я намагаюся зрозуміти ігрові об’єкти на основі компонентів.

Я розумію, що двигун створює ігровий об’єкт, а потім приєднує різні компоненти, які обробляють такі речі, як здоров'я, фізика, мережа та все, що ви з цим робите. Але я не розумію, як компонент X знає, чи Y змінив стан об'єкта. Як, наприклад, як PhysicsComponent знає, чи гравець живий, адже здоров'я контролює HealthComponent ..? І як HealthComponent відтворює "анімацію-помер гравця"?

У мене було враження, що це було щось подібне (In HealthComponent):

if(Health < 0) {
   AnimationComponent.PlayAnimation("played-died-animation")
}

Але знову ж таки, як HealthComponent знає, що до ігрового об’єкта, до якого він приєднаний, додається AnimationComponent? Єдине рішення, яке я бачу тут, - це

1. Проведіть перевірку, чи додано AnimationComponent чи ні (або всередині коду компонента, або з боку двигуна)

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

3. Напишіть, як, HealthWithAnimationComponent, HealthNoAnimationComponent та soo on, що, схоже, знову відповідає всій ідеї дизайну компонентів.

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

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

Компонент охорони здоров'я не надсилає повідомлення безпосередньо анімаційному компоненту. Можливо, він транслює його на кожен компонент у цій сутності, можливо, на всю систему; можливо, компонент анімації повинен повідомити систему обміну повідомленнями, що її цікавлять повідомлення "Я помер". Існує багато способів реалізації системи обміну повідомленнями. Однак ви реалізуєте це, справа в тому, що компонент здоров'я та компонент анімації ніколи не повинні знати або дбати про наявність іншого, і додавання нових компонентів ніколи не потребуватиме модифікації існуючих, щоб надсилати їм відповідні повідомлення.

Таким чином , що Артеміс вирішує цю проблему, щоб не робити обробки в компонентах. Компоненти містять лише необхідні їм дані. Системи читають кілька типів компонентів і виконують будь-яку необхідну обробку.

Отже, у вашому випадку у вас може бути RenderSystem, який читає в HealthComponent (та інших) і відтворює черги до відповідних анімацій. Таким чином відокремлення даних від функцій полегшує правильне управління залежностями.

У вашому коді ви можете знайти способи (я використовував їх, можливо, існують інші способи) дізнатися, чи змінився об'єкт стан:

1. Відправити повідомлення.
2. Читати безпосередньо дані з компонента.

1) Проведіть перевірку, чи додано AnimationComponent чи ні (або всередині коду компонента, або з боку двигуна)

Для цього я використав: 1. HasComponent функцію GameObject, або 2. коли ви приєднуєте компонент, ви можете перевірити залежності в якійсь конструюючої функції, або 3. Якщо я точно знаю, що в цьому об'єкті є цей компонент, я просто його використовую.

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

У деяких статтях я читав, що в системі Ideal компоненти не залежать один від одного, але в реальному житті це не так.

3) Напишіть, як, HealthWithAnimationComponent, HealthNoAnimationComponent, і так далі, що, схоже, знову відповідає всій ідеї дизайну компонентів.

Погано писати такі компоненти. У своєму додатку я створив компонент Health, який є найбільш незалежним. Зараз я замислююся над деякою схемою спостерігача, яка сповіщає передплатників про якусь конкретну подію (наприклад, "потрапляння", "загоєння" тощо). Тож AnimationComponent повинен самостійно вирішити, коли грати в анімацію.

Але коли я прочитав статтю про CBES, це мене вразило, тому я дуже радий зараз, коли використовую CBES та відкриваю нові можливості цього.

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

Його менше OOD і більше схоже на функціональне програмування. Коли я почав експериментувати з компонентним дизайном, я помітив цю проблему в дорозі. Я ще більше погуглився, і знайшов "Функціональне реактивне програмування" як рішення.

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

Однак певним чином ви все-таки можете стверджувати, що проблема знову змінилася. Бо що робити, якщо це не прямо, в якому порядку потрібно запускати ваші Системи? Що робити, якщо існують циклічні взаємозв'язки і це лише питання часу, перш ніж ви будете дивитися на безлад, якщо інакше і перемикаєте заяви? Це неявна форма обміну повідомленнями, ні? На перший погляд, я думаю, що це невеликий ризик. Зазвичай речі обробляються по порядку. Щось на кшталт: Введення гравця -> Позиції особи -> Виявлення зіткнень -> Логіка гри -> Візуалізація -> Почніть спочатку. У такому випадку ви маєте одну систему для кожної, надайте кожній Системі метод update (), а потім запускайте їх послідовно у вашому гейлері.