2013-08-22 5 views
1

Прежде чем задать вопрос, я объясню, какие требования мне нужны. В моей игре есть много текстур, необходимых для ее воспроизведения. Из-за этого и ограничения размера ipa (iOS), я считаю, что использование assetbundle является обязательным. Поскольку существующая реализация кода, я создаю набор ресурсов, 1 пакет активов для 1 изображения. Например: у меня есть 100 изображений, тогда я создам 100 ресурсов (с основным содержимым будет текстура) с тем же именем.С каким способом лучше справиться AssetBundle Download Management

Я хочу, чтобы моя игра можно было сыграть в автономном режиме ПОСЛЕ с первого раза пользователь загрузил все необходимые ресурсы. Поэтому, если пользователь впервые играет или загружает обновленную версию моей игры, игра будет вынуждена перейти в специальную сцену, где будет загружено все необходимое объединение активов, после чего пользователь сможет играть в игру без подключения к Интернету.

Я думал, что есть 2 пути относительно того, как загрузить эти assetbundle:

  1. Обычный способ: я поставил все 100 assetbundles на моем сервере, и положить 1 XML-файл, который состоят все assetbundles информации и ее версии. На специальной сцене игра загрузит xml-файл, и из него он будет загружать 100 пакетов активов через WWW.LoadFromCacheOrDownload. Цель состоит в том, чтобы хранить необходимые активы в кэше игры. После успешной загрузки всех из них пользователь может играть в автономном режиме, и если игре нужно загрузить ресурс, то я просто вызываю ссылку WWW.LoadFromCacheOrDownload, так как он все еще находится в кеше, его можно воспроизводить в автономном режиме. Конечно, я предполагаю, что кеш все еще существует, пока я не очищаю кеш явно.

  2. Жесткий путь: Я буду застегивать все 100 активов на 1 почтовый файл. В игре будет загружен xml-файл и zip-файл. Я буду распаковывать zip и поместить все 100 активов в мобильное хранилище (iOS и Android). Поэтому после этого, если игра должна загрузить актив, я просто вызываю WWW.LoadFromCacheOrDownload, при этом url использует схему file:///, указывающую на путь мобильного хранилища.

Резюме:

Нормальный путь:

Минус: Я предполагаю, что кэш все еще существует, но если есть что-то неправильное в кэше, пользователь не может играть игра.

Плюс: простая реализация, поскольку предположение, что кеш будет в порядке.

The Hard Way:

Минус: ну, я не знаю, что это минус точка или нет, но это один, я должен реализовать Разархивирован почтовый файл и сохранить их в памяти. Требуется дополнительная реализация на стороне сервера и на стороне приложения. И поскольку я новичок, я не знаю лучшей практики в этой области.

Plus: более надежные

Так какой из них лучше? или какие-либо рекомендации?

ответ

2

Мы по существу внедрили сочетание вашего обычного и трудного способа для нашего применения.Как и у вас, это довольно текстура тяжелая, поэтому большинство групп текстурных активов упаковываются в свои собственные пакеты активов. (В нашей тексту приложения есть логическая группировка, поэтому мы не собираем их отдельно). Однако мы не загружаем их непосредственно в кеш. Мы загружаем их на SD-карту и оттуда загружаем их (или получаем из кеша) по мере необходимости. (то есть LoadFromCacheOrDownload).

Это зависит немного от вашей ситуации, но я бы вообще советовал не упаковывать их в один ZIP-файл. В первую очередь в отношении обновлений. В нашем случае произошло то, что актив нуждался в некоторых обновлениях или что мы хотели добавить активы позже. Имея файл XML или базу данных, содержащую данные о версии, обновление данных на устройстве тривиально. И если меняется только один пакет, вам нужно только загрузить этот единственный пакет. И 2MB против 450MB в нашем случае - это различие.

+0

Да, я думаю, вы правы в том, что «против упаковки их в один почтовый ящик». Спасибо за ответ, это действительно помогает мне: D –