СКОРОСТЬ ЗАГРУЗКИ ИГРЫ

Илья Богин: Всем привет! Меня зовут Илья Богин. Я руковожу платформой для разработчиков в рамках Яндекс Игр, занимаюсь тем, чтобы жизнь разработчиков в рамках платформы была максимально комфортной, а игры получались качественными. Что-то у нас уже получается, что-то пока в процессе. Но, я надеюсь, у нас есть светлые цели, и мы к ним движемся. Сегодня мне поможет ещё Артём. Артём, тебе слово.

Артём Шалаев: Привет. Меня зовут Артём. Я маркетолог в команде Яндекс Игр, занимаюсь той частью маркетинга, которая у нас называется b2b или b2d. В основном специализируюсь на маркетинге, который взаимодействует с разработчиками. Всячески стараюсь помогать Илье с коммуникациями с вами. И сегодня я рад присоединиться к этому эфиру в роли не слушателя даже, а задающего вопросы. Потому что мой опыт в разработке игр оставляет желать лучшего, потому что я всё-таки маркетолог. Когда мы с Ильёй будем разбирать сегодняшнюю повестку, я буду задавать много разных вопросов — для того, чтобы мы могли эту тему раскрыть более широко.

Илья Богин: О чём мы сегодня поговорим?

Артём Шалаев: Будем разговаривать про скорость старта, и, может быть, не лишним будет начать с базового вопроса: что такое вообще скорость старта, что это за термин, что это за метрика?

Илья Богин: У меня есть небольшая презентация. Совершенно случайно вдруг она у нас ко встрече появилась. Давайте мы с неё и начнём.

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

Вопрос о скорости старта, скорости загрузки — этими понятиями мы будем жонглировать сегодня, называть то так, то эдак — это непростая задача. Почему? Представим метрику DAU — дневная активная аудитория. С ней более-менее всё понятно. Есть, конечно, сложности, но всё равно хотя бы на базовом уровне понятно: человек пришёл, запустил игру, поиграл. Это было в тот день, в который мы замеряем эту метрику, он засчитался нашим игроком. Со скоростью загрузки игры кажется: да, вот она, типа, быстро загрузилась — значит, там быстрая скорость загрузки. Медленно загрузилась — значит, медленная скорость загрузки.

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

С такой проблемой сталкиваемся не только мы в рамках игр, но сталкиваются все, кто занимается улучшением технических метрик — от веб-сайтов до мобильных или десктопных приложений. Сложился определённый подход к тому, какими числовыми метриками можно охарактеризовать скорость старта и как правильно выбирать эти точки, какая у них семантика. Я немножко опишу эту семантику, её state of the art, то есть текущее понимание скорости старта, как оно в большинстве как мобильных, так и веб-применений используется.

Скорость старта описывается набором метрик. Самая ранняя из них обычно по появлению — и с точки зрения пользователей, и с точки зрения замера — это FCP, First Contentful Paint. Это когда у нас появилась на экране какая-то первая информация, которая несёт какой-то смысл. Например, надпись «Loading». Если она появилась — уже хотя бы понятно, что происходит загрузка игры.

Артём Шалаев: Уточню. В момент, когда, например, я открываю игру на Яндекс Играх и вижу там лоадер от Unity, от движка, — это уже будет считаться FCP?

Илья Богин: Да, это уже засчитается FCP. Тут, кстати, отдельно ещё скажем, что игровые движки, поскольку они работают в большинстве своем через canvas, немножко эти метрики ломают. В случае игрового движка, как правило, FCP и LCP будут совпадать, потому что у вас сразу появляется достаточно большой блок, отрисованный на canvas. Если вы делаете игру чисто через canvas, не используя схему с отдельным слоем HTML, DOM, который сначала инициализируется, а уже за ним, задним слоем, загружается canvas с движком игры... есть такой подход... Так вот, если у вас отдельный слой HTML — FCP у вас может быть отдельно. А если вы работаете с чистым canvas, то у вас, скорее всего, FCP и LCP будут засчитаны одновременно. Есть такая особенность, и наш мир, мир игр, очень интересен тем, что он находится между мирами веба и приложений. Не относясь впрямую ни к тому миру, ни к другому, он сочетает в себе и то, и то. Это не совсем веб-сайт в привычном понимании и тем более не совсем приложение в привычном понимании. Получается, что игры где-то между, и мы что-то берём отсюда, что-то берём отсюда. Получается достаточно интересная необычная схема.

