Управление сценами в Unity без боли и страданий

Вам когда-либо приходилось думать над тем, как сделать управление сценами в вашем проекте менее болезненным? Когда у вас достаточно простая игра, в которой всего несколько сцен идущих одна за другой, то, зачастую, всё проходит гладко. Но когда количество сцен растёт и усложняются переходы между ними — они могу загружаться в разном порядке и поведение некоторых из них должно зависеть от входящих параметров — задача становится менее тривиальной.


Ниже несколько подходов к ее решению, которые мне приходилось видеть чаще всего:


  • Файлы — при переходе из одной сцены в другую, все необходимые данные записываются в JSON/XML файл, а когда следующая сцена загрузилась, считывают их обратно. Как минимум, это медленно (говоря о чтении и записи в файл), да и процесс дебага становится менее удобным.
  • Огромный статический класс, который обрабатывает все возможные переходы между сценами. Они очень похожи на божественные объекты и довольно часто являются причиной утечек памяти, а также боли в нижней части спины, когда новый разработчик пытается понять, что вообще происходит в этой тысяче строк статического кода.
  • DontDestroyOnLoad GameObject — этот подход похож на предыдущий, но представлен GameObject'а в сцене с кучей ссылок в Инспекторе. По сути, это один из тех синглтонов, которые каждый из нас видел в большинстве проектов...

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


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


public abstract class SceneArgs
{
    public bool IsNull { get; private set; }
}

Как я уже написал выше, у каждой сцены есть свой контроллер, который наследуется от SceneController.


public abstract class SceneController<TController, TArgs> : MonoBehaviour
        where TController : SceneController<TController, TArgs>
        where TArgs       : SceneArgs, new()
{
    protected TArgs Args { get; private set; }

    private void Awake()
    {
        Args = SceneManager.GetArgs<Tcontroller, TArgs>();

        OnAwake();
    }

    protected virtual void OnAwake() {}
}

Я использую отдельный класс для представления аргументов по одной простой причине. Изначально, метод загрузки сцены принимал аргументы в виде массива объектов params object[] args. Это был унифицированный способ для загрузки любой сцены с возможностью передать аргументы. Когда контроллер сцены получал управление, он парсил этот массив объектов и получал все необходимые данные. Но, кроме банального боксинга, здесь была ещё одна проблема — ни для кого, кроме разработчика, который писал этот контроллер (а со временем и для него самого) не было очевидно, какого типа аргументы и в каком порядке нужно передать, чтобы потом не возникло ошибок кастинга. Когда мы создаём новый метод, то в его сигнатуре указываем порядок и типы аргументов и затем IDE может нам подсказать, если при его вызове мы допустили ошибку. Но с аргументом params object[] args мы видим лишь то, что нужно передать массив аргументов и каждый раз, чтобы понять их порядок и типы, разработчику нужно лезть в код контроллера и смотреть как же они парсятся. Мне хотелось сохранить метод запуска таким же унифицированным (один метод для запуска любой сцены), но при этом дать возможность жестко ограничить типы аргументов для каждой из сцен. И для этого нужны ограничения where, которые есть в SceneController.


Как известно, мы должны каждый раз передавать name или buildIndex сцены, чтобы загрузить её через метод LoadScene() или LoadSceneAsync() в Unity API. Этого хотелось бы избежать, потому я использую кастомный атрибут SceneControllerAttribute, чтобы привязать конкретный контроллере к конкретной сцене. Здесь используется имя сцены, а не её buildIndex лишь по той причине, что, на моём опыте, оно реже подвергается изменениям.


[AttributeUsage(AttributeTargets.Class)]
public sealed class SceneControllerAttribute : Attribute
{
    public string SceneName { get; private set; }

    public SceneControllerAttribute(string name)
    {
        SceneName = name;
    }
}

Допустим, у нас есть сцена MainMenu. В таком случае, классы её аргументов и контроллера будут иметь следующий вид:


public sealed class MainMenuArgs : SceneArgs
{
    // args' properties
}


