В чем разница между игровым каркасом и игровым движком?

В чем разница между игровой средой (например, XNA с C #, SDL для c ++) и игровым движком?

Используют ли игровые рамки движки? Содержит ли игровой движок вспомогательные движки, такие как физические движки, движки частиц и т. Д.? Должны ли они использоваться вместе или они являются взаимоисключающими?

Я так понимаю, есть отдельные движки как для 2D, так и для 3D?

Там действительно нет строгих определений для «двигателя» или «рамки».

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

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

Могут быть «движки» или «фреймворки» для чего угодно - физики, звука и, да, даже 2D или 3D графики.

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

Простое определение, которое я использую: вы можете создать движок на фреймворке, но вы никогда не построите фреймворк на движке. Один - это скелет, который определяет архитектуру и ход программы, другой - мускул, который выполняет работу.

В качестве конкретного примера, Artemis - это аккуратный маленький фреймворк для построения систем компонентов, но вы бы никогда не назвали его движком. Вы можете создать Artemis Systems и стандартные компоненты для создания движка из него.

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

Пример: движок позволяет вам иметь список объектов, каждый из которых имеет свою позицию на карте. Каркас позволяет визуализировать 3D-объект в определенной позиции.

Таким образом, вы соединяете их, давая каждой из ваших сущностей трехмерный объект, и визуализируете их при необходимости.

И тада, у тебя есть игра.

Для действительно подробного объяснения я рекомендую прочитать одну-единственную Библию Game Engine Architecture от Jason Gregory. Я думаю, что это самая полная работа по этой теме, так как она была опубликована. Он не только обрабатывает часть C ++, но также и важен для каждого программиста игрового движка теорию / архитектуру. Это хорошая отправная точка, независимая от языка. Чтобы получить общее представление о том, что мы говорим, это изображение из книги

Позвольте мне попробовать ответить на вопрос.

Что бы вы ни написали, это будет код :-) после многолетнего опыта напишите, что вам нужно и как вам это нужно, или используйте то, что дает вам то, что вам нужно.

Термины « двигатель» и « фреймворк» происходят от архитектуры программного обеспечения вместе с другими терминами. Итак, давайте начнем с основных терминов и давайте двигаться вверх.

Библиотека

Типичные примеры: математическая библиотека, предоставляющая все основные типы и функции для математических вычислений (Vector, Matrix, ...) или библиотека изображений (jpeg или png), обеспечивающая функциональность для записи изображений в формате jpeg или png

В Unity 3D Math есть математическая библиотека.

Теория: библиотека предоставляет специальные функции по теме (например, по математике) и вызывается программистом по требованию .

Предварительный просмотр: могут быть библиотеки, содержащие фреймворки, иначе говоря, библиотеки фреймворков.

Фреймворк

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

Типичный пример: Unity 3D MonoBehaviour предоставляет такие методы, как Awake, Start, OnUpdate. Разработчик реализует эти методы, и затем эти методы вызываются средой (управление игровым объектом) (это инверсия управления) . То же самое с методами OnCollisionEnter, OnCollisionExit. Они находятся в том же Monobehaviour, но я держал бы пари, что они вызваны структурой физики.

Предварительный просмотр: Engine, Runtime, Editor, SDK

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

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

Редактор понятен. Это позволяет вам определять предопределенные данные, загруженные двигателем / временем выполнения.

Движок с редактором назывался SDK (например, Hammer SDK).

Тогда были / являются выделенными двигателями. Движок phyiscs, движок рендеринга, звуковой движок, движок управления игровыми объектами, сетевой движок, ....

По моему личному мнению, это не движки (особенно движок рендеринга НЕ является игровым движком, так как он делает только рендеринг). Когда я запускаю игровой движок Google, результаты содержат 90% движков рендеринга, которые не являются игровыми движками. Я бы назвал все эти библиотеки библиотеками, но, поскольку они могут загружать предопределенные данные, они будут соответствовать термину механизм, управляемый данными.

Последнее короткое примечание, прежде чем мы углубимся в детали: я успешно окончил магистратуру по информатике. Моя магистерская работа была посвящена теме «Как разработать ядро ​​игрового движка». Имеется в виду часть кода, которая объединяет все остальные движки, управляет игровыми объектами, игровым циклом и т. Д.