Артём Шалаев: При этом эти метрики и их вот обозначения, аббревиатуры они одинаковы и для веба?..

Илья Богин: Это общепринятые метрики. В частности, Google активно продвигает свой подход с Lighthouse, с измерением Lighthouse score, он ориентируется на эти метрики и их периодически меняет. Там раз в несколько лет происходит обновление: одни метрики уходят, другие приходят им на смену. Например, раньше был FMP — First Meaningful Paint, сейчас он заменился на FCP. Google им присваивает разные веса — в общем, там достаточно сложно и интересно.

Продолжаем рассказывать более глубоко об этих метриках. LCP, Largest Contentful Paint, — это появление какого-то уже большого осмысленного куска информации. И ещё 2 метрики, связанные с тем, готова ли игра к взаимодействию с пользователем, — TBT и TTI. Может быть, визуально всё уже готово: менюшка есть, картинка есть, есть надпись типа «Loading succeeded», но ничего не происходит, потому что на самом деле идёт ещё какая-то распаковка ресурсов, загрузка движка и т. д. И метрики TBT, Total Blocking Time, и TTI, Time to Interactive, как раз говорят о том, готово ли всё к старту или ещё нет, наступил ли момент интерактивности.

Это основные метрики, с которыми работают веб-разработчики. Они сейчас активно начинают использоваться и в мобильных приложениях. Но в нашем мире HTML5-игр, которые находятся между мирами, впрямую их применить не совсем получается — в частности, потому, что многие игры сразу показывают canvas, на нём сразу что-то происходит, что-то уже есть. Вроде бы, и FMP, и FCP, и LCP — всё уже прошло... Метрика CLS, Content Layout Shift, ещё одна интересная метрика, тоже неприменима, потому что у нас нет отдельной подзагрузки блоков, у нас обычно интерфейс загружается в более цельном варианте. И поэтому для разработчиков HTML5-игр я бы рекомендовал обращать внимание в первую очередь на TTI, Time to Interactive, то есть момент, когда игра стала интерактивной, когда она готова к работе.

Давайте погрузимся в глубины Time to Interactive, посмотрим, как она считается, как она смотрится и т. д. В идеале её хочется замерять автоматически. Есть 2 подхода: можно вручную пытаться что-то замерить со стороны игры, и это подход, связанный с GameReady API, когда ответственность лежит на разработчике игры, чтобы он правильно отмаркировал момент завершения загрузки. Но помимо ручного замера хочется иметь некие автоматизированные способы. Этот автоматизированный способ — как раз Time to Interactive. Но как изнутри игры понять, что игра готова, что TTI случился? Это непростая задача. Как мы её решаем и как вообще её принято решать?

Есть возможность слушать потоки выполнения задач. В первую очередь нас интересуют длинные задачи, которые надолго занимают ядра процессора, лонг-таски. Соответственно, появляется какое-то количество лонг-тасков, связанное с дозагрузкой ресурсов, инициализацией движка, с выполнением java-скрипта какого-то инициализационного — в общем, с большим количеством работы, которую необходимо провести на старте. Мы слушаем и ждём, пока они завершатся. Поскольку они могут приходить в произвольном порядке, они не обязаны выстраиваться в чёткую цепочку. Что делаем? Ждём, пока завершатся основные таски, выжидаем определенное время, чтобы понять, что новых тяжёлых тасков пока не появилось. И когда понимаем, что прошло это окно тишины, говорим: ага, значит, момент начала этого окна тишины и был тем самым TTI. Это достаточно важный момент: замеряется он в будущем, но цифру всё-таки даёт правильную в прошлом. Он высказывает гипотезу, типа: ага, появилось окно тишины, возможно, это TTI. Если эта гипотеза подтверждается — мы действительно репортим это значение как TTI. Если опровергается, мы говорим: ага, мы неправильно угадали TTI, ждём, пока опять завершатся все таски, опять выскажем гипотезу, может быть, сейчас как раз уже есть окно тишины. Замеряем. Да, вот теперь как раз наступило окно тишины. Возвращаемся назад и получаем то самое значение.

