Запуск GTA V в браузере через WebAssembly: что это значит для индустрии

Несмотря на то что GTA V вышла более десяти лет назад, проект по-прежнему требует производительного оборудования и предварительной покупки. Однако в октябре пользователи сети смогли на короткое время запустить масштабную игру напрямую в браузере Chrome без использования облачного стриминга.

Подобный неофициальный запуск стал возможен благодаря современным веб-технологиям. Проект быстро прекратил работу, однако он наглядно показал, что современные браузеры обладают достаточной вычислительной мощностью, поддержкой графики и памятью для запуска тяжелых проектов. Это событие поднимает вопрос о том, как именно будет развиваться индустрия браузерных игр в дальнейшем.

GTA V в браузере: особенности неофициального порта

В течение нескольких часов в начале октября пользователи могли запустить игру через сайт PlayGTA5.com. Видимые демонстрации работы проекта фиксировали запуск пролога сюжетного режима и свободного перемещения по Лос-Сантосу в браузере Chrome, в том числе на компьютере с процессором Apple M3 Pro. Перед началом игрового процесса браузер загружал около 700 МБ данных, а затем подгружал необходимые файлы по мере прохождения.

Распространенным предположением был облачный гейминг, при котором игра запускается на удаленном сервере, передавая видеопоток и принимая команды управления. Однако технический анализ показал совершенно иную картину. Игровой движок работал локально, используя ресурсы процессора, оперативной памяти и графического чипа пользователя.

Техническая проверка не выявила клиентов для стриминга видео или эмуляторов консолей. Вместо этого исследователи обнаружили движок RAGE от компании Rockstar и скомпилированный код GTA V внутри модуля WebAssembly размером 63 МБ, который содержал около 91 000 функций. Тем не менее автор публикации не предоставил исходного кода или сборочных инструкций, а распространение игровых ассистов без разрешения правообладателя привело к быстрому закрытию сайта.

Технологии за кулисами: как Wasm и WebGPU преодолели ограничения

Фундаментом для запуска игры в песочнице браузера стали технологии WebAssembly, Web Workers и WebGPU.

Роль WebAssembly и многопоточности

Технология WebAssembly (Wasm) позволяет выполнять внутри изолированной среды браузера код, изначально написанный на языках вроде C++. Для данного проекта движок RAGE был скомпилирован в 64-битную версию WebAssembly, поскольку игре требовался объем памяти, недоступный в классической 32-битной версии Wasm.

Модуль инициализировался с общим пространством памяти в 3 ГБ, которое могло увеличиваться до 16 ГБ в процессе работы десятков параллельных потоков. Эти потоки распределялись с помощью Web Workers и координировались через общую память и атомарные операции. Это позволило обойти ограничение, заключающееся в том, что десктопные движки привыкли ожидать завершения дисковых или графических операций в синхронном режиме, тогда как веб-интерфейсы работают асинхронно.

Трансляция графики и доставка данных

Для работы с графикой потребовалось отдельное решение. Игра генерировала команды Direct3D 12 или Direct3D 11, которые специальный модуль записывал в кольцевой буфер объемом 32 МБ. Выделенный рабочий поток считывал этот буфер и воспроизводил команды с помощью интерфейса WebGPU.

Кроме того, тысячи существующих шейдеров DXBC были предварительно обработаны и переведены в WGSL — язык шейдеров WebGPU. Неподдерживаемые геометрические элементы обрабатывались через альтернативные пути. Общий объем загруженных данных не ограничивался начальными 700 МБ: сервер содержал почти 21 ГБ ассистов разработки, а специальный модуль ввода-вывода запрашивал лишь необходимые блоки размером по 4 КБ по протоколу HTTP Range, кэшируя их в хранилище браузера.

Перспективы браузерного гейминга и будущее install-free игр

Несмотря на то что данный порт был неофициальным, требовательным к железу и нестандартным, само событие имеет серьезное значение для индустрии. Если сложная многопоточная игра на C++, созданная под архитектуру Windows и Direct3D 11, способна функционировать локально внутри вкладки браузера, значит, веб-обозреватели перестают быть инструментом исключительно для простейших проектов или облачного стриминга.

Ключевым фактором в этом процессе выступает интерфейс WebGPU, поддерживаемый современными браузерами и предоставляющий доступ к возможностям графических процессоров на уровне нативных API. Сочетание быстрого выполнения кода через WebAssembly, параллелизма рабочих потоков, постоянного локального хранилища и инкрементальной доставки данных способно изменить подход к распространению программного обеспечения.

В теории пользователю больше не требуется выполнять классическую установку: достаточно перейти по ссылке, загрузить начальные файлы локации, а остальной контент кэшировать по ходу прохождения. Разработчики получают возможность публиковать демоверсии, редакторы уровней, многопользовательские проекты или полноценные релизы прямо через URL. Обновления при этом могут происходить на сервере, а браузерная песочница обеспечивает изоляцию независимо от операционной системы.

Конечно, в ближайшее время крупные издатели не откажутся от нативных сборок в пользу исключительно браузерных версий, поскольку традиционные приложения обеспечивают лучший контроль над файлами, драйверами, системной памятью и защитой от пиратства. Кроме того, игровые движки вроде Unity и Godot нуждаются в доработке инструментов экспорта для полноценной поддержки веб-стандартов. Тем не менее эксперименты такого рода показывают смену общего направления, при которой процесс установки постепенно отходит на второй план, а браузер превращается в полноценную игровую платформу.