Привет! Меня зовут Максим и я frontend-разработчик в компании SimbirSoft. Думаю, из названия статьи вы уже поняли, что я не только занимаюсь разработкой интерфейсов, но и увлекаюсь созданием игр. Интерес к геймдеву появился у меня ещё в университете, когда я решил познакомиться с Unity. Тогда я не планировал строить карьеру разработчика игр, но сам процесс затянул. Даже став полноценным специалистом в своей области, я не перестал думать о геймдеве. Поэтому решил совместить приятное с полезным, а именно: изучить экосистему языка JavaScript на наличие инструментов для геймдева. Результатом стали три игры, опубликованные на платформе Яндекс Игры. Изучив и опробовав несколько технологий, я понял, что создавать игры на JavaScript вполне реально.
В этой статье я хочу рассказать, почему веб-игры переживают новый виток развития и какие инструменты JavaScript-экосистемы можно использовать для геймдева. Этот обзор будет полезен бизнесу, который хочет добавить в свой программный продукт новые возможности для вовлечения пользователей, и разработчикам, интересующимся созданием увлекательного игрового контента с помощью веб-технологий.
Ренессанс веб-игр
Все помнят flash-игры, в которые мы играли во ВКонтакте и Одноклассниках? Да, по динамичности и графике эти игры уступали тем, которые мы устанавливали на компьютер. Но нам было интересно! Мы постоянно заходили в них и играли. Эпоха flash-игр закончилась еще до официального прекращения поддержки технологии Adobe Flash Player. Уже с 2008 года стремительно начал развиваться мобильный гейминг — во многом благодаря появлению App Store и Android Market. С каждым годом мобильные устройства становились всё мощнее, аудитория росла и поэтому индустрия мобильных игры развивалась семимильными шагами, обгоняя даже десктоп. Веб-игры на какое-то время ушли в тень.

Время шло, прогресс не стоял на месте, в том числе и для браузеров, так как набирала обороты тенденция перехода десктопных приложений в веб. Постепенно развивались технологии работы с мультимедиа, улучшались браузерные движки, чтобы можно было делать сложные и производительные приложения. Ключевым моментом стал 2014 год — появление стандарта HTML5, который значительно расширил интерактивные возможности браузеров. Одним из нововведений стал html-элемент Canvas, позволивший творить чудеса с 2D- и 3D-графикой благодаря технологии WebGL. Появление WebGL позволило задействовать графический процессор устройства так же, как это делают современные десктопные и мобильные игры, ведь его выч��слительные мощности существенно превосходят возможности центрального процессора. В результате веб-игры снова вернулись в индустрию и заняли свою нишу. Это случилось благодаря ряду преимуществ перед десктопными и мобильными играми:
Кроссплатформенность. Браузер есть на большинстве устройств: компьютер, телефон и телевизор. Это позволяет создавать игру один раз и запускать везде.
Запуск без установки. Современные скорости интернета позволяют достаточно быстро загружать необходимые ресурсы для игр. Таким образом нет необходимости ждать скачивания и установки, что является большим плюсом для виральности.
Построение новых бизнес-моделей. Браузерные игры легко встраивать в любое веб-приложение, что повышает его привлекательность и даёт новые способы заработка через рекламу и подписки. Подобной практики придерживаются многие платформы: VK Play, Yandex Games, Poki, Grazy Games и другие.
Развитие PWA и WebView, стирает границу между нативом и вебом, позволяя устанавливать web-игры как приложения на мобильные устройства и компьютеры, если нужен доступ к специальным встроенным функциям.
Почему стандартные игровые движки – не панацея для веба
Я не призываю отказываться от движков, на которых разрабатывается большая часть игр, но у них есть ряд объективных ограничений. Далее я объясню, почему для разработки веб-игр лучше использовать не универсальные инструменты, а те, которые больше подходят для браузеров.
Первое, на что хочется обратить внимание, — размер билда. У игр, собранных под веб на Unity и Godot, он достаточно большой. Про Unreal Engine я даже говорить не буду, его практически никто не использует для веб-игр. Сейчас пустой веб-проект на Unity весит около 13 МБ, а на Godot — порядка 40 МБ. По мере наполнения игры кодом и ассетами размер сборки только увеличивается, и это действительно проблема: загрузка таких игр может быть долгой, а как мы знаем, пользователь не любит ждать. Поэтому есть риск потерять первых игроков еще до старта игры. К тому же платформы, распространяющие веб-игры, часто вводят ограничения на размер билда. Да, уменьшить его можно — разработчики находят решения, но чаще всего это похоже на «пляски с бубном», особенно когда дело касается Godot. Я сижу на многих тематических каналах разных движков и регулярно вижу, какую боль это приносит разработчикам: такие шаманства могут испортить билд игры.

