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

11

Я видел много игр, которые определяют компоненты сущностей в файлах сценариев, но когда они настраивают каждую сущность и указывают, какие компоненты у нее есть, они используют какой-то другой формат файла (например, 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
        }
    }
}

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

Пол Манта
источник

Ответы:

13

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

Дейв Шерохман
источник
Это может быть достигнуто простым наличием двух файлов (эквивалентных .h и затем .cpp). Я действительно задаюсь вопросом, кто был бы человеком, который хотел бы создать объект (помимо того, что он говорит, что ничего не делает, выглядит как ваза, а это ничего не делает, как маслянистый), который также не хотел бы добавлять в него некоторую логику (например, Если человек покрыт пыльцой с цветов в вазе, привлекают бабочку). Удобочитаемость для человека великолепна, и одна из моих мыслей о том, почему это так, но опять же я перехожу к тому, что JSON, таблицы Lua и XML имеют одинаковый уровень удобочитаемости для людей, не являющихся программистами.
Джеймс
2
Glest - это игра, созданная с использованием XML. Многие непрограммисты делают моды для этого. Определенно более приемлемо иметь xml / json, чем скрипт.
Будет
6

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

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

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

Будет
источник
5
В те времена, когда разработка основного программного обеспечения была лучше, это было известно как Принцип Наименьшей Мощности : в настоящее время мы должны оценить причины выбора не самого мощного, но наименее мощного решения. Причина этого в том, что чем менее мощный язык, тем больше вы можете делать с данными, хранящимися на этом языке.
1
@Joe Это на самом деле описывает довольно хорошо одна из причин , почему я использую этот подход. Сначала я пытался настроить свои сущности в скриптах, но мне было трудно реализовать save-игры (не мог отслеживать отношения между компонентами). Использование внешнего файла конфигурации помогает мне много.
Пол Manta
Я на самом деле вижу это как раз наоборот: если вы уже используете интерфейс сценариев, то теперь вам также нужно предоставить метод проверки данных для файла конфигурации вместо того, чтобы использовать уже определенный интерфейс сценариев, чтобы сделать это за вас.
Джеймс
2

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

Мартин Sojka
источник
1

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

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

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

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

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

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

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

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

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

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

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

Кристофер Ларсен
источник
2
Скрипты также являются данными по большинству определений
Will
1
-1. Вопрос не в данных и жестком коде, а в динамических сценариях и статических декларациях.
@ Кристофер Я добавил длинный ответ в свой ОП. Пожалуйста, проверьте это.
Пол Манта
0

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

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

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

Джеймс
источник