Как узнать, что игра станет хитом, или зачем издателю прототип

Расскажем, почему для этого не надо торопиться с геймплеем, стилистикой или стараться всё сделать идеально с первого раза.

Многие разработчики мечтают сразу всё сделать идеально и только потом показать результаты игрокам. Желание понятное, но парадокс в том, что при таком подходе игра скорее всего будет далека от ожиданий широкой аудитории (если вообще выйдет). Кому-то везет, но чаще это заканчивается потерей времени.

В классической модели разработки ААА-проектов такой подход может быть оправдан (очень на это надеюсь, CD Projekt RED), но он не всегда подходит небольшим студиям. Поэтому рассмотрим прототипирование и тестирование продуктов на примере рынка, который развивается слишком стремительно, чтобы надолго откладывать релизы — мобильного.

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

Сначала определимся с терминами. Разработчики под прототипом обычно понимают набор геймплейных механик, которые можно дать кому-то поиграть ради обратной связи. У издателя немного по-другому, ему в первую очередь интересно:

Другими словами, прототип для издателя — это MVP (Minimum Viable Product, минимально жизнеспособный продукт), достаточный чтобы собрать постановочный видеоролик с геймплеем. Всё. «На этапе прототипа паблишеру нужно получить рекламный креатив, чтобы замерить показатели привлечения пользователей — CTR и CPI (Click Through Rate — кликабельность, и Cost Per Install — стоимость за установку).»

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

После оценки CTR и CPI, издатель сопоставит их с предполагаемым LTV (Lifetime Value, пожизненная ценность пользователя — сколько в среднем он приносит за всё время) и оценит, насколько дальнейшая разработка игры вообще оправдана.

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

Так что прототип для издателя это не то, во что можно поиграть — это то, на чём можно замерить реальные метрики привлечения, сделав видеоролик на основе раннего билда.

Вообще есть способ проверить (и повысить) жизнеспособность концепта даже до появления прототипа — это фейкшоты. Например, у вас появилась оригинальная и необычная идея и вам не с чем её сравнить. Ничто не мешает нарисовать скриншоты выдуманной игры, придумать описание и показать это пользователям. Если на скриншот активно кликают — ура, можно задуматься о прототипе. Или проверить несколько вариантов кора/визуала и выбрать лучший.

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

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

Тогда мы, как издатель, сами делаем креативы — скриншоты и видеоролики — которые показывает игрокам, чтобы оценить, насколько их это заинтересует.

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

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

Если проект совсем простой (например, Stack Ball), то можно сразу сделать не только кор-механику, но и десятки уровней, чтобы протестировать ретеншн первых дней. Много ресурсов на это не уйдёт.

Но если проект посложнее, где нужны геймдизайн, левелдизайн и много разных механик (взрывающиеся бочки, падение объектов на противников и так далее) — то лучше сначала обойтись метриками привлечения и понять, окупится ли разработка.

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

Расскажу на примере.

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

В первую подборку креативов входил стандартный для этого жанра арт (мультяшные фрукты и котики), в другом мы тестировали более «взрослый» арт (стрит-арт, девушки в кепках с битами и т.д.), а в третьем — граффити.

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

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

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

Мой совет: общаться с людьми именно из геймдева, которые в этом разбираются. У нас люди, к счастью, открытые, с опытом, многие сами не раз наступали на грабли. Собственно, издатель тоже выступает в роли такого наставника.

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

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

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

Фокус-группами мы тоже почти не пользуемся. Снять репрезентативную статистику с фокус-группы будет тяжело — это должна быть огромная выборка со всего мира. Очевидно, собрать такие цифры гораздо проще через аналитику.

Например, закупить трафик со всего мира, или с группы стран, или конкретно из США и посмотреть, как они себя ведут в игре. В некоторых случаях можно заметить плохие метрики и не понимать, откуда они взялись. Вот в таком случае можно провести фокус-тесты, чтобы посмотреть на проблему со стороны — попросить игроков зафиксировать, где и что им не нравится.

Но чаще, проблемы в геймдизайне довольно очевидны, а ошибки в технической части легко выявляются аналитикой.

Что делать, если метрики проекта всё-таки не устраивают: переделывать или забросить? Допустим, мы понимаем, что есть проблемы, но не знаем, где именно.

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

А что если на разработку уже много потрачено? Есть простое правило:

У нас пивоты делаются в двух случаях:

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

Разберем возможный воркфлоу, когда решено сделать пивот.

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

