Каковы некоторые шаблоны проектирования программ, которые полезны в разработке игр? [закрыто]

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

Например, у меня есть книга под названием ActionScript 3 с Design Patterns, в которой представлены несколько шаблонов проектирования, таких как Model View Controller, Singleton, Factory, Command и т. д.

Как кто-то, новичок в этом, я не могу понять, какой из них будет полезен, или на самом деле, если какой-либо из них - это шаблоны проектирования, которые я должен изучать и пытаться использовать. Возможно, есть и другие, более специфичные для игры программирование шаблоны проектирования, о которых я даже не подозреваю?

Если у вас есть опыт использования определенного шаблона дизайна в разработке игр, я бы хотел его услышать. Рассуждая о том, почему он использовался, образцы кода или онлайн-ресурсы будут очень полезны, если они у вас есть. На данный момент я больше всего интересуюсь реализацией ActionScript 3 и C ++, но, безусловно, может извлечь выгоду из опыта и примеров с любого языка.

Спасибо!

122 голоса | спросил 2 revs, 2 users 100%
jcurrie33
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

9 ответов


155

Теперь для менее легкомысленного ответа, с некоторыми предложениями. Не принимайте их в качестве рекомендаций по внедрению, больше как примеры возможного использования.

  • Builder: настроить компонент на основе компонентов на один компонент за один раз на основе данных
  • Заводской метод: создайте виджеты NPC или GUI на основе строки, считанной из файла
  • Прототип: сохраните один общий символ «Elf» с начальными свойствами и создайте экземпляры Elf, клонируя его.
  • Синглтон: это пространство намеренно осталось пустым.
  • Адаптер: добавьте дополнительную стороннюю библиотеку, обернув ее в слой, который похож на ваш существующий код. Очень полезно с DLL.
  • Composite: создать граф сцены визуализируемых объектов или сделать графический интерфейс из дерева виджетов
  • Фасад: упростите сложные сторонние библиотеки, предоставив более простой интерфейс, чтобы облегчить вам жизнь.
  • Вес "мухи": хранить общие аспекты NPC (например, модели, текстуры, анимации) отдельно от отдельных аспектов (например, положение, здоровье) в основном прозрачным способом.
  • Прокси: создайте небольшие классы на клиенте, представляющие более крупные, более сложные классы на сервере, и пересылайте запросы через сеть.
  • Цепь ответственности: вводить ввод как цепочку обработчиков, например. глобальные ключи (например, для снимков экрана), затем графический интерфейс (например, если текстовое поле сфокусировано или меню вверх), то игра (например, для перемещения персонажа)
  • Команда: инкапсулировать функциональность игры как команды, которые можно вводить в консоль, сохранять и воспроизводить, или даже создавать сценарии, чтобы помочь протестировать игру.
  • Посредник: реализует игровые объекты как небольшой класс посредника, который работает с различными компонентами (например, чтение из компонента работоспособности для передачи данных в компонент ИИ).
  • Наблюдатель: иметь визуализированное представление символа, которое прослушивает события из логического представления, чтобы изменить визуальное представление, когда это необходимо, без логики игры, которая должна знать что-либо о рендеринге кода
  • Состояние: хранить NPC AI как одно из нескольких состояний, например. Нападение, Блуждание, Бегство. Каждый может иметь свой собственный метод update () и любые другие данные, которые ему нужны (например, сохранение того, с каким персонажем он атакует или убегает, область, в которой он блуждает, и т. Д.).
  • Стратегия: переключение между различными эвристиками для вашего поиска A *, в зависимости от того, в какой местности вы находитесь, или, возможно, даже для использования одной и той же структуры A * для создания как пути, так и более общего планирования.
  • Метод шаблона: настройте универсальную «боевую» процедуру с различными функциями перехвата для обработки каждого шага, например. уменьшать боеприпасы, вычислять вероятность попадания, разрешать удары или промахи, вычислять урон, а каждый тип умения атаки будет применять методы по-своему.

Некоторые шаблоны остались из-за недостатка вдохновения.

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
53

Я написал книгу именно по этой теме: Шаблоны программирования игр . Главы, которые там могут быть полезны для вас.

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
17

Одна вещь, о которой Брэндон Эйх имел здравый смысл, воспитывать в Coders at Work заключается в том, что шаблоны являются хаками и обходными способами: [Patterns] показывают какой-то дефект в языке. Эти шаблоны не являются бесплатными. Нет бесплатного обеда. Поэтому мы должны искать эволюцию на языке, который добавляет правильные биты.

