Чи хороший дизайн домену для ігор?

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

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

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

Як такий, моя відповідь на це полягає в тому, що це не «добре». Зазвичай це розумна відправна точка, але виявляється недостатньою, коли ви йдете далі. У вас рідко є один домен, але кілька різних доменів у межах одного програмного забезпечення - наприклад, у вас може бути домен гри (світ, персонажі, елементи), домен візуалізації (шейдери, сітки, матеріали), домен введення (файлова система, мережа, клавіатура та миша) та проблеми, коли домени перетинаються та впливають один на одного. Часто під час об'єднання 2 доменів разом, ви розумієте, що насправді існує залежність, яка вимагає змін, тобто одне з ваших уявлень стає більше тягарем, ніж допомогою.

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

Особисто я дуже обережно ставлюсь до будь-якої лейблу, що нагадує "Що б то не було" - Дизайн. Програмне забезпечення є занадто широким і надто складним, щоб існувати єдиний підхід для його створення. Натомість, намагаючись написати найкраще програмне забезпечення, яке я можу, я намагаюся повернутися до принципів SOLID . Вони дають вам гарне уявлення про те, наскільки хороший ваш код, не обіцяючи панацею від методу, який ви можете дотримуватися, і магічним чином дійти до хорошого коду. На жаль, без такої прикріпленої методології потрібно багато досвіду, перш ніж ви навчитеся відповідати цим керівництву, тому, ймовірно, тому так багато людей люблять методики.

Що стосується вашої проблеми з анемічними класами та об'єктами менеджера, це зазвичай те, що охоплюється вступними уроками орієнтації на об'єкти і насправді не вимагає дотримання будь-якої спеціальної методології для її виправлення. (Ви, можливо, захочете взяти книгу про об'єктно-орієнтоване програмування, якщо ви тільки починаєте.) Клас - це сполучення стану та поведінки, де поведінка модифікує цей стан, і це називається інкапсуляцією. Як правило, ви намагаєтеся якомога більше капсулювати, а це означає, що державою слід маніпулювати самим об'єктом (і лише цим об’єктом). Лише для поведінки, яку неможливо моделювати в класі, ви б делегували зовнішній клас, наприклад, менеджер, тому існування класів менеджерів часто вважається ознакою погано написаного об'єктно-орієнтованого коду.

Моя поточна модель дизайну знаходиться в Сінглтоні, і я хочу зробити кілька перекодувань, щоб вийти з цього матеріалу.

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

Парадигма

На момент написання цієї відповіді, інші відповіді, розміщені тут, - все неправильно.

Замість того, щоб запитувати, чи підходить дизайн, керований доменом, чи ні. Слід запитати, чи «Моделювання домену» добре для ігор чи ні.

Чи добре моделювання домену для ігор?

Відповідь: колись це абсолютно казково. Однак якщо ви створюєте гру в режимі реального часу, наприклад платформер або FPS або будь-яку іншу (багато ігор), то ні. Це не обов'язково добре підходить для цих систем. Однак можуть бути системи всередині тих ігор, в яких реалізація моделі доменної моделі є ефективною.

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

ВСЕ ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ НЕ ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ, ЩО ВИ ПИСЕТЕ. Деякі сильно відрізняються від інших.

Деякі приклади доменів, у яких добре працює моделювання доменів, - це карткові ігри, настільні ігри та інші типи систем, керовані подіями.

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

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

Шаблон моделі домену в архітектурах ігор

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

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

Користувальницький інтерфейс надає користувачеві стан гри. Користувач взаємодіє з інтерфейсом користувача, запускаючи команди на рівні обслуговування. Службовий рівень взаємодіє з об’єктами домену. Об'єкти домену підняли події домену. Слухачі подій чують події та викликають зміни в інтерфейсі користувача.

Користувацький інтерфейс> Службовий шар> Модель домену

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

Використовуючи цю архітектуру, ви маєте цілком тестоване ядро ​​ігрового ядра (рідкість в культурі розвитку ігор, і це показано) з інтерфейсом, керованим подією.

Гаразд, що таке DDD?

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

DDD не так добре, якщо ваша мета - просто почати кодування, пограти з системою, а потім з'ясувати, що ви хочете створити пізніше тощо. Це передбачає, що існує більше або менше домену. Отже, якщо ви не знаєте, якою буде ваша гра. Тоді це не спрацює.

Ні, я не думаю, що DDD або будь-яка інша архітектура "buzzword" насправді хороша для ігор. За можливим винятком «компонентної системи», яка здається справді популярною.

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

Так, але ви повинні адаптуватися.

Під час використання DDD ви отримаєте модульність та єдину відповідальність кожного домену. Але все інше просто ускладнює справи.

Дивіться мою відповідь тут