Как мы перешли с Unity плеера на WebGL

logogswgl

Переход на WebGL

Итак, мы перешли на WebGL. Предыстория и причины перехода описаны в моей предыдущей статье Монетизация Роял Флэш Покера. Кратко — браузеры или прекратили, или уже прекращают поддержку Unity плеера. В результате, для юнити разработчиков делать браузерные игры на Unity, кроме как делать их на WebGL, просто нет. Мы знали, что переходить будет сложно, что технология сырая и находится в разработке как в самом Unity team, так и со стороны браузеров или девелоперов JS. Тем не менее мы решили, что раньше сядешь — раньше выйдешь, да и терять особо было нечего (причины описаны в статье о монетизации РФП). Переход осуществлялся довольно долго, команде пришлось преодолеть огромное количество непредвиденных сложностей, но в конце концов мы это сделали. Результат, в отличие от этой статьи, оказался совсем не таким позитивным. Почему — читайте далее.

Статистика

Самой главной задачей перехода было повышение конверсии, так как на необходимости установить юнити плеер отваливалось 85% игроков из тех, у кого Юнити не был установлен. Из тех, у кого Юнити плеер уже был, в игру попадало 76%. Оставшиеся 24% терялись где-то по пути: у кого-то перестал работать плеер из-за его отключения в обновленном Хроме, кто-то не дожидался загрузки и так далее. В итоге, из всего трафика в игру попадало 36%, остальные 64% мы теряли:

w1

Здесь показана вполне репрезентативная статистика с июля по ноябрь 2015, совокупная по всем соцсетям где запущена игра (ОК, ВК, МойМир, RBK Games). Примерно четверть трафика — пришедшие после публикации в каталоге ВК дети до 18 (органический трафик), что конечно снизило показатели, но не сильно, в пределах 1-2%. Очевидно, что чем дальше, тем ниже будет конверсия: уже скоро наверное все основные браузеры заблокируют Юнити плеер и конверсия снизится до нуля.

WebGL позволяет играть прямо в браузере, не устанавливая плеер. Соответственно, конверсия должна быть значительно выше. Если прикинуть, что 26% теряются где-то между запуском игры и ее загрузкой, то соотношение должно бы быть такое же. Но оказалось, что это не так:

wg1

На этой картинке вы видите странную картину: пришло 4332 игрока, а загружается билд у 5579, как так? Дело в том, что в эту статистику попали те, кто уже пытался попасть в игру ранее, но не смог по причине необходимости установить Юнити плеер. Теперь они пробуют попасть в игру при помощи WebGL.

У 49% игроков из тех, кто пришел впервые, не получилось попасть в игру. Из всех же, кто вообще пытался загрузить игру, все еще хуже: только 39% попало в игру, то есть мы выиграли всего несколько процентов по отношению к предыдущим показателям. Причем размер WebGL билда не сильно отличается от размера контента, загружаемого через Юнити плеер: время загрузки на машинах, где я проверял, увеличилось всего на 5-10 секунд (весь контент пакуется gzip’ом и распаковывается браузером на лету). Но, тем не менее, игроки не доходят до завершения загрузки.

То есть получается, что мы, по сути, практически не повысили конверсию. Зато мы убрали риск того, что игра внезапно вообще прекратит работать во всех остальных браузерах, что, конечно, плюс.

Теперь сравним пороги: как игроки попадали в игру и сколько из них становилось активными игроками (грубо, мы считаем, что активными становятся те, кто сыграл 5+ игр). В юнити плеере картина была такая:

w2

От тех, кто попал в игру, 37% сыграли 5+ игр. Из всех пришедших — 13.2%. В WebGL версии картина выглядит лучше:

wg2

От всех, кто смог войти в игру, только половина создала персонажа (хотя ранее это было 63%). Скорее всего тут проблема в производительности в WebGL версии, так как тут в дело вступает скининг и анимация персонажа, а это сейчас в WebGL одна из самых слабых сторон. В результате, 35% сыграли 5+ игр, что ниже, чем в вебплеер версии (37.02%). Однако в связи с тем, что общее количество игроков, которые смогли войти в игру, стало выше, то мы получили ощутимый прирост к конверсии в активных игроков, почти +5%. Из этого сравнения можно сделать вывод, что если игроки смогли в игру попасть, то игра нравится примерно одному и тому же проценту аудитории. В случае, если бы удалось повысить конверсию входа и снизить ресурсоемкость при создании персонажа, то мы бы смогли значительно увеличить конверсию 5+ игр. Мы знаем, что Юнити тим в курсе проблем производительности скининга, но когда случится это чудо никто еще не знает.

Последним, что надо сравнить — это удержание. Тут статистика будет совсем нерепрезентативной, так как прошло совсем мало времени и ретеншенов д3-6, д7+ и, тем более д30+ еще просто нет. Но можно сравнить д1 и д2. В юнити плеере показатели следующие:

w3

Из тех, кто смог попасть в игру, в первый день вернулось 13.61%, во второй 8.71%, в период с 3 по 6-й дни вернулось 13%, с  седьмого по 30-й дни — 11.89%, и после 30-го дня 8.41%. Из всех же, кто пришел (органика и реклама) — 4.93% вернулись в тот же день, на второй — 3.15%, а игроками (те, кто регулярно возвращается спустя 30 дней) — 3%. В WebGL версии картина очень похожа на пороги:

wg3

