Как создать игровой движок на объектно-ориентированном языке? [закрыто]

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

Что такое хороший дизайн и как он будет реализован? Какие компромиссы нужно сделать и их плюсы / минусы?

Я сомневаюсь, что кто-то сможет сказать: «Вы должны сделать то и это, и это, и это, и это слоты с помощью шаблона X».

Тем не менее, некоторые полезные ресурсы:
Enginuity - серия статей по сборке движков на Gamedev.net.
Game Coding Complete - мне принадлежит эта книга, и она хорошо охватывает все (ну, почти) аспекты программирования игр. У этого также есть двигатель, построенный всюду по книге.
Game Engine Architecture - это еще одна замечательная книга по дизайну движков.
Схема двигателя C4 - взято из моего комментария, но это показывает высокоуровневый способ соединения каждой части двигателя вместе.

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

РЕДАКТИРОВАТЬ: я забыл, что статьи Gamedev были в архиве, так как новый сайт, исправлено :)

В качестве примера, вот как структурирован мой текущий roguelike-проект (на Java). Он использует движок 2D-графики, поэтому большая часть кода рендеринга уже была о мне позаботилась. Критика приветствуется.

class Game
Этот класс устанавливает конечный автомат, который управляет текущим состоянием игры. (в меню против запуска новой игры или игры в сохраненную игру)

interface State
Каждый класс State содержит два цикла: цикл обновления логики и цикл рендеринга. Они также содержат код для вызова Gameкласса и запроса изменения в другое состояние.

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

class Map
Карта содержит массив плиток и список всех существ и предметов на карте. Это довольно простой класс.

class Creature
Существа содержат информацию о себе, включая расчеты движения (требуя, чтобы они знали, на какой карте они находятся, и уметь запрашивать ее, чтобы узнать о препятствиях). Решать, делать ли это, или поручить какой-то класс менеджеров позаботиться обо всех существах - это то, с чем я борюсь.

interface AITask
Существа могут иметь список заданий AIT, которые выполняются каждый раз, когда запускается логический цикл существа. AITask имеет свой собственный логический цикл, который выдает команды существу, и условие завершения, которое определяет, была ли задача выполнена успешно или нет.

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

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

Наиболее близким к правильному ответу было бы что-то вроде: это очень сильно зависит от типа игры, целевой платформы, ограничений (времени) и т. Д.

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

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

У меня есть две библиотеки (статическая или динамическая зависит от того, как вы хотите собрать / доставить) Frameworkи Library.

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

Framework - это «двигатель», если вы хотите так его назвать. Многое из этого следует философии дизайна Quake3 (только в более объектно-ориентированном виде). Он содержит CLI , управление синхронизацией, специфический для ОС код и, в конечном итоге, сетевые уровни и т. Д.

Эти два затем связываются с фактическим приложением, которое создается. Game, Если вы хотите, который содержит код игр конкретного. Почти так же, как Quake3 загружает DLL в зависимости от того, какой мод воспроизводится.

Чтобы дать вам представление о структуре, вот краткая разбивка папок и содержимого для каждой библиотеки:

• Фреймворк
  • IO (специализированные классы управления файлами, классы печати текста (например, в CLI), ведения журналов и т. Д.)
  • сеть
    • Клиент (классы, которые представляют то, что Framework считает «человеком, играющим / подключенным к игре»)
    • Сервер (классы для управления соединением в рамках и управления плеером (ами))
  • Платформа (классы обработки клавиатуры / мыши / контроллеров, специфичные для ОС подпрограммы, такие как getTime ())
  • Система (классы очень низкого уровня, такие как класс ошибок, помогающий распечатывать сообщения об ошибках, классы Timing и сам CLI.)
  • Рендерер ( говорит сам за себя)
  • и т.п.

• Библиотека
  
  • Коллекции (классы, которые представляют коллекции данных, связанные списки / хэш-таблицы и т. Д.)
  • Math (базовые вспомогательные классы по математике, такие как векторы и матрицы)
  • и т.п.

НТН! Должен дать вам несколько советов ...

Что нужно учитывать

• У объектно-ориентированных языков есть проблемы, потому что они обычно не имеют функций первого класса или не все данные являются объектами (как целочисленные или с плавающей точкой в ​​Java). Шаблоны проектирования решают эти проблемы с помощью нескольких шаблонов. Как правило, быстрее кодировать и легче поддерживать использование языка, который может их выполнять (объекты первого класса); например, Python (который также позволяет объектно-ориентированное проектирование), вы будете иметь меньшую скорость.
• Исчисление событий, по крайней мере, для ИИ
• Hoare логика, используйте предварительные условия и постусловия, чтобы хотя бы протестировать Ваш код
• Агенты, посмотрите на сущности Quake
• Реляционные базы данных, мощный способ хранения данных

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

• сделать ER диаграмму
• сделать это правильно
• создать свою базу данных, объекты или структуры данных из нее

Данные являются ключом к программированию. Если вы правильно оценили свои данные, из них обычно вырабатываются алгоритмы (если вы не учитываете некоторые числовые алгоритмы, такие как вычислитель).