Второй момент — оптимизация. Очень часто можно заметить, что игры, которые разрабатывались на стандартных движках, тормозят в браузере. Причина в том, что изначально они не были адаптированы под его экосистему. Работа приложений на десктопе, мобильном устройстве или в браузере строится на разных архитектурных подходах. В первых двух случаях активно используется многопоточность, что позволяет создавать действительно производительные игры. Но в браузере вся логика завязана на асинхронность. Этот момент стараются учитывать разработчики движков, но, к сожалению, не всегда получается достичь нужного результата. Оно и понятно, ведь сложно создать универсальный инструмент.
И третий момент – контроль над кодом. Используя технологии из экосистемы JavaScript, мы работаем с родным для браузера языком и понимаем, как именно будет исполняться наш код. Мы пишем на JavaScript и знаем, что будет работать так, как задумано. Когда дело касается движков, к примеру Godot, то игры, написанные на GDScript или C#, должны будут переводиться в JavaScript или WebAssembly. Как именно это произойдет, зависит от реализации, которую заложили разработчики движка, и повлиять на это мы практически не можем. Так, в одной из версий Godot игры, собранные под веб, просто не запускались. Проблему в итоге исправили, но далеко не так быстро, как хотелось бы.
Подводя итог этому разделу, скажу так: разрабатывать игры на уже зарекомендовавших себя движках вполне можно, но надо быть готовым к нюансам и ограничениям.
Технологии для разработки игр на JavaScript
Начнём с библиотек Pixi.js и Three.js. Это не полноценные игровые движки, а инструменты для работы с графикой: Pixi.js ориентирован на 2D, а Three.js — на 3D. По сути, они предоставляют богатый функционал, который значительно упрощает работу с Canvas и WebGL. Несмотря на это, Pixi.js часто применяется в разработке игр, где физика взаимодействия между игровыми объектами и не требуется. К примеру: «три в ряд», пазлы, карточные игры и т.п.
С Three.js ситуация немного интереснее. Помимо функций для работы с 3D-графикой, вокруг него сформировалась экосистема библиотек, позволяющих реализовать физику объектов: Rapier.js и Cannon.js. Для React-разработчиков существует аж целый React Three Fiber. Это обёртка, которая работает с Three.js, используя компонентный подход. У React Three Fiber богатая экосистема, которая предоставляет функционал для работы с физикой, материалами и т.п. Мне недавно попадалась игра, сделанная на этом инструменте, и она вполне уверенно работала даже на моём Redmi Note 8. Вот ссылка, если кому-то интересно попробовать: https://www.shopify.com/editions/summer2025/drive.

Следующий инструмент – Phaser.js. Это полноценный фреймворк, который ориентирован на создание 2D-игр. Из коробки у него есть управление сценами, физикой, анимацией, таймлайном и т.п.

С третьей версии Phaser.js получил широкую известность особенно за рубежом. Тогда создатели проекта привлекли спонсоров и начали активно развивать его, выстраивая целую экосистему. Phaser.js богат на документацию и у него очень отзывчивое комьюнити. На данный момент у движка есть свой редактор, но он платный. Отдельно стоит отметить возможность подключения физического движка Box2D, который является де-факто стандартом в индустрии 2D-игр. Phaser.js также умеет работать с ассетами, созданными в Aseprite и Spine 2D — это инструменты, которые активно используются в разработке игр. В целом Phaser.js старается развиваться как полноценное решение для разработки 2D-игр и выглядит довольно уверенно.
Завершаю свою подборку аналогом Unity — движком Cocos Creator.

Это игровой движок, созданный китайскими разработчиками и получивший особое признание на азиатском рынке. Cocos Creator ориентирован на создание как 2D-, так и 3D-игр. Основной язык программирования — TypeScript. Одним из его главных плюсов является бесплатный редактор, который по интерфейсу и логике работы очень напоминает Unity. Да, у Cocos Creator отсутствуют определенные возможности, которые есть у Unity, и ему есть куда расти, но его инструментарий позволяет создавать достаточно масштабные игровые проекты. Еще одним большим плюсом является возможность экспорта игр на разные платформы: мобильные устройства, веб, десктоп и даже игровые консоли.
Но тут не всё так радужно, как хотелось бы. Есть несколько моментов, которые могут усложнить знакомство с данным инструментом:
Мало материалов для обучения, даже англоязычных. В основном вся информация находится на китайских источниках и плохо переводится.
Движок не лучшим образом взаимодействует со многими npm-пакетами, что ограничивает в использовании уже готовых решений.
Создание тайловых карт приходится выполнять в сторонних редакторах, при этом совместимость с ними неполная, поскольку некоторые используемые фичи могут просто не работать в Cocos Creator.
Многое нужно реализовывать вручную, в то время как в Unity или Godot это уже может быть доступно из коробки.
Тем не менее Cocos Creator достоин внимания, потому что на нём уже были сделаны такие известные игры, как Clash of Kings, Age of Apes, Geometry Dash и т.д.
Заключение
Подводя итоги всего вышесказанного, хочу сказать следующее: JavaScript — это достаточно мощный инструмент для разработки веб-игр (и не только веб-игр). Браузеры продолжают развиваться в сторону производительности, рынок веб-игр стабильно растёт, а значит, геймдев на JavaScript вполне можно рассматривать как одну из перспективных ниш.
А как вы считаете: стоит ли сегодня делать игры на JavaScript и есть ли у него будущее в этой области?
Больше авторских материалов для frontend-разработчиков от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.
