Створення браузерних ігор на WebGL: від прототипу до деплою

Клієнт приходить із прототипом на Unity: гра відмінно працює в редакторі, але після збірки в WebGL браузер видає Out of Memory або завантаження триває 30 секунд. Згідно з дослідженнями, 40% користувачів покидають сторінку, якщо час завантаження перевищує 3 секунди. WebGL — це 256 МБ пам'яті за замовчуванням, один потік, відсутність доступу до файлової системи та Safari зі своїми quirks. Ми займаємося розробкою WebGL-ігор під ключ із 2014 року. За 10+ років виконали понад 50 проєктів: гіпер-казуальні ігри для маркетингу, освітні симулятори, інтерактивні 3D-презентації. Наш досвід показує: без глибокої оптимізації проєкт не запуститься у половини аудиторії. Ми допомагаємо пройти шлях від прототипу до деплою, гарантуючи стабільну роботу на всіх цільових браузерах.

Чим WebGL відрізняється від нативного білда

Пам'ять — головне обмеження

Unity WebGL компілює C# у WebAssembly через IL2CPP і запускає все в одному браузерному потоці. Браузер виділяє лінійну пам'ять (Heap) при старті — за замовчуванням 256 МБ. Перевищення цього ліміту призводить до Out of Memory і крашу сторінки.

На практиці це означає:

• Всі ассети, завантажені через Resources.Load або Addressables, живуть в одному пулі пам'яті разом із wasm-кодом і стеком.
• Текстури потрібно стискати агресивно: ETC2 та ASTC не підтримуються WebGL — тільки DXT (Desktop) та PVRTC (Safari/iOS, з застереженнями). Використовуємо crunch compression + fallback на нестислі для Safari.
• AudioClip у форматі WAV — 40 МБ. Той самий кліп у Vorbis (OGG) — 3 МБ. У контексті 256 МБ heap це критично.

Для проєктів з великим обсягом контенту переходимо на ліміт у 512 МБ через PlayerSettings.WebGL.memorySize, але пам'ятаємо: це резервується одразу при завантаженні сторінки, незалежно від фактичного використання. Скорочення draw calls на 30% за рахунок batching та occlusion culling також знижує навантаження на пам'ять.

Як боротися з обмеженням пам'яті в WebGL?

Відсутність багатопоточності та workarounds

WebAssembly threading потребує SharedArrayBuffer, який заблоковано на більшості хостингів без правильних CORS-заголовків (Cross-Origin-Opener-Policy: same-origin + Cross-Origin-Embedder-Policy: require-corp). На практиці threading вмикаємо тільки якщо контролюємо сервер.

Без threading всі завдання — фізика, анімації, аудіо-декодування — виконуються в головному потоці. Це обмеження змушує інакше думати про архітектуру:

• Coroutines з yield замість важких Update() циклів — дозволяє розмазати обчислення по кадрах.
• Burst Compiler у WebGL працює і без threading — компілює гарячі шляхи в SIMD-оптимізований wasm, знижуючи час виконання на 20-40%.
• Алгоритми з O(n²) складністю, які непомітні на PC, вбивають framerate в браузері.

Як зменшити розмір білда та час завантаження?

Стандартний Unity WebGL білд без оптимізації важить 30-60 МБ (gzip). Користувач чекає завантаження — і йде. Оптимізуємо:

• Managed Stripping Level: High — видаляє невикористовуваний .NET код. Економить 5-15 МБ.
• IL2CPP Code Generation: Faster runtime для продакшну (повільніша компіляція, швидший runtime).
• Brotli compression замість gzip — сервер повинен підтримувати Content-Encoding: br. Стиснення краще на 15-20%.
• Addressables для ассетів — завантажуємо тільки те, що потрібно для поточної сцени, решта на вимогу.

