Про які патерни геймдизайну та програмування ігор ви хотіли б знати раніше, ніж дізналися?
Нещодавно Software Developer, який хоче почати розробляти свою гру як хобі, спитав у спільноти на Reddit, які патерни для геймдизайну та програмування є обов’язковими для створення гри. А також, які патерни фахівці спільноти хотіли б знати раніше, ніж вони дізналися. Тож, ми вирішили поцікавитися цим питанням у нашої української спільноти.
На Reddit топік стартеру порекомендували книгу Game Programming Patterns 📒
А також дали такі поради:
«Це не те щоб певний патерн, але використання event driven програмування — переламний момент. Замість того, щоб дізнаватися про стан гри у функції оновлення, виклик події під час запуску чи збою гри робить організацію та складність коду значно простішою для управління. Особливо для UI/анімацій. Якщо ви не вивчали events/delegates, втрачаєте фундаментальну частину розробки. Те, щоб якийсь event manager розіслав подію підписникам, має вирішальне значення для кожного проєкту, над яким я працював професійно чи особисто».
Проте інший користувач застерігає:
«У мене змішанні думки з цього приводу. Зручно використовувати події для чогось, що може відбутися лише раз, але не одразу, а коли щось завантажується (наприклад, подія OnGameStarted).
Проте (їхнє використання) для постійної/повторюваної логіки ігрового процесу, яка здатна виконуватися подіями, може доволі швидко роздуватися і викликати помилки та баги. Я значною мірою відмовився від подій на користь простих циклів оновлень/опитувань.
Багато геймплейних механік насправді працюють дуже добре, легко зчитуються/розуміються, як лінійна послідовність подій, заснованих на часі або стані, замість того, щоб для розуміння логіки перескакувати через кілька підписок на події/виклики/зворотні виклики/підписки тощо.
Я використовую події в розумній кількості. Наприклад, щоб прокомунікувати логіку стилю „fire and forget“ з коду моделювання ігрового процесу в користувацький інтерфейс. Або presentation code для запуску системи частинок (particles), звуковий ефект, показу UI-іконки чи чогось подібного. (UI, ймовірно, менше „стріляє та забуває“, лише якщо не працює за таймером, тож вам може часто знадобитися подія зникнення)».
«Уникайле класів богів. Використовуйте патерн спостерігача (observer pattern). Так, замість того, аби один об’єкт знав про всі об’єкти, які від нього залежать, дозвольте їм отримувати сповідення, коли щось відбувається. (Існує безліч способів це зробити)
Наприклад, коли у гравця стріляють, не оновлюйте користувацький інтерфейс. Замість цього зробіть так, аби UI слідкував за станом гравця і оновлював себе сам».
Інший користувач доповнює:
«(Комерційний AAA).
Я б пішов глибше і сказав, що завжди варто прагнути до розділення model/view.
Це трохи сповільнює імплементацію, але можливість запускати гру та оновлювати ігрові моделі з різною швидкістю, яка відрізняється від швидкості рендерингу, — велика перемога в багатьох площинах.
У маленьких іграх робіть все, що для вас працює».
«Те, що ви можете просто написати свою гру, замість того, щоб писати data driven рушій, який використовують інші люди для створення гри. Навіщо реалізовувати скриптовий рушій, якщо ви можете просто запрограмувати ці речі на C? Навіщо робити щось універсальне, що аналізує flash-файл або SVG, якщо за допомогою коду можна просто намалювати 5 полігонів, необхідних для UI? Це нормально, коли різні екрани вашої гри запускають різні основні та початковий цикли, замість того, щоб намагатися зробити екран інвентарю у вашому 3D-рушії...»
«Не все має бути class/instance. Я все сильніше віддаляються від oop. Тепер багато речей у грі можуть бути просто масивами цілих чисел, які можна буде швидко записати у файл. Звісно, можна щось задебажити, якщо у вас є помилки під час визначення зміщених даних. Окрім того, у кожного об’єкту в моїх іграх тепер є ідентифікатори, тому я загалом не зберігаю посилання на об’єкти (зараз працюю на Java), але це все цілочисленні ідентифікатори. Це робить збереження та завантаження елегантнішими...»
Немає коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів