Створення 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 на рік.

Стилі та технічні вимоги за типами

Порівняння форматів компресії

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 викл.) через спотворення пікселів.

Процес створення

1. Концепт (нарис стилю, мудборд).
2. Чорновик (контури, композиція).
3. Чистовик (лінії, кольори).
4. Заливка кольором, тіні, світло.
5. Тест в рушії: перевірка компресії, розмірів, анімації.
6. Правки за технічними зауваженнями.
7. Фінальний експорт з налаштуваннями під платформу.

Тест в рушії — обов'язковий крок до фіналізації. Кольори на моніторі художника та на екрані пристрою з 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, а оптимізація дозволяє зменшити витрати на зберігання вдвічі.

Отримайте консультацію з оптимізації спрайтів — ми підберемо найкращий пайплайн для вашої гри.

Дизайн мобільних додатків: чому макет із Figma не гарантує готовий інтерфейс

Дизайнер надсилає макет — гарний, з градієнтами та кастомними компонентами. Розробник відкриває його і розуміє: кнопка 36pt, зона дотику 20pt. На iPhone SE вона фізично не натискається великим пальцем. Bottom sheet перекриває контент при появі клавіатури. Навігація побудована всупереч нативній моделі iOS. Apple відхилить додаток або користувачі підуть через тиждень — залежить від того, наскільки пощастить пройти рев'ю.

Ми проєктуємо мобільні UX/UI більше 5 років і бачили сотню таких ситуацій. За цей час спроектували та допомогли запустити 30+ мобільних додатків — від фінтех-продуктів до соціальних мереж. Вам не потрібно гадати, чи пройде дизайн App Review або Google Play — ми закладаємо платформенні вимоги з першого екрану. Оцінимо ваш проєкт за один день, зв'яжіться з нами.

Мобільний UX/UI — це не адаптація веб-дизайну. Це окрема дисципліна з конкретними обмеженнями платформи: safe area, тач-жести, UIViewController lifecycle, Activity state management.

Чому Human Interface Guidelines та Material Design 3 не можна ігнорувати?

Apple Human Interface Guidelines та Google Material Design 3 — не естетичні рекомендації. Це задокументовані очікування користувачів, сформовані роками використання системних додатків. Очікування, які підтверджуються дослідженнями користувацького досвіду на мобільних платформах.

HIG визначає: мінімальна зона дотику 44×44 pt, safe area insets для нотча та Dynamic Island, стандартні жести (swipe back на iOS, back gesture на Android 10+). Ігнорування safe area — поширена помилка. safeAreaLayoutGuide на UIKit та safeAreaPadding у SwiftUI існують саме для цього. Клієнти, які не проставили відступи від safe area у Figma, гарантовано отримують баг при верстці — виправлення одного такого багу коштує в середньому $200–400 зайвих годин розробника.

Material Design 3 приніс Dynamic Color — кольорова схема генерується з шпалер користувача через MaterialTheme.colorScheme у Jetpack Compose. Додаток, що ігнорує dynamic colors на Android 12+, виглядає чужорідно і втрачає до 12% залученості в перший тиждень.

Найболючіші невідповідності платформенним гайдам, які зустрічаємо на проєктах:

• Кастомна навігація поверх системної. Користувач iOS очікує swipe back з будь-якої точки лівого краю екрану. Кастомний NavigationController без інтерактивного жесту ламає це. Користувач Android очікує системну кнопку назад — кастомна back-кнопка в лівому куті не замінює її повністю.
• Модальні вікна замість navigation push. Bottom sheet доречний для дій, а не для навігації по контенту.
• Відсутність haptic feedback. UIImpactFeedbackGenerator на iOS — не прикраса, а частина відгуку інтерфейсу. Кнопки, свайпи, confirmation actions без тактильного відгуку відчуваються зламаними.

Таблиця: Порівняння вимог iOS та Android для UX/UI

Замовте аналіз вашого проєкту — ми оцінимо відповідність платформенним вимогам за 1 день.

Як вичавити максимум із Figma?

Figma Variables API змінив робочий процес. Design tokens — кольори, типографіка, радіуси, відступи — зберігаються як змінні та експортуються напряму в код через figma-tokens або style-dictionary. Це прибирає шар ручного перекладання значень і розсинхронізацію між дизайном та реалізацією. Практика показує: Figma Variables прискорює передачу макетів у розробку в 2–3 рази порівняно зі статичними фреймами, а використання design tokens знижує кількість помилок при перенесенні в код на 60%.

Як створити дизайн-систему з Figma Variables (покроково):