Из тех, кто смог попасть в игру, 59.88% сыграли одну игру, что ниже, чем в юнити плеере. Это снова подтверждает тезис о том, что WebGL билд работает хуже и дойти до игры сложнее, ведь ничего внутри игры не менялось — изменились только технические требования. В первый день вернулось 9,93%, что ниже на почти 4% от тех, кто вернулся играя на юнити плеере. Целых 4% для ретеншена — очень много. По этому и следующим показателям ретеншена видно, что игроки стали менее довольны игрой. Мы получили довольно много сообщений от наших игроков о том, что «игры стала сильно тормозить», и это снова возвращает нас к проблеме производительности в WebGL версии, а именно — проблеме скининга и анимаций. Теперь, вместо одного персонажа в гардеробе, мы получили сразу десять, и все анимированы и заскинованы. Очевидно, что слабые машинки просто не могут потянуть такую нагрузку и игроки не хотят возвращаться в игру, где все так медленно.

Однако на общую картину (относительно вообще всех пришедших на страницу) картина не изменилась, так как все-таки смогло попасть в игру больше человек. Д2 даже незначительно лучше, но прирост на 0.1% это не имеет особого значения. Д3-6 тут выглядит хуже, так как от выборки еще не прошло 6+ дней. Так, если взять д3-6 от 24-25 чисел, то д3 = 4.74%, что тоже практически равно юнити версии. Д7 и д30 еще предстоит увидеть через неделю и месяц, соответственно, но я думаю там тоже не будет особой разницы.

Выводы

Хоть WebGL и не оправдал надежд на то, что мы увеличим конверсию, он снял основной риск — то, что игра вдруг перестанет работать. Показатели, хоть и не стали лучше, не стали и хуже, что уже неплохо. Однако, WebGL находится в зачаточной стадии и пока что очень сырой, и мы на это повлиять не можем, кроме как быть в контакте с Юнити тим и сообщать им о серьезных проблемах и ошибках в WebGL билдах (что мы делаем, отдельное огромное спасибо Юнити тим и Jonas Echterhoff за постоянную поддержку и оперативное реагирование на багрепорты).

Одной из основных проблем, из-за которых игроки отваливаются на входе, мы считаем недостаток памяти. Дело в том, что на текущий момент WebGL не умеет динамически выделять нужный объем памяти, и его сейчас необходимо задавать вручную. Поэтому, если у пользователя открыто много вкладок, или мало памяти на машине, то билд покрешится с соответствующей ошибкой. Все, что можно сделать — максимально снизить необходимое количество памяти (сделано) и ждать, когда разработчики WebGL’а реализуют функционал динамического выделения памяти.

То же самое со скинингом, о котором уже писалось выше. Но и тут мяч не на нашей стороне, и даже не на стороне Юнити тим, а на стороне разработчиков браузеров, явы и WebGL технологии. Тут мы ждем релиз технологии webassembly, которая (предполагается) значительно повысит производительность WebGL игр, позволив реализовывать многопоточность (сейчас, все что внутри WebGL, работает в одном потоке).

Планы

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

Диаграмма входа в игру

Временное это решение потому, что рано или поздно юнити плеер перестанет работать во всех прочих браузерах. Однако к тому времени, вероятно, все же появится во всех основных браузерах полноценная поддержка asm.js и, может быть, даже webassembly.

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

Для WebGL версии все серьезно изменится, когда Юнити тим реализует следующие возможности:

123

1 — Значительно снизит тормоза, позволив распределять нагрузку по разным потокам. Например, сейчас лента друзей грузится в лобби игры, и пока она не загрузится, игра тормозит, даже не смотря на оптимизацию этого функционала, паковкой пакетов и паузами между загрузкой профилей/аватарок. То же самое касается и загрузки комнат: сейчас все грузится последовательно, комнаты, персонажи, анимации, текстуры и прочее, скинуются, текстурируются (идет сборка текстур). Распараллеливание позволит делать все это в фоне, влияя на игровой процесс гораздо слабее.

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

3 — Снизит объем JS кода, позволив работать бинарным библиотекам в браузерах, повлияет вообще на все и считается панацеей от всех бед WebGL’а. Так ли это — пока неизвестно, но разработчики технологии пишут, что перформанс вообще всего значительно вырастет. А самое главное — в результате требования к памяти снизятся и, мы предполагаем, браузеры научатся выделять столько памяти, сколько нужно, и креши из-за недостатка памяти исчезнут. Вероятно, это повысит конверсию входа еще на Х% (на сколько — неизвестно, так как мы не располагаем статистикой сколько игроков не смогли зайти в игру из-за этого, и нет технической возможности ее как-либо собрать).

Звучит все здорово, но есть нюансы (с). Заключаются они в том, что все это находится не в роадмапе Юнити, а в разделе Research. Почему? Потому что это разрабатывает не (только) юнити тим, а, в основном, разработчики самого JavaScript, браузеров и WebGL технологии. Когда это появится все в реальной жизни никто не знает, знаем только, что разработка идет активно и, если посмотреть репозитории на гитхабе, то коммиты и тесты идут ежедневно и в большом количестве.

На этом пока что все. В одной из следующих статей я поделюсь результатами конверсии и удержания, которые даст «заплатка» с выбором способа игры, а также поделюсь статистикой удержания д7+ (д30+ будет только после нового года). Если у вас есть замечания, вопросы, опыт работы с WebGL — делитесь, спрашивайте, предлагайте, постараюсь на все ответить.

 



Добавить комментарий

Навигация