Комментарии 17
Чем только люди не занимаются, лишь бы протобафом не пользоваться
Изучать сторонний специализированный инструмент вместо того, чтобы продумать механизм миграций?
Предлагаю решение рядом - хранить данные не в json, а в sqlite.
А как мигрировать данные в БД - куча готовых решений и\или хотя бы у всех больше опыта )
Какая разница, json/sql/реестр windows. Функцию MigrateFrom1_0_To__1_1 кто-то должен написать. Никто кроме автора не знает, чем отличается 1.0 от 1.1. А если функция миграции есть - в чем проблема ее вызвать?
Так автор описал же. Когда json - хочется просто делать сериализацию и десериализацию. Миграции не дают это делать удобно, пришлось прикрутить дополнительную либу к процессу.
А когда у вас БД - то вы в любом случае не можете просто сделать "десериализацию", маппинг сущности на табличку придётся делать сознательно, данные мигрировать - сознательно =)
есть готовые решения а-ля flyway (нз под .net), и мы пишем их на человеческом sql запуская 1 раз и код вообще не знает про все эти нюансы с деприкейтед полями, жизнь легка и проста. Ну т.е. есть возможность и классы написать, но для исключительных ситуаций это необходимо
А знаете какие-нибудь решения для миграции в БД, которые можно к Юнити подключить. Мне в голову только EF/EF Core приходит, но его вряд ли получиться к Юнити подключить, хотя попробовать можно :)
Я юнити никогда не видел в глаза даже, не в курсе.
Если там обычный дотнет - то EF Core должен отлично работать.
Не знаю насчёт Unity (но не вижу причин, почему не должно работать), но можно посмотреть в сторону FluentMigrator.
Разработка игры как правило начинается с полной авторитарности клиента. Если только заранее не известно что 100% будет сервер.
Потому выгодно по времени начать сохранять профиль игрока в локально, а лучший формат - json. БД для этого редко тянется, так же как и ORM'ки как NHibernate и/или EF.
Безусловно, если есть сервер, то это, грубо говоря, не проблема клиентского разработчика.
А так да, sqllite - хорошее решение, но я всего 1 раз встречал их в реальных игровых проектах (из 20-30 к которым так или иначе имел доступ).
Привет. В таком подходе стоит обязать писать тесты со всеми старыми вариантами сигнатур, чтобы легче было вспомнить что вообще ранее было. А еще круче, использовать авто комбинаторику для таких данных, а в тесте делать NUnit.Assume(), чтобы проверить что миграция не отвалится на корнер кейсах.
Так можно делать не только с json, а с любым нетипизированным набором.
Может в геймдеве и правда все так плохо, хз, Сет сомневаюсь. В вебе давно придумали миграции.
И зачем вы вообще что-то такое храните в json? На всех мобильных же есть встроенная БД, если не ошибаюсь SQLite. С миграциями не будет ни проблем, ни костылей.
Миграция json файлов