Який правильний об’єктно-орієнтований підхід до дизайну класів при розробці гри?

Я в розпалі розробки 2D-спрайтової гри для Windows 7 Phone, використовуючи XNA. Навчальні та навчальні посібники, доступні для цього, дуже корисні, але проблема, з якою я стикаюся, полягає в тому, що кожен з них підходить до свого дизайну класів по-різному, і код не має особливих обставин. В результаті мені складно було добре зрозуміти, які обов'язки я повинен надати певному класу.

Наприклад, я міг би мати базовий клас спрайтів, BaseSpriteякий вміє малювати себе, перевіряти на колізії тощо. Тоді я міг би мати AnimatedSpriteклас, який би знав, як орієнтуватися на його спрайтовому аркуші, ExplodingSpriteкласі тощо. Ця методика демонструється на прикладі Space Invaders у матеріалах Windows 7 Phone Jumpstart Session 2 .

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

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

Який правильний об’єктно-орієнтований підхід до дизайну класів при розробці гри?

Я використовую більш орієнтований на компонент підхід, де у вас був би клас Sprite з такими компонентами, як Visual, Collision, Animation, Input тощо. При такому підході я не маю глибокої ієрархії класів (що добре) .

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

В іграх шаблон компонентів є загальним рішенням.

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

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

Останні кілька проектів я більше схилявся до підходу в стилі MVC.

Спочатку ми не були впевнені, чи це спрацює, але це справно працювало.

Модель

Об'єкти даних. Просто чисті дані. Ні поведінки, ні рендерінгу.

Менеджер даних. Просто обробка "списків" об'єктів даних. (Можна також покращити для підтримки об’єднання.)

Вид

Ми їх називаємо рендерами. Для кожного типу об'єктів даних існує візуалізація. При дзвінку з менеджером він відображатиме всі об'єкти у цьому списку.

Контролер

Те саме, що рендері, але контролює поведінку.

Приклад

У ShipManager є список кораблів. ShipController перемістить кораблі відповідно до їх стану. ShipRenderer видасть кораблі відповідно до їх стану.

Чому?

Таким чином погляд і логіка суворо відокремлені. Це робить перенос на нову платформу досить простим. Оптимізація макета даних всередині XxxManager також дуже проста.