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

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

Браузерна гра — це будь-яка гра, яка запускається без встановлення. За цим простим визначенням скриваються три принципово різні технології: Unity WebGL, три.js / Babylon.js (нативний WebGL), та Phaser (2D Canvas/WebGL). Вибір стека визначає й можливості, й обмеження.

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

Unity WebGL — якщо команда вже працює на Unity, якщо гра переносится з мобайла/PC, якщо потрібна складна фізика або 3D. Компілюється в WebAssembly, важкий початковий білд (10-50 МБ), але повний доступ до Unity-екосистеми.

Phaser 3 — для 2D ігор, які створюються спочатку для браузера. JavaScript/TypeScript, легкий білд (кілька МБ), відмінна підтримка SpriteBatch, Tilemaps (Tiled інтеграція), фізика через Arcade (проста) або Matter.js (складна). Хороший вибір для казуалок, пазлів, platformer-демо.

Three.js / Babylon.js — для інтерактивних 3D-дослідів, не класичних ігор. Маркетингові демо, конфігуратори, showroom. Babylon.js має більш повний ігровий фреймворк; Three.js — краща екосистема плагінів.

PixiJS — чистий 2D рендерер на WebGL, максимальна продуктивність для 2D. Без ігрової логіки з коробки, але фантастично швидкий для спрайтів та частинок.

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

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

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

Завантаження та TTFP (Time To First Play)

Користувач відкрив посилання. Якщо через 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. Важливо: версіонування кеша при оновленні гри.

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

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

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

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

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

Найнетривіальніша частина. UDP недоступен напрямку.

WebSocket — TCP, трохи вищий latency ніж 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-3 дні). Жанр, платформа-таргет, команда — все це визначає Unity WebGL vs. Phaser vs. нативний WebGL.

Розробка з browser-first mindset. Кожну неделю — тест у браузері, не тільки в редакторі/локальному сервері. Поведінка у браузері відрізняється від нативного: аудіоконтекст потребує user gesture для запуску, iframe накладає обмеження на доступ до API.

Оптимізація білду (1-3 дні перед релизом). Розмір, час завантаження, сумісність браузерів.

QA. Chrome, Firefox, Safari Desktop, Chrome Mobile, Safari iOS. BrowserStack для автоматизації.

Вартість розраховується після уточнення жанру, цільової платформи та вимог до мультиплеєру або платіжної інтеграції.