Где хранить игровые данные в мобильной игре под андроид, сделанной на Unity?
Игра достаточно простая. Если попытаться описать её кратко, то это фентези РПГ-квест, то есть минимум картинок, анимаций и прочего (потому что в команде художника нету). Повествование истории будет происходить текстом, но основа игры будет похожа на Мир теней и ей подобные.
Проблема возникла вот в чем. Как хранить данные игры? В частности описание заданий, предметов, способностей, а также характеристики каждого этого, так сказать "явления". Ведь всего этого будет много, раз мы не можем потянуть в графику Игра делается на Unity.
Для чего-то сложнее тетриса надо(!) юзать редактор игровых данных. Либо самописный на таблицах экселя|google spreadsheet|scriptable object, либо готовый менеджер. В 2018 году менеджить игровые данные в SQL, XML это наркомания.
EVGENY T., Хм. Я не знаю процесс разработки игр, поэтому не понимаю как связаны игровые данные, SQL/XML и дизайнеры.
Т.е. в моём разработческом мире, игровые данные, это просто данные. И хранить их нужно в месте, предусмотренном для этого. Это либо системы хранения (для доступа к которым нужен SQL), либо файлы (и тут xml как способ хранения). Но как в этой логике крутятся рисовальщики (дизайнеры), не понимаю.
Семён Семёнов, выше EVGENY T. уже ответил. Добавлю еще то что в большом XML файле довольно легко сделать ошибку. Он ОЧЕНЬ избыточен по синтаксису.
По SQL это система управления данными. добавление/изменение/удаление/поиск и моделирование. Из всего этого набора функционала при запуске игры нужна только загрузка всех данных. Но ради этого придётся поднять инстанс БД в своем процессе или в чужом, подключиться к нему, сделать запросы на эти данные. Это очень затратно + дополнительные зависимости (тащить клиент или embedded версию СУБД). Неопытные разработчики тянут знакомые решения туда, где они ограничено применимы.
Управлять данными в помощью SQL СУБД можно, и потом выгружать в какой либо простой формат, идеально если в бинарный. Вопрос только найдете ли вы удобные и доступные по цене инструменты взаимодействия с этой СУБД. Такие чтобы все гейм-дизайнеры/программисты могли их установить на свои Маки/Линуксы и достучаться до общего сервера. И придётся самому писать экспорт/импорт этих данных и генерацию кода для них.
Сейвы на клиенте лучше всего делать сериализацией в scheme-less формат (BSON, JSON, MessagePack, YAML) на файловую систему. С сейвами проблема в постоянном изменении схемы и миграции между этими изменениями. С самоописываемыми форматами проще мигрировать: можно попробовать загрузить "как-есть", что замапилось то и замапилось. Можно загрузить как динамические данные и попытаться по известным процедурам "сконвертировать" в новую схему, а потом уже замапить на классы. С форматами имеющими схему не так просто, надо знать все предыдущие схемы (иногда набор старых классов для этих схем). Ведь апдейт игры может быть с любой версии, хоть с самой первой.
