Ми створюємо спрайтові атласи для 2D-ігор — це дає зниження draw calls у 3–10 разів на мобільних пристроях. Десять окремих спрайтів у папці — десять текстурних біндингів при відмальовці. Ті самі десять спрайтів в одному атласі — один біндинг. На мобільному різниця в продуктивності колосальна. Наш досвід — 5+ років у геймдеві та десятки проектів — підтверджує: правильний атлас скорочує час завантаження на 40% і економить до 70% draw calls.
Але атлас — не просто «скласти текстури в одну велику». Неправильно складений атлас дає артефакти, memory waste і не знижує draw calls так, як повинен. Ми гарантуємо якість упаковки та налаштування під цільову платформу.
Технічна база: TexturePacker
TexturePacker — стандартний інструмент для створення спрайтових атласів у геймдеві. Підтримує всі актуальні рушії: Unity, Godot, Cocos2d, Phaser. Ключові налаштування, які визначають якість атласу:
Algorithm. MaxRects BestShortSideFit — найкраща упаковка для більшості проектів (максимальне використання простору текстури). Basic — швидше, але гірша упаковка. Для продакшн-атласів — MaxRects.
Padding. Відстань між спрайтами в атласі. Без padding — bleeding артефакти: при рендерингу спрайта захоплюються пікселі сусіднього спрайта. Стандарт: 2px padding. При використанні міпмапів — 4–8px (міпмапи змішують сусідні пікселі на нижніх рівнях).
Rotation. Дозволити TexturePacker повертати спрайти на 90° для кращої упаковки. Рушій повинен підтримувати це (Unity Sprite Atlas — так, деякі старі рушії — ні).
Power of Two. Фінальний атлас повинен мати розміри кратні ступеню двійки: 512×512, 1024×1024, 2048×2048. GPU кешують текстури power-of-two ефективніше. Нестандартний розмір (наприклад 1000×800) на деяких GPU призводить до автоматичного апскейлу до найближчого ступеня двійки — memory waste.
Як правильно групувати спрайти в атласи?
Найважливіше рішення: які спрайти об'єднати в один атлас.
Правило одного draw call. В один атлас об'єднуються спрайти, які рендеряться одночасно. UI-елементи головного меню — один атлас. Анімаційні кадри одного персонажа — один атлас. Тайли одного біома — один атлас. Змішувати UI, персонажів і тайли в один «загальний» атлас — антипатерн: збільшує розмір текстури без зниження draw calls.
Ліміт розміру атласу. 2048×2048 — безпечний максимум для mobile. 4096×4096 підтримується на більшості сучасних Android/iOS пристроїв, але є винятки (старі бюджетні Android). Перевищення максимального розміру текстури для пристрою = краш або degraded fallback.
Анімаційні атласи. Спрайт-лист (всі кадри анімації в одному атласі) — стандарт для frame-by-frame анімацій. TexturePacker Sprite Sheet Export створює атлас + JSON/XML з координатами кожного кадру. Unity Sprite Editor читає цей JSON через Custom Physics Shape або через автоматичну нарізку по Sprite Editor.
Чому формат стиснення критичний для мобільних ігор?
Формат зберігання текстури в атласі — критичний вибір для продуктивності:
| Платформа |
Формат |
Особливості |
| iOS |
ASTC (4×4 або 6×6) |
Найкраща якість/розмір для iOS A8+ |
| Android (сучасний) |
ETC2 (RGB) / ETC2 RGBA |
GLES 3.0+, підтримується 95%+ пристроїв |
| Android (legacy) |
ETC1 + окремий альфа-канал |
Для дуже старих пристроїв |
| PC/WebGL |
DXT1 / DXT5 |
Стандарт для desktop |
| Універсальний |
RGBA32 |
Без стиснення, максимальна якість, максимальний розмір |
RGBA32 для фінального продакшн-білда — помилка. 2048×2048 RGBA32 = 16МБ відеопам'яті. Та сама текстура в ASTC 4×4 = 2МБ. Різниця × кількість атласів у грі = проблема з пам'яттю на мобільних.
В Unity Platform-specific overrides для Texture Importer дозволяють задати різні формати для iOS і Android без дублювання асетів.
Атлас в Unity: Sprite Atlas Asset
Unity Sprite Atlas (починаючи з версії, що підтримує Sprite Atlas) — нативний інструмент без сторонніх плагінів. SpriteAtlas asset створюється в Project → Create → 2D → Sprite Atlas. Додаються папки або окремі спрайти в Objects for Packing. Unity автоматично пакує атлас при білді.
Важливий нюанс: спрайти повинні мати налаштування Packing Tag або бути додані безпосередньо в Sprite Atlas — інакше вони пакуються як окремі текстури. Змішування атласних і неатласних спрайтів в одному UI Canvas — draw call розривається.
Late Binding (сучасні версії Unity): атлас завантажується лише при першому використанні спрайту, що входить до нього, а не при старті сцени. Критично для великих ігор з багатьма атласами — знижує час завантаження початкової сцени.
Типові артефакти та їх причини
- Bleeding (пікселізація краю): padding = 0 або міпмапи без збільшеного padding
- Пусте місце в атласі (>20%): неоптимальний алгоритм упаковки або несумісні за розміром спрайти
- Draw calls не знизилися: спрайти з різних атласів в одному Canvas або рендер-батчі
- Артефакти повороту: рушій не підтримує rotation, але TexturePacker включив його
Що входить в роботу
- Аудит поточних асетів: список всіх спрайтів, розміри, формати, наявність атласів.
- Групування та розподіл спрайтів по атласах за правилом одного draw call.
- Упаковка: TexturePacker з правильними параметрами під платформу.
- Формат стиснення: налаштування під iOS/Android/PC.
- Інтеграція: імпорт в рушій, налаштування Sprite Atlas, перевірка draw calls (Frame Debugger).
- Профілювання: до і після атласів, підтвердження зниження draw calls.
- Документація та доступи: передача готових атласів, налаштування, рекомендації.
| Масштаб |
Термін |
| Аудит і реструктуризація атласів існуючого проекту |
2–5 днів |
| Створення повного сету атласів для нового проекту (до 500 спрайтів) |
1–2 тижні |
| Оптимізація + налаштування платформених форматів + документація |
2–4 тижні |
Вартість розраховується індивідуально, виходячи з обсягу асетів і кількості платформ. Оцінимо ваш проект безкоштовно. Зв'яжіться для консультації.
2D-арт та анімація
Ми стикалися з проєктами, де 2D-графіка займала 70% місця в збірці. Оптимізація починалася із заміни frame-by-frame на скелетну анімацію. Але важливо не просто перевести спрайти в Spine — потрібно правильно спроектувати риг, упаковку атласів і формат текстур. Наша послуга — повний цикл 2D: від концепт-арту та ілюстрацій до фінальної Spine-анімації з оптимізацією під мобільні платформи.
Мобільна гра з 200 анімаціями персонажів займає 800 МБ лише на текстурах. APK відхиляє Google Play через розмір. При цьому половина анімацій — варіації одного й того ж руху з незначними відмінностями. Це класична проблема команд, які обирали frame-by-frame анімацію там, де скелетна дає кращий результат з часткою розміру.
Наша команда створює 2D-графіку та ілюстрації для ігор будь-яких жанрів — від піксель-арту до реалістичних стилів. Ми працюємо з Unity, Unreal Engine та Godot. Кожна анімація перевіряється на продуктивність: FPS budget, кількість draw calls, розмір текстур.
Що входить у послугу
- Концепт-арт та ілюстрації — персонажі, оточення, UI-елементи, промо
- Спрайт-анімація — frame-by-frame в Aseprite з палітрою та оптимізацією кадрів
- Скелетна анімація — Spine (професійна ліцензія), DragonBones для бюджетних проєктів
- 2D-ефекти — particle-based (Shuriken, VFX Graph) та шейдерні (Shader Graph для URP/HDRP)
- Оптимізація атласів — TexturePacker, Unity Sprite Atlas, стиснення під платформу (ASTC, ETC2, DXT)
Як скелетна анімація зменшує розмір APK?
Spine (Esoteric Software) — де-факто стандарт скелетної анімації для 2D ігор. Скелетна анімація — метод, при якому рух задається кістками та вагами вершин, а не цілими кадрами. В Spine анімація персонажа з 15 анімаціями займає ~2 МБ, frame-by-frame — 10 МБ (в 5 разів більше). Альтернативи — DragonBones (безкоштовний, менше функцій) та нативний 2D Animation package в Unity (зручний, але слабший за Spine за інструментами).
Окупність ліцензії Spine Professional настає при створенні значної кількості унікальних анімацій — кожна покадрова анімація коштувала б у рази більше часу та об'єму. При масштабуванні на велику кількість анімацій економія на одному проєкті стає значною на розробці та трафіку через зменшення розміру APK. Зв'яжіться з нами — ми розрахуємо економію для вашого проєкту.
Коли скелетна анімація ефективніша за покадрову?
| Критерій |
Скелетна (Spine) |
Frame-by-frame (Aseprite) |
| Розмір даних |
Малий (кістки + ваги) |
Великий (кадри як зображення) |
| Гнучкість блендингу |
Висока |
Відсутня |
| Виразність |
Залежить від ригера |
Повна художня свобода |
| Час виробництва |
Довгий ригінг, швидкі ітерації |
Кожна анімація з нуля |
| Підходить для |
Персонажі, UI, істоти |
Піксель-арт, особливий стиль |
Правило, яке працює на практиці: якщо у персонажа більше 15 унікальних анімацій — Spine економніший за розміром і часом ітерацій. Якщо проєкт стилістично вимагає frame-by-frame (піксель-арт, ротоскопіювання, мультиплікаційний стиль з умисними артефактами) — Aseprite.
Mesh Deformation в Spine — одна з ключових можливостей. Персонаж гнеться органічно, одяг складається, щоки надуваються. Workflow:
- В Spine створюємо mesh на спрайті (Tools > Mesh > Edit Mesh)
- Призначаємо ваги вершин до кісток (Weights mode)
- Встановлюємо кількість вершин виходячи з потрібної деталізації деформації — більше вершин = плавніша деформація, але вища обчислювальна вартість
Path Constraints — кістка слідує по кривій. Використовується для хвостів, волосся, щупалець, мотузок — будь-яких елементів, які повинні згинатися органічно.
IK Constraints в Spine працюють через дво- або трикісткову ланцюжок. Для кінцівок це обов'язково: аніматор рухає IK target (позицію долоні), а ланцюжок плече-передпліччя-кисть вибудовується автоматично. Без IK анімувати кінцівки в FK — витрачати вдвічі більше часу.
Як інтегрувати Spine у Unity?
Офіційний Spine-Unity runtime — активно підтримується. Компоненти:
-
SkeletonAnimation — основний компонент для анімації
-
SkeletonMecanim — інтеграція з Animator Controller Unity (зручно для перевикористання Mecanim-логіки)
-
SkeletonGraphic — для Canvas/UI (рендериться через CanvasRenderer, не через MeshRenderer)
Важливий момент продуктивності: SkeletonAnimation створює окремий Mesh per instance. При 50+ персонажах на екрані це 50 draw calls мінімум (без батчингу). Рішення — SkeletonAnimation Batching через SubmeshSeparator + GPU instancing, або обмеження кількості одночасно видимих Spine-об'єктів.
Spine Events — механізм синхронізації: подія в анімації (footstep, attack_hit, spawn_particle) диспатчиться в Unity-код через AnimationState.Event. Правильна архітектура: Spine Event → UnityEvent → звук/партікл/логіка. Не хардкодити синхронізацію за часом — анімація може сповільнюватися через timeScale.
Як зменшити draw calls у 2D UI за допомогою атласів?
Кожен окремий спрайт в Unity створює окремий draw call. 100 UI-іконок без атласу = 100 draw calls лише на UI. Sprite Atlas пакує спрайти в єдину текстуру, дозволяючи батчити draw calls для об'єктів, що використовують один атлас. Texture atlas — техніка, що застосовується в 3D і 2D для зниження числа перемикань текстур.
TexturePacker проти Unity Sprite Atlas
TexturePacker (CodeAndWeb) — зовнішній інструмент, більш гнучкий у налаштуванні упаковки. Підтримує безліч алгоритмів упаковки, trim прозорих пікселів, extrude країв для запобігання bleeding, експорт у специфічні формати платформ (PVRTC для iOS, ETC2 для Android). Ліцензія окупається на першому проєкті з атласами.
Unity Sprite Atlas (вбудований) — зручний для Addressables та динамічного завантаження. Два режими: Master Atlas (повний контроль) і Variant Atlas (зменшена версія для low-end пристроїв через Scale Factor).
Практичні правила упаковки:
- Групувати за сценою/екраном: все, що видно одночасно — в одному атласі. Інакше atlas не допомагає з батчингом
- Максимальний розмір атласу: 2048x2048 для мобільних, 4096x4096 для ПК. Більше — ризик проблем на старих GPU
- Trim прозорих пікселів: обов'язково. Спрайт з великими прозорими полями марно займає місце в атласі
- Padding: 2-4 пікселі між спрайтами запобігає texture bleeding при mipmapping і UV filtering
Формати стиснення текстур
| Платформа |
Рекомендований формат |
Примітка |
| Android |
ETC2 (RGB) / ETC2 RGBA8 |
Апаратне прискорення на всіх сучасних Android |
| iOS |
ASTC 4x4 / 6x6 |
ASTC універсальний: якість + розмір |
| ПК/Консолі |
DXT5 (BC3) |
Або BC7 для високої якості |
| WebGL |
DXT5 + fallback |
Перевірити підтримку через SystemInfo |
Для атласів з великою кількістю дрібних спрайтів і sharp краями — ASTC 4x4 переважніший за ASTC 6x6 (менше артефактів на дрібних деталях).
Що дає оптимізація 2D-асетів на практиці?
Кожен із цих пунктів перевірено на десятках проєктів: trim прозорих пікселів в атласі (економія до 30% площі), padding 2–4 пікселя (усуває bleeding), максимальний розмір атласу 2048x2048 для мобільних (стабільна робота на старих GPU), використання ASTC 4x4 для iOS і ETC2 для Android, Mesh Deformation в Spine замість зайвих кісток для щік і складок одягу, групування UI-елементів по екранах у різні атласи. Замовте розробку 2D-анімації з гарантією продуктивності — ми врахуємо всі нюанси вашого стеку та платформи.
Який пайплайн для 2D-ефектів обрати?
Particle System (Shuriken) — для більшості 2D-ефектів достатньо вбудованого. Для 2D важливо: Renderer Mode = Billboard або Horizontal Billboard, Simulation Space = World для ефектів, які не повинні рухатися з персонажем.
Visual Effect Graph (VFX Graph) в URP — GPU-based particles, підходить для складних ефектів з тисячами частинок. Для мобільних — обережно, вимагає Compute Shaders (не всі пристрої підтримують).
Shader Graph для 2D: dissolve-ефекти, outline через SDF, distortion (water, heat shimmer), анімовані UV (лава, вода). Sprite Lit Shader + кастомні ноди в Shader Graph — стандартний шлях для 2D в URP.
2D Animation Package (нативний Unity): PSDImporter для імпорту шарів з Photoshop як окремих спрайтів, Sprite Skin для скелетної анімації всередині Unity без Spine. Підходить для простих персонажів з обмеженою кількістю анімацій — якщо команда не хоче купувати ліцензію Spine (Professional або Enterprise). Ці витрати окупаються за один проєкт, якщо анімацій більше 15.
Ми готові розробити 2D-графіку та анімацію для вашої гри. Зв'яжіться з нами, щоб обговорити деталі та отримати консультацію з оптимізації асетів. Отримайте прикидку вартості та термінів на основі вашого ТЗ — ми відповімо протягом робочого дня.