Веб-игры снова в игре: Poki, WebAssembly и новая реальность браузера

Послушал выпуск Software Engineering Daily с Эриком Дабилбором, principal engineer в Poki и разработчиком веб-игр. Ниже — сжатый пересказ о том, как браузер снова стал серьезной игровой платформой, где реальные ограничения, и почему дистрибуция в вебе отличается от Steam и App Store.

Кто такой Эрик и почему его мнение важно

Эрик одновременно работает над платформой для разработчиков в Poki и сам выпускает игры на этой же платформе. Такой двойной опыт дает редкую оптику:

• он видит системные проблемы платформы изнутри;
• он проходит тот же путь публикации и QA, что и внешние студии;
• он может быстро тестировать продуктовые гипотезы на собственных играх.

По сути, это позиция “builder + platform engineer” в одном лице.

От Flash к ренессансу веб-игр

В разговоре хорошо описана эволюция рынка:

1. Эпоха Flash — огромная волна браузерных игр.
2. Провал после ухода Flash — многие разработчики и практики исчезли.
3. Новый подъем — благодаря WebAssembly, WebGL/WebGPU и зрелым export pipeline в движках.

Ключевая мысль: web games вернулись не как копия Flash-эры, а как новая категория с другими ожиданиями аудитории и другими техническими компромиссами.

Что реально дали WebAssembly, WebGL и WebGPU

Эрик объясняет стек без маркетинга:

• WebAssembly ускорил выполнение и дал движкам путь компиляции C++/C#-стека в браузер.
• WebGL долго был основой рендеринга и до сих пор дает широкий охват устройств.
• WebGPU приносит более современную модель работы с GPU (батчинг и асинхронные команды), но пока зависит от поддержки драйверов и браузеров.

Важно: WebAssembly сам по себе не “общается” напрямую с DOM/API браузера — для этого нужен мост через JavaScript.

Движки: хорошее состояние, но с нюансами

Для практики разработки картина такая:

• Unity и Godot дают рабочий web export и активно развиваются;
• PlayCanvas, Phaser, PixiJS, Construct, Cocos — сильные web-native варианты;
• Unreal web export убрал, потому что дорого поддерживать паритет с основной рендеринг-системой.

При этом у больших движков чаще болит размер сборки: чем больше initial download, тем выше отток игроков до старта.

Главное ограничение веба: время до первого интереса

Одна из самых сильных идей эпизода: в вебе игрок “ничем не обязан” игре.

Если в первые секунды не зацепило, он уходит в соседний тайтл в один клик. Отсюда вытекают продуктовые правила:

• onboarding должен быть почти без текста;
• туториал должен ощущаться как игра, а не инструкция;
• “вау-момент” нужно показывать сразу;
• первая минута важнее длинного endgame-контента.

Это гораздо ближе к короткому контенту в соцсетях, чем к классическому desktop funnel.

Почему мобильный веб диктует portrait-first

Для Poki мобильная аудитория растет быстрее desktop, а поведение игроков требует минимального трения. Поэтому для web-mobile чаще рекомендуют portrait:

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

Плюс появляются чисто практические задачи: safe areas, вырезы (notch), разный aspect ratio и адаптация UI под десятки устройств.

Что такое Poki для разработчика

Poki позиционируется как curated-платформа с большой аудиторией (100M+ MAU), где:

• разработчик загружает веб-билд (zip с index.html);
• Poki берет на себя дистрибуцию и монетизацию через рекламу;
• есть подробный QA и продуктовые рекомендации перед релизом;
• доступна аналитика, управление версиями и выплаты.

Главный value proposition: разработчик может фокусироваться на игре, а не на пользовательском acquisition.

Самый интересный инструмент: playtesting в реальном трафике

В подкасте отдельно выделяют внутренний цикл тестирования:

• можно быстро получить сессии от реальных игроков платформы;
• просмотреть видео игрового процесса и ввод (клавиатура/мышь);
• увидеть честную реакцию “понял/не понял” в первые секунды.

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

Что по-прежнему болит

Несмотря на прогресс, остаются открытые темы:

• ограниченные social sharing API в браузере;
• зависимость WebGPU от комбинации браузер + драйвер + устройство;
• сложность оптимизации больших Unity/Godot-сборок, особенно если проект изначально не строился с отложенной загрузкой ассетов.

Технический вывод простой: web-геймдев уже зрелый, но требует дисциплины в performance и product design с первого дня.

Ключевые выводы из эпизода

1. Браузер снова полноценная игровая платформа, а не fallback-канал.
2. Успех веб-игры = скорость входа + ясный первый опыт, а не только качество core loop.
3. Дистрибуция решает: платформа уровня Poki может снять большую часть маркетинговой нагрузки.
4. Размер и загрузка критичны: каждый лишний мегабайт влияет на удержание.
5. Playtesting на живой аудитории дает инсайты, которые почти невозможно получить в “лабораторных” условиях.

Источник: Software Engineering Daily, выпуск с Эриком Дабилбором (Poki) о состоянии веб-геймдева и платформенной экосистеме.

Читай также

• Паттерны проектирования ИИ-агентов - Каталог из 18 архитектурных паттернов для проектирования агентов на основе foundation models
• System Design для LLM: разбор trade-offs - Практические решения по архитектуре AI-продуктов