Разработка обучающего уровня (Tutorial) мобильной игры
Первые 60 секунд в игре определяют, останется пользователь или удалит. По данным Sensor Tower, 70% мобильных игр теряют пользователя в первую сессию — и большинство этих потерь происходит именно во время туториала или сразу после него. Либо объясняет слишком много, либо не объясняет ничего.
Архитектурные решения
Туториал в мобильной игре — это отдельный контекст с собственным состоянием, логикой прогрессии и системой триггеров. Реализовывать его как набор флагов isTutorialStep1Completed, isTutorialStep2Completed в GameManager — путь к спагетти-коду, который невозможно тестировать и сложно менять дизайнеру без правки кода.
State machine для туториала. Каждый шаг — состояние с условием перехода. Условие может быть: tap в зоне, выполнение игрового действия, истечение таймера, или комбинация. На Unity — StateMachineBehaviour или кастомный TutorialStateMachine с ScriptableObject-конфигурацией для каждого шага. На SpriteKit/iOS — конечный автомат через GKStateMachine из GameplayKit. Коллина Mouchoux предложил хороший паттерн: TutorialStep как протокол с методами activate(), validate() -> Bool, deactivate() — это дает тестируемость каждого шага в изоляции.
Конфигурация из данных, не из кода. Если каждый шаг туториала — JSON/ScriptableObject с текстом, позицией highlight, типом действия — дизайнер может менять туториал без участия разработчика. В Unity это TutorialConfig : ScriptableObject с сериализуемыми TutorialStepData[]. Версионируется в git вместе с остальными ассетами.
Система highlight и маскирования
Самая технически сложная часть туториала — выделение конкретного элемента интерфейса с затемнением остального экрана.
В Unity UI (uGUI) классический подход: Canvas с сортировочным порядком поверх игрового UI, полупрозрачный overlay с вырезанным «окном» над нужным элементом. Вырез делается через RectMask2D или кастомный Image с shader-ом, рисующим прямоугольник/овал с альфа-каналом. Более гибкий вариант — UI Toolkit (USS + UXML) с динамически генерируемым VisualElement-оверлеем.
Проблема: при изменении разрешения или ориентации экрана координаты highlight-зоны должны пересчитываться. Anchor-based система в Unity помогает, но при кастомных highlight-формах нужно слушать Screen.orientation и пересчитывать bounds вручную. На SpriteKit — SKCropNode с маской из SKShapeNode.
Стрелка-указатель. Анимированная стрелка к целевому элементу — SKAction.sequence с moveBy и wait, или в Unity — DOTween с Sequence. Стрелка должна всегда быть направлена к цели, даже если цель анимируется — значит, обновляем rotation каждый кадр в Update() / SKScene.update(_:).
Принудительное vs адаптивное прохождение
Два полярных подхода:
Forced tutorial — нельзя пропустить, нельзя кликнуть мимо. Работает для казуальных игр с простой механикой. Реализуется блокировкой input кроме целевой зоны: в Unity — EventSystem с кастомным IPointerClickHandler на overlay, пропускающим события только через «окно».
Contextual hints — туториал появляется по мере необходимости. Первый раз видишь лук — появляется подсказка как стрелять. Требует системы триггеров: TutorialTrigger компонент на игровых объектах, при активации отправляющий event в TutorialManager. На iOS без Unity — NotificationCenter или Combine pipeline.
Для большинства mid-core игр оптимален гибрид: первые 2–3 шага forced (базовые механики), дальше contextual hints по мере открытия новых систем.
Персистентность прогресса
Прогресс туториала должен переживать перезапуск приложения. На iOS — UserDefaults для простых флагов, CoreData или файл JSON если шагов много и нужны детальные данные. В Unity — PlayerPrefs (но с осторожностью: не используй для чувствительных данных) или кастомный SaveSystem с JSON сериализацией через JsonUtility.
Если игра имеет облачные сохранения (Game Center, Google Play Games, iCloud) — статус туториала должен синхронизироваться. Иначе пользователь, восстановивший игру на новом устройстве, проходит туториал снова.
Skip-кнопка
Давать ли возможность пропустить? Для простых игр — да, опытные пользователи раздражаются от принудительного туториала. Реализуй skipButton с задержкой появления в 3–5 секунд — пользователь видит туториал, но может пропустить если хочет. Логируй пропуски: если 40% пропускают на шаге 2 — шаг 2 либо непонятен, либо слишком очевиден.
Срок: от 3 до 5 дней. Простой туториал из 3–5 forced-шагов — 3 дня. Система с contextual triggers, data-driven конфигурацией, кастомными highlight-эффектами и аналитикой пошагового прохождения — 5 дней.