Дизайн игрового движка и данных

Я слышал о проекте, ориентированном на данные, и некоторое время изучал его. Итак, я прочитал несколько статей, чтобы получить концепции.

Одна из статей Data Driven Design, написанная Кайлом Уилсоном. Как он описал, мне кажется, что код приложения (т.е. Код для управления такими ресурсами, как память, сеть...) и код логической игры должен быть отделен, а код логики игры должен управляться внешними источниками данных. На данный момент я могу представить, что разработчик напишет какой-то редактор игр, который принимает внешние данные о игровых объектах (таких как информация о символах, информация о оружии, информация о карте...). Конструкция сценария будет написана с помощью пользовательского языка/инструмента, написанного программистом, чтобы позволить игровому дизайнеру взаимодействовать между игровыми объектами. Разработчик игры либо использует существующий/настраиваемый язык сценариев для записи script для игры, либо инструмент перетаскивания для создания игрового мира. Пример инструментального подхода, о котором я могу думать, - это World Editor, который обычно упаковывается вместе с играми Bliizard.

Однако другая статья противоречит использованию Data Driven Design, "Дело против данных, управляемых дизайном" . Автор предлагает не позволять игровому дизайну управлять данными, потому что для разработки игры потребуется больше времени, так как разработчик игр несет бремя программирования. Вместо этого, будет программист игры, чтобы запрограммировать игру свободно из эскизного дизайна и проверен разработчиком игры после завершения игрового программирования. Он называет это программистом. То, что я думаю об этом методе, похоже на то, как я это делал: логика игры - это само приложение, как и в вышеупомянутой идее, приложение - это редактор игр, а настоящая игра разработана на основе инструмента.

Для меня первый метод кажется более разумным, поскольку игровые компоненты могут использоваться повторно для многих проектов. Со вторым методом, который противопоставляет проектированию, управляемому данными, игровой код принадлежит только этой игре. Вот почему я считаю, что Warcraft имеет в нем столько жанров, как оригинальная Warcraft и различные пользовательские карты, и одна из самых известных: DOTA, которая фактически определяет новый жанр. По этой причине я слышал, как люди называют World Editor игровым движком. Это правда, как игровой движок должен быть?

Итак, после всего этого, я просто хочу проверить, есть ли какой-либо недостаток в моем понимании этих идей (управляемый данными, диск программиста, сценарии и т.д.)?

Ответ 1

Будут разные мнения, люди предпочитают разные подходы. Не существует правильного. Вы понимаете подходы правильно.

My defenition для Game Engine будет: - Библиотека времени выполнения с различными менеджерами, такими как вы говорите ресурсы, память, сеть - Инструменты (редактор, конвертеры, инструменты для упаковки и т.д.)

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

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

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

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

Вы должны весить плюсы и минусы в зависимости от ваших потребностей и бюджета времени.

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

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

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