Большинство API и структур проектов в Unity идентичны для всех поддерживаемых платформ, а в некоторых случаях проект можно собрать заново, чтобы он работал на новом устройстве. Однако, существуют принципиальные различия в аппаратных средствах и способах развёртывания, это означает что некоторые части проекта не могут быть перенесены между платформами без изменений. Ниже приводится информация о некоторых общих вопросах кросс-платформенности и предложениях по их решению.
The most obvious example of different behaviour between platforms is in the input methods offered by the hardware.
Функция Input.GetAxis очень удобна в применении на настольных платформах, потому что объединяет способы ввода с клавиатуры и джойстика. Тем не менее, эта функция не имеет смысла для мобильных платформ, которые рассчитаны на сенсорный ввод. Более того, стандартный ввод с настольной клавиатуры не переносится на мобильные устройства, потому как предназначен только для набора текста. Стоит добавить слой абстракции в ваш код обработки ввода если вы в будущем планируете перенос на другие платформы. В качестве простого примера, если вы делали гонку, то вы можете создать собственный класс ввода и обрабатывать вызовы Unity API в собственных функциях:-
// Returns values in the range -1.0 .. +1.0 (== left .. right).
function Steering() {
return Input.GetAxis("Horizontal");
}
// Returns values in the range -1.0 .. +1.0 (== accel .. brake).
function Acceleration() {
return Input.GetAxis("Vertical");
}
var currentGear: int;
// Returns an integer corresponding to the selected gear.
function Gears() {
if (Input.GetKeyDown("p"))
currentGear++;
else if (Input.GetKeyDown("l"))
currentGear--;
return currentGear;
}
Одним из преимуществ обработки вызовов API в классе является то, что все они сосредоточены в одном исходном файле и, следовательно, их легко найти и заменить. Тем не менее, более важная идея состоит в том, что вы должны спроектировать свои функции, обрабатывающие ввод, в соответствии с логикой входных значений в вашей игре. Это поможет вам изолировать остальную часть игрового кода от индивидуального способа ввода, используемого на конкретной платформе. Например, функция коробки передач, представленная выше, может быть изменена таким образом, что ввод будет происходит от прикосновений на экране мобильного устройства. Использование целочисленного представления выбранной передачи отлично работает для всех платформ, но смешивание специфичных для разных платформ вызовов API с остальной частью кода вызовет проблемы. Вы можете найти это удобным для использования при компиляции для разных платформ в сочетании различных реализаций функций обработки ввода в том же исходном файле, чтобы избежать замены вручную.
Функции Input.GetMouseButtonXXX спроектированы таким образом, что имеют достаточно очевидную интерпретацию на мобильных устройствах, хотя нет никакой “мыши” как таковой. Одиночное касание экрана сообщает о ЛКМ и свойство Input.mousePosition передаёт позицию нажатия на экран до тех пор, пока палец касается экрана. Это означает, что игры с простым управлением мышью зачастую могут свободно работать как на настольных , так и на мобильных платформах. Тем не менее обычно преобразование намного сложнее. Настольная игра может использовать более одной кнопки мыши, а мобильная способна различать несколько касаний экрана одновременно.
Как и c вызовами API, проблема может частично решена с помощью представления входных логических значений, которые потом используются в остальной части игрового кода. Например, жест-“щипок” для масштабирования на мобильном устройстве может быть заменен на настольном компьютере нажатием клавиши плюс/минус; функция, обрабатывающая ввод, может просто вернуть значение с плавающей точкой, определяющее коэффициент масштабирования. Точно так же, можно было бы нажатие двумя пальцами на мобильном устройстве заменить ПКМ на настольном компьютере. Тем не менее, если свойства устройства ввода являются неотъемлемой частью игры, то невозможно перестроить их на другую платформу. Это может означать, что игра не может быть перенесена на все платформы или, что ввод и/или геймплей должны быть серьёзно изменены.
Эти устройства ввода появились благодаря мобильности портативных устройств, потому как у настольных компьютеров нет эквивалентных устройств. Тем не менее, в некоторых случаях, использование стандартных способов управления игрой может быть достаточно легко портировано. Например, рулевое управление в гонке может быть реализовано с помощью наклона мобильного устройства (определяется с помощью акселерометра). В подобных случаях, вызовы API ввода, как правило, довольно легко заменить, поэтому ввод с акселерометра может быть заменен нажатием клавиш. Тем не менее, это может быть необходимо для калибровки или даже варьирования сложности игры, чтобы учесть другой метод ввода. Наклон устройства медленнее и в конце концов напряжённее, чем нажатие клавиш, а также труднее сконцентрироваться на дисплее. Это может привести к более трудному освоению игры на мобильном устройстве, и поэтому целесообразнее замедлить геймплей или предоставить больше времени на уровень. Это потребует от кода игры, чтобы тот был сконструирован так, что эти факторы были легко учтены.
Мобильные устройства имеют меньше памяти ПЗУ, ОЗУ и мощности процессора, чем у настольных машин, поэтому перенести игру может быть затруднительно из-за недостатка аппаратной производительности. Некоторыми вопросами, касающимися ресурсов, можно управлять, но если вы расширите пределы аппаратных ресурсов на настольном компьютере, то игра, вероятно, не является хорошим кандидатом для портирования на мобильную платформу.
Currently, mobile devices are highly reliant on hardware support for movie playback. The result is that playback options are limited and certainly don’t give the flexibility that the MovieTexture asset offers on desktop platforms. Movies can be played back fullscreen on mobiles but there isn’t any scope for using them to texture objects within the game (so it isn’t possible to display a movie on a TV screen within the game, for example). In terms of portability, it is fine to use movies for introductions, cutscenes, instructions and other simple pieces of presentation. However, if movies need to be visible within the game world then you should consider whether the mobile playback options will be adequate.
Видео, аудио и даже текстуры могут занимать много места для хранения, и, вы должны иметь это ввиду, если хотите портировать игру. Объём ПЗУ (который часто связан с временем загрузки), как правило, не является проблемой на настольных машинах, но это не в случае с мобильными устройствами. Кроме того, магазины мобильных приложений часто накладывают ограничения на максимальный размер продукта. Для решения этих проблем может потребоваться некоторое планирование в ходе разработки вашей игры. Например, вам может понадобиться предоставить урезанную версию ассетов для мобильных телефонов в целях экономии места. Существует вариант, чтобы игра была разработаны таким образом, что большие ассеты могли быть загружены по требованию, а не быть частью первой загрузки приложения.
Восстановление неиспользуемой памяти от “мертвых” объектов автоматически обрабатывается Unity и часто бывает незаметно на настольных машинах. Однако более медленная память и производительность процессора на мобильных устройствах приводит к тому, что сборки мусора могут происходить чаще и время, которое они занимают может повлиять на производительность (приводит к нежелательным паузам в геймплее и т.д.). Даже если для работы игры достаточно памяти, по-прежнему необходимо оптимизировать код, чтобы избежать пауз при сборке мусора. Более подробную информацию можно найти на странице управления памятью.
Игра, которая хорошо работает на настольном компьютере, может страдать от плохого FPS на мобильном устройстве просто потому, что процессор мобильного устройства борется со сложностью игры. Поэтому когда проект переносится на мобильную платформу, возможно, требуется уделить дополнительное внимание эффективности кода. Ряд простых шагов по повышению производительности изложены в нашем руководстве на этой странице.