Зачем размещать конфигурацию объекта вне скриптов?

Я видел много игр, которые определяют компоненты сущностей в файлах сценариев, но когда они настраивают каждую сущность и указывают, какие компоненты у нее есть, они используют какой-то другой формат файла (например, XML). Почему они это делают?

Я спрашиваю, в основном, чтобы понять, каково было объяснение других. Я также настраиваю свои сущности вне сценариев (хотя я выбрал JSON, а не XML). Мои причины для этого состоят в том, чтобы мне было проще реализовать сохранение игр, а также потому, что я думаю, что этот тип конфигурации лучше организован в нечто вроде XML или JSON.

@ Кристофер Ларсен ответ: слишком долго, чтобы оставлять комментарии

Боюсь, вы могли немного отклониться от предмета вопроса. Проблемы, которые вы описываете, больше связаны с иерархическими объектами; обратите внимание, в моем вопросе я упомянул, что я говорил о компонентных компонентах.

Вот пример того, что я хотел спросить. Ниже приведены два альтернативных способа настройки объекта: через сценарий и через внешний файл JSON. У меня был вопрос: почему так много людей предпочитают настраивать сущность вне сценариев?

Базовый класс Entity:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

Подход сценария:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

Подход JSON:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

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

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

Одна из причин, по которой я обычно использую конфигурационный файл, а не скрипт для этого:

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

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

Конфигурация объекта может быть просто сериализацией определенного объекта. Это позволяет обрабатывать вывод инструментов редактирования и моддинга игры примерно так же, как при сохранении игры. В частности, для игр, в которых вы не можете предсказать, в каком состоянии данная сущность будет находиться во время сохранения игры - например, из-за их ИИ или потому, что они изначально генерируются частично процедурно - полезно иметь возможность сбрасывать все данные, определяющие, что сущность «есть» (в отличие от того, что она «делает») как поток байтов для сохранения.

Шаблон, который вы описываете, является реализацией управляемой данными системы.

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

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

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

Давайте возьмем пример стереотипного существа "орк" ...

Одним из способов реализации для нашего орка было бы написать полное описание в коде всех характеристик и логики для орка.

• 10 = максимальное количество здоровья
• урон = 3 урона в секунду
• беглый = верно
• Runawaywhen = здоровье <10
• агрессивны = верно

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

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

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

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

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

Чтобы понять, почему люди предпочитают делать это обычно в XML, а затем - в логике, - это имеет смысл, когда вы это говорите. Вот мое определение объекта в данных, что такое хороший формат хранения данных? Это почти всегда XML (хотя я также использую JSON;). И затем, когда они хотят добавить в логику, хорошо, что либо кодируется, либо помещается в файл сценария.

Это не неправильное мышление, но в моих глазах люди просто не идут к следующему шагу. Посмотрите на любой полный язык, c / c ++ / c # ,. Вы можете определить объекты и их логику на одном языке, почему бы не сделать то же самое в вашем интерфейсе сценариев ... Это все равно, что сказать, что мы должны определить наши классы в XML и наши методы в c #, когда вы думаете об этом. Возможно, старые языки сценариев игры были недостаточно мощными, и они все еще держатся так, как это было сделано.