Створення іконок та UI-елементів мобільної гри

Створення іконок та UI-елементів мобільної гри

Ігровий інтерфейс — не веб-іконки і не корпоративний UI. Він повинен працювати на екранах від 4.7" до 6.7", читатися під час активного геймплею (поки гравець стежить за тим, що відбувається, а не за інтерфейсом), передавати стиль гри без тексту. Наша команда має понад 5 років досвіду на ринку ігрового UI: понад 30 успішних проєктів, від гіперказуалок до RPG. Ми гарантуємо якість кожного елемента, використовуючи перевірені техніки оптимізації. При цьому ключовий біль — пакування текстур без втрати продуктивності та єдиний стиль на всіх екранах. Помилки в 9-slice або атласах призводять до перевитрати пам'яті та падіння FPS. Розберемо, як цього уникнути.

Мінімальний tap target — 44×44pt — Apple HIG.

Технічні вимоги для ігрового UI

• Розміри та щільність: Мінімальний tap target за Apple HIG — 44×44pt. Для ігрових кнопок в екшн-грі краще 60×60pt і більше, гравець натискає не дивлячись. Дрібні іконки в інвентарі — від 64×64px до 128×128px залежно від кількості на екрані.
• Чому 9-slice критичний для кнопок?: Кнопки та рамки не просто розтягуються — вони масштабуються через 9-slice: кути фіксовані, краї тягнуться. У Unity Sprite Editor → Sprite Border задає межі. Одна кнопка 40×40px з 9-slice працює для кнопки 80×200px без спотворень.
• Sprite Atlas: пакування UI: Усі UI-елементи одного екрана — в одному атласі. Unity UI → Canvas → Render Mode: Screen Space Overlay малює все за один раз за умови одного Material / Atlas. Різні атласи для HUD (постійно на екрані) та інвентарю (відкривається рідко).
• Налаштування піксельної щільності: Для pixel art UI — Filter Mode: Point, Compression: None. Для векторно-намальованого UI — ASTC 6x6 нормально. Іконки з тонкими лініями (1–2px) погано переносять ASTC — потрібно ASTC 4x4 або без компресії.

Типові ігрові UI-елементи

HUD: постійний інтерфейс

Смуга здоров'я, мана, досвід, рахунок, таймер — постійно на екрані під час геймплею. Повинні бути мінімально інвазивні: займати краї екрана, не перекривати ігрову область. Safe Area на iPhone з notch — завжди враховуємо.

Іконки предметів: система фреймів

Однаковий фрейм + унікальний предмет. Система: фрейм за рідкістю (сірий — звичайний, синій — рідкісний, золотий — легендарний) + іконка предмета на ньому. Фрейми — один атлас, іконки предметів — окремий (додаються в міру виходу контент-патчів без переробки атласу фреймів).

Кнопки: стани та анімація

Normal, Pressed (scale 0.95 + tint), Disabled (opacity 50%). У Unity Button: ColorTintTransition або AnimationTransition з анімацією через Animator. Для критичних кнопок (купити за реальні гроші) — Highlighted стан з glow ефектом.

З практики: RPG колектор, Unity

Іконки предметів робилися окремими PNG без атласу — 200 іконок × 2 draw call кожна = 400 зайвих draw calls на екрані інвентарю. FPS в інвентарі падав до 40. Після пакування в 2 атласи 2048×2048 — draw calls інвентарю стали 8, FPS — 60.

Як пакування в атласи впливає на продуктивність?

Використання атласів безпосередньо знижує кількість draw calls. Ось порівняння для типового екрану інвентарю:

Економія очевидна — правильне пакування звільняє ресурси для геймплею. Вартість окремої іконки предмета з фреймом — від 1000 до 3000 гривень залежно від складності. Завдяки 9-slice та атласам продуктивність зростає в 5 разів порівняно з неоптимізованим UI.

Анімовані UI-елементи

Particle effects в канаві

Canvas Particle System в Unity — система частинок, що працює в Canvas space. Для збору монет, level up ефектів, нагород. Sort Layer повинен бути вищим за ігрові об'єкти, але нижчим за головний HUD.

Tween-анімації: DOTween

DOTween (Unity) або LeanTween — стандарт для ігрового UI. Bounce при отриманні нагороди: transform.DOPunchScale(Vector3.one * 0.3f, 0.3f). Shake при помилці: transform.DOShakePosition(0.3f, 5f). Флоатинг текст при отриманні XP: DOTween.Sequence() з Move + Fade.

Шрифти в ігровому UI

Ігровий шрифт — частина арт-стайлу. TMP (TextMeshPro) в Unity — стандарт, SDF рендеринг читаємий у будь-якому масштабі. Кириличні шрифти вимагають окремої генерації TMP Font Asset з кириличним Character Set (Window → TextMeshPro → Font Asset Creator). Fallback шрифти — для emoji або спеціальних символів.

Процес та обсяг робіт

Що входить у проєкт

• Іконки предметів / персонажів / здібностей в єдиній стилістиці
• Фрейми за рідкістю / типом
• HUD елементи: смуги, лічильники, таймери
• Кнопки в кількох станах (normal, pressed, disabled)
• Панелі, рамки, фони діалогів з 9-slice
• Іконка додатку для iOS та Android (включаючи адаптивну)
• Експорт у правильних розмірах + налаштовані атласи для Unity / Godot
• При необхідності: анімовані елементи (іконки нагород, ефекти)

Приблизний кошторис термінів

Базовий UI-kit для одного екрана (10–20 елементів) — 3–7 робочих днів, вартість від 50 000 до 100 000 гривень. Повний UI-kit для гри (HUD, інвентар, меню, магазин, іконки предметів) — 1–3 тижні. Вартість розраховується індивідуально, орієнтовно від 150 000 до 400 000 гривень залежно від складності. Зв'яжіться з нами — оцінимо ваш проєкт за 1 день.

Покроковий процес створення UI

1. Визначення стилістики та збір референсів.
2. Створення базових форм у векторі або растрі.
3. Перевірка на реальному пристрої з урахуванням safe area та щільності.
4. Пакування в атласи з правильним 9-slice.
5. Експорт з налаштуваннями: ASTC для текстур, Point для pixel art.

Які формати експорту оптимальні для різних типів іконок?

Замовте оцінку вашого проєкту — отримайте консультацію з пакування атласів та стилю. Ми надаємо гарантію на всі роботи та сертифікати про проходження курсів Unity.

Дизайн мобільних додатків: чому макет із 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 день та запропонуємо оптимальний обсяг робіт.