Как сохранить и загрузить файлы конфигурации пользователя для игры на C ++?

Question

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

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

В сторону - я думал об использовании сценариев для определения таких вещей, как элементы, но лучше ли будет язык разметки, такой как xml, или язык сценариев (например, angelscript, который я использую)?

Answer 1

Я использую Lua, который имеет небольшой вес и хорошо работает в качестве языка конфигурации . Шли годы, я все больше и больше переходил к сценариям Lua, пока все, кроме основного движка, не было закодировано в Lua. На последней итерации даже игровая динамика закодирована в Lua с помощью обратных вызовов с очень небольшим снижением производительности. Я не говорю, что должен сделать это, но Lua позволит вам расти и его очень легко реализовать на c / c ++.

Answer 2

Буферы протокола Google

Я думаю, что существует давняя путаница между сериализацией и сообщениями .

Сериализация

Обычно недолговечен и включает в себя обход объектов.

Как указано в статье, COM и CORBA являются хорошо известными примерами его использования.

Сообщения

о связи между различными сущностями.

---

Проблема в том, что многие люди, когда видят проблему с сообщениями, просто думают: сериализуйте и покончите с этим.

Но это не адаптировано.

Сериализация объекта означает способность «кодировать» объект и восстанавливать его ... что произойдет, если вы внезапно изменили свой путь, и каким был один объект, теперь 2, как вы справляетесь с обратной совместимостью?

Проблема здесь в том, что если сериализация работает очень хорошо с стабильной моделью, любое изменение модели может быть проблемой.

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

---

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

Я предлагаю Google Protocol Buffers, потому что это нормально и проверено.

1. Прямая и обратная совместимость легко обрабатываются
2. Может генерировать либо читабельный, либо двоичный формат
3. Одно и то же сообщение может быть закодировано / декодировано на разных языках

Мне не нужно представлять, почему 1. важен. 2. означает, что вы можете просто отредактировать файл вручную, чтобы настроить его, 3. означает, что вы можете легко кодировать графический интерфейс или скрипт проверки.

Answer 3

Как насчет создания класса C ++, который представляет вашу конфигурацию, а затем сериализовать его?Посмотрите, например, на повышение сериализации.

http://www.boost.org/doc/libs/1_40_0/libs/serialization/doc/index.html

Answer 4

Вас может заинтересовать Класс сообщений , который является частью моей сетевой библиотеки . Это позволяет вам удобно хранить любые данные, с той или иной иерархией / структурой, которую вы хотите включить. Данные сериализуются в не зависящий от платформы двоичный формат. Существуют API для C, C ++, Java, Python и C #, и их легко использовать.

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

Answer 5

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

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

Я думал об использовании сценариев для определения таких вещей, как элементы, но лучше ли будет язык разметки, такой как xml, или язык сценариев (например, angelscript, который я использую)?

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

Нет единого правильного ответа. Для начала, текстовый / XML формат выглядит хорошо для меня. Но со временем и усложнением игры вам может понадобиться перейти к DSL и двоичной форме.

Answer 6

IniParser - Простой в использовании, стандартный синтаксис ini, C, но тривиально для переноса в классе.

Answer 7

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