Pull to refresh

Comments 9

Почему просто не закачивать в фоне ресурсы и не складывать их в папку пользовательских данных (sdcard, etc)? А потом грузить только то, что нужно. Архивация для уменьшения времени загрузки тоже звучит странно — какая разница, если данные едут в фоне и будут доступны только при следующем запуске приложений и только в случае успешной докачки? Единственный минус — придется придумать свои форматы для всего, чтобы можно было быстро загружать из локальных файлов + сжатие текстур на лету не всегда работает в принципе (загрузка и перекладывание через Get/SetPixels в текстуру со сжатием не всегда помогают — DXT5 на десктопе отрабатывало как надо, на android tegra2 — не работало в принципе, всегда возвращая ARGB32).
Почему просто не закачивать в фоне ресурсы и не складывать их в папку пользовательских данных

Как я уже писал в статье, если вам не нужно использовать нативные файлы Unity, вы можете не использовать AssetBundle. В нашей ситуации мы были вынуждены его использовать.

Архивация для уменьшения времени загрузки тоже звучит странно — какая разница, если данные едут в фоне и будут доступны только при следующем запуске приложений и только в случае успешной докачки?

Во-первых, данные будут доступны как только закачается соответствующее DLC. О перезапуске приложения я ничего не писал. Данные будут обновляться по мере загрузки DLC. Скачали 20 вещей, они сразу появились в игре когда юзер повторно зашел в магазин. Об это я написал в постановке задачи.
Во-вторых, есть большая разница закачивать 200 мб или 60 мб. Особенно на 3G интернете.
Как я уже писал в статье, если вам не нужно использовать нативные файлы Unity, вы можете не использовать AssetBundle. В нашей ситуации мы были вынуждены его использовать.

Было сказано, что решили использовать то, что есть. К тому же я об этом написал:
Единственный минус — придется придумать свои форматы для всего, чтобы можно было быстро загружать из локальных файлов

Т.е. реализовать кастомную сериализацию для «нейтивных» файлов юнити с последующей десериализацией в рантайме любым удобным способом (хоть в параллельном потоке с синком в главный только в момент готовности данных).

О перезапуске приложения я ничего не писал.

Я имел ввиду перезапуск магазина и скан уже загруженного контента в виде паков (контент же может быть зависимым от чего-то другого в этом паке и нельзя сразу отдавать его, пока весь пак не доедет, хотя у вас может был другой случай).

Во-вторых, есть большая разница закачивать 200 мб или 60 мб. Особенно на 3G интернете.

Сейчас игрушки под ретину начинают весить до 1.5-2Гб + апдейты к ним. Несчастные 200Мб вообще ни о чем. Но более правильной политикой было бы предлагать юзверу самому решить — качать DLC на текущем коннекте или нет + опцию в настройках.
Т.е. реализовать кастомную сериализацию для «нейтивных» файлов юнити с последующей десериализацией в рантайме любым удобным способом (хоть в параллельном потоке с синком в главный только в момент готовности данных).


Интересная идея, мы думали об этом. Это может сработать для файлов типа asset, правда не сработает для scene файлов.
На мой взгляд это выглядит как еще один хак. Нет точных гарантии, что asset будет корректно сериализроваться и десериализоваться. К тому же даже если этот механизм будет работать идеально, мы имеет дополнительные затраты на конвертацию ассетов в «наш формат», и затем обратную конвертацию в ассет. А также это потенциально новые баги в багобазе.
В нашем варианте AssetBundle берет на себя часть задач и гарантирует целостность данных внутри. Все таки решение с бандлом мне видится более надежным.

Сейчас игрушки под ретину начинают весить до 1.5-2Гб + апдейты к ним. Несчастные 200Мб вообще ни о чем.

Ну далеко не все игры. Наша игрушка весила всего 40 мб. По сути, как демо версия. Дальше она выкачивала порядка 300 мб DLC. Причем под разные девайсы были разные ресурсы. И под ретину DLC было в разы больше.

Но более правильной политикой было бы предлагать юзверу самому решить — качать DLC на текущем коннекте или нет + опцию в настройках.

Согласен с вами полностью. Но игра предназначалась домохозяйкам и опций должно было быть минимум.
Нет точных гарантии, что asset будет корректно сериализровться и десериализроваться. К тому же даже если этот механизм будет работать идеально, мы имеет дополнительные затраты на конвертацию ассетов в «наш формат», и затем обратную конвертацию в ассет. А также это потенциально новые баги в багобазе.
В нашем варианте AssetBundle берет на себя часть задач и гарантирует целостность данных внутри. Все таки решение с бандлом мне видится более надежным.

Я имел ввиду не бинарную сериализацию ассета в лоб, а именно полностью свой (оптимизированный) вариант сериализации для всего. Например, шейдеры в ассетах хранятся в скомпилированном виде для всех поддерживаемых платформ. Зачем, блин? Ну и так для всего — можно сделать различные оптимизации (те же нормали хранить в 2-х short-ах и восстанавливать 3-ий компонент, хранить UV так же в 2 short-ах, если они нормализованы, etc). Ну и, как говорилось, это все можно грузить как-угодно в фоне, синкаясь с основным потоком только в момент инстанцирования. По поводу подготовки данных — редактор юнити прекрасно расширяется и позволяет тесно интегрировать свой функционал бесшовно в основной редактор, к которому дизайнеры уже привыкли. В дальнейшем просто рисуются комиксы в картинках (инструкции) по использованию новых пунктов и все работает как надо.
А также это потенциально новые баги в багобазе.

Зато в дальнейшем работающие выжимки можно использовать сразу в следующих проектах, а так же срубить денег в юнисторе :)
Ну да, можно и так конечно.
Получится вроде своего DLC с пасьянсом и профурсетками )
Беглый взгляд по ассет стору ничего подобного не выдал, так что место пока вакантно.

Но я в ближайшее время не планирую заниматься DLC. Есть другие более интересные задачи.
Для того чтобы юнити стала удобной и гибкой, необходимо заставить самих разработчиков юньки писать на своем же движке. А то каждая задача это борьба с движком!
Native плохо пишется на managed :)
//сохраняем byteData в файл с расширением .unity3d
не совсем понял для чего нужен этот шаг, ведь LoadFromCacheOrDownload сама сохраняет версию на диск и следит за ее актуальностью?
Sign up to leave a comment.

Articles