Браузерные игры становятся серьёзнее: что показывают проекты с открытым исходным кодом и боевыми системами

Я начал это исследование, ожидая найти несколько интересных экспериментов с боевыми системами в браузере. Вместо этого обнаружил гораздо более широкую экосистему: настоящие прототипы экшенов от третьего лица с фиксацией цели, ветвящимися деревьями комбо, идеальным парированием, неуязвимостью во время уклонения, системами стойкости, воздушными атаками, телеграфированием атак боссов, motion warping, hit-stop, физическими столкновениями оружия, поддержкой геймпада, сенсорным управлением и детерминированной симуляцией.

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

Для меня как веб-разработчика именно это особенно интересно. В старой модели игр были установщики, большие загрузки, патчеры, лаунчеры и задержка между тем, как ты находишь игру, и тем, как реально начинаешь с ней взаимодействовать. Браузер резко сокращает этот путь: открыть ссылку, загрузить ресурсы и начать играть.

В этом исследовании я сосредоточился на проектах с играбельной браузерной сборкой и публичным исходным кодом. Экспорты Unity WebGL я намеренно исключил, потому что хотел изучать игры, построенные вокруг веб-технологий, а не игры, которые лишь экспортировали в веб.

Самые сильные проекты, которые я нашёл

Самые полезные находки были сильны по разным причинам. В одних были самые глубокие системы комбо. В других — лучшая архитектура игры от третьего лица, более чистая симуляция боя или более убедительные физические попадания.

Почему результаты меня удивили

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

Отсюда следуют полезные различия:

• тайминг анимации — не тайминг боя;
• частота кадров рендеринга — не частота симуляции;
• коллизия сама по себе ещё не означает валидное попадание;
• анимация не обязательно определяет фактическое движение;
• визуальный контакт — не то же самое, что ощущаемая сила удара.

Эти различия снова и снова встречались в самых сильных проектах, и они важнее логотипа рендерера в README.

Voxel Musou: у браузерного боя может быть настоящая грамматика приёмов

Voxel Musou — один из самых наглядных примеров того, что браузерный бой больше не обязан сводиться к одной анимации атаки на одной кнопке. Исходный код доступен в репозитории mike007jd/voxel-musou.

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

current move + buffered input + combat state -> next move

Для character-action игры это гораздо лучшая основа, чем разрастающийся набор условных конструкций для частных случаев. Проект также показывает воздушные атаки, специальные последовательности, несколько наборов приёмов персонажей, поведение боссов, hit-stop и бой с большими группами врагов.

Более общий инженерный вывод: приёмы должны стать данными, а переходы — явными. Когда это сделано, добавление нового персонажа больше не требует переписывать весь боевой контроллер.

Long Wind: ближе всего к современной браузерной экшен-игре

Long Wind — один из самых сильных комплексных примеров, потому что сочетает передвижение от третьего лица с лёгкими и тяжёлыми атаками, фиксацией цели, блоком, идеальным парированием, неуязвимостью во время уклонения, давлением на стойкость, добиваниями, реакциями на подбрасывание и сбивание с ног, снарядами, боссами и несколькими архетипами врагов. Исходный код доступен в репозитории jbang2004/long-wind.

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

Motion warping решает проблему, которую веб-демо часто игнорируют

Samurai Third-Person Template ThreeJS особенно интересен тем, что решает классическую проблему ближнего боя от третьего лица. Исходный код доступен в репозитории achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Заранее созданная анимация атаки предполагает, что цель будет находиться на определённом расстоянии, когда удар дойдёт до кадра контакта. В реальной игре цель почти никогда не расположена идеально. Если персонаж просто проигрывает анимацию на месте, меч может визуально промахнуться, хотя игра всё равно нанесёт урон. Если телепортировать персонажа в нужную точку, атака выглядит искусственно.

Motion warping даёт лучший ответ: во время атаки корректировать поворот и перемещение так, чтобы персонаж оказался в ожидаемой позиции контакта в нужный момент.

Ключевое различие:

animation intent != movement authority

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

Обнаружение коллизии и валидация попадания — разные задачи

Stick & Steel исследует совсем другую модель боя. Исходный код доступен в репозитории Rabneba/stick-steel.

Вместо того чтобы рассматривать меч прежде всего как анимацию с объёмом нанесения урона, проект придаёт оружию физическое присутствие. Здесь имеют значение скорость контакта, ориентация оружия, область тела, блоки, столкновения оружия, сбивания с ног и обезоруживание.

Самый переносимый вывод здесь не в том, что каждая экшен-игра должна использовать полностью физическое оружие. Он в другом:

Коллизия говорит лишь о том, что два объекта соприкоснулись. Она не говорит, произошло ли значимое попадание.

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

Централизованное разрешение боя упрощает логику сложной защиты

Hollowmere, исходный код которого находится в репозитории euuuuuuan/hollowmere-public, выделяется не столько визуальной зрелищностью, сколько архитектурой ПО.

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

Более чистая модель:

incoming attack -> evade | parry | hit

Рендерер должен отображать результат, а не создавать вторую версию истины о бое.

По мере усложнения боя это различие становится всё важнее. Детерминированная симуляция и явные переходы состояний — не самые эффектные возможности, зато они упрощают тестирование, отладку и расширение сложной боевой системы.

Ощущение от игры — инженерная система, а не украшение

