Створення 2D-анімацій для мобільних ігор
Розробники ігор регулярно стикаються з однією й тією ж проблемою: художник створив гарний спрайт-лист з 60 кадрів, аніматор експортував атлас 2048×2048, а на пристроях середнього рівня fps падає до 18 і батарея нагрівається. Проблема не в анімації — в тому, як вона потрапляє в movimento і відтворюється на GPU мобільного чипа.
Де ламається конвеєр анімацій у мобільних іграх
Найпоширеніша помилка — спроба використовувати покадрову анімацію там, де потрібна скелетна, та навпаки. Frame-by-frame у Unity через Sprite Renderer + Animation Clip означає постійну заміну текстури кожен кадр. На Snapdragon 680 зі спільною пам'яттю CPU/GPU кожна заміна текстури коштує дорого. Якщо сцена має 15 персонажів з 60-кадровими анімаціями — пропускна спроможність GPU потрапляє в стелю, перш ніж LateUpdate встигне закінчитися.
Скелетна анімація через Spine 2D або DragonBones — протилежна проблема: розробники тягнуть повний runtime з mesh deformation та attachment swapping для простого персонажа з п'ятьма костями. Spine Runtime важить ~500 КБ в APK, і з десятьма типами ворогів це додає вагу. Для цих випадків Skeletal Animation у пакеті Unity 2D Animation працює добре: він вбудований, підтримує IK через 2D IK, і до восьми костей працюють без помітних overhead.
Проблеми зі спрайт-атласами виникають з невідповідності степенів двійки. Атлас 900×700 замість 1024×512 не стискується нормально ETC2/ASTC, займаючи вдвічі більше пам'яті. На Android це критично: більшість пристроїв обмежені 2–4 ГБ, і з 20 персонажами на екрані OutOfMemoryError приходить несподівано.
Ефекти частинок — окрема історія. ParticleSystem у Unity з неправильним Simulation Space (World замість Local) спричиняє додатковий draw call на кожен ефект. На бюджетних Android-пристроях сцена з 10 активними системами частинок дає 40+ draw calls лише від ефектів. Вирішується правильним batching через GPU Instancing та обмеженням Max Particles залежно від рівня пристрою через SystemInfo.graphicsMemorySize.
Побудова конвеєру анімацій
Почніть з інвентаризації: кількість унікальних персонажів, одночасно на екрані, цільовий FPS (30 або 60), мінімальна підтримувана версія Android API та iOS.
Для персонажів з 8+ костями та attachment swapping — Spine 2D з його компонентом SkeletonAnimation та AnimationState для blending між станами. Для простих NPC або UI-персонажів — Unity 2D Animation з PSD Importer, де художники працюють прямо в Photoshop з rigged шарами.
Спрайт-атласи збираються через Unity's Sprite Atlas з Allow Rotation та Tight Packing. Формат — ASTC 6×6 для iOS, ETC2 для Android. На старіших Android (API 19–21) ASTC не підтримується — там ETC2 з fallback на ETC1 для RGB без альфа.
Для ефектів переходів між станами — DOTween Pro з Sequence. Наприклад, анімація смерті персонажа: fade out спрайта (DOFade), масштабування вниз (DOScale) з Ease.InBack, одночасне породження ефекту частинок. Все в одній Sequence, один виклик, без корутин з WaitForSeconds.
Оптимізація для пристроїв: створіть три пресети якості — High (60 FPS, повні атласи, всі ефекти), Medium (30 FPS, атласи ×0,5, спрощені частинки), Low (30 FPS, мінімальні атласи, без mesh deformation). Переключення через QualitySettings.SetQualityLevel при запуску на основі GPU benchmark.
Інструменти та формати
| Завдання | Інструмент | Формат виходу |
|---|---|---|
| Скелетна анімація | Spine 2D 4.x | .skel + .atlas |
| Простий риггинг | Unity 2D Animation | Вбудований |
| Ефекти частинок | Unity VFX Graph / Particle System | .prefab |
| Покадрова анімація | Aseprite → Texture Packer | Sprite Atlas PNG |
| UI анімація | DOTween Pro | Code-driven |
| Профілювання | Unity Profiler + GPU Usage | — |
Етапи роботи
Почніть із технічного завдання по анімаціям: список станів кожного персонажа (idle, run, attack, death, hit), вимоги до blending, формат вихідників від художника. Без цього документа не починаємо — переробка анімаційного конвеєру посередині проєкту коштує дорого.
Далі: риггинг та експорт з Spine або налаштування 2D Animation у Unity → імпорт та налаштування атласів → збірка AnimatorController або AnimationState machine → інтеграція з ігровою логікою → профілювання на цільових пристроях → оптимізація.
Тестування обов'язково на реальних пристроях: Samsung Galaxy A32 (Snapdragon 720G) для Android mid-range, iPhone SE 2nd gen для iOS low-end. Якщо цільовий FPS тримається там — на флагманах буде чудово.
Часові шкали залежать від кількості персонажів та складності анімаційного дерева. Простий проєкт з 3–5 персонажами та базовими анімаціями — від двох тижнів. Повнофункціональний action з 15+ персонажами, ефектами та оптимізацією для широкого спектру пристроїв — до трьох місяців. Вартість розраховується індивідуально після аналізу вимог.