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

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

Браузерная игра — это любая игра, запускающаяся без установки. За этим простым определением скрываются три принципиально разных технологии: 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 плагин с вызовом 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 для автоматизации.

Стоимость рассчитывается после уточнения жанра, целевой платформы и требований к мультиплееру или платёжной интеграции.