Это окно тишины по-разному принято замерять. Подход Google — 5 секунд тишины. В рамках именно Яндекс Игр мы используем 3 секунды тишины. Это может варьироваться. У нас пользователь сразу, как только что-то появилось, уже готов играть. Мы не можем ждать 5 секунд, ему нужно обязательно что-нибудь нажать и уже начать играть.

Важный момент — это эвристика. Это некий набор наших правил, которые мы применяем, чтобы замерить. Он может давать ложные результаты. Его плюс в том, что для разработчиков игр не требуется дополнительных действий, чтобы эта метрика автоматически рассчитывалась, но она может давать некорректные результаты. Поэтому мы и используем 2 метрики и предоставляем вам возможность ручного замера, чтобы вы могли сами, основываясь на вашей экспертизе, на вашем JS-коде, С#-коде, JDScript-коде и т. д., сказать: да, моя игра готова к работе.

Артём Шалаев: Резюмирую для себя. Мы считаем Time to Interactive основной метрикой, которая определяет скорость старта.

Илья Богин: Это важная с точки зрения пользователя метрика, потому что в этот момент он может начать игру. До её достижения не может.

Артём Шалаев: Понял, спасибо. А если откатиться назад? Вот мы определили и сформулировали для себя эти метрики. И для меня, пока ты проводил аналогию с какими-то продуктовыми метриками, было максимально понятно. Как маркетолог, я понимаю, как и зачем считается DAU. А почему так важно именно метрики скорости загрузки обсчитывать?

Илья Богин: Уточню. Ты задаёшь вопрос именно зачем в целом нужно следить за скоростью загрузки игр или всё-таки за какими-то конкретными моментами?

Артём Шалаев: В целом.

Илья Богин: Если было бы не нужно, мы бы не вводили эти метрики. Поэтому, конечно же, нужно. Теперь чуть-чуть поговорим о том, зачем это нужно.

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

Илья Богин: Давайте сразу чуть-чуть дисклеймера. Сейчас пара слайдов будет про еком. Это не HTML5-игры, это еком. Для Google еком-сервисы, реклама — рынок гораздо больше, поэтому он проводил исследования в первую очередь такого применения и такого влияния скорости старта на пользовательские метрики. Он смотрел с разных сторон. Во-первых, на то, как пользователи воспринимают сайты с разной скоростью загрузки. Есть различные подходы: NPS, готовность рекомендовать, удовлетворённость транзакцией. Вот с точки зрения именно NPS и готовности рекомендовать улучшение скорости старта статистически значимо повышало индекс удовлетворённости, который измеряется в виде готовности порекомендовать этот сайт кому-то из своих знакомых, коллег, друзей как сайт, через который следует работать. Изменение на 3 секунды дало улучшение этого показателя на 10%, что, на мой взгляд, очень большое значение.

Даже улучшение на 100 миллисекунд давало улучшение конверсии для транзакционных сервисов. Транзакционный сервис — это постоянная воронка-воронка-воронка. Сначала пользователь попал на сайт. Выберет он товар или нет? Если да, добавит ли его в корзину? Если да — перейдёт ли в чекаут? Если да — оплатит ли товар? И т. д. И во всей этой воронке срезается на каждом этапе какое-то количество пользователей: что-то не загрузилось, что-то я отвлёкся... Поэтому всё меньше и меньше доходит до целевого действия — заплатить деньги и оформить заказ. Улучшение этапа на сто миллисекунд давало значительное улучшение этой воронки, то есть количества пользователей, которые дошли до следующего шага. Поэтому общепринято считается, что скорость загрузки веб-сервисов влияет на их продуктовые показатели.

Теперь давайте перейдём к нашему домену — игровому. Может быть, у нас что-то по-другому? Другие пользователи и задачи? Может быть, пользователь, увидев иконку, влюбляется в неё, и ему уже не важно ждать 5–10–100 секунд — он ждёт и готов, и не будет этого среза воронки? Может быть.

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