[SceneControllerAttribute]
public sealed class MainMenuController : SceneController<MainMenuController, MainMenuArgs>
{
    protected override void OnAwake()
    {
        // scene initialization
    }
}

Собственно, это всё (из того, что касается контроллера сцены и её аргументов). Осталось лишь понять, как происходит переход от одной сцены к другой. Этим занимается внезапно статический класс SceneManager. Очень важно, чтобы он был как можно меньше, проще и понятнее. Чтобы он не превратился в один из тех ненавистных божественных объектов с тоннами зависимостей. У него всего лишь одна простая задача — передать управление от контроллера одной сцены к контроллеру следующей. За все последующие инициализации и прочее отвечает уже сам контроллер.


public static class SceneManager
{
    private static readonly Dictionary<Type,  SceneArgs> args;

    static SceneManager()
    {
        args = new Dictionary<Type,  SceneArgs>();
    }

    private static T GetAttribute<T>(Type type) where T : Attribute
    {
        object[] attributes = type.GetCustomAttributes(true);

        foreach (object attribute in attributes)
            if (attribute is T targetAttribute)
                return targetAttribute;

        return null;
    }

    public static AsyncOperation OpenSceneWithArgs<TController, TArgs>(TArgs sceneArgs)
        where TController   : SceneController<TController, TArgs>
        where TArgs         :  SceneArgs, new()
    {
        Type                     type       = typeof(TController);
        SceneControllerAttribute attribute  = GetAttribute<SceneControllerAttribute>(type);

        if (attribute == null)
            throw new NullReferenceException($"You're trying to load scene controller without {nameof(SceneControllerAttribute)}");

        string sceneName = attribute.SceneName;

        if (sceneArgs == null)
            args.Add(type, new TArgs { IsNull = true });

        return UnityEngine.SceneManagement.SceneManager.LoadSceneAsync(sceneName);
    }

    public static TArgs GetArgs<TController, TArgs>()
        where TController   : SceneController<TController, TArgs>
        where TArgs         :  SceneArgs, new()
    {
        Type type = typeof(TController);

        if (!args.ContainsKey(type) || args[type] == null)
            return new TArgs { IsNull = true };

        TArgs sceneArgs = (TArgs)args[type];

        args.Remove(type);

        return sceneArgs;
    }
}

Позвольте мне немного объяснить этот код. При вызове OpenSceneWithArgs() вы передаёте тип контроллера (TController) сцены, которую нужно загрузить, тип параметров (TArgs) и, собственно, сами параметры (sceneArgs). В первую очередь, SceneManager проверяет, есть ли у TController атрибут SceneControllerAttribute. Он должен быть, потому именно он определяет, к какой сцен привязан контроллер TController. Дальше мы просто добавляем аргументы sceneArgs в словарь. Если не было передано каких-либо аргументов, мы создаём экземпляр типа TArgs и присваиваем его свойству IsNull значение true. Если всё прошло гладко, то будет вызван метод из Unity API LoadSceneAsynс() и ему будет передано имя сцены, которое берётся из атрибута SceneControllerAttribute.


Загружается следующая сцена и у её контроллера вызывается метод Awake(). Дальше, как видим в SceneController, TController вызывает SceneManager.GetArgs(), чтобы получить аргументы, которые были переданы и записаны в словарь, а затем производит все необходимые инициализации.


