Створення браузерних ігор: стек, оптимізація та інтеграція

Розробка браузерних ігор

Ми розробляємо браузерні ігри, які запускаються без встановлення прямо у вікні браузера. За цим простим визначенням ховаються три принципово різні технології: Unity WebGL, Three.js / Babylon.js (нативний WebGL) та Phaser (2D Canvas/WebGL). Вибір стеку визначає можливості та обмеження, і наше завдання — підібрати оптимальний під жанр, платформу та бюджет проекту. Браузерні ігри затребувані в казуальному сегменті, маркетингових активностях та інтеграціях на платформах на кшталт Яндекс Ігри, VK Play, CrazyGames. Досвід нашої команди включає проекти від простих 2D пазлів до мідкорних 3D RPG на Unity WebGL з мультиплеєром та платіжними SDK.

Як обрати стек для браузерної гри?

Вибір движка безпосередньо впливає на продуктивність та час розробки. Для 2D казуалок Phaser 3 у 2-3 рази швидше оновлює спрайти порівняно з Canvas-рендерингом завдяки WebGL-бекенду. Для 3D проектів з критичною фізикою (симуляції, гонки) Unity WebGL залишається стандартом, незважаючи на розмір білда. Three.js оптимальний для візуалізацій та прототипів, де не потрібен повний набір ігрових систем — фізика, ІІ, навігація. Ми рекомендуємо проводити Proof of Concept (PoC) на цільовому движку перед початком повномасштабної розробки: це виявляє вузькі місця (пам'ять, завантаження, FPS) на ранньому етапі.

Коли що обирати

Unity WebGL — якщо команда вже працює на Unity, якщо гра переноситься з мобайлу/PC, якщо потрібна складна фізика або 3D. Компілюється в WebAssembly, важкий початковий білд (10-50 МБ), але повний доступ до Unity-екосистеми. Phaser 3 — для 2D ігор, які створюються спочатку для браузера. JavaScript/TypeScript, легкий білд (кілька МБ), відмінна підтримка SpriteBatch, Tilemaps (Tiled інтеграція), фізика через Arcade (проста) або Matter.js (складна). Three.js / Babylon.js — для інтерактивних 3D-досвідів, не класичних ігор. Маркетингові демо, конфігуратори, showroom. Babylon.js має більш повний ігровий фреймворк; Three.js — краща екосистема плагінів. PixiJS — чистий 2D рендерер на WebGL, максимальна продуктивність для 2D. Без ігрової логіки з коробки, але фантастично швидкий для спрайтів та часток.

Технічні обмеження браузерних ігор

Чому завантаження критичне для браузерних ігор?

Користувач відкрив посилання. Якщо через 5 секунд він не бачить нічого цікавого — частина з них закрила вкладку. Оптимізація завантаження — не опціональне завдання. Progressive loading pattern: спочатку завантажуємо мінімум для показу першого екрану (лого, loading screen з анімацією), паралельно у фоні — основні асети. Для Unity WebGL: стартовий кадр через compressed data.unity3d з Bootstrap loader. Для Phaser: Phaser.Loader з onProgress callback + preloaded scene. Service Worker для кешування: після першого завантаження асети кешуються, повторний вхід — миттєвий. Реалізується через Workbox або вручну через Cache API. Важливо: версіонування кешу при оновленні гри. Оптимізація асетів (стиснення текстур, видалення зайвих) може скоротити час завантаження до 50% та заощадити до 30% трафіку користувачів — цифри, підтверджені на практиці.

Що не можна зробити в браузері

• Прямий доступ до файлової системи (тільки IndexedDB через Web Storage API, або File System Access API з явним дозволом користувача)
• UDP-сокети для мультиплеєра — тільки WebSocket (TCP) або WebRTC DataChannel (UDP-like, але через STUN/TURN)
• Фонові потоки без WebWorker — весь JavaScript однопоточний за замовчуванням
• Persistent процеси — вкладка закрита, гра померла. Стан — тільки в LocalStorage/IndexedDB/Cookie

Збереження та персистентність

Для браузерних ігор немає стандартного аналога PlayerPrefs. Варіанти:

• LocalStorage — 5-10 МБ, синхронний, тільки рядки. Для невеликих збережень.
• IndexedDB — практично необмежений об'єм, асинхронний, structured data. Для повноцінних save файлів. Доступ через Dexie.js (обгортка з нормальним API).
• Хмарні збереження — єдиний спосіб переносити прогрес між пристроями. Firebase Firestore, PlayFab CloudSave, або власний API.

Unity WebGL доступ до IndexedDB — через jslib плагін з викликом JS з C#.

Мультиплеєр в браузері

Найнетривіальніша частина. UDP недоступний напряму. WebSocket — TCP, трохи вища затримка ніж UDP, але стабільний. Для покрокових ігор, чатів, асинхронного PvP — цілком достатньо. Socket.io на сервері (Node.js) або Photon Realtime з WebSocket transport. WebRTC DataChannel — UDP-like передача даних між браузерами peer-to-peer або через сервер. Використовується в іграх, де latency критична (шутери, гонки). Вимагає STUN/TURN інфраструктури (coturn — open source TURN сервер). Значно складніший за WebSocket у реалізації.

Для Unity WebGL мультиплеєра — Mirror з SimpleWebTransport (WebSocket) або Photon Fusion (WebSocket relay). UDP-rollback netcode в браузері недоступний без WebRTC.

Інтеграція з платформами

Браузерні ігри часто вбудовуються в сторонні платформи: Яндекс Ігри, VK Play, CrazyGames, itch.io, Kongregate. Кожна платформа має власний SDK для: авторизації (OAuth через postMessage між iframe), лідербордів, реклами (rewarded video, interstitial) та платежів (в Яндекс Ігри та VK Play — власна валюта). Яндекс SDK: ysdk.init() → авторизація через ysdk.getPlayer() → реклама через ysdk.adv.showRewardedVideo(). Для Unity — Яндекс надає офіційний плагін, але він працює тільки з IL2CPP build (не Mono). Наш досвід показує, що інтеграція з платформою додає в середньому 1-2 тижні до розробки, включаючи тестування та модерацію.

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

1. Вибір стеку та архітектури (1-3 дні). Жанр, платформа-таргет, команда — все це визначає Unity WebGL vs. Phaser vs. нативний WebGL. Проводимо PoC для перевірки гіпотез.
2. Розробка з browser-first mindset. Кожного тижня — тест у браузері, не тільки в редакторі/локальному сервері. Поведінка в браузері відрізняється від нативної: аудіоконтекст вимагає user gesture для запуску, iframe накладає обмеження на доступ до API.
3. Оптимізація білда (1-3 дні перед релізом). Розмір, час завантаження, сумісність браузерів.
4. QA. Chrome, Firefox, Safari Desktop, Chrome Mobile, Safari iOS. BrowserStack для автоматизації.

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

• Архітектурна документація (вибір стеку, план завантаження, схема мультиплеєра)
• Вихідний код проекту з коментарями
• Оптимізований білд під цільові платформи
• Інтеграція SDK обраних платформ (Яндекс Ігри, VK Play тощо)
• Навчання команди замовника по розгортанню та підтримці
• Пост-релізна підтримка: фікс помилок, оновлення під нові версії браузерів

Вартість розраховується після уточнення жанру, цільової платформи та вимог до мультиплеєру або платіжної інтеграції. Ми гарантуємо якість: 5+ років на ринку, понад 50 реалізованих проектів, сертифіковані фахівці. Економія до 30% трафіку завдяки оптимізації.

Порівняння продуктивності стеків

Для поглибленого розуміння технології WebGL зверніться до офіційної документації та Unity WebGL.

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

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

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

Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності 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 гарантують дотримання термінів.