Мы провели набор улучшений, который позволил общее время в рамках одного из перцентилей... Про перцентили мы поговорим потом... Даже сокращение на 1,3 секунды общего времени загрузки игры... Чтобы вы понимали абсолюты, для той когорты игр это в среднем было с 9 секунд до, условно, 7,5 секунд... Это сокращение дало улучшение ретеншна на три процентных пункта... 1,3 секунды — не очень большое значение, потому что понятно, что влияние Яндекс Игр на общее время загрузки игры, — конечно же, гораздо меньше, чем влияние движка самой игры, который может подгружать все свои модули или ваши ассеты, которые в большом количестве добавили в игру, которые необходимо скачать с сервера. Конечно, это даёт гораздо больше влияния, поэтому тут наше влияние ограничено, но даже в рамках него, когда мы смогли улучшить на одну секунду скорость загрузки, — это уже улучшило ретеншн на три процентных пункта.

Артём Шалаев: Уточняю: под ретеншном здесь мы понимаем некую возвращаемость пользователей обратно на сервис и конкретно в игру?

Илья Богин: Да. Поэтому в рамках домена игр, наших HTML5-игр, мы можем тоже говорить, что скорость влияет в первую очередь на ретеншн.

Артём Шалаев: Окей. Мы проговорили метрики, которые определяют скорость запуска игры. И видим, что это влияет и на возвращаемость пользователей, и на их восприятие. В том числе на восприятие игры в целом. А как же всё это применительно к Яндекс Играм нашим разработчикам оценивать?

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

Мы потому и не проводили этот вебинар, пока у нас не появились инструменты, которые мы готовы вам предоставить, чтобы вы следили за скоростью загрузки ваших игр. И как раз недавно мы анонсировали, что у нас на дашбордах появились 2 новых технических графика, с помощью которых вы, надеюсь, сможете измерять скорость загрузки игр. А дальше — уже предпринимать активные действия для улучшения скорости загрузки игр.

Вы можете замерять скорость загрузки игры либо в ручном режиме, либо в автоматическом. Мы рекомендуем делать и то, и то. Time to Interactive измеряет в автоматическом режиме. С одной стороны, для разработчика это максимально удобно: не нужно встраивать никакой дополнительный код, всё работает из коробки. Какие минусы подхода? Мы говорили, что TTI — это всё-таки эвристика. Она может в каких-то случаях давать не совсем корректные результаты, в том числе из-за того самого окна ожидания.

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

Артём Шалаев: И тут как раз уточняющий вопрос про возможные неточности. Когда пользователь перед стартом игры, если разработчик настроил показ рекламы, видит рекламные объявления — мы уже считаем, что игра загрузилась? Или этот TTI наступает после?

Илья Богин: Нужно аккуратно смотреть и перепроверять. Может быть и так, и так. Вы можете этим действительно замедлить, как бы обмануть радары и замедлить формальный TTI. И это одна из причин, почему мы всячески призываем использовать GameReady API. Потому что с ним вы сами чётко знаете, когда у вас закончился процесс загрузки игры, и до показа рекламы можете его вызвать. И тогда гарантированно у вас попадёт в отрезок старта только то, что действительно относится к старту.

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

Артём Шалаев: Верно ли, что подключенный GameReady API даёт более точную картину скорости?

Илья Богин: Это зависит от вас. Если вы его в код ставите в произвольном месте, наверное, он не будет давать точную информацию. Но если сделаете это осознанно, то он даст точную информацию, когда завершились все действия до этого этапа.

Артём Шалаев: Давай попробуем теперь сделать подход к непростым, на первый взгляд, графикам. Вот эти линии, которые обозначены как p25, p50. Что они означают?

Илья Богин: Начнём с простого. Запросы.

Запросы — это график, который измеряется по правой шкале. У нас здесь график с двумя шкалами. Левая отвечает за всё, что относится к перцентилям, — это то, что обозначается буквой p латинской. А правая шкала относится именно к запросам. Запрос — это отсылка информации либо о TTI, либо о GameReady. То есть 1 вызов соответствующей функции.

Теперь измеренное значение. Мы показываем его в виде 4 потенциальных линий. Вы можете их включать-отключать, по умолчанию включены p50 и p95. Это перцентили — 50-й и 95-й. Почему мы их используем? Разберём.

