Ваш вопрос действительно широк из-за огромного количества жанров, но вот точка зрения профессионального разработчика программного обеспечения.
Вы предоставили список критериев, которые вы хотите использовать, чтобы определить, какой механизм сохранения данных вы используете. Это были:
- Размер проекта.
- Платформа, на которую ориентирована игра.
- Сложность структуры данных.
- Переносимость данных среди многих проектов.
- Как часто следует обращаться к данным
- Несколько типов данных для одного приложения
- Любой другой момент, который вы считаете интересным при принятии решения о том, что использовать.
Сначала нам нужно установить, какие варианты доступны для нас. Поскольку вы не указали язык или технологию, сложно сказать точно, но вы, вероятно, пытаетесь выбрать между XML и хранилищем реляционных баз данных.
Важное отличие заключается в том, что XML на самом деле не столько механизм хранения, сколько метод сериализации. Это способ представления структур в памяти для вашей игры. Учитывая это, вы действительно говорите о хранении плоских файлов и реляционных баз данных. Это не единственные варианты, но они наиболее распространенные, поэтому я собираюсь их использовать.
Для плоских файлов:
- XML
- JSON
- YAML
- XAML
- Простой текст
Для баз данных:
- SQL Server
- MySQL
- DB2
- оракул
- Многое другое
РЕДАКТИРОВАТЬ: Вы спрашивали о других типах механизмов, кроме файлов и реляционных баз данных. Единственный известный тип базы данных, который я видел, используется на регулярной основе - это базы данных в стиле Беркли, которые, по сути, основаны на значениях ключей. Они обычно используют B-деревья для структурирования данных, поэтому поиск выполняется быстро. Они отлично подходят для поиска конфигурации / настройки, когда вы точно знаете, чего хотите (например, предоставьте мне все данные телеметрии для «Уровня 1»).
Теперь, когда у нас есть все основы, давайте коснемся некоторых ваших критериев.
Размер проекта.
Некоторые могут не согласиться, но размер вашего проекта не обязательно окажет огромное влияние на ваш механизм сохранения данных. Вы захотите создать библиотеку функций многократного использования, которая будет хранить / загружать данные из любого механизма, который вы захотите. Я бы даже предложил реализовать слой абстракции (см. Шаблон адаптера ), чтобы вы могли легко изменить свой механизм персистентности, если вам это нужно.
Тем не менее, для небольших проектов использование XML в файловой системе потенциально может работать хорошо, но вы захотите решить некоторые проблемы безопасности (например, шифрование), чтобы игроки не могли изменять данные по своему желанию.
Платформа, на которую ориентирована игра.
Платформа тоже не станет большой проблемой. Вы должны больше заботиться о своей платформе разработки, чем целевой платформе. Причина этого заключается в том, что некоторые языки обрабатывают определенные типы разметки или базы данных лучше, чем другие из коробки. Это не значит, что вы не можете использовать ни одно из вышеперечисленного практически на любом языке, но иногда лучше использовать поддерживаемые инструменты, которые вам доступны. Любая платформа будет поддерживать простые файлы и анализировать XML, но на мобильных платформах вы можете рассмотреть возможность двоичной сериализации, если это возможно, или, по крайней мере, оптимизировать ваш XML для хранения.
Сложность структуры данных.
Это довольно сложно. Реляционные базы данных отлично подходят для хранения сущностей и их отношений. У вас больше возможностей для принудительного применения структуры с использованием реляционного хранилища, чем у файлов в файловой системе. Подумайте о типах отношений между вашими сущностями, а также о том, как часто вы меняете их или находите связанные сущности. Для чрезвычайно сложных структур я бы предложил пойти по маршруту базы данных.
Переносимость данных среди многих проектов.
Когда дело доходит до переносимости, вы должны учитывать тот факт, что базы данных, естественно, более тяжелые, чем файлы. Затраты на установку и настройку, разные базы данных будут доступны для разных платформ и т. Д. SQLite - неплохой способ обойти это. Однако, когда дело доходит до переносимости, вам, скорее всего, будет легче с решениями на основе файлов, такими как XML.
РЕДАКТИРОВАТЬ: Есть некоторые другие проблемы, которые вы упомянули о переносимости в одном из ваших комментариев. В конечном итоге вы не хотите, чтобы ваши данные были слишком тесно связаны с каким-либо продуктом или типом файла. В конечном счете, лучше всего, если вы можете хранить данные о запасах (уровни, враги и т. Д.) В каком-то абстрактном формате (файлы с разделителями табуляции, XML и т. Д.), Которые можно легко анализировать и хранить в базе данных / файловой системе при компиляции или загрузке. время. Это означает, что вы можете по своему усмотрению поменять механизм хранения и просто переписать часть анализа.
Как часто следует обращаться к данным
Много доступа к данным означает много операций ввода-вывода, если у вас нет какого-либо механизма кэширования. Базы данных хранят структуры в памяти и отлично подходят для манипулирования данными и их поиска. Если вы действительно постоянно сохраняете данные, вы можете придерживаться базы данных.
Несколько типов данных для одного приложения
Объем, безусловно, учитывается, но если вы не говорите о сохранении тысяч или миллионов объектов, файловая система все равно будет приемлемым решением.
Тип игры
Тип создаваемой вами игры может оказать огромное влияние на выбранную вами платформу. Да, для большинства однопользовательских игр только для клиентов вам будет хорошо, если использовать решение на основе сжатой или зашифрованной файловой системы. Если вы говорите об играх с онлайн-компонентом, это было бы безумием. Пройдите маршрут базы данных и избавьте себя от головной боли. Позвольте серверу управлять всеми вашими данными с помощью внутреннего кластера.
Надеюсь, что некоторые из этих отзывов помогут. Он ни в коем случае не является полностью исчерпывающим, и принятие решения в конечном счете зависит от вас, но мой комментарий должен дать вам некоторые соображения.
РЕДАКТИРОВАТЬ: Есть несколько случаев, когда принятие гибридного подхода имеет большой смысл. Например, допустим, вы разрабатываете MMORPG. На стороне клиента вы можете хранить кэшированные данные о других игроках в нереляционной базе данных (как упомянуто выше). На стороне сервера вы храните все игровые данные в реляционной базе данных, чтобы сохранить их. С другой стороны, на стороне клиента вы, вероятно, храните данные журнала, данные конфигурации и т. Д. В XML / плоских файлах для облегчения доступа.
Другой автор также упомянул, что иногда хорошо, даже если вы храните данные для производства в базе данных, чтобы иметь возможность использовать плоские файлы для разработки вместо этого ... может быть проще удалить другой продукт из смеси ,