Было бы лучше использовать XML / JSON / Text или базу данных для хранения игрового контента?

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

С другой стороны, есть небольшие портативные базы данных, такие как SQLite или Tokyo Cabinet. Хотя эти файлы не являются непосредственно читаемыми человеком, с ними легко взаимодействовать, и я полагаю, что какой-то инструмент редактирования в любом случае предпочтительнее для дизайна игрового контента. Использование БД позволяет последовательно хранить информацию о конфигурации и легко извлекать данные. Вы также можете сериализовать данные в БД для сохранения игр.

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

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

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

JSON очень легок и прост для понимания. Я думаю, что это лучше подходит для игры. cJSON действительно хорош. он также будет включен в ваш источник так же, как SQLlite.

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

Я опоздал на вечеринку здесь, но я потратил много времени на изучение этого.

Во-первых, почему я не использую следующее:

XML: чрезмерно многословный. Тонны избыточности. Повторять имена полей? ВАЛОВОЙ

JSON: Я думаю, что JSON отлично подходит для макета пользовательского интерфейса, но для базы данных, черт возьми, нет. У него будут те же проблемы, что и у XML, избыточность и глубокое вложение. ВАЛОВОЙ.

SQL : это отличный вариант, если вы справляетесь с головной болью при его настройке. Я создал мобильные игры, в которых мы храним игровые данные онлайн в базе данных SQL. Формат таблицы хороший. Проблема заключалась в том, что нам пришлось извлекать базу данных из Интернета и настраивать ее, может быть хлопотно. Но SQL - достойное решение. Unity не поддерживает это изначально, и у плагинов, которые я пробовал, были серьезные проблемы (особенно при попытке заставить его работать с контролем версий).

Наконец, вот решение, которое я решил использовать (и мне это нравится).

CSV : просто. Позволяет мне использовать формат таблицы, и у меня есть одна простая точка отсчета, когда мне нужно ее обновить. У меня может быть таблица для всего моего оружия, столбцы для всех атрибутов и строки для каждого типа оружия.

Вы можете использовать Microsoft Excel, но он выдает эти глупые предупреждения каждый раз, когда вам нужно сохранить. Вы можете использовать макросы, чтобы переопределить его, но я говорю, избавьте себя от проблем и получите LibreOffice . Он бесплатный, поддерживает редактирование CSV, и когда вы открываете файл, он загружает ширину столбца в соответствии с именем (Excel этого не делает, и это сводит меня с ума).

Тогда вам просто нужно проанализировать файлы CSV в вашей игре. Я использую Unity, поэтому все, что мне нужно было сделать, это использовать этот изящный C # CSV-парсер, который я нашел:

Пример парсера CSV

Вы конвертируете файлы CSV в свои объекты игровых данных, и все готово. С Unity вы можете превратить их в ScriptableObjects . Итак, мой рабочий процесс: обновить CSV -> разобрать CSV в объекты Scriptable -> использовать данные из ScriptableObjects для моей игры

Ответ на это зависит от того, какой язык вы используете для игры.

Если вы используете C ++, вам было бы полезно использовать одну из существующих библиотек XML (например, TinyXml или eXpat ).

С другой стороны, если вы используете PHP, вы можете очень легко использовать сервер базы данных, такой как MySQL или SQLite. (Имейте в виду, что если вы пойдете по этому пути, вам потребуется больше ресурсов, потому что сервер базы данных будет работать как отдельный процесс, и более крупные приложения баз данных, такие как MySQL, могут потреблять много оперативной памяти при запуске.)

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

Короче говоря, это зависит от того, что легко использовать на вашем языке.

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

Например, Fast Infoset - это реализация двоичного XML

Можно считать Fast Infoset gzip для XML, хотя FI стремится оптимизировать как размер документа, так и производительность обработки, тогда как gzip оптимизирует только размер. Хотя первоначальное форматирование потеряно, при преобразовании из XML в FI и обратно в XML не теряется информация.

Я занимаюсь проектированием баз данных и играю со многими идеями в течение многих лет. Мой личный фаворит на данный момент, это какой-то текстовый, понятный человеку формат для конфигураций, но затем анализ этих «медленных сценариев» в нечто более работоспособное. Так же, как JAVA и .NET скомпилированы в байт-код времени выполнения.

Та же самая идея идет здесь. У меня есть «исходная» версия компонентов, а затем через них проходит прекомпилятор / парсер. Если они занимают слишком много памяти, вы можете поместить их в какую-нибудь быструю базу данных SQL или сохранить как двоичные файлы. Но я хочу использовать память или базу данных SQL в качестве рабочей области / кэша, чтобы вам не приходилось анализировать сценарии снова и снова. Вы можете создать компилятор, переместить проанализированные файлы в «source-lib» и таким образом позволить прекомпилятору также выполнять управление версиями (сохраняя предыдущие файлы для отката).

Если речь идет о «неограниченном пространстве для жесткого диска», зарегистрируйтесь в Dropbox или Amazon S3 и синхронизируйте их.

Таким образом, план для меня в настоящее время:

1. Config / scripts / xml (некоторый читаемый человеком формат) в виде текстовых файлов (как исходный код)
2. Парсер / валидатор, который запускает новые скрипты и проверяет, что они следуют правилам
3. Компилятор, который делает двоичные или SQL-строки из исходных файлов, чтобы их можно было быстро получить + быстро запустить.

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

Если вы используете couchdb, вы по существу будете сохранять все как структуру JSON. Couchdb будет более или менее безболезненно копировать данные вашего (нескольких) пользователей.

Вы можете найти процедуру в Unity Wiki с PHP, MySQL и C # / JavaScript, и она отлично работает для своей цели.

Состоит из трех шагов

1. Создайте пустую базу данных MySQL и таблицу.
2. Создайте сценарий на стороне сервера PHP (он подключится к таблице MySQL, получит данные из сценария Unity (шаг 3) и запросит базу данных (в приведенных примерах либо вставка данных, либо выбор))
3. Создайте скрипт Unity Controller (он подключится к скрипту PHP, созданному на шаге 2)