Comments 18
Картинка из начала топика недвусмысленно намекает на The Binding of Isaac.
Помню, мы в команде сначала обрадовались встроенному сериалайзеру и начали юзать его. Но довольно скоро поняли, что чего-то не хватает (сейчас уже не вспомню, чего именно). Что-то очень важное не сериализовалось.
Пришлось для всей карты и данных игрока писать сериалайз/десериалайз руками…
Пришлось для всей карты и данных игрока писать сериалайз/десериалайз руками…
Если все-равно делается явная сериализация / десериализация указанных данных, то почему не использовать JSON вместо XML? Быстрее, места меньше занимает, к тому же можно получать / отправлять через веб без дополнительной работы на стороне сервера. Да, валидация по схеме отсутствует как класс, но нужна ли она в данном случае?
Сам недавно «мучился» с выбором формата в .Net приложении. Остановился на XML.
Да, JSON привлекательнее, но XML нативно поддерживается в .Net Framework, а для работы с JSON нужны сторонние библиотеки.
Да, JSON привлекательнее, но XML нативно поддерживается в .Net Framework, а для работы с JSON нужны сторонние библиотеки.
Простейшая сериализация / десериализация пишется в 100-150 строк кода вручную, либо достаточно быстро через какой-нибудь coco/r + схема с www.json.org/json-ru.html — результат в любом случае будет быстрее и меньше по объему.
Да, я в курсе. Можно вполне использовать что-нибудь типа JSON.Net, но мы (наш отдел разработки) уже трижды сталкивался с косяками в opensource проектах.
Мой коммент был не про opensource косяки, а про создание своего упрощенного строкового сериализатора в поток за 2 дня работы максимум среднего программиста.
2 дня работы разработчиков стоят денег.
Если выбор технологии, не окупает их, то нет смысла тратить ресурсы.
Если выбор технологии, не окупает их, то нет смысла тратить ресурсы.
Т.е. весь код каждый раз пишется с нуля и никогда не используются собственные прошлые наработки?
Естественно, используются. У меня складывается впечатление, что мы о разных вещах говорим. Мы используем повторно написанный ранее код. Да, мы стараемся использовать нативные механизмы (избегать сторонних библиотек) в случаях, когда для бизнеса не критично. Пример, общение сервера с API сервиса через XML, а не через JSON.
Вероятно, о разных. Я погуглил, нашел маленькое готовое решение, оптимизировал его под минимальное потребление памяти и скорость, теперь использую везде — вот это называется повторное использование однажды полезно потраченного времени. Геймдев тем и отличается от Ынтерпрайза, что применение оптимизированных кастомных велосипедов, а не проверенных годами промышленной эксплуатации решений, очень часто оправдано в плане скорости работы и получении нужного конечного результата.
Спасибо за статью!
Как раз в проекте скоро встанет вопрос о сохранении. Благодаря вам уже знаю, как его решить (или хотя бы в каком направлении копать).
Как раз в проекте скоро встанет вопрос о сохранении. Благодаря вам уже знаю, как его решить (или хотя бы в каком направлении копать).
Очень кстати статья. Спасибо за информацию.
Я конечно не специалист в Unity3D, но кеп во мне подсказыват что класс PlayerPrefs предназначен для храниния «настроек» пользователя но никак не сохранений.
Хранение сохранений в реестре выглядит дико, на мой взгляд для сохранений гораздо лучше использовать все же папку пользователя.
Так что я думаю лучше воздержаться от использования этого класса данным способом.
Хранение сохранений в реестре выглядит дико, на мой взгляд для сохранений гораздо лучше использовать все же папку пользователя.
Так что я думаю лучше воздержаться от использования этого класса данным способом.
На самом деле, PlayerPrefs прекрасно подходит в случае, если вам не нужно сохранять большое кол-во данных. Во-первых PlayerPrefs работает из коробки, во-вторых работает на всех платформах. А там, где все же приходится сохранять класс, мы сериалайзим его в JSON и итоговую стрингу уже пишем в PlayerPrefs. Всего один вызов, быстро и вкусно)
Sign up to leave a comment.
Сохранение игры в Unity3D