Различные метрики имеют различные типы распределения. Первое — то, что называется «нормально распределённые величины». Самый простой пример — это рост людей. Здесь написано «в городе», а мы начнём с комнаты: вашего класса, офиса, вагона метро, в котором вы сейчас едете... Если я вас попрошу прикинуть минимальное и максимальное значение роста в этом помещении, то, думаю, у всех получатся более-менее одинаковые показатели (если мы берём взрослых людей). Минимум — 1 м 40 см, а максимум — ну, 2 м 30 см. О чём это говорит? С одной стороны, вроде бы, у всех разный рост. Но при этом диапазон различных значений в целом ограничен ± 50-ю процентами. Ну максимум 100 процентами. Это если мы берём от ста сорока до двухсот восьмидесяти.

У многих метрик такое же нормальное распределение. Количество игроков в день тоже день ото дня не то чтобы сильно скачет. Если растёт — то тоже более-менее понятными скачками. Есть экспоненциально распределённые величины — например, доход. Если мы возьмем опять вагон метро, то, может быть, даже в вагоне метро, я думаю, разница будет гораздо больше того 2X, о котором мы говорили про рост. Может быть, с вами едет в вагоне метро тайный миллиардер, и он зарабатывает больше в тысячу раз. А возможно, вы — тот самый наш разработчик, который зарабатывает миллионы в рамках Яндекс Игр. Тогда вы смотрите на всех окружающих, которые зарабатывают раз в сто меньше, чем вы. Диапазон изменения — экспоненциальный. То есть иксы могут быть почти неограниченные. То есть ограниченные, но гораздо-гораздо большего масштаба. 2Х и 100Х, 2X и 500Х. И время загрузки игры, к сожалению, такая же величина. У кого-то включенный Wi-Fi, проложенная оптика, супермощный игровой компьютер — и игра загружается мгновенно.

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

Предположим, есть некоторое количество запусков вашей игры. Я отсортировал их по скорости загрузки. От самого быстрого — это номер один — до самого медленного. Это вполне то, что вы действительно можете увидеть в данных о ваших пользователях. Возьмём стандартное наше среднее, как мы обычно пытаемся что-то оценить — посчитали, получили 37. О чём нам говорит это 37? К сожалению, ни о чем.

Илья Богин: Потому что если мы берём быстрые загрузки — они 1–10 секунд, совсем не 37. Если мы берем медленные загрузки — они будут 80–100 секунд, совсем не 37! И проблема в том, что для экспоненциально распределённых величин среднее не говорит в принципе ни о чём. Поэтому приходится брать величины, которые называются перцентили.

Что означает перцентиль? Например, 50-й означает значение, в которое укладывается 50% ваших замеров. То есть, в нашем случае, — 50% замеров скорости старта игры. И мы видим по этим данным, что 50% замеров укладываются в восемь секунд. Эта информация даёт нам понимание о том, как в основном выглядит юзер экспириенс для тех, у кого всё хорошо.

Берем p95. Аналогично: это значение, в которое укладываются 95% пользователей. Мы видим, что это сто секунд. И понимаем, что p50 было достаточно неплохо, восемь секунд. Но как только мы выходим за p50 и добегаем до p95, там уже у нас экспириенс гораздо хуже. Мы видим, что в сценарии worst case пользователь будет очень долго ждать загрузки нашей игры, и, вероятно, будет достаточно много отвалов. Перцентили дают понимание, как распределены значения скорости старта для ваших пользователей. Смотреть мы в первую очередь рекомендуем именно на p50 и на p95. Это 50% лучших стартов. Плюс p95 — это в целом что происходит с теми, кто чувствует себя не очень, кто загружается в плохих условиях. Плюс смотрите на остальные метрики. Смотрите на ретеншн, смотрите на DAU и так далее.

Артём Шалаев: А как могло произойти такое, что мой перцентиль 50 стал хуже, а перцентиль 95 улучшился или наоборот?

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

Артём Шалаев: А разработчику понять в целом, насколько у него адекватная скорость загрузки даже в рамках 50-го перцентиля? Вот восемь секунд, которые есть на слайде, — это норм?

Илья Богин: Это норм. Есть исследования, которые показывают, как психологически человек воспринимает и ведёт себя в зависимости от разной скорости загрузки сайтов и так далее. Психологи говорят, что больше десяти секунд — повышается вероятность, что пользователь отвлечётся на что-то ещё.

Артём Шалаев: Правильно ли, что основная идея этого инструмента — постараться в максимальном количестве перцентилей приблизиться к параметру в десять секунд загрузки?

Илья Богин: Да.