И тут пришла идея перевесить камеру — сделать из игры шутер от третьего лица. Стоит ли срочно менять камеру в текущем билде и лить на него трафик, чтобы замерить новые метрики? Подождите.

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

Первым и правильным вариантом будет — вернуться к этапу тестирования через креативы.

Перевесьте камеру за плечо персонажа и снимите видео прямо внутри движка с выгодных ракурсов. Чтобы в ролике не было видно плохих анимаций, неудобного управления (когда надо жать влево, чтобы идти вперед) и некрасивых сбоку ассетов. Обычным тестом такого креатива, наравне с текущими топ-даун креативами, можно будет сравнить метрики — какой из концептов окажется лучше. Это лучше, чем сидеть 3 месяца, тратить силы и деньги, чтобы выяснить, что вид от третьего лица нравится игрокам ещё меньше.

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

Сравнить версии можно, открыв новый билд для ограниченного процента пользователей в Google Play. Тогда сравнение будет честное — на одном и том же трафике. Посмотрите на метрики версий в сравнении, доработайте, залейте ещё раз, посмотрите на цифры, опять уберите, посидите ещё и ещё раз залейте. И так до тех пор, пока метрики на новой версии не станут лучше. Или пока не поймёте, что вся идея нерабочая.

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

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

Более того, тесты на креативах не дают 100% гарантии, какой UI лучше (особенно с точки зрения UX). Это надо проверять внутри продукта. Чтобы сэкономить время разработки, можно взять концепт UI, наложить поверх тех же самых видеокреативов и посмотреть, какой вариант лучше перформит. Это не гарантия, но какое-то подспорье — в какую сторону развиваться и что рисовать в первую очередь.

Со звуками, музыкой и эффектами та же история. Понятно, что на этапе привлечения и внутри игры звуки могут восприниматься по-разному, потому что креатив — 15-30 секунд — может смотреться привлекательно на такой короткой дистанции, а в игре через 15 минут те же звуки могут начать раздражать.

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

Это делать намного легче, чем непосредственно в игре. А делать сразу по своему вкусу, это как пытаться угадать вкусы людей на другой стороне Земли со своей ментальностью и привычками. Тут лучше опираться на цифры.

Особенность быстрых и беспрерывных процессов разработки в том, что как только возникает малейшая потребность узнать, как на реальном рынке работает что-то, что мы только что сделали — мы сразу узнаем. И мы хотим получить наиболее репрезентативные данные, а это означает, что проект надо тестить на весь мир.

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

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

Если же вы делаете что-то новое или на мобильном рынке, где всё очень быстро меняется, то в таком подходе особого смысла нет.

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

После первой статьи ко мне появились ещё несколько небольших вопросов, которые решил выделить отдельно.

— Если прийти к вам с 10 идеями без единого прототипа — вы поможете?

Студии, которые занимаются прототипами тех же самых казуальных игр, обычно так и делают. Мы садимся, они показывают свои идеи, мы показываем свои, и вместе обсуждаем, что нам интересно. Можем договорить делать сразу 2-3 проекта.

Если приходит разработчик, который ничего ранее не делал — мы должны сначала оценить его уровень реализаций, посмотреть портфолио, оценить сильные и слабые стороны — может быть он лучше работает с 2D, а может придумывает креативные и свежие идеи. Далее ничто не мешает нам пойти по стандартному пути и заказать 1-2 прототипа «на пробу».

— Может мне сначала прийти с одной идеей, а если не зайдёт, то потом с другой?

Вот здесь распыляться как раз можно. Если речь об идее, а не прототипе, то лучше расписать 10 механик и прийти к опытному человеку, чтобы спросить — что из этого сработает, а что нет. Так у вас начнёт формироваться собственная экспертиза. Главное, чтобы ваш «ментор» действительно в этом разбирался.

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

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

— Есть ли у вас пороговый CPI для прототипов?

Нет, потому что CPI без LTV мало о чём говорит. Как правило, после тестов на CPI мы примеряемся к продуктовым показателям близких продуктов из нашего портфолио, а также оцениваем потенциал монетизации, которую игра позволяет реализовать. И принимаем решение исходя из результатов теста по CPI и предполагаемого нами LTV.

— Что ещё надо протестировать, кроме CTR и CPI?

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

После интеграции аналитики в проект, мы выявляем точки роста или, наоборот, видим проблемы. Потом копаем глубже, чтобы понять, как это исправить и не повторить в будущем.

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

#хакатон2020