Fabled Revolutions, исходный код которого находится в репозитории ericrius1/FabledRevolutions, полезен именно тем, что изолирует эффекты, из-за которых попадания ощущаются весомыми.

Логически корректная боевая система всё равно может ощущаться слабой. Коллизия может быть точной, урон может наноситься в правильном кадре, а результат всё равно будет выглядеть так, будто две модели проходят друг сквозь друга.

Ощущение удара часто складывается из набора кратковременных эффектов:

• hit-stop;
• тряска или рывок камеры;
• шлейфы оружия;
• частицы удара;
• вспышка при получении урона;
• отбрасывание;
• реакция анимации;
• точно синхронизированный звук.

Отсюда ещё одно полезное различие: корректность боя — не то же самое, что ощущение боя. Браузерной игре нужны оба аспекта.

Рендерер не был главным предиктором качества боя

Одна из самых интересных закономерностей исследования: лучший бой не определялся тем, использует ли проект самый новый API рендеринга.

Three.js встречался снова и снова. Некоторые проекты использовали технологии рендеринга, связанные с WebGPU, другие — обычные стеки на базе WebGL. В исследованных проектах встречались физические движки, TypeScript, JavaScript, Vite, WebAssembly и разные подходы к рендерингу.

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

Для веб-разработчиков это обнадёживает. Не нужно ждать, пока у каждого пользователя появится самый новый графический стек, чтобы экспериментировать с серьёзным дизайном боевых систем.

Почему распространение через браузер меняет расклад

У браузера есть преимущество, почти не связанное с графикой: крайне мало барьеров при распространении.

В традиционных играх между обнаружением и взаимодействием часто стоит несколько шагов: найти страницу в магазине, скачать большой пакет, установить его, запустить, дождаться обновлений, а иногда ещё и создать аккаунт до того, как доберёшься до содержательного игрового процесса.

Браузерная игра может сократить этот путь до одной ссылки.

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

Это преимущество особенно важно для экспериментальных игр и независимой разработки. Браузер — не только среда выполнения, но и система распространения.

Где браузер всё ещё проигрывает

Исследование не убедило меня, что браузеры заменили нативные игровые платформы. Не заменили.

Несколько ограничений остаются важными:

• Большой объём ресурсов. Мгновенный доступ перестаёт ощущаться мгновенным, когда игре нужна очень большая первоначальная загрузка.
• Давление на память. Браузеры должны сосуществовать с другими вкладками и операционной системой, а поведение памяти менее предсказуемо, чем в отдельном нативном процессе.
• Тепловые ограничения мобильных устройств. Технически работоспособная 3D-игра всё равно может сильно троттлить во время длинной сессии.
• Различия между браузерами. Графика, звук, захват указателя, полноэкранный режим, контроллеры и характеристики производительности не полностью одинаковы.
• Подготовка шейдеров и ресурсов. Компиляция или загрузка всё ещё могут вызывать заметные паузы, если пайплайн спроектирован неаккуратно.
• Ограничения офлайн-режима и локального хранения. Нативные приложения сохраняют более прямой контроль над большими локальными установками и файлами.
• Безопасность соревновательных игр. Серьёзный античит и предположение о враждебном клиенте становятся гораздо сложнее, когда клиент — веб-приложение.

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

ИИ заметно сокращает цикл от прототипа до URL

ИИ здесь уместен, но не потому, что магически превращает предложение в готовую качественную игру. Более реалистичное преимущество — скорость итераций.

Современная разработка игр включает много небольших задач, которые в сумме обходятся дорого: настройка машин состояний, создание отладочных представлений, написание тестов, эксперименты с поведением врагов, создание форматов данных для приёмов, рефакторинг кода ввода, прототипирование шейдеров, разбор ошибок физики и подключение временного контента.

ИИ может сократить многие из этих циклов. В сочетании с веб-дистрибуцией рабочий процесс становится необычно прямым:

idea -> prototype -> deploy -> open URL -> test -> iterate

Браузер уже делает развёртывание быстрым. ИИ может ускорить и сторону реализации в том же цикле.

Важная оговорка: быстрая генерация не заменяет вкус и проверку. Сгенерированный боевой контроллер может быть структурно неправильным. Тайминг анимации всё ещё требует человеческого суждения. Физику всё ещё нужно отлаживать. Производительность всё ещё нужно измерять. ИИ снижает стоимость проверки идей, но не избавляет от необходимости решать, какие идеи хороши.

Что это значит для веб-разработчиков

Граница между веб-разработкой и разработкой игр становится менее жёсткой.

Серьёзная браузерная игра теперь может использовать привычные веб-инструменты и при этом требовать классических концепций игровой инженерии:

• фиксированные шаги симуляции;
• машины состояний;
• буферизация ввода;
• графы анимаций;
• пространственные запросы;
• физика;
• бюджеты кадра;
• управление ресурсами GPU;
• тайминг звука;
• детерминированные системы.

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

Исследование изменило мою собственную картину мира. Я больше не воспринимаю браузерные игры прежде всего как упрощённые версии нативных. Я вижу браузер как всё более способную игровую платформу с другим набором сильных сторон: мгновенным распространением, быстрыми итерациями, всё более серьёзными возможностями 3D и огромной существующей экосистемой разработки.

Веб не просто становится лучше в отображении игр, созданных где-то ещё. Он всё чаще становится местом, где серьёзные игровые системы можно проектировать, реализовывать, тестировать, распространять и играть в них напрямую.