Артём Шалаев: Есть вопрос. Я не совсем понимаю, что разработчик имеет в виду. Он звучит так: «При улучшении скорости загрузки будут ли увеличиваться рамки размера игры?».

Илья Богин: Видимо, речь о нашем пороге. Порог в том числе как раз и сделан для того, что если его не ограничить, то вы будете загружать... Я уверен, что у вас прекрасные художники, прекрасные 3D-моделлеры. Они могут создавать высокополигональные модели с 4К-текстурами и так далее. И вы будете их загружать. И этим мы немножко ограничили: ребята, поаккуратнее, всё-таки у нас много мобильного веба. Пожалейте пользователей. Они не могут скачать столько за раз. Я тоже не до конца понимаю, что спрашивает наш разработчик. В смысле, имеет ли он в виду, что если он улучшит скорость старта, разрешим ли мы ему увеличить бандл. Возможно. Пишите нам. Напишите, скажите: я всё сделал, всё придумал, у меня грузится всё моментально, разрешите мне увеличить бандл. Напишите, мы что-нибудь придумаем. Но in general я боюсь, что если мы поднимем, то спадёт это ограничение.

Артём Шалаев: Какие рекомендации помимо веса билда?

Илья Богин: Мы говорим как о метрике старта о времени интерактивности, то есть времени, когда всё готово к запуску игры. Помимо ресурсов, получения ресурсов и их распаковки, есть такое понятие как движок. Его нужно проинициализировать, нужно загрузить в оперативную память соответствующие объекты, проинициализировать их там и т. д. Если вы упростите инициализацию, то есть не будете использовать дополнительных модулей, которые тоже потратят время на инициализацию и на размер, в том числе движка... На самом деле вам эти модули не нужны или вы могли бы их заменить на что-то другое, что-то сделать по-простому, более просто.

Спускаясь уже на уровень конкретных движков. Что я здесь могу порекомендовать? Есть неплохой плагин WebGL optimizer для Unity. Он в виде такого визарда пробегает по различным типам ресурсов, возможностей движка и говорит, типа: вот я вам рекомендую вот тут это отключить, а вот тут у вас какой-то жирный ресурс, давайте его подожмём.

Для других движков — в целом, подход в том же направлении. Вам нужно облегчить работу на старте.

Артём Шалаев: Если вернуться коротко к тому плагину, про который ты сказал. Он именно подсвечивает проблемные места или он даёт какой-то предикт, что вы попадёте в такую-то скорость? То есть лучший способ...

Илья Богин: Он, к сожалению, пока ещё не настолько умный. Может быть, мы сделаем свой аналог с помощью YandexGPT, который сразу оценит и предскажет ещё и DAU, и успех игры, всё вместе. Но нет, он достаточно в этом плане простой.

Артём Шалаев: А верна ли рекомендация, что если это игра новая, у которой пока самая первая загрузка, самый первый билд, то для того, чтобы...

Илья Богин: Не обращайте на это внимание, да.

Артём Шалаев: Да, нужно подождать?

Илья Богин: Наберите значение, да. Опять-таки, если у вас DAU порядка сотни — 100, 200 — то значения могут быть перекошенными очень сильно. На DAU больше тысячи, наверное, значениям уже действительно можно доверять с гораздо большей степенью уверенности.

Артём Шалаев: Ещё есть вопрос. «В будущем планируется ли выделять сервера для разработчиков с целью создания многопользовательских игр?»

Илья Богин: Хороший вопрос. Мы об этом, безусловно, думали. Понятно, что multiplayer SDK — это всё-таки что-то уже не совсем тривиальное с точки зрения использования. Мы думаем об этом, но в контексте, как бы нам сделать такой multiplayer SDK, чтобы им было легко пользоваться. Потому что вы можете пользоваться Photon, вы можете пользоваться Unity Networking, но они тяжёлые достаточно, местами дорогие, и не хочется создавать что-то такое же тяжёлое в интеграции, в использовании. Поэтому если мы что-то будем делать — мы будем делать что-то простое и удобное для использования. Это сложнее сделать. Мы верим в то, что онлайн-мультиплеерность улучшает вовлечённость в игры. Это тоже, кажется, тот самый state of the art, можно сослаться на исследования, на метаисследования и так далее. Мы верим в то, что в такие игры пользователи играют более охотно и проводят в них больше времени. Поэтому если мы хотим, чтобы появлялось на платформе больше качественных игр и люди проводили больше времени, нам, безусловно, нужно больше мультиплеерных игр, и мы действительно должны помогать нашим разработчикам их создавать. Но для того, чтобы нам его стартовать, опять-таки нужно его спроектировать таким образом, чтобы это действительно было для вас оправданным. Чуть ли не сегодня я наткнулся на интересную статью о сочетании трёх компонентов для организации мультиплеерности: Unity, Яндекс Игры и Player IO. Он не бесплатный, но по каким-то адекватным ценам. Можно попробовать его, чтобы понять, заходит ли ваша идея или не заходит.

