Как выбрать, как хранить данные?

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

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

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

Вопрос в следующем: как выбрать тип хранения данных для игрового проекта?

И мне было бы интересно по следующему критерию при выборе:

• Размер проекта.
• Платформа, на которую ориентирована игра, а также используемая платформа разработки.
• Сложность структуры данных.
• Добавлена переносимость данных среди многих проектов.
• Добавлено 2 Разумное использование данных среди разных проектов. (т.е. данные пользователя)
• Добавлено Как часто следует обращаться к данным
• Добавлено несколько типов данных для одного приложения
• Добавлено2 Конфигурация с несколькими хранилищами данных.
• Любой другой момент, который вы считаете интересным при принятии решения о том, что использовать.

РЕДАКТИРОВАТЬ Я знаю о том, было бы лучше использовать XML / JSON / Text или базу данных для хранения игрового контента? , но думал, что это не касается именно моей точки зрения. Теперь, если я ошибаюсь, мне бы показывали ошибку на моем пути.

РЕДАКТИРОВАТЬ2 Добавил еще несколько моментов, которые я бы посчитал актуальными. Кроме того, мне было бы интересно услышать, какие другие варианты доступны, кроме хранения плоских файлов и реляционной базы данных. Как насчет нереляционной базы данных, например? Когда уместно использовать такую ​​базу данных поверх ранее упомянутых других вариантов?

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

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

• Размер проекта.
• Платформа, на которую ориентирована игра.
• Сложность структуры данных.
• Переносимость данных среди многих проектов.
• Как часто следует обращаться к данным
• Несколько типов данных для одного приложения
• Любой другой момент, который вы считаете интересным при принятии решения о том, что использовать.

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

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

Для плоских файлов:

• XML
• JSON
• YAML
• XAML
• Простой текст

Для баз данных:

• SQL Server
• MySQL
• DB2
• оракул
• Многое другое

РЕДАКТИРОВАТЬ: Вы спрашивали о других типах механизмов, кроме файлов и реляционных баз данных. Единственный известный тип базы данных, который я видел, используется на регулярной основе - это базы данных в стиле Беркли, которые, по сути, основаны на значениях ключей. Они обычно используют B-деревья для структурирования данных, поэтому поиск выполняется быстро. Они отлично подходят для поиска конфигурации / настройки, когда вы точно знаете, чего хотите (например, предоставьте мне все данные телеметрии для «Уровня 1»).

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

Размер проекта.

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

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

Платформа, на которую ориентирована игра.

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

Сложность структуры данных.

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

Переносимость данных среди многих проектов.

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

РЕДАКТИРОВАТЬ: Есть некоторые другие проблемы, которые вы упомянули о переносимости в одном из ваших комментариев. В конечном итоге вы не хотите, чтобы ваши данные были слишком тесно связаны с каким-либо продуктом или типом файла. В конечном счете, лучше всего, если вы можете хранить данные о запасах (уровни, враги и т. Д.) В каком-то абстрактном формате (файлы с разделителями табуляции, XML и т. Д.), Которые можно легко анализировать и хранить в базе данных / файловой системе при компиляции или загрузке. время. Это означает, что вы можете по своему усмотрению поменять механизм хранения и просто переписать часть анализа.

Как часто следует обращаться к данным

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

Несколько типов данных для одного приложения

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

Тип игры

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

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

РЕДАКТИРОВАТЬ: Есть несколько случаев, когда принятие гибридного подхода имеет большой смысл. Например, допустим, вы разрабатываете MMORPG. На стороне клиента вы можете хранить кэшированные данные о других игроках в нереляционной базе данных (как упомянуто выше). На стороне сервера вы храните все игровые данные в реляционной базе данных, чтобы сохранить их. С другой стороны, на стороне клиента вы, вероятно, храните данные журнала, данные конфигурации и т. Д. В XML / плоских файлах для облегчения доступа.

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

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

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

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

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

Теперь все это взлом, и я не советую копировать его, но вот в чем суть: не полагайтесь только на одну систему. Используйте реляционную базу данных и выдумайте систему. Или используйте два разных типа систем хранения данных (например, плоский файл и реляционная база данных?), Чтобы вы могли получить максимальную выгоду от обоих. Неважно, что люди предлагают или какую систему вы используете, в дальнейшем вы будете находить обстоятельства, при которых другой подход будет работать лучше, поэтому будьте готовы добавить альтернативу и посмотрите, куда вас это приведет.

В гене RTS игровые данные хранятся в файлах.

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

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

Зачем использовать один метод хранения данных?

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

Вот сравнение некоторых требований к выпуску / разработке: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

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

В одном проекте, над которым я работал много лет назад, загрузка данных уровня с CD заняла слишком много времени (с HD тоже не было ничего хорошего). Итак, я придумал следующее. У меня было три способа загрузки данных уровня:

1. Нормальная загрузка - для времени разработки, когда активы менялись
2. Предварительная версия - эффективный метод для преобразования обычных данных в данные с быстрой загрузкой
3. Release - только быстрые данные (не редактируемые)

Это уменьшило время загрузки с минут до секунд.