Стратегия загрузки игровых ресурсов для плавного ux

#ios #memory #assets #2d-games

#iOS #память #ресурсы #2d-игры

Вопрос:

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

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

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

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

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

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

Ответ №1:

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

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

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

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

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

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

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

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