Кажется, облачный гейминг переживает не лучшие времена, но с этим стоит поспорить. Как минимум одна российская компания уверенно чувствует себя на этом рынке.
Мы позвали Сергея Панферова, основателя и генерального директора Loudplay, чтобы он рассказал как создавался их сервис, на каком стеке делали, какие проблемы решали, почему провалилась Google Stadia и как в последний момент выскочить из под санкционного пресса.
Как создавали Loudplay
На уровне идеи Loudplay появился в 2014 году. Тогда NVIDIA презентовала решения серверных графических карт NVIDIA GRID. Это была перспективная технология, на основе которой вполне можно было построить коммерчески успешный игровой стриминг — перенести все необходимые для игр расчеты на удаленный сервер, чтобы даже самые требовательные к железу проекты запускались на любом компьютере.
Все, кто стал ядром нашей команды, тогда работали в дочке Мегафона, которая занималась развитием новых цифровых продуктов и технологий. Начальство идеей не заинтересовалось, так что вскоре появился новый стартап.
Сперва мы прошли в акселератор ФРИИ, открыли компанию, начали пилить MVP. Выбранная стратегия: не уходить в дебри разработки, а как можно раньше запуститься, проверить идею, получить отзывы пользователей, протестировать каналы привлечения — в итоге себя оправдала.
С технической точки зрения проект начинался очень просто. Мы купили сервер на Авито, видеокарту на Amazon и запустили первых пользователей. Качество видео было низким, сервер — слабым, а я выполнял функции бэкенда, вручную, по IP-адресу добавлял пользователей на сервер в порядке очереди. Потом написали простейший бэкенд и сервис заработал 24/7, но начиналось все буквально на коленке.
Несмотря на то, что это было MVP, пользователи сутками играли сверхпопулярный тогда PUBG, и благодаря им к 2018 году мы привлекли внимание инвесторов. Арендовали новые сервера, начали вкладываться в разработку собственного протокола видео-стриминга, сайта, интерфейсов. Однако принципиально ситуация изменилась только после переезда в Иннополис. Там мы нашли серьезные инвестиции, кучу клевых ребят из университета, которые стали частью команды и помогли допилить продукт.
Сейчас сервис работает на Windows, MacOS, Android. Над версией для Linux тоже думали, но бета-клиент скачали единицы, поэтому он пока остался в лаборатории. Мы будем работать с Linux в проекте по реализации рабочих мест для B2B, но это отдельная история, сперва расскажу, как устроен Loudplay.
Наш стек
У нас 4 крупных направления разработки, в каждом из которых применяется свой стек. На Android — это Kotlin и С++. В десктопном приложении мы используем JS + Electron + React + Typescript + NodeJS. Тот же стек и на веб-сайте. Самое важное для нас направление — стриминг-движок — целиком, и клиентская, и серверная части, написан на C++.
На бэкенде, где крутится вся логика нашего продукта, основной язык программирования — Java и его фреймворки, например, Spring Boot, а для мелких задачек на бэке мы используем Python и Perl. В основном это сбор статистики, небольшие кусочки легаси-кода и движок ИИ для анализа пользовательского опыта на основе действий игроков.
В качестве идеологии для API мы взяли RESTful API. Мы используем его для взаимодействия наших трех фронтов — Android, десктоп и веб, с бэкендом. В качестве технологии авторизации применяем JWT-токены.
Данные храним в трех разных базах, в зависимости от их типа и статуса. Одна реляционная БД и две NoSQL. Одну из них используем в качестве брокера сообщений между компонентами системы и для пользовательской очереди на подключение к сервису.
Сначала мы использовали монолитную архитектуру на бэкенде, но быстро поняли, что монолит развивается долго и мешает оперативно выводить новые функции на рынок. Тогда приняли решение перейти на микросервисы. Сейчас у нас около 40 микросервисов различной «тяжести»: от авторизации и управления сессиями, до подсистем, отвечающих за управление гипервизором. Для работы с ними мы выбрали Kubernetes.
Технический стек построен на системе виртуализации, которая устанавливается на хост, виртуальных машинах с гостевыми операционными системами и стриминг-сервере. В основные функции последнего входят: захват изображения, его энкодирование в транспортный видеопоток и передача видео на клиентскую часть. В роли хоста выступает производительный сервер с графическим процессором, желательно, с поддержкой виртуализации. Технологии NVIDIA и AMD позволяют пробрасывать не весь чип карты в виртуальную машину а, «нарезать» его в зависимости от требуемой производительности и выделять конкретному игроку. Игровые сервера подключены к единой системе хранения, в которой лежат игры и пользовательские данные.
Стандартная спецификация одной виртуальной машины — 4 ядра 2,8, 3,5 ГГц, 16 или 32 Гб оперативной памяти и от 12 до 16 Гб видеопамяти. С этими ресурсами большинство новых игр работает в диапазоне от 45 до 60 FPS.
Впрочем, мы экспериментировали с и 4К-8К разрешением и с 120 FPS. Под эти задачи требуется больше ресурсов, так что один сервер одновременно обслуживает меньше пользователей. Но это скорее задел на будущее, высокие разрешение и частота кадров пока не пользуются особым спросом.
Сейчас стриминг работает стабильно, но так было далеко не сразу. На этапе тестирования мы получили массу негативных отзывов. Чаще всего игроки жаловались на качество изображения и задержки.
Как мы нашли баланс между скоростью интернета и качеством картинки
Эти два параметра в основном и определяют качество пользовательского опыта при облачном гейминге. Сложность в том, что они зависят друг от друга.
По статистике, большая часть наших пользователей играет в Wi-Fi сетях. Они-то чаще всего и сталкивались с «лагами» и снижением качества картинки.
Со временем мы поняли, что Wi-Fi довольно часто теряет пакеты, но обычно это незаметно. YouTube да и все остальные сервисы потокового видео используют буферизацию на клиентской стороне. Она нивелирует потери, возможные в Wi-Fi сетях. Однако, буферизация в облачном гейминге существенно увеличивает задержки управления в игре, так что мы не можем использовать этот подход.
Пришлось пойти по другому пути и разрабатывать технологию избыточности данных для нашего протокола передачи видео. Она требуется, чтобы в режиме реального времени восстановить потерянные данные на клиентской стороне без перезапроса пакетов и пережить достаточно высокие потери на сети Wi-Fi без лагов, артефактов картинки и увеличения задержек управления.
Цели мы добились, но отладка протокола потребовала уйму времени: сложность в том, что мы имеем дело с ограниченной шириной канала и чем большую избыточность закладываем при передаче данных, тем меньше пропускной способности остается для «полезных» данных. В результате страдает качество картинки. Здесь необходимо поддерживать постоянный динамический баланс.
С одной стороны, необходимо чтобы канал до пользователя использовался на все 100%, а с другой поддерживать уровень избыточности в достаточном диапазоне, чтобы нивелировать внезапные потери в «воздухе», но не ухудшать качество картинки.
Для этого мы разработали технологию автоматического битрейта. Мы измеряем время прохождения видеофрейма от момента отправки его на энкодер на серверной стороне до момента его отрисовки на клиентской стороне. Если ширина канала начинает утилизироваться на 100% и в сети появляется бутылочное горлышко, то сервер фиксирует увеличение времени прохождения фрейма и начинает снижать битрейт, не допуская сброса пакетов на «боттлнеке». Если сервер фиксирует снижение времени прохождения фрейма, то битрейт увеличивается. Через некоторое время, после того как алгоритм нащупал пределы, мы начинаем менять битрейт чаще и с меньшей амплитудой, чтобы приблизиться к 100% ширины канала.
Этот метод имеет одно важное преимущество. Дело в том, что бутылочным горлышком может быть не только сетевое оборудование, но и декодер клиентского устройства. Если клиентский ПК не справляется, и время декодирования и отрисовки картинки увеличивается, то с помощью алгоритма мы снимаем с него излишнюю нагрузку.
Когда найдены верхние пределы канала, можно вернуться к настройке избыточности. Вначале мы увеличивали или уменьшали избыточность в зависимости от типа клиентского подключения и доступной ширины канала, но это давало не очень хорошие результаты. Ситуация значительно улучшилась, когда мы усовершенствовали алгоритм и в качестве входных данных добавили уровень потерь на канале.
После этого мы начали эксперименты с нейросетью: в качестве входных данных добавили несколько параметров состояния канала и начали обучать алгоритм на возможность предсказания времени, когда у пользователя начинаются «внезапные» потери.
В результате удалось достичь точности предсказания на уровне 90%. Далее мы научили алгоритм использовать эти предсказания и заранее (за несколько секунд до возникновения потерь) увеличивать избыточность, чтобы избежать потери данных. С помощью этого приема мы включаем избыточность, когда это действительно необходимо, так что качество картинки в среднем стало заметно лучше. Сеть обучается, и результаты продолжают улучшаться.
Такая тонкая настройка алгоритмов позволила нам существенно улучшить качество передачи видео и на Android, где связь еще более непредсказуемая, особенно когда пользователь передвигается.
Когда мы начали анализировать технологии, существующие на рынке, то оказалось, что так глубоко еще никто не копал. Так что все эти алгоритмы мы запатентовали.
Как решили проблему залипаааания клавиш
Другой заметной проблемой стало то, что иногда игровые персонажи не слушались управления, шатались или бежали куда-то вопреки командам. Это было совсем не похоже на обычные проблемы с пингом, так что мы отдельно исследовали такие случаи. Проблема появлялась на больших расстояниях до сервера, и, опять же, при игре через Wi-Fi, но дело было не в самом подключении, а в том, как мы доставляли команды до сервера.
В начале мы использовали обычный протокол UDP. Он быстрее TCP, который накладывает дополнительные оверхеды и задержки. Проблема в том, что каждое нажатие клавиши в UDP представляет собой два отдельных сигнала: нажатие и отпускание клавиши.
Если игрок нажимает кнопку и отпускает, но второй сигнал не добирается до сервера, то клавиша как бы залипает. Персонаж все время бежит, например, налево, пользователь этому сопротивляется и жмет кнопку вправо. Конечно, это не помогает. Чтобы клавиша отлипла, надо еще несколько раз нажать влево, но это контринтуитивно.
В итоге мы пришли к двум решениям. Первое — когда сервер понимает, что клавиша залипла и отпускает ее принудительно. Это не совсем подходит, потому, что пока сервер поймет, что клавиша залипла, игра какое-то время остается нерабочей.
Поэтому мы используем второй путь: если нажата или отпущена клавиша, мы отправляем повторное нажатие или отпускание в течение N миллисекунд. Это повышает вероятность доставки сигнала. Оказалось, что таким образом мы можем нивелировать до 50% потерь на исходящем канале. Решение логически, хоть и простое, но потребовало существенной переработки сервера и клиента, так как при играх используются и клавиатура, и мышка, и джойстики.
Был случай, когда мы организовывали соревнование по Dota 2 на презентации 5G от МегаФон. Сервера стояли в Питере, а играли в Москве, и на последней миле, то есть уже на самой выставке, сигнал как раз передавался по воздуху. Но хак с повторной отправкой команд сработал, багов не было, киберспортсмены остались довольны.
Что насчет мобильных устройств
Наладив стриминг и передачу команд мы смогли вплотную заняться мобильным приложением. Основным вызовом стало управление. У большинства наших клиентов нет геймпада, который можно подключить к смартфону, поэтому нам пришлось разрабатывать экранные органы управления.
Удачное расположение виртуальных кнопок и стиков мы частично подсмотрели у разработчиков, которые портировали PC-игры на смартфоны, но в большей части разрабатывали сами, так как далеко не все игры имеют мобильные версии. Один универсальный вариант мы так не нашли и реализовали эмуляцию нескольких видов контроллеров под разные типы игр: шутеры, гонки и стратегии.
Похоже, получилось неплохо. По крайней мере по статистике уже 50% наших клиентов играет со смартфонов и этот показатель продолжает расти. При этом среднее время в игре составляет 20 часов в неделю.
Про NVIDIA и планы на будущее
По данным на октябрь 2022 наше мобильное приложение скачали более 3 млн раз, а прирост пользователей составляет 15-20% в месяц. Активнее всего растет спрос в США, Мексике, Бразилии, Аргентине и Таиланде. Отчасти это органический трафик, но мы довольно успешно научились привлекать пользователей с помощью рекламы и совместных проектов с телеком-операторами с Ближнего востока и Латинской Америки.
Только мы нарастили вес на фоне мировой cloud gaming-индустрии, как NVIDIA ушла с российского рынка. За много лет сотрудничества у нас сложились достаточно теплые отношения с этой компанией. Они поддерживали Loudplay с 2015 года. Все это время у нас был доступ к серверным картам, обновлениям драйверов и технической поддержке, но сейчас отношения затихли — компания внезапно исключила нас из реестра прямых партнеров, и, хотя на личном уровне мы продолжаем общаться, доступа к технологиям и обновлениям больше нет.
Это было бы сильным ударом, но мы уже давно старались смотреть по сторонам, делали лабораторные испытания — заранее апробировали стриминг-сервер под AMD, и, когда пришло время, — ввели его в эксплуатацию. Технология виртуализации видеопамяти у AMD в чем то похожа на Nvidia. За исключением того, что на Nvidia за распределение запросов от виртуальных машин в ядро отвечает софтверный модуль, а AMD делится на уровне ядра (MxGPU).
При этом за рубежом, в Европе, США, странах Латинской Америки, мы выбрали организационное решение и перешли на бизнес-модель аренды инфраструктуры у телеком операторов сразу со всеми подсанкционными лицензиями и драйверами.
Можно сказать, что для нас санкции стали дополнительным стимулом к диверсификации бизнеса. Когда мы проектировали сервис, то отказались от идеи с собственной библиотекой игр. Вместо этого мы предоставляем игрокам доступ к полноценной виртуальной машине, где они сами устанавливают любимые игры.
Эта концепция виртуального ПК легко распространяется на компании, которые нуждаются в удаленных рабочих местах. После ухода Citrix и VMware снова возникла потребность в таких решениях. В принципе на таких, расположенных за рубежом машинах, можно запускать и тот софт, который сейчас недоступен в России. Мы прорабатываем такую возможность, но пока не знаем, как к такой хитрости отнесутся регуляторы.
Впрочем, беспокоиться нам не о чем. После недавнего закрытия Google Stadia многие поспешили похоронить клауд гейминг, но мне кажется, что этот случай не показателен. Во многом этот сервис стал жертвой неудачного позиционирования: закрытая библиотека игр с малым числом новых релизов, трения с издателями, продажа физических джойстиков. Проблема Stadia не в технологии, а в негибкой бизнес-модели.
У нас есть клиенты в более чем 50 странах мира, и везде свои паттерны потребления. В США и Мексике у нас больше всего играют в GTA V, Marvel’s Spider-Man и Call of duty. В Бразилии любят CS:GO и FIFA23, в Тайланде сейчас на пике популярности DYNASTY WARRIORS 8. В Индии, как и в РФ игроки любят устанавливать различные моды.
Время, проведенное игроком на нашем сервисе, тоже различается. В США это примерно по 30 минут в день. В странах Ближнего Востока пользователи играют по несколько часов в день. А в Индии и Таиланде, некоторые пользователи играют по 8-10 часов в сутки, но в основном с мобильных устройств. Так что и стоимость тарифов мы подбираем индивидуально под каждую страну.
Кстати, языковая адаптация сервиса и рекламы под разные страны тоже оказалась непростой. Найти хорошего переводчика на японский — целый квест. Да что там, даже такой «обычный» рынок, как США преподносит сюрпризы. Когда мы только вышли в штатах, то никак не ожидали, что количество испаноязычных игроков вскоре сравняется с числом англоязычных и продолжит расти.
При этом один тренд прослеживается четко — устойчивый рост спроса на клауд гейминг в России, Азии, странах Латинской Америки и США.
Облачный гейминг в ближайшее время, возможно и не заменит игровые компьютеры, но тренд на использование смартфонов для ПК игр мы уже отчетливо видим. Вполне возможно через 5-10 лет тонкие клиенты будут занимать значительную долю рынка. Клауд гейминг будет расти, плавно вовлекая пользователей — чем больше людей узнают, как это работает, — тем больше будет пользователей у таких сервисов. И мы в Loudplay к этому готовы.