Реальний кейс: гіпер-казуальна гра для маркетингової кампанії. Початковий білд — 48 МБ gzip. Після stripping, оптимізації текстур та розбивки на Addressable-бандли — 11 МБ початкове завантаження, решта ассетів підвантажувалися у фоновому режимі. Час до першого геймплею скоротився з 18 до 4 секунд. Економія бюджету на хостинг склала 40% за рахунок меншого трафіку.

Чому WebGL-гра може не працювати на Safari?

Safari реалізує WebGL інакше, ніж Chrome, і не підтримує threading. Також відрізняється робота з пам'яттю: на iOS WebGL-контекст може бути скинутий при нестачі ресурсів. Ми тестуємо на реальних пристроях за допомогою BrowserStack та LambdaTest, щоб гарантувати сумісність. Замовте аудит вашого WebGL-проєкту — ми виявимо вузькі місця та запропонуємо рішення.

Що входить в нашу роботу

• Аналіз вимог та цільових браузерів
• Архітектура ассетів з Addressables
• Розробка та оптимізація під WebGL
• QA на реальних пристроях
• Деплой з правильними MIME-типами та CDN
• Документація по збірці та підтримці

Стек та інструменти

Двигун: Unity актуальної LTS, URP (Built-in pipeline для WebGL небажаний — legacy). ShaderGraph з обмеженнями: деякі ноди не транслюються в WebGL GLSL коректно, перевіряємо через Preview в редакторі.

Взаємодія з браузером: JavaScript-плагіни через jslib файли в Assets/Plugins/WebGL/. Виклик JS із C# через [DllImport("__Internal")]. Виклик C# із JS через SendMessage() або через Module.dynCall. Для складних інтеграцій (OAuth, платіжні системи, analytics) — власна JS-обгортка поверх Unity.

Мультиплеєр у WebGL: WebSocket замість UDP. Mirror з Transport SimpleWebTransport — працює через WSS. Photon Fusion підтримує WebGL через WebSocket relay. Latency вища, ніж UDP, — закладаємо в дизайн.

Аналітика та реклама: UnityAds для WebGL працює через iframe. Для власної аналітики — прямі виклики через jslib до Google Analytics / Amplitude. Firebase SDK у WebGL — лише Firebase Analytics та Firestore (Auth та Realtime Database — обмежено).

Сумісність браузерів

Тестуємо на реальних пристроях. BrowserStack або LambdaTest — для автоматизації.

Процес розробки

1. Аналіз вимог (2-3 дні). Визначаємо: цільові браузери, вимоги до пам'яті, чи потрібен мультиплеєр, інтеграція із зовнішніми сервісами (авторизація, платежі, аналітика). WebGL-проєкт починається з обмежень, а не з фіч.
2. Архітектура ассетів. Плануємо Addressable Groups на старті — які ассети в початковому білді, що підвантажується по ходу. Помилка — додавати Addressables в середині проєкту: це рефакторинг всіх шляхів завантаження.
3. Розробка та оптимізація. Паралельно з розробкою — регулярні білди та замір розміру через Build Report. Unity Profiler працює для WebGL через Development Build + віддалене профілювання з редактора.
4. QA на цільових платформах. Обов'язково: реальний мобільний Safari, реальний Chrome на Android mid-range пристрої. Емулятори в DevTools не відображають реальне споживання пам'яті та GPU throttling.
5. Деплой. Nginx з правильними MIME-типами (.wasm → application/wasm, .data → application/octet-stream) та Brotli/gzip. CDN для статики — завантаження ассетів з edge-ноди замість origin суттєво знижує час до першого кадру.

Терміни — від 1-2 тижнів для простих казуальних ігор до 2 місяців для мідкор-проєктів з мультиплеєром та складною інтеграцією. Вартість розраховується індивідуально після аналізу ТЗ.

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

Проектування механік: з чого починається чуйне керування

