Виклики функцій за кадром та повідомленнями, керовані подіями в дизайні ігор

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

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

Керована подіями архітектура ігор добре описана в: Кодування гри завершено Майком МакШафрі .

Чи можу я просити про допомогу з наступними питаннями:

• Які переваги та недоліки обох підходів?
• Де один кращий за іншого?
• Чи є дизайн ігор універсальним і кращим у всіх сферах? Тому це рекомендується використовувати навіть на платформах для мобільних телефонів?
• Який з них більш ефективний, а який складніший для розвитку?

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

Приклад: Це запитання викликало тут трохи суперечок, тому дозвольте запропонувати вам приклад: За даними MVC, ігровий движок розділений на три основні частини:

1. Прикладний рівень (апаратне забезпечення та ОС)
2. Логіка гри
3. Перегляд гри

У гоночній грі Game View відповідає за максимально швидке відображення екрана, принаймні 30 кадрів в секунду. Game View також слухає дані гравця. Зараз це відбувається:

• Гравець натискає педаль палива до 80%
• GameView створює повідомлення "Нагнітається паливна педаль автомобіля до 80%" і надсилає її до Game Logic.
• Game Logic отримує повідомлення, оцінює, обчислює положення та поведінку нового автомобіля та створює такі повідомлення для GameView: "Намалюйте педаль палива для автомобіля 2 на 80%", "Прискорення звуку автомобіля 2", "Координати автомобіля 2 X, Y". .
• GameView отримує повідомлення та обробляє їх відповідно

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

Які переваги та недоліки обох підходів?

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

Де один кращий за іншого?

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

Чи є дизайн ігор універсальним і кращим у всіх сферах? Тому це рекомендується використовувати навіть на мобільних платформах?

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

Який з них більш ефективний, а який складніший для розвитку?

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

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

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

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

Суть: Ні кращого підходу, ні вони не є ексклюзивним.

Це почалося як коментар до відповіді bummzack, але отримало довго.

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

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

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

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

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

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

Дизайн, який використовується для будь-якого конкретного об'єкта, повинен базуватися на потребах цих об'єктів, а не базуватися на певній ідеології для системи в цілому.

Відредаговано, щоб бути більш зрозумілим у моєму першому реченні.