Приветствую всех друзья! В прошлой статье мы поговорили о способах добавления случайных геймплейных элементов в Unity. Сегодня я хочу рассказать вам о том, с какими проблемами вы можете столкнуться при разработке кроссплатформенной игры на Unity, и каким способом их можно решить. Надеюсь эта статья будет вам полезна.
Большая часть API (программный интерфейс приложения), а также структура вашего проекта одинаковы для всех поддерживаемых Unity платформ, и в некоторых случаях проект может быть просто пересобран для запуска на разных платформах. Однако фундаментальные различия на аппаратном уровне, а также в методах развертывания означают, что некоторые части проекта не могут переноситься между платформами без изменений. Ниже я приведу подробные сведения о некоторых распространенных кроссплатформенных проблемах и способах их решения.
Управление.
Наиболее очевидный пример различного поведения между платформами – это методы ввода, которые предлагаются аппаратным обеспечением платформы. Как вы знаете на компьютере чаще всего используют клавиатуру и мышь, на мобильных тачскрин, а на консолях это игровые джойстики.
Управление с клавиатуры и джойстика.
Стандартной функцией для управления на компьютерах является Input.GetAxis, она объединяет в себе управление как с клавиатуры, так и с джойстика. Сразу оговорюсь что для простых игр это решение подойдет, но в более сложных проектах я рекомендую использовать либо сторонние плагины (можно найти на Asset Store, он находится по пути в контекстном меню Window/Asset Store), либо использовать недавно появившуюся систему ввода, которая разработана как пакет (пакеты - это модули, которые более нативны по отношению к Unity чем плагины из Asset Store, почти все они разработаны самими Unity). Чтобы установить себе этот пакет перейдите в контекстном меню по пути Window/Package Manager далее в верхней части открывшегося окна слева выберите пункт из выпадающего списка All packages, а справа в выпадающем окне установите галочку на пункте Show preview packages. После всех вышеописанных манипуляций найдите в вертикальном списке пакет Input System и установите его нажав на кнопку Install в нижней части окна. В будущих статьях мы обязательно подробно рассмотрим менеджер пакетов, а также все имеющиеся в нем пакеты, сейчас же я дал подсказку тем, кто уже знаком с этим инструментом.
Однако эта функция и плагины, о которых я написал выше, не имеют смысла для мобильных платформ, которые предполагают сенсорный ввод. Поэтому если вы рассматриваете перенос вашей игры на другие платформы в будущем, то стоит добавить уровень абстракции к вашему коду управления. В качестве простого примера, если вы делаете игру о вождении, то можно создать свой собственный класс и обернуть вызовы Unity API в свои собственные методы:
Преимуществом такого написания кода является тем, что все вызовы API сосредоточены в одном классе, и, следовательно, их легко найти и изменить. Однако более важная идея заключается в том, что вы должны проектировать свои методы в соответствии с логическим смыслом входных данных в вашей игре. Это поможет изолировать остальную часть игрового кода от конкретного метода ввода, используемого с конкретной платформой. Например, приведенный выше метод Gears может быть изменен таким образом, чтобы фактический ввод происходит от прикосновения к экрану мобильного устройства. Использование целого числа для представления данного механизма переключения скоростей прекрасно работает для всех платформ, но смешивание специфичных для платформы вызовов API с остальной частью кода вызовет проблемы. Для удобства работы с кодом я рекомендую сделать интерфейс и реализовать от него классы, которые будут отвечать за работу ввода на различных платформах, а для того чтобы это работало автоматически и вам не требовалось вручную менять код каждый раз при переключении платформы – используйте платформенно-зависимую компиляцию. О ней я напишу отдельную статью, а тут приведу скриншот того как она упрощает жизнь разработчика:
Нажатия и клики.
Если вы делаете простую игру, то для определения касания и кликов по экрану, а также работы с левой кнопкой мышки вам достаточно метода Input.GetMouseButtonXXX. Он спроектирован таким образом, что определяет, как нажатие по левой кнопке мыши, так и однократное касание по экрану мобильного, помимо этого метод Input.mousePosition также дает позицию нахождения курсора мыши, или пальца на экране одинаково хорошо для обеих платформ. Но не стоит забывать, что этот подход работает только для простых взаимодействий. Бывают случаи, когда нужно определять не только левый клик мышки, а также и другие ее кнопки, также как бывают случаи, когда необходимо отслеживать несколько нажатий на экран одновременно. Для таких случаев необходимо использовать платформа зависимые методы, о которых я еще буду рассказывать в своих будущих статьях.
Принцип разработки тут точно такой же, как и в примере управления для машины. Мы создаем класс прослойку, который будет представлять методы управления внешнему коду, а для каждой платформы мы делаем отдельный класс реализации управления и общий интерфейс через который все они будут работать. Например, жест щипка на мобильных устройствах может быть заменен кнопками +\- на компьютере. Однако бывают случаи, когда игра заточена под один тип управления, и перенести ее на другую платформу без сильного изменения геймплея нет возможности, об этом также важно помнить и думать перед тем как вы начнете разработку.
Акселерометр, компас, гироскоп и GPS.
Все эти виды управления в основном существуют на мобильных устройствах и могут не иметь никаких эквивалентов на компьютере. Однако бывают случаи, когда и такие способы управления можно заменить. Например, вы сделали гоночную игру, в которой вы управляете поворотами машины через акселерометр поворачивая телефон в стороны как руль. Такое управление с легкостью заменяется управлением с клавиатуры.
Однако не стоит забывать, что часто после переноса на другую платформу – игру придется править в плане баланса. Обращаясь к примеру, выше с гоночным симулятором – акселерометр не будет столь же быстро работать как нажатие на клавиши, поэтому если вы перенесли игру с ПК на мобильное устройство без изменения сложности, то скорее всего игрокам на мобильных устройствах будет сложнее играть, чем тем, кто играет на ПК. Поэтому разрабатывайте свой код с учетом корректировок сложности в будущем при переносе.
Оперативная память, память жесткого диска и производительность центрального процессора.
Мобильные устройства неизбежно имеют меньше мощности по сравнению с настольными компьютерами, и поэтому игру может быть трудно портировать, из-за недостаточной производительности. Некоторые проблемы с ресурсами можно решить, но, если ваша игра очередной "Crysis" – стоит задуматься, что таковая не может являться хорошим кандидатом для переноса на мобильную платформу.
Воспроизведение видео в игре.
На мобильных платформах вы можете показать начальный ролик или туториал в виде полноэкранного видео. Однако если в вашей игре есть произведение видео внутри мира (например, на экране монитора), то оно не будет работать на мобильных устройствах (речь о видео, создаваемых с помощью Movie Texture). Однако если сильно хочется, то можно воспользоваться плагинами с Asset Store. Но в любом случае я думаю это повлияет на производительность игры.
Условия хранения.
Видео, аудио и другие части игры (например, текстуры) могут занимать довольно много места на жестком диске. Кроме того, чем больше весит игра, тем дольше она загружается на устройстве, что довольно критично для мобильных устройств. Также не стоит забывать, что многие магазины приложений ограничивают размеры билда для заливки. Отталкиваясь от вышесказанного, мы можем предпринять два варианта: первый это сократить размеры всех ресурсов (например, ужать их), но такой метод потребует создания отдельных ресурсов для билда на мобильные платформы и отдельных для ПК. Второй способ — это разделение билда на обязательную небольшую часть которая будет по требованию подгружать ресурсы. В будущих статьях я еще рассмотрю подробно оба этих метода.
Автоматическое управление памятью.
Сборка и удаление мусора в Unity происходит автоматически, часто на ПК мы этого не замечаем. Однако из-за низкой производительности мобильных устройств – сборка может происходить более часто и при этом влиять на производительность самой игры вызывая тормоза и паузы в игровом процессе. Чтобы этого не допустить необходимо оптимизировать код. Об этом также будет отдельная статья.
Производительность процессора.
Игра, которая хорошо работает на ПК, может страдать от плохой частоты кадров на мобильных устройствах просто потому, что мобильные процессоры борются со сложностью кода игры. Поэтому при переносе проекта на мобильную платформу может потребоваться дополнительное внимание к эффективности кода. В будущем я напишу статью, о том какими методами достигается результат быстрой работы кода.
На сегодня это все. В следующей статье мы научимся создавать билд своей игры, а также познакомимся с методами уменьшения его размера и вкратце поговорим о конвейере сборки билдов. Спасибо всем, кто дочитал эту статью до конца, подписывайтесь на канал, ставьте лайки, а для тех, у кого появились вопросы - спрашивайте в комментариях! А если вы хотите помочь данному каналу в развитии – делитесь этой статьей с друзьями в социальных сетях!
