Вам когда-либо приходилось думать над тем, как сделать управление сценами в вашем проекте менее болезненным? Когда у вас достаточно простая игра, в которой всего несколько сцен идущих одна за другой, то, зачастую, всё проходит гладко. Но когда количество сцен растёт и усложняются переходы между ними — они могу загружаться в разном порядке и поведение некоторых из них должно зависеть от входящих параметров — задача становится менее тривиальной.
Ниже несколько подходов к ее решению, которые мне приходилось видеть чаще всего:
- Файлы — при переходе из одной сцены в другую, все необходимые данные записываются в 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
, отвечающий исключительно за передачу управления между ними. Просто попробуйте применить этот подход в одном из ваших пет проектов и вы заметите, на сколько прозрачнее и понятнее для вас и всех кто работает с вами станут переходы между сценами и их инициализации. Буду рад вашим комментариям. Успехов в разработке!
anonymous
Спасибо. Познавательно.
Возможно Вы еще подскажете решения по обновлению версий приложений без апдейтов в сторы?
flat-mango Автор
Благодарю за отзыв!
К сожалению, на вскидку ничего не приходит в голову, так как не возникало такой нужды. Но если будет что-нибудь интересное, то напишу.
And42
Далее речь про андроид:
Если речь про обновление каких-либо платформенных штук (типо названия приложения, версии в системе), то никак. Проблема тут в том, что все эти сведения содержатся в apk, который изменить без установки поверх нового apk с изменениями не получится чисто из-за устройства ОС.
Если речь об обновлении кода, то можно, если использовать mono в качестве бэкенда. С сервера скачивать новые dll, затем подгружать их через Assembly.Load. Таким макаром можно обновлять логику (конечно, нужно проделать доп. манипуляции по выносу загружаемого кода в отдельную библиотеку). Но тут нюанс в том, что таким образом можно в теории загрузить вообще любой код, что по правилам Google Play в относительно серой зоне по дозволенности (можно загружать код, если он в виртуалке и имеет ограниченный доступ к системе).
Но, зная реалии и то, что сейчас в моде il2cpp, всё усложняется. В данном случае нужно уже встраивать какой-нибудь интерпретатор, тот же интерпретатор javascript, а потом с сервера скачивать и выполнять уже js.
TLDR:
Изменять код с mono backend: загрузка с сервера dll + Assembly.Load.
Изменять код с il2cpp backend: загрузка с сервера скриптов + использование интерпретатора
anonymous
Спасибо за ответ. вопрос больше про яблоко с их неадекватным подходом с апрувом версий. Смотрим на топовых издателей и видим как у них после установки игры идет еще загрузка с их серваков и обновления тоже. Поэтому и есть желание делать лоадер, апрувить в стор и уже потом через него грузить основной модуль.
flat-mango Автор
Если вы имеете в виду обновление именно контента, то можно банальными ассет бандлами обойтись (на любой платформе). Но мне изначально показалось, что вы спрашиваете о полностью автономных обновлениях (контент, логика, библиотеки и пр.). В таком случае, как уже говорил, ничего относительно простого и прозрачного не припоминается.
And42, дельный совет, спасибо за комментарий!
anonymous
Для начала рассматривается внедрение новых уровней в игре. Я понимаю., что пейменты и тд. это уже на грани бана, но простое обновление версии с новыми уровнями и багофиксом более 2 недель — это жесть.
propheat
Если говорить за мобайл, то нельзя загружать новый исполняемый код без обновления приложения в сторе, выход один, разбить свою игру на логические блоки и с помощью плэймэйкера/болт, грузить через ассет бандлы новый контент.
anonymous
Спасибо! А ссылкой не поделитесь полезной по данной теме?