Створення 2D-спрайтів для мобільної гри з оптимізацією
Створення 2D-спрайтів для мобільної гри — це не просто малюнки. Ми знаємо, що кожен спрайт має бути оптимізований під GPU, упакований в атласи та вписаний у draw call бюджет. Без цього красивий арт роняє FPS на Android. Наша команда має багаторічний досвід у створенні спрайтів для мобільних ігор та виконала десятки проєктів, де кожен спрайт проходив перевірку на реальних пристроях.
Технічний контекст для спрайтів
Sprite atlas. Безліч окремих PNG — це безліч draw calls. Один атлас 2048×2048 з 50 спрайтами — один draw call. У Unity: Sprite Atlas через Package Manager, автоматична упаковка через SpriteAtlas.Pack(). У Godot: AtlasTexture. Для 2D-гри з сотнями спрайтів атласи обов'язкові — інакше mid-range Android не вивезе.
Компресія текстур. PNG на пристрої займає місце в RAM у стисненому вигляді — 2048×2048 RGBA = 16 МБ GPU пам'яті. Потрібна GPU-нативна компресія: ASTC 6x6 для iOS (сучасні пристрої) та Android (сучасні версії), ETC2 для старих Android (версія 4.4+). У Unity TextureImporter — Compression: High Quality, Format: ASTC 6x6. Втрата якості при ASTC мінімальна для ігрової графіки, економія пам'яті — у 6–8 разів. ASTC забезпечує стиснення в 6 разів краще, ніж PNG без компресії. Додатково варто враховувати пропускну здатність GPU (GPU memory bandwidth) та кількість текстурних семплів.
Як оптимізувати спрайти для різних платформ?
Вибір формату компресії — ключовий крок. Для iOS оптимальний ASTC 6x6, для Android — ASTC 4x4 або ETC2. Якщо гра підтримує старі пристрої, використовуйте ETC2 з fallback на ETC1 для прозорості. У Unity налаштування відбувається через TextureImporter з вибором платформи. Ми гарантуємо, що кожен спрайт пройде тест на еталонних пристроях.
Pivot та Pixels Per Unit. Pivot спрайта (точка обертання) має відповідати логічній точці об'єкта — для персонажа це основа ніг, для снаряда — центр. Pixels Per Unit визначає масштаб у світових координатах. Якщо PPU не узгоджені між спрайтами — персонаж розміром з вежу або піксель розміром з екран.
Анімація спрайтів
Spritesheet vs individual frames. Spritesheet — стандарт: всі кадри анімації в одному PNG на рівних комірках або запаковані через TexturePacker. TexturePacker упаковує щільніше, ніж Unity Sprite Editor, і підтримує експорт для будь-якого рушія.
Spine 2D documentation рекомендує використовувати скелетну анімацію для персонажів, щоб зменшити розмір збірки та підвищити плавність.
Unity Documentation: "Sprite Atlas дозволяє групувати спрайти в одну текстуру, зменшуючи кількість draw calls."
Кадрова анімація в Unity: Animator + AnimationClip з Sprite property keyframes. Для простих анімацій (4–8 кадрів) — Animator Override Controller дозволяє змінювати анімацію без створення нового AnimatorController.
Skeletal animation (Spine, DragonBones). Для персонажів з плавною анімацією — скелетна анімація ефективніша за покадрову. Вона зменшує розмір збірки вдвічі порівняно з покадровою. Spine 2D (платний, ~$69 essential) або безкоштовний DragonBones. Один спрайт-лист з частинами тіла (руки, ноги, тулуб, голова) + кістки + keyframe дані = плавна анімація без малювання 30 кадрів бігу. Spine Runtime для Unity — офіційний пакет від Esoteric Software. Важливо: версія Spine Runtime має збігатися з версією Spine Editor, інакше бінарні файли несумісні.
Що обрати: покадрову чи скелетну анімацію?
Якщо гра потребує плавних переходів (персонажі, тварини) — скелетна анімація заощадить до 40% розміру збірки (у 2 рази менше). Для простих об'єктів (вороги, снаряди) достатньо покадрової. Ми допомагаємо обрати оптимальний підхід під ваш проєкт.
З практики: платформер на Unity, численні унікальні анімаційні стани персонажа. Художник намалював кілька кадрів для кожного — сотні PNG файлів. Атлас не вміщався в 2048×2048, потрібно було два атласи. Після переходу на Spine з тими самими спрайт-частинами — набір атрибутів плюс JSON дані анімацій, один атлас 1024×512. Анімації стали плавнішими, розмір збірки зменшився на значний обсяг. Економія на зберіганні та завантаженні — до 60%, що заощадило близько $2000 на рік.
Стилі та технічні вимоги за типами
| Тип спрайта | Рекомендована роздільна здатність | Формат | Особливості |
|---|---|---|---|
| Персонаж (покадровий) | 128×128 — 512×512 на кадр | PNG + Atlas | Парна кількість кадрів для Spine |
| Тайли фону | 64×64 — 256×256 | PNG + Atlas | Точний збіг країв (seamless) |
| UI-елементи | 2× / 3× роздільна здатність | PNG + 9-slice | 9-slice для кнопок та рамок |
| Ефекти (VFX) | 64×64 — 256×256 | PNG sequence | Particle System в Unity |
| Іконки предметів | 128×128 або 256×256 | PNG + Atlas | Прозорий фон, однаковий стиль |
Порівняння форматів компресії
| Формат | Платформа | Стиснення | Якість |
|---|---|---|---|
| ASTC 6x6 | iOS, Android | 6:1 | Відмінна |
| ETC2 | Android (API 18+) | 4:1 | Добра |
| PVRTC | iOS (застарілий) | 4:1 | Середня |
Типові помилки при створенні спрайтів
- Використання PNG без стиснення в рантаймі (величезна витрата RAM). - Невідповідність Pivot та PPU між персонажами (розміри «стрибають»). - Анімаційні листи з непарною кількістю кадрів (Spine потребує парну). - Відсутність тесту на реальному пристрої (кольори на моніторі спотворюються).Pixel art специфіка
Pixel art потребує додаткових налаштувань. Filter Mode: Point (no filter) в Unity — інакше пікселі згладжуються. Pixels Per Unit = розмір спрайта в пікселях (спрайт 32px = PPU 32). Compression: None — ASTC руйнує чіткість пікселів. Для руху без субпіксельного мерехтіння — Round Sprites to Nearest Pixel в Camera. Також важливо налаштувати mipmapping для зменшення aliasing при віддаленні, але для pixel art mipmapping вимикають (Trilinear filtering викл.) через спотворення пікселів.
Процес створення
- Концепт (нарис стилю, мудборд).
- Чорновик (контури, композиція).
- Чистовик (лінії, кольори).
- Заливка кольором, тіні, світло.
- Тест в рушії: перевірка компресії, розмірів, анімації.
- Правки за технічними зауваженнями.
- Фінальний експорт з налаштуваннями під платформу.
Тест в рушії — обов'язковий крок до фіналізації. Кольори на моніторі художника та на екрані пристрою з AMOLED-дисплеєм можуть відрізнятися. Темні тіні на чорному фоні «провалюються» на некаліброваних екранах. Ми гарантуємо, що кожен спрайт пройде тест на фізичному пристрої.
Що входить в роботу
- Створення спрайтів у узгодженому стилі (за мудбордом або референсами)
- Анімаційні листи для покадрової анімації або rig-ready частини для Spine/DragonBones
- Підготовка атласів під Unity / Godot / Cocos Creator
- Налаштування Pivot, PPU, компресії текстур
- Тест в рушії з корекцією
- Вихідники в PSD / Aseprite (для pixel art)
Терміни та бюджет
Залежить від кількості та складності спрайтів. Один персонаж з базовим набором анімацій (idle, run, jump, attack, death) — 5–10 робочих днів. Повний пакет спрайтів для гіпер-казуальної гри (персонаж + оточення + UI) — 2–6 тижнів. Для великого проєкту — обговорюється індивідуально. Вартість розраховується після аналізу технічного завдання — зв'яжіться з нами для оцінки. Орієнтовна вартість типового пакету для гіпер-казуальної гри — від $2000 до $5000, а оптимізація дозволяє зменшити витрати на зберігання вдвічі.
Отримайте консультацію з оптимізації спрайтів — ми підберемо найкращий пайплайн для вашої гри.