Як сконструювати ігровий движок на об'єктно-орієнтованій мові? [зачинено]

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

Що таке хороша конструкція і як вона буде реалізована? Які існують компроміси, які слід здійснити, та їх плюси та мінуси?

Я сумніваюся, хтось зможе сказати: "Ви повинні зробити це і те, і це, і ці слоти з тим, використовуючи шаблон X".

Однак деякі корисні ресурси:
Enginuity - серія статей про створення двигунів на Gamedev.net.
Ігрове кодування завершено - у мене є ця книга, і вона добре переглядає кожен (ну, майже) аспект ігрового програмування. Він також має вбудований двигун у всій книзі.
Архітектура ігрових двигунів - це ще одна чудова книга для дизайну двигунів.
Структура двигуна C4 - Згідно з мого коментаря, але це показує високий рівень підгонки кожної частини двигуна разом.

Це може бути трохи занадто багато для того, що вам потрібно, але ви не можете занадто багато знати про щось, і я впевнений, що ви отримаєте від них хороший план.

EDIT: Я забув, що статті Гамедева архівуються з нового сайту, виправлено :)

Як приклад, ось як структурований мій поточний негідний проект (на Java). Він використовує 2D графічний двигун, тому багато коду візуалізації вже подбали про мене. Критика вітається.

class Game
Цей клас встановлює державну машину, яка керує поточним станом гри. (у меню проти початку нової гри проти гри в збережену гру)

interface State
Кожен клас State містить дві петлі: цикл для оновлення логіки та цикл для візуалізації. Вони також містять код для виклику Gameкласу та запиту на зміну в інший стан.

class ResourceManager
Синглтон, який ініціалізується Gameкласом, який завантажує всі необхідні ресурси та дозволяє отримати доступ до них. Мені не подобається ця конструкція, тому що важко завантажувати / вивантажувати ресурси, наприклад, на різних рівнях. Я б, мабуть, спроектував це по-іншому, якби я починав із початку.

class Map
Карта містить масив плиток та список усіх істот та предметів на карті. Це досить базовий клас.

class Creature
Істоти містять інформацію про себе, включаючи обчислення руху (вимагаючи, щоб вони знали, на якій карті вони перебувають, і мати можливість запитувати її, щоб дізнатися про перешкоди). Вирішувати, чи потрібно це робити, чи мати якийсь клас керівника, щоб подбати про це для всіх істот - це те, з чим я борюся.

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

interface UIElement
Я реалізував власний інтерфейс для цього двигуна. Кожен UIElement має цикл візуалізації та логічний цикл. Вони також мають цикл для обробки вводу клавіатури / миші. Усі елементи можуть мати ряд дочірніх елементів, які надаються після їх батьків, і приймають клавіатуру / мишу. Це дозволяє, наприклад, мати меню з підменю.

Першим важливим моментом є те, що на це питання немає жодної «хорошої» відповіді.

Найближчим до правильної відповіді буде щось на кшталт: Це дуже залежить від типу гри, цільової платформи, обмежень (часу) тощо.

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

Мій сучасний дизайн - це гібрид Quake3 / Doom3 і трохи бібліотека класів .NET :)

У мене є дві бібліотеки (статична або динамічна залежить від того, як ви хочете побудувати / доставити) Frameworkі Library.

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

Framework - це кишки 'двигуна', якщо ви хочете його так назвати. Багато з цього випливає з філософій дизайну Quake3 (просто більш об'єктно орієнтованим способом). Він містить CLI , управління тимчасовим часом, специфічний код ОС, а з часом мережеві шари тощо.

Потім ці два пов'язані з фактичним додатком, який виробляється. Game, Якщо ви хочете, який містить код ігр конкретного. Таким же чином Quake3 завантажує DLL, залежно від того, який "мод" відтворюється.

Щоб дати вам уявлення про структуру, тут можна швидко розбити папки та вміст для кожної бібліотеки:

• Рамка
  • IO (Спеціалізовані класи управління файлами, класи друку тексту (наприклад, до CLI) та ведення журналів тощо)
  • Мережа
    • Клієнт (класи, які представляють те, що Рамка вважає "людиною, яка грає / пов'язана з грою")
    • Сервер (класи для управління підключенням до фреймворку та керування програвачем)
  • Платформа (Класифікація клавіатури / миші / контролери, що займаються класами, специфічні для ОС процедури, як getTime ())
  • Система (класи дуже низького рівня, як клас помилок, що сприяє друку повідомлень про помилки, класи часу та самі CLI.)
  • Здійснювач (пояснення)
  • тощо.

• Бібліотека
  
  • Колекції (класи, що представляють колекції даних, пов'язані списки / хештелі тощо)
  • Математика (основні уроки з математики, такі як Вектори та матриці)
  • тощо.

HTH! Потрібно дати вам кілька покажчиків ...

Речі, які слід врахувати

• Об'єктно-орієнтовані мови мають проблеми, оскільки вони зазвичай не мають функцій першого класу або не всі дані є об'єктними (як цілі чи плаваючі в Java). Шаблони дизайну вирішують ці проблеми за допомогою декількох моделей. Як правило, швидше кодувати і легше користуватися мовою, яка може їх робити (об'єкти першого класу); наприклад, Python (який також дозволяє об'єктно-орієнтований дизайн), у вас буде менша швидкість швидкості.
• Обчислення подій, принаймні, на AI
• Логіка Hoare, використовуйте передумови та постумови, щоб принаймні протестувати свій код
• Агенти, подивіться на сутність Quake
• Реляційні бази даних, потужний спосіб зберігання даних

Хороший дизайн

• скласти діаграму ER
• зробити це правильним
• створити з нього базу даних, об'єкти або структури даних

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