Подходит ли Domain Driven Design для игр?

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

Мой текущий шаблон дизайна в Синглтоне, и я хочу сделать некоторую перекодировку, чтобы получить все это. Я никогда не видел DDD на играх (на данный момент), но это хороший подход? Я просто начинающий программист (склонен к разработке игр), поэтому я хочу узнать больше о хорошей архитектуре, прежде чем игра станет слишком раздутой для перепроектирования.

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

Таким образом, мой ответ на это, что это не "хорошо". Обычно это разумная отправная точка, но она оказывается неадекватной по ходу дела. У вас редко есть один домен, но несколько разных доменов в одном программном обеспечении - например, у вас может быть домен игры (мир, персонажи, предметы), домен визуализатора (шейдеры, сетки, материалы), домен ввода (файловая система, сеть, клавиатура и мышь), и проблемы возникают, когда домены перекрываются и влияют друг на друга. Часто в процессе объединения двух доменов вы понимаете, что на самом деле существует зависимость, которая требует изменения, означающего, что одно из ваших представлений становится больше бременем, чем помощью.

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

Лично я очень настороженно отношусь к любому лейблу, который напоминает "Whither-Driven-Design". Программное обеспечение слишком широкое и слишком сложное, чтобы его можно было использовать в одном подходе. Вместо этого, когда я пытаюсь написать лучшее программное обеспечение, которое я могу, я пытаюсь использовать принципы SOLID . Они дают вам хорошее представление о том, насколько хорош ваш код, без обещания панацеи от метода, которому вы можете следовать и волшебным образом получить хороший код. К сожалению, без такой прикрепленной методологии требуется много опыта, прежде чем вы научитесь соответствовать этим рекомендациям, и, вероятно, поэтому многим людям нравятся методологии.

Что касается вашей проблемы с анемичными классами и объектами менеджера, это обычно то, что рассматривается на вводных уроках по ориентации на объекты и на самом деле не требует от вас придерживаться какой-либо специальной методологии, чтобы «исправить» ее. (Возможно, вы захотите взять книгу по объектно-ориентированному программированию, если только начинаете.) Класс - это сочетание состояния и поведения, где поведение изменяет это состояние, и это называется инкапсуляцией. Обычно вы пытаетесь инкапсулировать как можно больше, что означает, что состояние должно управляться самим объектом (и только этим объектом). Только для поведения, которое не может быть смоделировано внутри класса, вы делегируете его внешнему классу, такому как менеджер, поэтому существование классов менеджера часто считается признаком плохо написанного объектно-ориентированного кода.

Мой текущий шаблон дизайна в Синглтоне, и я хочу сделать некоторую перекодировку, чтобы получить все это.

Я не знаю, что вы подразумеваете под этой линией. Шаблон проектирования - это хорошо известный способ написания небольшой части вашей программы. У вас не будет «текущего» шаблона проектирования, и он не будет формировать остальную часть вашей программы. Для новичков эти шаблоны полезны для того, чтобы вы пошли по правильному пути, в то время как для экспертов они больше подходят для общения о типичных ситуациях кода. Однако важно одно: синглтоны - это почти всегда плохая идея, и вам следует избегать их, когда это возможно. Вы можете найти много мнений о синглетонах на этом сайте и более на Stack Overflow, но вот один практический вопрос с ответами, которые помогут вам избежать их использования.

парадигма

На момент написания этого ответа все остальные ответы здесь были неправильными.

Вместо того, чтобы спрашивать, хорош ли доменно-управляемый дизайн для игр. Вы должны спросить, подходит ли «Моделирование домена» для игр.

Хорошо ли моделирование предметной области для игр?

Ответ: иногда это абсолютно невероятно. Однако, если вы создаете игру в реальном времени, такую ​​как платформер или FPS или что-то еще (МНОГИЕ виды игр), то нет. Это не обязательно хорошо подходит для этих систем. Однако в этих играх могут существовать системы, в которых эффективна реализация модели модели предметной области.

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

ВСЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ - это НЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, КОТОРОЕ ВЫ ПИШИТЕ. Некоторые сильно отличаются от других.

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

Игры, которые работают с частотой кадров X с движением и т. Д., Определяемыми дельтами времени как понятиями основной области, вероятно, не очень подходят. В этом случае наш «домен» часто настолько прост, что нет необходимости в моделировании домена. Обнаружение столкновений, порождение новых объектов, влияние сил на существующие объекты и т. Д., Как правило, охватывают большую часть игрового процесса.

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

Модель предметной модели в игровой архитектуре

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

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

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

UI> Сервисный уровень> Модель домена

Короче говоря, в итоге получим модель-представление-контроллер с реализацией сервисного уровня.

Используя эту архитектуру, вы получаете полностью тестируемое игровое ядро ​​(редкость в культуре разработки игр, и это видно) с интерфейсом, управляемым событиями.

Хорошо, теперь, что такое DDD?

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

DDD не очень хорошо справляется, если ваша цель - просто начать программирование, поэкспериментировать с системой, а затем выяснить, что вы хотите построить позже, и т. Д. Предполагается, что существует более или менее домен. Так что, если вы не знаете, какой будет ваша игра ... Тогда она не сработает.

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

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

Да, но вы должны адаптироваться.

При использовании DDD вы получаете модульность и единую ответственность за каждый домен. Но все остальное просто усложняет ситуацию.

Смотрите мой ответ здесь