Які схеми дизайну програмування корисні при розробці ігор? [зачинено]

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

Наприклад, у мене є книга під назвою ActionScript 3 з шаблонами дизайну, в якій детально описано кілька моделей дизайну, таких як контролер перегляду моделі, Singleton, Factory, Command тощо.

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

Якщо у вас є досвід використання певного шаблону дизайну в розробці ігор, я б хотів це почути. Обґрунтування того, чому він використовувався, зразки коду чи Інтернет-ресурси, також були б дуже корисними, якщо у вас є. На даний момент я найбільше зацікавлений у впровадженні ActionScript 3 та C ++, але, безумовно, міг би скористатися досвідом та прикладами з будь-якої мови.

Дякую!

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

• Builder: налаштуйте об'єкт на основі компонентів по одному компоненту за раз на основі даних
• Фабричний метод: створити віджети NPC або GUI на основі рядка, прочитаного з файлу
• Прототип: зберігайте один загальний символ 'Elf' з початковими властивостями та створюйте екземпляри Elf, клонуючи його.
• Синглтон: цей простір навмисно залишився порожнім.
• Адаптер: включіть додаткову бібліотеку сторонніх виробників, загорнувши її в шар, схожий на існуючий код. Дуже корисно з DLL.
• Композит: складіть графік сцени з зображуваних об'єктів або створіть графічний інтерфейс із дерева віджетів
• Фасад: спростіть складні сторонні бібліотеки, надавши більш простий інтерфейс, щоб згодом полегшити ваше життя.
• Легка вага: зберігайте спільні аспекти NPC (наприклад, моделі, текстури, анімації) окремо від окремих аспектів (наприклад, положення, здоров'я) переважно прозорим способом
• Проксі: Створіть невеликі класи на клієнті, які представляють великі, складніші класи на сервері, і переадресація запитів через мережу.
• Ланцюг відповідальності: обробляти введення як ланцюжок обробників, наприклад. глобальні клавіші (наприклад, для знімків екрана), потім графічний інтерфейс (наприклад, якщо текстове поле зосереджене або меню вгору), то гра (наприклад, для переміщення персонажа)
• Команда: інкапсулюйте функціонал гри як команди, які можна вводити в консоль, зберігати та відтворювати або навіть сценарій, щоб допомогти перевірити гру
• Посередник: реалізовуйте ігрові сутності як невеликий посередницький клас, який працює на різних компонентах (наприклад, читання з компонента здоров’я для передачі даних в компонент AI)
• Спостерігач: пропонуйте зображувальне зображення персонажа слухати події з логічного подання, щоб змінити візуальну презентацію, коли це необхідно, без логіки гри, нічого необхідного знати про код візуалізації
• Держава: зберігайте NPI AI як один із кількох станів, наприклад. Напади, блукання, втечі. Кожен може мати власний метод update () та будь-які інші необхідні йому дані (наприклад, зберігання того, якого персонажа атакує чи втікає з нього, області, в якій він блукає тощо).
• Стратегія: переключіться між різною евристикою для пошуку A *, залежно від того, на якій місцевості ви перебуваєте, або, можливо, навіть використовувати один і той же A * фреймворк, щоб зробити як обхід маршрутів, так і більш загальне планування
• Метод шаблону: встановіть загальний порядок «бойових дій» з різними функціями гака для обробки кожного кроку, наприклад. зменшення боєприпасів, обчислення шансу удару, вирішення удару або пропуску, обчислення шкоди, і кожен тип навичок атаки реалізує методи по-своєму.

Деякі зразки залишилися через відсутність натхнення.

Я написав книгу саме на цю тему: Шаблони ігрового програмування . Розділи, які там є, можуть бути корисними для вас.

Одне, що Брендон Ейх мав гарний сенс виховувати в програмі Coders на роботі, - це те, що шаблони - це хакі та обхідні шляхи: [Шаблони] показують певний дефект мови. Ці візерунки не є безкоштовними. Безкоштовного обіду немає. Тож нам слід шукати еволюцію в мові, яка додає правильних шматочків.

Як ігрові програмісти, а не дизайнери-компілятори, ми рідко отримуємо можливість розвивати мови, якими ми користуємось, але можемо навчитися розвивати власний стиль, щоб краще відповідати нашій мові та вимогам. Шаблони є деяким із цього, але не використання шаблонів є іншою частиною, тим більше, що, як каже Брендон, шаблони рідко обходяться без помітних витрат на продуктивність чи пам'ять чи коди. MVC просто не чудовий зразок для багатьох речей в іграх. Singleton - це вирішення для кульгавих правил статичної ініціалізації C ++, і ви, мабуть, не повинні цього робити. Фабрика спрощує створення складних об'єктів - можливо, ваші об'єкти повинні бути просто простішими для початку. Популярні зразки - це інструменти, до яких можна вдатися, коли вони нам потрібні щоб керувати чимось складним, а не інструментами, які нам слід прагнути використати, щоб побудувати щось складне на початку.

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

Звичайно, як говорили інші, всі моделі корисні в правильних обставинах, і частина навчання, як ними користуватися, - це навчання, коли ними користуватися. Однак у чудовій книзі Основні методи та алгоритми ігрового програмування Даніеля Санчеса-Креспо Далама перелічено шість моделей програмування та шість моделей зручності використання, як особливо корисні в програмуванні ігор.

Програмування:

• Сінглтон: Я не ненавиджу цього, як це роблять багато людей; його можна використовувати для таких речей, як плеєр для одного гравця або зчитувач клавіатури.
• Фабрика: Дозволяє ефективно створювати та знищувати об'єкти.
• Стратегія: Дозволяє елегантно змінювати стратегії AI.
• Просторовий індекс: допомагає виконувати запити на наборах просторових даних.
• Композит: Встановлює корисну ієрархію об'єкта.
• Легкий вага: звільняє пам’ять, генеруючи речі, як ідентичні вороги.

Корисність:

• Щит: захищає від випадкового активізації драматичних дій.
• Стан: Візуальний підказки світу / статус інтерфейсу користувача.
• Скасування автоматичного режиму: Робить гру більш наочною.
• Магнетизм: Автонаправлення та простий вибір блоку.
• Фокус: Усунення відволікаючих елементів інтерфейсу користувача
• Хід роботи: Універсально корисний.

Книга, звичайно, детальніше описується щодо кожного з них.

Системи сутності є приємним видом. Це не зовсім модель дизайну, оскільки це не строко OOP. Однак ви можете змішати його з OOP.

Кілька хороших посилань (початок зверху для введення):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

Усі. За винятком Сінглтона. [/ фліппанство]

Не дуже про закономірності, а про основні принципи, що стоять за ними У "Шаблонах дизайну: елементи багаторазового використання об'єктно-орієнтованого програмного забезпечення" (1995) банда з чотирьох (Гамма, Еріх; Річард Гельм, Ральф Джонсон та Джон Вліссайдс) рекомендує лише два принципи для об'єктно-орієнтованого дизайну: (1) програма для інтерфейс, а не реалізація та (2) перевагу композиції об’єктів над успадкуванням класів.

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

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

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

Наприклад, ви можете використовувати це під час компіляції класів для декількох платформ або двигунів (dx проти opengl), де дисперсія типу відома під час компіляції.

Шаблон дизайну, який я розвивався протягом багатьох років і який був для мене надзвичайно корисним, - це те, що я називаю "посередницькими наборами визначення"; як узагальнити його в термінах GOF видається суперечливим, але це запитання, про яке я писав про нього на StackOverflow, вникає в нього детально.

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