Проектування архітектури 2D-локацій: паралакс, тайлмапи, читабельність

Платформа, яка зливається з фоном — гравець промахується при стрибку. Шипи зеленого кольору замість червоного — гравець наступає і дивується. Це не помилки управління, це помилки архітектури 2D-локації. Ми проектуємо архітектуру 2D рівнів так, щоб візуал і геймплей працювали як єдиний механізм. Наш досвід — 5 років у 2D геймдеві, понад 30 проектів. Ми гарантуємо сумісність з Unity 2022 LTS та Unreal Engine 5. Кожна локація проходить етап QA на читабельність та колайдери.

«Архітектура 2D-локації» — це не розстановка декоративних елементів. Це проектування простору, в якому відбуватиметься геймплей: де стоять колайдери 2D, як влаштовані шари глибини (parallax шари), як тайли стикуються без артефактів, як гравець читає напрямок руху та небезпечні зони без додаткових підказок. Розберемо ключові аспекти на прикладах з реальних проектів. У цій статті ми розглянемо layering Unity, tilemap та читабельність локації на конкретних кейсах з мобільних та PC-ігор. Ви дізнаєтеся, як уникнути типових помилок і прискорити розробку.

Як правильно побудувати layering для 2D-локації?

Сучасна 2D-локація складається з багатьох шарів рендерингу. В Unity це Sorting Layers + Order in Layer, в Godot — CanvasLayer з z-індексами. Типова структура:

• Background (BG): статичне небо, далекі гори — мінімальний parallax або статика
• Far Parallax: повільно рухомі далекі об'єкти (0.2–0.4× швидкості камери)
• Mid Parallax: середній план (0.6–0.7×)
• World Layer: ігровий простір — платформи, підлога, стіни з колайдерами
• Character Layer: персонажі, NPCs, вороги
• Foreground: декорації перед персонажем (0 parallax або 1.1–1.3× для зворотного ефекту)
• UI: інтерфейс поверх усього

Помилка в порядку шарів — персонаж рендериться за деревами переднього плану, хоча має бути перед ними. Це виправляється за 30 секунд у налаштуваннях, але виявляється часто лише при фінальному тесті рівня.

Як уникнути артефактів на стиках тайлів?

Для tilemap-локацій ключове питання — правила стикування тайлів. Unity Rule Tile автоматично вибирає потрібний тайл на основі наявності сусідніх тайлів того ж типу. Правильно налаштований Rule Tile прибирає візуальні артефакти на стиках — внутрішні кути, переходи між типами поверхонь. Rule Tile працює швидше ручної розстановки тайлів у 3–5 разів.

Часта проблема: тайли намальовані з неправильними розмірами. Базовий тайл 16×16 px при scale 1.0 має давати рівно 1 юніт в Unity (якщо 16 PPU — pixels per unit). Змішування тайлів різного PPU в одній сцені дає «плаваючі» об'єкти — вони не стикуються, хоча візуально мають.

Collision tiles vs visual tiles. У складних локаціях колайдери не повинні точно збігатися з візуальними тайлами. Трава зверху платформи — візуальний елемент, колайдер проходить по нижньому краю трав'яного шару, не по верхньому. Це дає відчуття, що персонаж стоїть «на траві», а не «на коробці». TilemapCollider2D + CompositeCollider2D об'єднують колайдери тайлів в один mesh — важливо для продуктивності при великій кількості тайлів.

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

Гравець має за 1–2 секунди зрозуміти в локації: де можна пройти, де небезпечно, куди рухатися далі. Це завдання архітектури локації, не UI.

Силуетне правило. Платформи читаються як окремі об'єкти через контрастний силует. Темні платформи на світлому фоні, або світлі на темному — але не однакові за яскравістю. Якщо платформа зливається з фоном, гравець промахується при стрибку — не через неточне управління, а через візуальну плутанину.

Кольоровий код небезпек. Шипи — теплі кольори (червоний, помаранчевий). Кислота — зелений. Лава — червоно-помаранчевий. Електро-пастки — жовтий/синій. Це конвенція жанру, і порушувати її без явної причини — помилка. Гравець знає ці правила з інших ігор.