Как программисты, а не разработчики компиляторов, мы редко получаем возможность развивать языки, которые мы используем, но мы можем научиться развивать наш собственный стиль, чтобы лучше соответствовать нашему языку и требованиям. Шаблоны - это некоторые из них, но не использовать шаблоны - это еще одна часть, тем более, что, как говорит Брэндон, шаблоны редко бывают без заметной производительности, а также из-за нехватки памяти или производительности. MVC просто не является отличным примером для многих вещей в играх. Синглтон является обходным путем для статических правил инициализации хромой C ++, и вы, вероятно, не должны этого делать. Фабрика упрощает создание сложных объектов - возможно, ваши объекты должны быть проще для начала. Популярные шаблоны - это инструменты, чтобы прибегать к , когда они нам нужны , чтобы управлять чем-то сложным, а не инструментами, которые мы должны стремиться использовать для создания чего-то сложного с самого начала.

Хороший (игровой) код может использовать шаблоны, или он может и не быть. Если он использует шаблоны, отлично - они являются отличным инструментом коммуникации для объяснения структуры кода для других программистов на высоком, независимом от языка уровне. Если вы считаете, что код лучше, не используя шаблон, не бить себя над ним - это, вероятно, есть.

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
7

Системы сущностей - хороший вид шаблона. Это не совсем шаблон дизайна, так как это не сложно ООП. Однако вы можете смешивать его с ООП.

Некоторые хорошие ссылки (начало сверху):

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
6
Все они. Кроме Синглтона. [/Легкомыслие]
ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
6

Конечно, как говорили другие, все шаблоны полезны при правильных обстоятельствах, а часть обучения их использованию учится, когда их использовать. Тем не менее, отличная книга Основные методы и алгоритмы в игровом программировании Daniel Sanchez-Crespo Dalmau, перечисляет шесть шаблонов программирования и шесть моделей удобства использования, которые особенно полезны в игровом программировании.

Программирование:

  • Синглтон: Я не ненавижу это, как это делают многие люди; его можно использовать для таких вещей, как однопользовательский плеер или клавиатурный ридер.
  • Factory: позволяет эффективно создавать и уничтожать объекты.
  • Стратегия: позволяет вам легко изменить стратегии AI.
  • Пространственный индекс: помогает выполнять запросы в пространственных наборах данных.
  • Композитный: устанавливает полезную иерархию объектов.
  • Flyweight: освобождает память, генерируя такие вещи, как идентичные враги.

Юзабилити:

  • Щит: защищает от случайной активации драматических действий.
  • Состояние: визуальные подсказки о статусе мира /пользовательского интерфейса.
  • Отмена автоматического режима: делает игру более интуитивно понятной.
  • Магнетизм: автоматическое определение и легкий выбор единиц.
  • Фокус: устранение отвлекающих элементов пользовательского интерфейса.
  • Прогресс: универсально полезен.

В книге, конечно, подробно рассматривается каждый из них.

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
5

Не о моделях, а об основных принципах, стоящих за ними. В «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения» (1995) , банда четырех (Гамма, Эрих, Ричард Хелм, Ральф Джонсон и Джон Влиссидес) рекомендует только два принципа объектно-ориентированного проектирования: (1) для интерфейса, а не для реализации, и (2) поддерживает композицию объекта над наследованием класса.

Эти 2 принципа очень полезны во многих задачах разработки игр. Например, многие игровые программисты использовали иерархию классов для представления игровых объектов. Существует еще один подход, основанный на композиции - игровых объектах на основе компонентов. Статья об этом подходе. Еще больше ссылок . Это образец декоратора .

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
5

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

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

Например, вы можете использовать это при компиляции классов для нескольких платформ или движков (dx vs. opengl), где дисперсия типа известна во время компиляции.

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00
4

Шаблон дизайна, который я развивал в течение многих лет, и который был эффектно полезен для меня, - это то, что я называю «брокером определений»; как обобщить его в терминах GOF, представляется противоречивым, но Этот вопрос, о котором я писал об этом в StackOverflow , подробно рассказывает об этом.

Основная концепция заключается в том, что некоторое свойство модели, подобно виду существа, настроено так, что каждое возможное значение для свойства имеет соответствующий объект определения - единый, общий объект за значение - который указывает его поведение, и к ним обращаются через центральный брокер (который GOF-мудрый может быть реестром, фабрикой или обоими). В моем использовании они также обычно доступны через скалярные ключи, чтобы облегчить слабую привязку для целей морфинга времени выполнения.

ответил coderanger 29 MaramTue, 29 Mar 2011 00:11:00 +04002011-03-29T00:11:00+04:0012 2011, 00:11:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132