Почему Google Stadia - шаг вперёд, но не панацея?

На прошлом «Горячем Чае», помимо прочих новостей, обсуждался анонс нового игрового сервиса от Гугла — Stadia. На ММОзговеде уже есть отличная статья про Стадию, но в ней в большей степени рассуждается не о технических проблемах, с которыми может столкнуться сервис и его клиенты. Я же, поскольку по долгу службы имею некоторое отношение к «инфраструктурно-техническим» аспектам передачи данных через интернет и прочим низкоуровневым штукам, хотел бы подробнее окунуться именно в них.

Итак, Google Stadia. Напомню коротенечко, что она собой будет представлять — фактически, это надстройка над стандартной функциональностью Youtube, дополненная возможностью обратной связи. То есть вы, как и раньше, смотрите в браузере (разумеется, раз это Гугл — речь идёт о Хроме) видеотрансляцию, но в руках у вас манипулятор, будь то геймпад или мышь с клавиатурой — и вы, глядя на изображение, можете тыкать в кнопочки, отправляя на серверы Гугла сигнал, перемещающий вашего персонажа, начинающий каст заклинания, поворачивающий самолёт — что угодно. Звучит, согласитесь, довольно многообещающе.

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

Как и было сказано Atron `ом в предыдущей заметке про Стадию — это существенно снижает порог вхождения, устраняя необходимость иметь свежее и производительное железо. Возможность запустить игру на здоровенном телевизоре, вольготно расположившись, приняв диагональное, а то и горизонтальное положение на диване перед ним — моя давняя мечта.

Переходим от восторженной части к скептической.

Гугл анонсировал довольно солидный список игр, которые будут доступны для игры через Стадию в момент релиза. В нём присутствуют файтинги, шутеры, гонки… даже одна полноценная ММО — TESO. Некоторые из игр — чисто «спинномозговые», то есть завязаны на скорость реакции и оперативный ответ игрока. Знаю, некоторые могут сразу же начать рассказывать мне про 25, а то и 60 кадров в телевизоре, про десятки миллисекунд и то, что Гугл «шутить не будет», расположив свои дата-центры чуть ли не в каждом городе-миллионнике. Господа, забудьте про это, просто забудьте — вот вам, например, полноценное научное исследование, демонстрирующее результаты в районе 200-250 миллисекунд. Если выборка в 120 подопытных вас не впечатлила, то вот менее академическое по форме, но значительно более репрезентативное. Безусловно, существуют особи, реагирующие значительно быстрее — взять хотя бы киберспортсменов. Но мы-то сейчас, напомню, про снижение порога и доступ к играм для широких слоёв населения, в том числе пожилых и к онлайн-играм доселе непривычных, поэтому использование среднего результата вполне оправданно.

Итак, 250 миллисекунд. Пусть, для ровного счёта, будет 200. Что это за число? Это промежуток между моментом, когда на экране возникает изображение и моментом, когда человек, смотрящий на экран, делает что-то, среагировав на него — в нашем случае нажимает клавишу и/или двигает мышью. Надо заметить, что, на самом деле, все мы живём немного в прошлом — то, что мы видим и слышим, на самом деле, уже произошло, а до нашего сознания эти сигналы приезжают с небольшой задержкой, требующейся на достижение видимым светом или звуком соответствующих рецепторов (это быстро, пренебрежём), возбуждение нервных клеток, передачу сигнала в мозг и его обработку.

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

• 0 мсек — на экране появилось изображение противника
• 0-200 мсек — сигнал доехал до мозга, обработался, игрок отправил сигнал в руку нажать на кнопку стрельбы (напомню, что всё это время внутри игры что-то происходит — модельки не стоят на месте, а двигаются, стреляют и т. д.)
• 200 мсек — кнопка нажата, электрический сигнал от геймпада едет к браузеру, а оттуда — через интернет в дата-центр Гугла
• 250 мсек — сигнал о том, что игрок решил пострелять, доходит до Гугла (примем для простоты, что Гугл у нас под боком и пакеты до него доходят за 50 мсек, временем обработки внутри Гугла пренебрежём, т. к. оно действительно может быть небольшим)
• 250 мсек — Гугл отправляет новую картинку с результатом стрельбы обратно игроку
• 300 мсек — новая картинка доезжает до экрана игрока
• 500 мсек — игрок осознаёт, что произошло

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

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

В случае с многопользовательскими играми на локальном компьютере — это незаметная на первый взгляд хитрость, заключающаяся в том, что происходящее на экране не отображает в точности положение вещей, обсчитываемое на сервере. Объясню подробнее — когда вы играете в хорошо спроектированную ММО, клиентская часть игры, которая запущена у вас на компьютере, показывает вам действия персонажа до того, как соответствующая информация доедет до сервера. Нажали на кнопку — и человечек побежал одновременно с этим, а не после того, как данные доедут до сервера, обработаются и вернутся обратно. Да, такая реализация зачастую приводит к коллизиям и странному — фаерболл может скастоваться, но не нанести урона, потому что за те самые 50 миллисекунд, пока информация о нём доедет до игрового сервера, цель успеет забежать в укрытие. Сакраментальное проваливание транспорта под текстуры в Eco — это же оно самое! Машина на экране едет, а сервер ещё не успел прислать подтверждение, что там есть в наличии твёрдая поверхность. А раз не успел — мы падаем под текстуры в соответствии с физическим движком. Расплата за значительно большую отзывчивость.

Предвосхищая грабли, которые я описал, Гугл, надо отдать ему должное — анонсировал некую систему, направленную на улучшение этой самой отзывчивости:

«Negative latency» is a concept by which Stadia can set up a game with a buffer of predicted latency between the server and player, and then use various methods to undercut it. It can run the game at a super-fast framerate so it can act on player inputs earlier, or it can predict a player's button presses.

Но хватит про «инпут лаг», поскольку есть и другие замечания. Второе, о чём я хотел бы поговорить — случаи временного отсутствия передачи данных. Ну, скажем, где-то что-то сглючило и несколько пакетов на пути между игроком и сервером Гугла потерялись. Что будет происходить в этом случае? В обычных играх вы можете этого даже не заметить, просто все модельки вокруг вдруг скачкообразно переместятся. То же самое и с вашим персонажем — та же самая хитрая клиентская часть игры запоминает ваши нажатия и аккумулирует их, отправляя на сервер не одни и те же координаты и действия, а разные — это, кстати, и превращается в различные «спидхаки» и «прохождение через стены» в случае злонамеренного использования; ваш персонаж всё это время радостно продолжает движение. А когда у нас нет ничего, кроме картинки — что делать? Очевидно, у вас на экране всё застынет, а потом, когда передача данных восстановится, вы окажетесь в том же самом месте, где остановились. А может и нет — это как Гугл решит.

Насчёт «хаков», кстати, я настроен довольно скептически. Несмотря на то, что в Стадии будет невозможна модификация сетевых пакетов, мы встаём лицом к лицу с другой проблемой — существенным упрощением жизни ботам. Посудите сами — у нас есть только браузер, без какого-либо античита и защиты от постороннего ПО. Остаётся только один раз настроить распознавание изображения — и практически недетектируемая автоматизация прокачки будет готова.

Следующее замечание — про качество интернет-канала. Не буду рассказывать наверняка уже всем надоевшие и известные вещи про то, что даже минимальные потери пакетов могут драматическим образом ухудшить процесс передачи данных. Да, для видеопотока это не так критично — там же наверняка UDP и потери пакетов просто будут вызывать артефакты изображения, которые, в общем-то, не так уж и критичны. Ну а обратная связь? Что, если мы нажали на кнопку, а пакет с этой информацией потерялся? Наверняка для действий игрока будет предусмотрена некоторая отказоустойчивость или избыточность, но фактически — это ровно то самое, что by design реализовано в TCP — гарантированная доставка или оповещение отправителя о неудаче. Проблему с потерей пакетов это решает, но создаёт новую — взаимодействие становится раза в три медленнее.

Продолжая тему с каналом, хочу также напомнить про такие феномены современного интернета, как «ассиметричная маршрутизация» и «пиринговые войны». Первая представляет собой ситуацию, когда данные между двумя точками в одну и другую сторону передаются разными путями, зачастую с существенно отличающимися задержками. Бывает такое как из-за некорректно настроенного сетевого оборудования, так и сознательно — для экономии денег. Пиринговые войны — отличный пример попытки такой экономии: это ситуация, при которой два интернет-провайдера или просто владельца автономных систем почему-то не смогли договориться и, даже будучи подключенными к одной точке обмена трафиком, передают пакеты друг другу через кого-то третьего. В наиболее экзотических случаях это может приводить, например, к тому, что вы, будучи, скажем, в РФ, пытаетесь зайти на сайт, расположенный в РФ, а данные при этом ходят через Европу, а то и Америку с соответствующим пингом и уменьшением скорости загрузки. А учитывая, насколько в последнее время различные государственные структуры склонны к «регулированию интернета», исключать возникновение подобных казусов никак нельзя.

Моё любимое, про пропускную способность. Гугл анонсировал, если помните, "at least 10 Mbit/s for 720p 60 FPS Stereo, 20 Mbit/s for 1080p HDR Video 60 FPS 5.1 Surround, and 35 Mbit/s for 4K HDR Video 60 FPS 5.1 Surround". Остановимся на видеопотоке, поскольку про сжатие музыки я знаю гораздо меньше. Итак, раз Стадия работает через Гугл Хром, значит, скорее всего, будет использован гугловский же кодек VP9. Безбожно утрируя, да простят меня профессионалы, практически все современные алгоритмы сжатия видео работают примерно так: берём целую картинку, слегка оптимизируем её в соответствии с особенностями человеческого зрения — это будет так называемый «ключевой кадр», от которого мы дальше и будем плясать. Поскольку полностью или хоть сколько-нибудь сильно изображение на экране меняется относительно редко, мы можем поиспользовать ключевой кадр для того, чтобы все следующие изменения на экране отображать, трогая только изменяющиеся места — и уже на одном этом экономим ну очень существенно. Кроме этой хитрости изображение может разбиваться на блоки, похожие блоки «схлопываться» и т. д. — всё это уже высокоуровневая магия, в такие дебри углубляться не будем. Для нашей заметки важно запомнить одно — чем больше изменяется на экране, тем выше в данный момент битрейт видео, а значит и требуемая пропускная способность канала. В случае игр у нас есть простор для экономии в виде совершенно неподвижных частей экрана вроде графического интерфейса, панелей со скиллами и т. п. Минимум 10 мегабит для 720p, окей. Но кто в наше время захочет 720p, согласитесь? Мой смартфон пятилетней давности имеет разрешение экрана выше, ближе к 1080p. Понятно, что на телевизорах разрешение бывает низкое, пиксели огромные — но далеко не все такие. 1080p по площади выше 720p в 2.25 раза. 4K — выше в 9 раз. Разумеется, имеются многочисленные (это просто какое-то дежурное слово заметки получается) хитрости в кодировании видео и просто брать и умножать 10 мегабит на девять не стоит, но фактически — в случае передачи одних и тех же сцен, амплификация будет плюс-минус кратной, то есть если в каком-нибудь активном замесе средние 10 мегабит у 720p превратятся в 15, то средние 35 у 4К-изображения — как бы не в 80. Всё это, разумеется, рассуждения вилами по воде, но с точки зрения сисадмина я хотел бы заметить, что далеко не каждый вайфай и даже не каждый домашний роутер, подключенный по кабелю, выдержит не то, что 80, 50 мегабит. Дешёвые устройства просто не предназначены для таких скоростей, а если интернет-провайдер ещё и использует какую-то инкапсуляцию вроде L2TP, то вообще пиши-пропало. Опять же — если в квартире, подъезде, доме таких 4К-игрунов несколько, то и нагрузка на оборудование провайдера увеличивается соответственно — тут уже никаких хитростей не придумаешь. Хорошо, если опорная сеть у него гигабитная. А если нет и там 100 мегабит на всех пользователей подъезда/дома?

Заметка получилась совершенно монстроузная по размеру, но ещё один абзац, я верю, что вы, уважаемые читатели, осилите. Он будет про аппаратное обеспечение сервиса со стороны Гугла. Окей, предположим, что все страшилки, перечисленные выше, не случились и всё идёт по плану, красиво и отзывчиво. Нам предлагают массу разных по жанру игр от разных разработчиков. Какие-то из них хорошо оптимизированы, какие-то — не очень. Гуглом было заявлено, что «крутиться» в дата-центрах всё это будет на специально разработанных для них CPU и GPU. Оставим в сторонке обычные процессоры, благо — с ними обычно проблем не бывает и обратим взор на «видеокарты». Они, разумеется, не те, что стоят у нас внутри системных блоков, но пара параметров известна — "custom AMD GPU with HBM2 memory, 56 compute units, and 10.7 teraFLOPS". Звучит неплохо, для сравнения — мой предыдущий Radeon 4870 обладал всего 2.5 терафлопсами, а текущий VII — 13.5. Однако, как я сказал раньше — не все игры одинаково оптимизированы и даже использование высокопроизводительного Vulkan`а не всегда решает задачу — видеокарта в некоторых играх загружается на 80-100%. Нужно сказать, что даже в случае нетребовательных или круто написанных игр проблема никуда не уходит, потому что если разделение процессорного времени CPU между несколькими несвязанными между собой задачами хорошо и неоднократно реализовано, то то же самое на GPU — под вопросом. Да, там значительно больше вычислительных юнитов, но насколько сильно будет страдать общая производительность при распределении по ним нескольких задач — не ясно. Это я к тому, что в худшем случае получится — «один игрок на одной видеокарте».

Закругляя и так чересчур затянувшиеся рассуждения, могу сказать, что в целом я оптимистично настроен по отношению к Стадии и считаю, что в некоторых случаях этот сервис будет очень к месту. В список случаев, разумеется, не попадают ММО с активным PvP, стрелялки и файтинги, но для более спокойных активностей она должна подойти. Разработка новых аппаратных решений — тоже безусловное благо в условиях довольно вялой конкуренции на рынках обычных и графических процессоров. Каким-то убийцей Стима и GOG`а Stadia станет вряд ли, но в целом — «будем посмотреть».