Напрямні лінії. Паралакс-шари, освітлення, розташування об'єктів створюють «лінії погляду», які направляють гравця. Доріжка монет веде до бонусної зони. Яскравіше освітлення в кінці коридору — там ціль. Це архітектурне рішення, не UI-елемент.

Структура роботи над локацією

1. Reference та mood board — аналоги з ігор жанру + унікальні елементи стилю.
2. Blockout — груба розкладка геометрії з колайдерами, тест геймплею. Без фінального арту.
3. Layer scheme — визначення кількості та типу шарів, parallax коефіцієнтів.
4. Tileset design — тайли з урахуванням Rule Tile правил, PPU, розмірів.
5. Art pass — фінальна графіка, освітлення, атмосферні ефекти.
6. Polish — анімовані елементи (трава, вода), particle effects, ambient sounds.
7. QA — тест колайдерів, тест читабельності на різних роздільних здатностях екрану.

Типові помилки на етапі блокінгу

• Забувають виставити правильне сортування шарів — артефакти рендерингу.
• Використовують один PPU для всіх тайлів, але імпортують спрайти з різною роздільною здатністю — об'єкти «плавають».
• Не залишають зазор між колайдерами для плавного руху — персонаж застрягає на стиках.

Порівняння роздільних здатностей тайлів

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

При замовленні проектування 2D-локації ви отримуєте:

• документацію схеми шарів із зазначенням parallax-коефіцієнтів;
• налаштований Rule Tile для тайлсету;
• колайдери з урахуванням геймплею та readibility;
• фінальний art pass з освітленням та атмосферними ефектами;
• тест читабельності на цільових роздільних здатностях.

Значна увага приділяється візуальній навігації: ми використовуємо AutoTile в Godot для швидкого прототипування — це вдвічі швидше за ручне налаштування. Також ми впроваджуємо техніки frustum culling та GPU instancing для оптимізації продуктивності, що покращує показники FPS у 2–3 рази на великих локаціях. Для прискорення роботи з тайлсетами ми застосовуємо Sprite Atlas, що зменшує кількість Draw Calls на 30-50%. Наші рішення дозволяють заощадити до 40% часу на проектуванні завдяки автоматизації тайлсетів.

[CreateAssetMenu]
public class MyRuleTile : RuleTile<MyRuleTile.Neighbor> {
    public class Neighbor : RuleTile.TilingRuleOutput.Neighbor {
        public const int Any = 3;
        public const int Empty = 4;
    }
    public override bool RuleMatch(int neighbor, TileBase tile) {
        switch (neighbor) {
            case Neighbor.Any: return tile != null;
            case Neighbor.Empty: return tile == null;
            default: return base.RuleMatch(neighbor, tile);
        }
    }
}

За матеріалами документації Unity: Rule Tile

Зв'яжіться з нами, щоб ми оцінили проект та запропонували оптимальну архітектуру. Отримайте консультацію — це безкоштовно.

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. Зв'яжіться з нами — ми розрахуємо економію для вашого проєкту.

Коли скелетна анімація ефективніша за покадрову?

Правило, яке працює на практиці: якщо у персонажа більше 15 унікальних анімацій — Spine економніший за розміром і часом ітерацій. Якщо проєкт стилістично вимагає frame-by-frame (піксель-арт, ротоскопіювання, мультиплікаційний стиль з умисними артефактами) — Aseprite.

Mesh Deformation в Spine — одна з ключових можливостей. Персонаж гнеться органічно, одяг складається, щоки надуваються. Workflow:

1. В Spine створюємо mesh на спрайті (Tools > Mesh > Edit Mesh)
2. Призначаємо ваги вершин до кісток (Weights mode)
3. Встановлюємо кількість вершин виходячи з потрібної деталізації деформації — більше вершин = плавніша деформація, але вища обчислювальна вартість

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

Формати стиснення текстур

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