Зв'язок, керований подіями в ігровому двигуні: Так чи ні?

Я читаю ігрове кодування завершено, і автор рекомендує комунікацію, керовану подією, між ігровими об'єктами та модулями.

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

Це перевірений і рекомендований підхід? Як я повинен вирішити, чи використовувати його?

Це розширення мого коментаря до повної відповіді, як було запропоновано.

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

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

РЕДАКТУВАННЯ : Щоб вирішити питання щодо коментарів щодо того, яким чином ви знаєте, які об’єкти повинні отримати повідомлення : Самі об’єкти повинні Requestбути повідомлені про події. Вашому EventMessagingSystem(EMS) знадобиться Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback)як і відповідність Unregister(зробити унікальний запис для iEventIdвказівника об'єкта та зворотного виклику). Таким чином, коли об’єкт хоче дізнатися про повідомлення, яке він може отримати Register()із системою. Коли йому більше не потрібно знати про події, він можеUnregister(). Зрозуміло, що ви хочете отримати пул цих об'єктів реєстрації зворотних викликів та ефективний спосіб додавання / видалення їх зі списків. (Я зазвичай використовую масиви для самостійного замовлення; вигадливий спосіб сказати, що вони відслідковують власні розподіли між стеком пулу невикористаних об'єктів та масивами, які змінюють їх розміри на місце за потреби).

EDIT : Для повністю працюючої гри з циклом оновлення та системою обміну подіями, ви можете перевірити проект моєї старої школи . Посилання, пов’язане з переповненням стека, також посилається на нього.

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

І це добре, адже коли ти закінчиш, ти насправді матимеш гру, а гра набагато крутіша, ніж система передачі повідомлень.

Краще питання, які альтернативи є? У такій складній системі з правильно розділеними модулями для фізики, AI тощо, як ще можна оркеструвати ці системи?

Передача повідомлень здається "найкращим" рішенням цієї проблеми. Я зараз не можу придумати альтернативи. Але є чимало прикладів передачі повідомлень на практиці. Фактично, операційні системи використовують передачу повідомлень для декількох своїх функцій. З Вікіпедії :

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

(Міжпроцесовий зв'язок - це зв'язок між процесами (тобто запущеними екземплярами програм) в середовищі операційної системи)

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

Я також задав питання щодо переповнення стека, "Структури даних для передачі повідомлень у межах програми?" , яку ви, можливо, захочете прочитати.

Повідомлення зазвичай працюють добре, коли:

1. Річ, що надсилає повідомлення, не хвилює, чи отримана вона.
2. Відправника не потрібно отримувати негайну відповідь від одержувача.
3. Можливо, декілька приймачів прослуховують одного відправника.
4. Повідомлення надсилатимуться нечасто або непередбачувано. (Іншими словами, якщо кожному об'єкту потрібно отримувати повідомлення "оновлення" кожен кадр, повідомлення насправді не купують вас багато.)

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

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

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

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

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

Ну, я знаю, що ця посада досить стара, але я не втримався.

Нещодавно я побудував ігровий двигун. Він використовує бібліотеки 3d-партій для візуалізації та фізики, але я написав основну частину, яка визначає та обробляє сутності та логіку гри.

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

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

Незважаючи на примітивну систему повідомлень, я б сказав, що система значною мірою є "циклом оновлення на основі".

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

Але я також думаю, що у чистої системи на основі циклу оновлення, як у мене, є і деякі проблеми.

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

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

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

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

Ще одна перевага: Ви можете прослуховувати кілька підсистем для однієї події. Наприклад, всі ваші віддалені види (гравці) можуть автоматично підписатися на подію створення сутності та породжувати сутності у кожного клієнта з невеликою роботою з вашого боку. Уявіть, як би більше працювало, якби ви не використовували події: вам доведеться Update()десь телефонувати або, можливо, дзвонити view->CreateEntityз логіки гри (де знання про вигляд та необхідну інформацію не належить). Важко вирішити цю проблему без подій.

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

Детальніше та реалізація тут .

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

• Ігрові двигуни обробляють велику кількість даних.
• Ігри повинні бути швидкими (20-30 FPS має бути мінімальним).
• Часто доводиться знати, чи щось було зроблено чи коли це буде зроблено.

При загальному підході розробника ігор, "він повинен бути максимально ефективним", така система обміну повідомленнями не є такою поширеною.

Однак я погоджуюся, що вам варто просто продовжити і спробувати. Звичайно, існує багато переваг у такої системи, і обчислювальна потужність сьогодні недорого доступна.