Разработка браузерных игр
Мы разрабатываем браузерные игры, которые запускаются без установки прямо в окне браузера. За этим простым определением скрываются три принципиально разных технологии: 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% трафика пользователей — цифры, подтверждённые на практике. Средний бюджет на такие проекты начинается от $3000.
Что нельзя сделать в браузере
- Прямой доступ к файловой системе (только 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, чуть выше 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-2 недели к разработке, включая тестирование и модерацию. Стоимость такого этапа варьируется в пределах $500-$1500.
Процесс разработки
- Выбор стека и архитектуры (1-3 дня). Жанр, платформа-таргет, команда — всё это определяет Unity WebGL vs. Phaser vs. нативный WebGL. Проводим PoC для проверки гипотез.
- Разработка с browser-first mindset. Каждую неделю — тест в браузере, не только в редакторе/локальном сервере. Поведение в браузере отличается от нативного: аудиоконтекст требует user gesture для запуска, iframe накладывает ограничения на доступ к API.
- Оптимизация билда (1-3 дня перед релизом). Размер, время загрузки, совместимость браузеров.
- QA. Chrome, Firefox, Safari Desktop, Chrome Mobile, Safari iOS. BrowserStack для автоматизации.
Что входит в работу (deliverables)
- Архитектурная документация (выбор стека, план загрузки, схема мультиплеера)
- Исходный код проекта с комментариями
- Оптимизированный билд под целевые платформы
- Интеграция SDK выбранных платформ (Яндекс Игры, VK Play и т.д.)
- Обучение команды заказчика по развертыванию и поддержке
- Пост-релизная поддержка: фикс ошибок, обновления под новые версии браузеров
| Тип игры | Стек | Ориентировочные сроки |
|---|---|---|
| 2D казуалка | Phaser 3 | 1-4 недели |
| Маркетинговое 3D-демо | Three.js / Babylon.js | 1-3 недели |
| Порт мобильной игры | Unity WebGL | 1-4 недели (зависит от адаптации) |
| Мидкор с мультиплеером | Unity WebGL + Photon | 1-2 месяца |
| Платформенная интеграция | Зависит от платформы | +1-2 недели к основной разработке |
Стоимость рассчитывается после уточнения жанра, целевой платформы и требований к мультиплееру или платёжной интеграции.
Сравнение производительности стеков
| Критерий | Phaser 3 | Unity WebGL | Three.js |
|---|---|---|---|
| Размер билда (initial) | 1-3 MB | 10-50 MB | 0.5-2 MB (свой код) |
| 2D FPS (спрайты 1000 шт) | 60 fps | 60 fps | 40-50 fps |
| 3D FPS (средняя сцена) | N/A | 60 fps | 60 fps |
| Сложность мультиплеера | Низкая (WebSocket) | Средняя (WebSocket + Photon) | Высокая (WebRTC) |
| Поддержка мобильных браузеров | Отличная | Хорошая (требует настройки) | Хорошая |
Для углублённого понимания технологии WebGL обратитесь к официальной документации и Unity WebGL.
Закажите разработку браузерной игры — свяжитесь с нами для обсуждения вашего проекта.