Артём Шалаев: Ещё вопрос про A/B. «Можно ли проводить A/B-тесты внутри игры с помощью удалённой конфигурации? Аналог Firebase Remote Config. Можно ли это настроить с помощью функции эксперимента в Яндекс Метрике?»

Илья Богин: Действительно и в Яндекс Метрике, и в Яндекс Аппметрике появилась возможность эксперимента. Это сделано через возможность создания конфига со значениями, так называемый ремоут конфиг. В рамках экспериментальной группы вы создаете копию этого конфига, меняете в ней значение на нужное. Если у вас интегрирована Аппметрика, вам ничего не мешает обратиться через Яндекс Метрику за ремоут конфигом и применить его себе в приложении. Возможно, потребуется отредактировать CSP, возможно, нет. Если да — напишите.

Вы проводите эксперимент, чтобы понять влияние ваших изменений на метрики вашей игры. И здесь вопрос: какие метрики игры есть в Яндекс Метрике? Об этом я уже сегодня говорил: мы находимся между миром веба и миром мобильных приложений. Метрика существует в двух вариантах: Аппметрика для мобильных приложений, Метрика — для веб-сайтов. И то, и то не ложится идеально на игры. Они живут по-другому — как мобильные приложения, но в веб-мире. Какие-то метрики Метрика просто физически не может снять, потому что у вас всё в canvas. Метрика такая: так, где тут DOM-дерево, чтобы можно было подписаться на onClick и автоматически залогировать клики? А у вас нет DOM-дерева. У вас один элемент, условно, — один большой элемент canvas, и Метрика просто не понимает, что происходит. Поэтому вопрос в том, насколько те метрики, которые вы видите в Яндекс Метрике, которые вы отсылаете сами, насколько они действительно отражают ситуацию с вашим приложением. Если они совпадают с тем, что вы видите на наших дашбордах, — значит, наверное, можно попробовать. Если вы видите, что они радикально различаются... Проблема в том, что она не предназначена для HTML5-игр, которые живут целиком в canvas. Она про другое, поэтому те механизмы, которые она использует, могут давать ошибку.

Эксперименты вы сможете через Метрику сделать, но вопрос: насколько адекватно то улучшение, которое она вам показала, в реальных цифрах, в реальных пользователях, в реальном ретеншене пользователей? Насколько оно действительно адекватно, совпадает или не совпадает. Мы понимаем, что это проблема, поэтому работаем над тем, чтобы принести A/B к нам, чтобы вы могли применять A/B и смотреть на то, как влияет ваш эксперимент на те метрики, которые мы умеем считать.

Артём Шалаев: И, может быть, самый последний, ещё один, только что прилетел. Илья, готов? Есть у тебя ещё время?

Илья Богин: Готов. Да.

Артём Шалаев: Давай последний. «Подключенная к игре Amplitude показывает плейтайм 16-17 минут на большой выборке в 500-1000+ игроков. Плейтайм в дашборде Яндекс Игр показывает 11-12 минут. С чем это может быть связано?»

Илья Богин: Я с Amplitude не работал, поэтому я не могу вам с ходу сказать, на что ориентируется Amplitude для подсчёта времени сессии. Здесь, кажется, разговор, похожий на тот, который был с Яндекс Метрикой и с нашим сервисом.

Артём Шалаев: Спасибо. По вопросам, кажется, всё. Я думаю, что мы можем, наверное, эту встречу завершать.

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

Артём Шалаев: Спасибо, друзья. До новых встреч.

Илья Богин: И не забывайте улучшать скорость ваших игр!