Розробка обучаючого рівня (Tutorial) для мобільної гри
Перші 60 секунд у грі визначають, залишиться користувач чи видалить. За даними Sensor Tower, 70% мобільних ігор втрачають користувача в першу сесію — й більшість цих втрат відбуваються саме під час туторіалу або одразу після нього. Або пояснює занадто багато, або не пояснює нічого.
Архітектурні рішення
Туторіал у мобільній грі — це окремий контекст зі своїм станом, логікою прогресії та системою триггерів. Реалізовувати його як набір флагів isTutorialStep1Completed, isTutorialStep2Completed у GameManager — шлях до спагеті-коду, що неможливо тестувати та складно змінювати без правки коду.
State machine для туторіалу. Кожен крок — стан із умовою переходу. Умова може бути: tap у зоні, виконання ігрового дій, спливання таймера, або комбінація. На Unity — StateMachineBehaviour або кастомна TutorialStateMachine із ScriptableObject-конфігурацією для кожного кроку. На SpriteKit/iOS — скінченний автомат через GKStateMachine з GameplayKit. Colin 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(_:).
Примусове проти адаптивного проходження
Два полярні підходи:
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) — статус туторіалу повинен синхронізуватися. Інакше користувач, що відновив гру на новому пристрої, проходить туторіал знову.
Кнопка пропуску
Дати можливість пропустити? Для простих ігор — так, досвідчені користувачі дратуються від примусового туторіалу. Реалізуй skipButton із затримкою появи в 3–5 секунд — користувач бачить туторіал, але може пропустити. Логуй пропуски: якщо 40% пропускають на кроці 2 — крок 2 або незрозумілий, або занадто очевидний.
Термін: від 3 до 5 днів. Простий туторіал із 3–5 forced-кроків — 3 дні. Система з contextual triggers, data-driven конфігурацією, кастомними highlight-ефектами та аналітикою пошагового проходження — 5 днів.