Я опубликовал свою магистерскую диссертацию в виде (короткой) книги. Единственный комментарий на Amazon от покупателя / читателя (после нескольких лет): это не игровой движок. Поскольку я успешно закончил и поэтому защитил свою диссертацию против 3 опытных программистов (2 из них посвящены играм и интерактивным приложениям), я думаю, что я написал игровой движок.

редактор

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

Это то, что делает редактор Unity 3D.

время выполнения

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

Среда выполнения выполняет сгенерированные данные и делает то, что имеет отношение к данным. Например, покажет вам игру и позволит вам играть в нее. Он не создает никаких данных (за исключением, возможно, сохранения игр) в том смысле, что вы не можете изменять саму игру.

Unity Web Player - это / была среда выполнения, позволяющая играть в игры Unity в веб-браузере.

Вы можете загружать и запускать несколько разных игр с одинаковым временем выполнения.

В случае API сценариев Unity 3D существует разрыв между функциональностью, которая будет работать в игре, и функциональностью, которая будет работать только в редакторе.

SDK

Этот термин часто также называют структурой .

В то время SDK был набором инструментов, таких как редактор, IDE (интегрированная среда разработки) для программистов, экспортеры для форматов данных и среда выполнения / движок.

Таким образом, SDK / framework предоставляет вам предопределенный рабочий процесс и утилиты и показывает (хорошо продуманный) способ, которым вы можете (легко) создать игру.

По сути, движок Unity 3D был бы неправильным, поскольку он больше подходил бы для направления SDK. Но поскольку Unity еще больше, требуется новое слово / определение, чтобы соответствовать тому, что оно есть.

В любом случае, чтобы ввести другой термин, SDK / framework предоставляет вам предопределенный конвейер разработки игр (не только конвейер ресурсов, но, может быть, как Unity, конвейер для ресурсов, логики, сборок, развертываний и т. Д.)

двигатель

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

Давайте запустим это:

Двигатель

1. это кусок кода / программного обеспечения
2. он предназначен для повторного использования в нескольких проектах (вы также можете написать игровой движок только для одной игры)
3. для повторного использования игровой движок отделяет повторно используемую часть от специфической для игры части
4. для возможности повторного использования (в зависимости от того, как он предназначен для повторного использования) существуют различные разновидности, такие как механизм на основе данных, загружающий внешние данные

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

• движок рендеринга, выполняющий рендеринг (СНОВА: бог, черт, ад: код, выполняющий только рендеринг, НЕ является игровым движком)
• физический движок, выполняющий физику (это физический движок, а не игровой движок)
• движок ИИ, работающий с ИИ (это движок ИИ, а не игровой движок)
• сетевой движок (например, RakNet), выполняющий сетевые операции (это сетевой движок, а не игровой движок)
• звуковой движок, выполняющий аудиообработка (это звуковой движок, а не игровой движок)

Пример для приложения, основанного на ядре, предоставляющего платформу на основе плагинов для объединения всего в модели управления игровыми объектами на основе компонентов. Каждый подсистема (рендеринг аудио) представляет собой модуль, добавляемый в игровой движок в виде подключаемого модуля. Каждый компонент может быть частью подсистемы / модуля. И (на основе компонентов) управление игровыми объектами является связующим звеном между отдельными модулями.

Ближайшее определение для Game Engine

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

Движок игры - беспорядок в середине.

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

Фреймворк содержит базовую абстракцию API для работы, предоставляя пользователю инструменты более высокого уровня для взаимодействия с платформой или функциональностью, не беспокоясь о производительности, совместимости и т. Д. В приведенных вами примерах SDL - это фреймворк, он дает вы отстранены от работы над платформой и можете создавать свое программное обеспечение за этим уровнем, не беспокоясь об управлении окнами, специфических для ОС вещах и т. д. Если вы хотите создать целое программное обеспечение, вам потребуются различные платформы, например SDL для управления мультимедиа и платформы, Box2D для управления физикой и т. д.

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