Да, к сожалению у многих так. Не до конца понятно что с игрой. Иногда на идентичных устройствах работает, или не работает. Так до конца и не поняли проблему.
Спасибо за развернутый отзыв. В игре и правда есть неоднозначные моменты вроде тех что вы описали. Некоторые из них просил издатель, некоторые мы родили своим надмозгом :)
По поводу пушей — сам их не люблю, но рынок требует. Необходимое зло так сказать.
Здравствуйте! Вопрос достойный своей маленькой истории, так как вызывал свои особенные, ни с чем не сравнимые муки. Поначалу мы пробовали попользоваться хакинтош машиной, но он работал крайне неудовлетворительно (Возможно виной тому тот факт что устанавливали мы хакинтош на старенький ноут). Как результат прикупили за < 200$ MacBook Pro 2011 года у друга. Ему было не легко, но он таки справляется со своей задачей. Мое мнение — нужно, или любой оригинальный макбук, либо мощный и хорошо совместимый хакинтош. Тут уже зависит от того сколько вы готовы заплатить/потанцевать с бубном.
Да, про него. Он opensource. Единственное что для Unity при работе на il2cpp AOT, там есть проблемы. Я использую этот плагин который по сути является форком с улучшеной совместимостью (Там вообще какая то чихарда с именованиями, так что могу слегка приврать. По крайней мерее там точно есть Newtonsoft.dll). Он так же бесплатный.
Ваш подход возможен, но не очень правилен с точки зрения работы с базой данных. Я чуть выше другому человеку уже коментировал почему не стал так делать. Не буду еще раз дублировать. Но он бы стработал :)
JsonUtility имеют свои ограничения вроде отсутствия сериализации для dictionary, null, свойств, полиморфных типов и кучу других ограничений. Да и по факту это бы никак не повлияло на проблему с преобразованиями внутри фаербейз.
Я хотел, однако firestore на тот момент был в бета тесте. Не хотелось иметь больше проблем. С другой стороны вероятно их было бы меньше. В следующем обязательно firestore.
Сериализация происходит на нашей стороне силами newtonsoft json. На самом деле, это не так проблема, как неожиданность. Когда пишешь массив, ожидаешь считать массив. То есть например массив:
{ new Something(), null, new Something() } после сериализации newtonsoft таки массив. После передачи в firebase и считывания обратно, это уже будет объект:
0: Something
2: Something
Если знать про это поведение, его обыграть не составляет труда.
Я пожалуй не лучший пример привел в статье. Подправлю этот момент.
На самом деле мы именно так и делаем и сериализируем используя newtonsoft.json и записываем через SetRawJson однако, у firebase на этот счёт свои мысли и похоже происходит ещё и преобразование на стороне firebase :)
Про передачу ключ строка не думали так как дальше планируем добавлять возможность для игрока смотреть прогресс друзей из того же facebook и это будет не так удобно в итоге. Ну и бд на то и бд что бы использовать ее как бд :)
Плюс эффективность в трафике. Я не ручаюсь за это, но похоже что исходя из того что я вижу (объем передаваемого трафика), firebase имеет свой протокол который так или иначе уменьшает объем передаваемых данных исходя из структуры json. Если же использовать строку, это скорее всего сойдёт на нет. Не добавлял это в статью так как пока это на уровне домыслов и сопоставлений с тем что вижу.
Если не считать время, то да. Если считать опыт, то даже в плюсе :)
Да, к сожалению у многих так. Не до конца понятно что с игрой. Иногда на идентичных устройствах работает, или не работает. Так до конца и не поняли проблему.
По поводу пушей — сам их не люблю, но рынок требует. Необходимое зло так сказать.
Спасибо за визуал, старались.
Спасибо
Благодарю. Будем стараться дальше :)
Ваш подход возможен, но не очень правилен с точки зрения работы с базой данных. Я чуть выше другому человеку уже коментировал почему не стал так делать. Не буду еще раз дублировать. Но он бы стработал :)
JsonUtility имеют свои ограничения вроде отсутствия сериализации для dictionary, null, свойств, полиморфных типов и кучу других ограничений. Да и по факту это бы никак не повлияло на проблему с преобразованиями внутри фаербейз.
Я хотел, однако firestore на тот момент был в бета тесте. Не хотелось иметь больше проблем. С другой стороны вероятно их было бы меньше. В следующем обязательно firestore.
Сериализация происходит на нашей стороне силами newtonsoft json. На самом деле, это не так проблема, как неожиданность. Когда пишешь массив, ожидаешь считать массив. То есть например массив:
{ new Something(), null, new Something() } после сериализации newtonsoft таки массив. После передачи в firebase и считывания обратно, это уже будет объект:
0: Something
2: Something
Если знать про это поведение, его обыграть не составляет труда.
Я пожалуй не лучший пример привел в статье. Подправлю этот момент.
Спасибо за замечание.
На самом деле мы именно так и делаем и сериализируем используя newtonsoft.json и записываем через SetRawJson однако, у firebase на этот счёт свои мысли и похоже происходит ещё и преобразование на стороне firebase :)
Про передачу ключ строка не думали так как дальше планируем добавлять возможность для игрока смотреть прогресс друзей из того же facebook и это будет не так удобно в итоге. Ну и бд на то и бд что бы использовать ее как бд :)
Плюс эффективность в трафике. Я не ручаюсь за это, но похоже что исходя из того что я вижу (объем передаваемого трафика), firebase имеет свой протокол который так или иначе уменьшает объем передаваемых данных исходя из структуры json. Если же использовать строку, это скорее всего сойдёт на нет. Не добавлял это в статью так как пока это на уровне домыслов и сопоставлений с тем что вижу.