Unity и хранение данных

Взято с geek-and-poke.com

- Ты знаешь SQL?
- Нет
- …

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

Зачем?

Зачем хранить данные в игре должно быть очевидно, поэтому опишем этот момент кратко.

Аксиома

Игра представляет из себя изменение исходных данных с какой-либо целью.

Исходные данные

Сообщество довольно часто постулирует - путь Unity по созданию исходных данных это подготовка наборов префабов(Prefab), скриптуемых объектов(ScriptableObject), сцен и инструментов для управления ими в редакторе, а конфиги в других видах не нужны.

Данные для сохранения

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

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

Встроенные хранилища

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

Плюсы:

• Очень просто реализовать

Минусы:

• Хранятся в открытом виде
• Не особо быстрые
• Хранятся в странных местах, допустим, на Windows они хранятся в реестре с лимитом в 1Мб на запись, на других платформах другие ограничения.

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

Serialization

Остальные методы требуют сериализации, так что быстренько пробежимся по доступным вариантам:

• Binary - сложно редактировать и обмениваться, но хранить в целом нормально.
• CVS - почему-то это первый ответ на вопрос про базы данных и юнити в гугле от комьюнити... Вы серьёзно?
• XML/JSON - старые добрые форматы, только количество символов разное.
• ProtoBuf like - например, MessagePack или FlatBuffers. Что это такое, с чем это едят, почему не JSON и даже не ProtoBuff вы можете прочитать прямо там, на странице FlatBuffers.

Файлы

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

SQL

Единственным кандидатом будет:

• SQLite - быстрый, простой, проверенный временем, в общем, победивший стандарт.

В Asset Store есть другие варианты, включающие в названии акроним SQL, но очень уж они похожи на обёртки над тем же SQLite. Для облегчения жизни есть ORM решения, например, sqlite-net. Так что если есть необходимость в реляционной базе данных, то смысла искать что-то ещё особо нет.

NoSQL

Благодатная тема последнего десятилетия и благодаря этому можно выделить больше одного решения:

• SQLite - кто может нам запретить использовать её как kv-хранилище?
• iBoxDb - существует давно, заявляется поддержка Unity из коробки, говорят работает.
• LiteDb - в отличие от предыдущего варианта статей по использованию больше и даже таблицы сравнения производительности с файлами и SQLite можно найти, в которых она выглядит очень неплохо. Так же можно взглянуть на нашу статью LiteDB и Unity.

На текущий момент выбор NoSql решений фактически стал стандартом и с трудом можно придумать оправдание не пользоваться ими. Понятно что самым популярным решением тут выглядит SQLite, а остальные не имеют и сотой доли её популярности.

High scalability, high availability enterprise production platform

В последнее время часто мелькает упоминание Realm.io и подобных решений, которые позволяют настроить синхронизацию локальной и внешней баз данных, снимая большу́ю часть работы с разработчиков. К сожалению, сам Realm.io хоть и заявляет о поддержке .Net Standard 2.0, но завестись под Unity последних версий не особо то и желает, так что остаётся ждать, когда их новый владелец в лице MongoDb обратит своё внимание на игровую индустрию.

Альтернативы, на которые стоит обратить внимание:

• Firebase - заявляется о поддержке Unity. В последних версиях появилась поддержка офлайн режима.
• CouchBase - заявляется о поддержке Unity в Mobile версии.

Конечно же, это решения enterprise уровня и задач, для тех кто делает очередной Hearthstone и понимает, зачем оно нужно.

Заключение

С одной стороны, данная статья не должна была дать серебряную пулю, чтобы убить все проекты. С другой стороны, выбор вариантов, которые предлагаются комьюнити не так уж широк и всё по старинке решается на уровне binary/json + file/sqlite. А такое прохладное отношение комьюнити к хранению данных, видимо, объясняется наличием более других узких мест в проектах. Однако если ваша душа жаждет приключений, то можно попробовать LiteDb и FlatBuffers. Я определённо протестирую их, но это будет уже совсем другая статья. Пока! =)

Update: про LiteDB так же можно прочитать нашу новую статью LiteDB и Unity.