Устранение распространенных межплатформенных проблем

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

Вводимые ресурсы

Лучшим примером разного поведения между платформами являются методы ввода, предлагаемые аппаратурой.

Клавиатура и джойстик

Input.GetAxis функция удобна на настольных платформах, где нужно объединить ввод с клавиатуры и геймпада. Для мобильных платформ с сенсорным вводом она не подходит. Стандартный настольный клавиатурный ввод годится лишь для переноса набираемого текста на мобильные устройства. Если вы планируете портирование на другие платформы, добавьте в свой код ввода слой абстракции. Например, для гоночной игры можно завести собственный класс ввода и обернуть вызовы API Unity в свои функции:

using UnityEngine;

public class CarControls : MonoBehaviour
{
    // Returns values in the range of  -1.0 to 1.0, which correspond to left and right.
    public float Steering()
    {
        return Input.GetAxis("Horizontal");
    }

    // Returns values in the range of -1.0 to 1.0, which correspond to acceleration and braking.
    public float Acceleration()
    {
        return Input.GetAxis("Vertical");
    }

    private int currentGear = 0;

    // Returns an integer corresponding to the selected gear.
    public int Gears()
    {
        if (Input.GetKeyDown(KeyCode.P))
            currentGear++;
        else if (Input.GetKeyDown(KeyCode.L))
            currentGear--;

        return currentGear;
    }
}

Обёртка вызовов API в класс собирает их в одном файле исходного кода, и их становится легко найти и заменить. Функции ввода стоит проектировать исходя из логического смысла ввода в вашей игре. Это отделяет остальной код игры от конкретного способа ввода, применяемого на той или иной платформе.

Например, вы можете модифицировать функцию Gears выше, так чтобы фактический ввод происходил от касания экрана мобильного устройства. Вы можете использовать целое число для представления выбранного зубчатого колеса для всех платформ, но если вы смешиваете платформенные вызовы API с остальным кодом, вы можете вызвать проблемы. Вы также можете использовать платформенно-зависимую компиляцию для объединения различных реализаций вводных функций в одном и том же исходном файле и избежать ручных обменов.

Прикосновения и щелчки

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

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

Например, вы можете заменить жест прижатия для увеличения на мобильном устройстве нажатием клавиши +/- на рабочем столе; функция ввода может возвращать плавающее значение, указывающее фактор увеличения. Аналогичным образом, вы можете использовать нажатие двумя пальцами на мобильном устройстве для замены правого щелчка на рабочем столе. Однако, если свойства устройства ввода являются неотъемлемой частью игры, то, возможно, не удастся изменить их на другой платформе. Это может означать, что вы не сможете перенести игру или что вам потребуется существенно изменить ввод или геймплей.

Акселерометр, компас, гироскоп и GPS

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

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

Память, хранилище и CPU производительность

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

Требования к хранению

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

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

Автоматическое управление памятью

Unity автоматически управляет восстановлением неиспользуемой памяти из «мертвых» объектов и часто происходит незаметно на настольных компьютерах. Однако, меньшая память и мощность CPU на мобильных устройствах означает, что сбор мусора может быть более частым, влияя на производительность и вызывая нежелательные перерывы в игре. Даже если игра работает в доступной памяти, может потребоваться оптимизация кода, чтобы избежать перерывов в сборе мусора.

Дополнительную информацию см. в страница управления памятью.

CPU мощность

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