Домен Driven Design хорош для игр?

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

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

9 голосов | спросил Sylpheed 9 +04002011-10-09T21:00:46+04:00312011bEurope/MoscowSun, 09 Oct 2011 21:00:46 +0400 2011, 21:00:46

4 ответа


12

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

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

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

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

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

  

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

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

ответил Kylotan 9 +04002011-10-09T23:49:36+04:00312011bEurope/MoscowSun, 09 Oct 2011 23:49:36 +0400 2011, 23:49:36
5

Paradigm

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

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

Является ли подходящим для игр доменное моделирование?

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

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

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

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

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

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

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

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

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

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

UI> Уровень обслуживания> Модель домена

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

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

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

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

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

ответил Shawn McCool 26 Maypm16 2016, 12:30:52
3

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

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

ответил Nevermind 10 +04002011-10-10T11:15:19+04:00312011bEurope/MoscowMon, 10 Oct 2011 11:15:19 +0400 2011, 11:15:19
-1

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

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

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

ответил b.ben 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 01 Sep 2018 21:05:58 +0300 2018, 21:05:58

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

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

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