Создание 2D-анимаций для мобильной игры
Разработчики игр регулярно сталкиваются с одним и тем же провалом: художник сделал красивый спрайт-лист на 60 кадров, аниматор экспортировал атлас 2048×2048, а на устройствах mid-range падает FPS до 18 и греется батарея. Проблема не в анимации — в том, как она попадает в движок и воспроизводится на GPU мобильного чипа.
Где ломается пайплайн анимации в мобильных играх
Самая частая ошибка — попытка использовать покадровую анимацию там, где нужна скелетная, и наоборот. Frame-by-frame в Unity через Sprite Renderer + Animation Clip — это постоянная смена текстуры на каждом кадре. На Snapdragon 680 с его общей памятью CPU/GPU каждый swap текстуры стоит дорого. Если в сцене 15 персонажей с 60-кадровыми анимациями — GPU memory bandwidth уходит в потолок раньше, чем успевает отработать LateUpdate.
Скелетная анимация через Spine 2D или DragonBones — противоположная проблема: разработчики тащат полный runtime с mesh deformation и attachment swapping для простого персонажа с пятью костями. Spine Runtime весит ~500 КБ к APK, и если у вас десять типов врагов — это заметно. Для таких случаев работает Skeletal Animation в Unity's 2D Animation package: он встроенный, поддерживает IK через 2D IK, и до восьми костей работает без заметных оверхедов.
Проблема со спрайт-атласами — несоответствие степеней двойки. Атлас 900×700 вместо 1024×512 не сжимается ETC2/ASTC нормально, текстура занимает в памяти вдвое больше. На Android это критично: большинство устройств ограничены 2–4 ГБ, и при 20 персонажах в сцене OutOfMemoryError приходит неожиданно.
Particle effects — отдельная история. 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), scale down (DOScale) с Ease.InBack, одновременный spawn particle effect. Всё в одном Sequence, один вызов, никаких корутин с WaitForSeconds.
Оптимизация под устройства: делаем три пресета качества — High (60 FPS, полные атласы, все эффекты), Medium (30 FPS, атласы ×0.5, упрощённые частицы), Low (30 FPS, минимальные атласы, без деформации меша). Переключение через QualitySettings.SetQualityLevel при старте по бенчмарку GPU.
Инструменты и форматы
| Задача | Инструмент | Формат вывода |
|---|---|---|
| Скелетная анимация | 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+ персонажами, эффектами и оптимизацией под широкий спектр устройств — до трёх месяцев. Стоимость рассчитывается индивидуально после анализа требований.