Перш ніж говорити про геймдизайн, зафіксуємо розмежування: геймдизайн — це не «придумати ідею». Придумати може будь-хто. Завдання — спроектувати систему правил, яка виробляє конкретний емоційний та поведінковий результат. Це інженерна дисципліна, тільки замість компілятора — людський мозок.

Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності coyote time та jump buffering. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.

Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.

Які послуги з геймдизайну ми пропонуємо?

Повний цикл: від концепту до вивіреного білду. Під ключ — ви отримуєте геймдизайн-документ (GDD), таблиці балансу, прототип ключових механік на Unity/Unreal, і супровід аж до релізу. Гарантія якості — покрокове узгодження на етапі прототипу, щоб уникнути переробок.

Що входить в роботу (deliverables):

• Документація: GDD, специфікації механік, наративні дерева, API для розробників
• Таблиці балансу: прогресія, економіка, DPS-калькулятори
• Прототипи: інтерактивні сцени з core loop (рух, бій, інвентар)
• Конфігурація в рушії: ScriptableObject, DataTable, анімаційні події
• Проведення плейтестів та ітерацій за метриками (утримання, монетизація, retention)

Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.

Як спроектувати бойову систему без помилок?

Бойова система — найдорожча помилка: на перший погляд проста, на ділі — пекло з edge cases. Розберемо melee combat.

Вибір методу hit detection

Hitbox — колайдери на зброї. Просто, але при швидких атаках виникає tunneling: зброя пролітає крізь противника за кадр. Рішення — Physics.CCD (Continuous Collision Detection), але це дорого. Raycast/spherecast — кастуємо промені вздовж траєкторії зброї. Точніше, менше залежить від fps. Ми віддаємо перевагу spherecast для action-ігор. Докладніше про методи — у статті про виявлення зіткнень.

Налаштування вікон атаки

Кожна атака — три фази: Startup, Active, Recovery. Довгий startup створює «важкі» удари. Короткий recovery дає агресивний стиль. В Unity аніматор кидає подію через AnimationEvent, код вмикає/вимикає hitbox. Типові таймінги для рукопашного бою: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс. Зміна startup з 400 на 250 мс змінює відчуття з «важкий» на «середній» — це фіксується в метриках.

Побудова state machine

Персонаж — скінченний автомат. Базові стани: Idle, Moving, Jumping, Attacking, Hurt, Dead. Бізнес-логіку виносимо в C#-код, аніматор відповідає лише за переходи анімацій. Ієрархічні state machine (через Override Animator Controller) дозволяють вкладені підстани, не дублюючи переходи.

Чому математична модель економіки критична?

Економіку «на око» не роблять — виходить розвал через місяць після релізу. Базова прогресія: лінійна (нудно), експоненціальна (XP(n) = base * multiplier^n, multiplier 1.5–2.0), поліноміальна (a * n^b, b 1.5–2.5). Ми будуємо таблиці в Google Sheets за 2–3 дні, перевіряючи, скільки годин гравець витратить на кожен рівень.

Потоки валют

Принцип: кожна валюта — явне джерело (tap) і стік (sink). Приклад двовалютної системи:

Однонаправлена конвертація захищає монетизацію. Дисбаланс легко виявити за DPS і TTK: якщо TTK зброї вдвічі нижче за інші — воно стає meta. Ми виявляємо це на етапі прототипу, скорочуючи наступні правки на 40%.

Наратив та левел-дизайн: як навчати без тексту?

Environmental storytelling — розташування об'єктів, звуків, слідів — часто ефективніше за діалоги. Для діалогів використовуємо Ink (інтеграція з Unity). Ink-скрипти читає наративний дизайнер без програміста. Кожен рівень перевіряємо за принципом: гравець повинен зрозуміти механіку дією, а не за підказкою.

Інструменти в процесі

Ітерація та плейтестинг: 2-тижневий цикл

Перший прототип завжди незручний — це норма. Наш цикл: плейтест кожні 2 тижні. Після — список змін з числами: «startup 400 мс → 250 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.

Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.