В результате у нас каждая сцена сама отвечает сама за себя, а переходы происходят через небольшой класс SceneManager, отвечающий исключительно за передачу управления между ними. Просто попробуйте применить этот подход в одном из ваших пет проектов и вы заметите, на сколько прозрачнее и понятнее для вас и всех кто работает с вами станут переходы между сценами и их инициализации. Буду рад вашим комментариям. Успехов в разработке!

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 15

    0

    Спасибо. Познавательно.
    Возможно Вы еще подскажете решения по обновлению версий приложений без апдейтов в сторы?

      0
      Благодарю за отзыв!

      К сожалению, на вскидку ничего не приходит в голову, так как не возникало такой нужды. Но если будет что-нибудь интересное, то напишу.
        0

        Далее речь про андроид:
        Если речь про обновление каких-либо платформенных штук (типо названия приложения, версии в системе), то никак. Проблема тут в том, что все эти сведения содержатся в apk, который изменить без установки поверх нового apk с изменениями не получится чисто из-за устройства ОС.
        Если речь об обновлении кода, то можно, если использовать mono в качестве бэкенда. С сервера скачивать новые dll, затем подгружать их через Assembly.Load. Таким макаром можно обновлять логику (конечно, нужно проделать доп. манипуляции по выносу загружаемого кода в отдельную библиотеку). Но тут нюанс в том, что таким образом можно в теории загрузить вообще любой код, что по правилам Google Play в относительно серой зоне по дозволенности (можно загружать код, если он в виртуалке и имеет ограниченный доступ к системе).
        Но, зная реалии и то, что сейчас в моде il2cpp, всё усложняется. В данном случае нужно уже встраивать какой-нибудь интерпретатор, тот же интерпретатор javascript, а потом с сервера скачивать и выполнять уже js.
        TLDR:
        Изменять код с mono backend: загрузка с сервера dll + Assembly.Load.
        Изменять код с il2cpp backend: загрузка с сервера скриптов + использование интерпретатора

          0

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

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

            And42, дельный совет, спасибо за комментарий!
              0

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

          0

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

            0

            Спасибо! А ссылкой не поделитесь полезной по данной теме?

          0

          Для этой задачи лучше подойдёт Zenject. Там тоже нужно кидать специальный класс в сцены, но не нужно создавать классы для каждой сцены, а только для тех, где нужно отлавливать параметры.
          В любом случае рекомендую пользоваться этой библиотекой(и для других целей), жизнь станет проще когда привыкните.
          А ещё ожидал увидеть как вы делаете переходы с анимациями(пока анимация проигрывается можно загрузить другую сцену и поломать всё), и загрузку по порядку. К слову там бывает проблема, когда загружаешь 2 сцены подряд аддитивом, но первая загруженная сцена решает тоже загрузить или выгрузить другую сцену и порядок ломается.

            0
            Zenject это вообще великолепная вещь. Как говорится, знаем, практикуем. Кажется, любой, единожды оценивший все прелести DI, уже не захочет без него работать. Специально его не упоминал, так как был уверен, что кто-нибудь дополнит в комментариях. :)
              0
              А как Zenject сочетается со скриптами темы? Как? Или почему тут решили что-то своё использовать? Соглашусь, что инструмент удобный, в т.ч. позволяет удобно контролировать память, но слишком уж много сложностей и неопределённости без достаточной документации, и так же, как оказалось, не мало способов сделать всё ещё хуже в плане архитектуры. После некоторого опыта решил, что оно того не стоит, если хотя бы какую-то часть проекта отправить в «свободное плавание» со средним разработчиком.

              Мы в другом проекте используем менеджер для загрузки/выгрузки сцен с контролем по имени сцены и соот. enum, грузится всё через async Task функцию, где возвращается объект со сцены IScreen по срабатыванию OnSceneLoaded(после Awake, OnEnable, но до Start), что позволяет проводить функции загрузки всё так же в Start, а ссылки назначать до того. Проблему пока вижу только в том, что будут ошибки при загрузке 1 сцены с 2 мест одновременно, но для нас это не критично. Очень уж убог функционал по загрузке сцен в самой Unity, а то можно было бы сделать и лучше.
            0

            Благодарю за решение. То же возникала подобная проблема, решение из этой статьи думаю мне подойдёт. Жду следующих полезных статей)

              0
              Спасибо!
              Буду ещё статьи, подписывайтесь.
              0
                0
                Интересное решение, наткнулся на него около месяца назад. Респект автору, но мне показалось, что, как для такой не очень сложной задачи, это немного оверинжениринг. ИМХО, конечно.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое