Стратегия загрузки игровых активов для плавного UX - PullRequest
0 голосов
/ 21 апреля 2019

Я работаю над сюжетной игрой на основе изображения / текста.Ничего особенного для него не используется, но есть множество компонентов пользовательского интерфейса, которые полагаются на фоновые изображения / элементы изображения.

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

На некоторых предыдущих устройствах вы можете четко видеть, что на экране появляются изображения, размер которых составляет от 0,2 до 4 секунд.Я предполагаю, что это является узким местом загрузки многих изображений с диска.

Я решил эту проблему, предварительно загрузив изображения в память, теперь все там без задержек.

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

Отсюда вопрос.Это так или лучше предварительно загружать игровые ресурсы?

1 Ответ

1 голос
/ 26 апреля 2019

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

Просто следите за объемом памяти вашего приложения. Система завершит работу вашего приложения в середине предварительной загрузки, если оно займет слишком много памяти. Для iPhone 6 я помню, что порог был около 500 МБ. Не уверен, если это зависит от устройства. Кроме того, даже если вы можете предварительно загрузить все игровые ресурсы сразу, если он слишком близок к порогу, действие пользователя, открывающего даже легкое приложение, может привести к тому, что система завершит работу вашего приложения, чтобы освободить память. Поэтому, когда они вернутся к вашей игре, нужно будет снова загрузить все заново.

В конце концов, по мере того, как ваша игра становится больше и использует больше ресурсов, предварительная загрузка всего за один раз больше не будет возможностью, так как ваше приложение будет остановлено в середине этого процесса.

Когда дело доходит до этого, вам нужно будет выбрать точки для разделения игрового процесса, например, начало, середина и конец: A, B, C. Поэтому, когда вы запускаете игру, предварительно загружаются только активы A, и затем где-то между A и B вы запускаете предварительную загрузку активов B в фоновом режиме. И как только достигается B, вы удаляете ссылки на активы A, вызывая освобождение этой памяти.

При этом ваш общий объем памяти уменьшается, и вы сокращаете время начальной загрузки, чтобы начать играть в игру. Первой стратегией предварительной загрузки всего было разделение вашего игрового процесса на 1 часть. Чем больше разделов, тем выше эффективность.

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

Эффективная стратегия будет зависеть от характера вашей игры, но суть заключается в том, чтобы загрузить то, что вам нужно, до того, как оно вам понадобится. И освободить память о вещах, которые вам больше не нужны. В игре с дискретными уровнями обычно проще всего это сделать, поскольку вы можете предварительно загрузить только ресурсы этого уровня, а затем, когда уровень закончится, освободить эту память и загрузить активы следующего уровня, пока вы показываете экран загрузки. Или, если ваша игра является непрерывной, вы можете разделить ее на этапы, и на каждом этапе хранить ссылки на используемые им ресурсы. Поэтому, если A и B совместно использовали некоторые активы, удаление ссылок на активы A не освободит память о ресурсах, ссылки на которые у B все еще есть. И если ваш игровой процесс позволяет пользователю также двигаться назад, например, возвращаясь к А после достижения В, то вместо освобождения всех активов А после достижения В, возможно, вы освободите только первую половину А. эти конструкции движущихся буферов тоже, потому что, возможно, все A используют одни и те же активы повсюду.

Кроме того, если в вашей игре много мелких ресурсов, то было бы эффективнее поместить их все в атлас текстуры и предварительно загрузить атлас текстуры вместо всех отдельных ресурсов (см. SKTextureAtlas в SpriteKit).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...