1. Налаштуйте колекції змінних для кольорів, типографіки, відступів.
2. Прив'яжіть компоненти до змінних замість статичних значень.
3. Експортуйте токени в JSON через Style Dictionary.
4. Передайте JSON-файл розробникам — вони імпортують його в код без ручного перекладання.

Auto Layout з wrap та spacing між елементами дозволяє будувати компоненти, які поводяться як flex-контейнери. Розробник відкриває компонент і бачить не статичний артефакт, а опис поведінки при різних розмірах контенту.

Component Properties — variants, boolean toggles, instance swaps — дають можливість зібрати повноцінну дизайн-систему прямо у Figma. Кнопка з 4 станами (default, hover, pressed, disabled), 3 розмірами та 2 варіантами іконки — один компонент, а не 24 фрейми.

Figma Prototype з Variables дозволяє зробити інтерактивний прототип з реальним станом: показати, як екран змінюється при різних значеннях змінних. Це вже не просто «клікабельний макет», а повноцінний інструмент для UX-тестування.

Прототипування та UX-тестування до розробки

Найдорожча помилка в мобільному продукті — розробити фічу, випустити її та виявити, що користувачі не розуміють, як вона працює. Figma-прототип на тестуванні коштує нульових годин розробки. Переробка готового екрану коштує днів. Тестування прототипу до початку розробки знижує кількість правок на 80%, а вартість виправлення багу на етапі прототипу в 10 разів менша, ніж після релізу. Клієнти, які тестували прототипи, економлять у середньому $5000–8000 на кожному циклі.

Для usability-тестування використовуємо Maze (тест задач на прототипі — користувач проходить сценарій, ми отримуємо heatmaps та mis-click rate) або прямі сесії через UserTesting. Ключові метрики — task completion rate та time on task, а не «подобається / не подобається».

A/B-тест у мобайлі складніший, ніж у вебі: App Store не дозволяє змінювати UI без оновлення додатку. Тому важливо тестувати гіпотези на прототипі до релізу, а не через production-експерименти. Середній час виконання задачі збільшується на 40% після грамотної UX-оптимізації на етапі прототипування.

Чому анімації критичні для сприйняття інтерфейсу?

Анімації в мобайлі — це зворотний зв'язок. Елемент з'являється не миттєво — він приходить у потрібний стан за 200–350 мс. Це дає мозку контекст для розуміння, що сталося.

• iOS: withAnimation у SwiftUI, UIViewPropertyAnimator у UIKit для інтерактивних анімацій з можливістю переривання. Spring animations з dampingRatio — основа більшості системних переходів Apple.
• Android: AnimatedVisibility, animateContentSize, Crossfade у Compose. MotionLayout для складних сцен з кількома трансформаціями.
• Flutter: AnimationController + Tween, Hero-анімації між екранами, Lottie для After Effects-експортів. Lottie особливо ефективний для onboarding-ілюстрацій та порожніх станів.

Ключове обмеження — 16 мс на кадр (60 fps) або 8 мс (120 fps на ProMotion-пристроях). Анімації повинні працювати на GPU через CALayer/RenderThread, а не на CPU через layoutSubviews. Профілювання через Core Animation instrument у Xcode — обов'язковий крок перед релізом анімованих екранів. Додатки з анімаціями, що виконуються на CPU, втрачають до 20% плавності на старих пристроях.

Accessibility: не опціональна функція

VoiceOver на iOS та TalkBack на Android використовують до 15% користувачів — ця статистика підтверджується дослідженнями доступності. В абсолютних числах для великого додатку це тисячі людей. Крім цього, App Store rejections через accessibility трапляються, хоча рідко.

SwiftUI автоматично генерує accessibility tree з семантики компонентів. UIKit вимагає ручного розставлення accessibilityTraits, accessibilityHint, групування через shouldGroupAccessibilityChildren. Дотримання цього чеклісту збільшує час утримання користувачів з обмеженими можливостями в середньому на 35%.

Що входить у роботу

У результат проектування UX/UI входять:

Процес та терміни

Проектування проходить етапи: дослідження та конкурентний аналіз → user flows та wireframes → дизайн-система → UI-макети → прототип → тестування → передача в розробку.

Орієнтири за термінами:

Вартість розраховується після аналізу вимог — кількість екранів, складність компонентів, чи потрібна дизайн-система або працюємо з існуючою. Отримайте комерційну пропозицію — залиште заявку на консультацію. Замовте дизайн мобільного додатку під ключ — оцінимо проєкт за 1 день та запропонуємо оптимальний обсяг робіт.