King’s Road — одна из самых успешных браузерных 3D MMO на сегодняшний день. В ее разработке принимали участие бывшие сотрудники Blizzard, BioWare, EA и Lucas Arts. Но, несмотря на звездный состав, успех пришел далеко не сразу . На прошедшей GDC 2014 продюсер проекта Джон Юн рассказал о том, cтоит ли гнаться за дешевым трафиком из Филиппин, почему аналитика не должна подменять здравый смысл и как опыт разработки «MMO по подписке» вредит при работе над F2P.
Андрей Скочок, сотрудник компании 101XP, занимающейся издательством King’s Road в СНГ, подготовил для адаптированную версию доклада.
О Rumble Entertainment
Костяк команды Rumble Entertainment состоит из выходцев из BioWare, EA, LucasArts, Blizzard и Zynga. Все они, в той или иной степени, занимались MMO, работающими по системе подписки (pay2play). Новообразованная команда поставила себе цель — «порвать» рынок f2p-игр на Facebook за счёт high production value и хорошей трёхмерной графики, нетипичной для социальных игр.
Для core-аудитории, желающей играть на Facebook, в то время всё было ужасно — даже ужаснее, чем релизная версия Windows 8.
По плану первая версия проекта должна была выйти уже через шесть месяцев — уложились всего в девять. Учитывая, что игрой занимались люди опытные, надежды на успех были велики, но итог софт-лонча оказался ужасным. Монетизация не работала должным образом, ретеншн был практически на нуле… Что же пошло не так?
Шаг 1: Система обучения
Отсутствие в игре внятной системы обучения сыграло первую злую шутку — большинство пользователей уходило в первые же минуты игры, не желая разобраться в особенностях игры. Те же, кто задерживался подольше, вскоре тоже отваливались — люди просто не понимали, что им нужно делать, из-за чего процент вовлечённости стремительно падал вниз.
Из этого был извлечён первый урок — игре необходим максимально доходчивый, но в то же время не надоедающий режим обучения, который должен пояснить игроку основы.
Было принято решение сделать его максимально жёстким, заставляя игрока пройтись по всем аспектам игры. Сначала все критиковали эту затею, но в итоге она оказалась правильной — процент «отвала» значительно уменьшился.
Шаг 2: Проблемы с UI
Недопонимание с UI вызвало первую (и основную) проблему оттока пришедшей аудитории. Большинство функций, необходимых в игре, либо отсутствовали в принципе, либо находились вне зоны быстрой досягаемости.
У пользователей не было желания разбираться в хитросплетениях интерфейса, и следствием к этому была ещё одна проблема — отсутствие системы обучения.
Шаг 3: Геймдизайнер не думал как игрок
Геймдизайнер, как и любая творческая натура, не всегда мыслит как конечный потребитель. Подобная ошибка особенно дорого стоит в социально ориентированных и f2p-играх.
Основная ошибка, с которой столкнулись пользователи на этапе софт-лонча — несовершенство игровой логики. Простой пример — пользователь проходит миссию, но по каким-то причинам победа и причитающиеся за неё награды, не засчитываются. Кто-то начинал заново, игра вновь не засчитывала прохождение, недовольный игрок уходил из проекта, считая, что столкнулся с неисправностью игры, в то время как геймдизайнер неверно сформулировал условие победы — где-то в глубине запутанного уровня он прятал незаметного монстра, которого нужно убить.
Проблема решилась двумя действиями — максимальным упрощением структуры уровня (отказом от запутанных, больших лабиринтов с хитросплетениями коридоров и запрятанными в них монстрами) и облегчением условия победы — достаточно было убить главного злодея. После решения проблем отток пользователей приостановился.
Шаг 4: Удержание игрока
Даже для софт-лонча, контента в игре было невероятно мало — был всего один класс персонажа, не была введена система крафтинга предметов, а основным развлечением, доступным геймеру, оставался лишь сумасшедший гринд (монотонное уничтожение монстров в одной и той же локации с целью получения опыта или голда — ред.).
В игре не было города — места, где игрок мог спокойно сбросить лишние предметы, приобрести расходники, прокачать умения и так далее. Все эти действия приходилось делать прямо на поле боя — не очень приятно, когда на тебя со всех сторон наседают монстры, не правда ли? А когда, предположим, уровень проходится не в одиночку, а с друзьями? Ещё хуже. Казалось, что для core-аудитории подобная схема будет работать отлично, но реальность быстро расставила всё по своим местам.
Шаг 5: Монетизация
Место, где было набито больше всего шишек. Разработчики, которые всю жизнь занимались subscription MMO, даже близко не представляли, как работает монетизация в условно-бесплатных играх. Проблема была типичной — как заставить игроков платить, и при этом оставлять их удовлетворёнными.
Первое решение было наиболее «дубовым» — поставить таймеры везде, где только можно. Умер? Будь добр подождать полчаса или занеси денег.
Это было самым ужасным решением в жизни проекта — раззадоренный игрок, увлечённый боем, умирает. Мало того, что он упивается горечью поражения, пониманием, что для победы ему нужно мощное снаряжение и прокачка (гринд, больше гринда!), так его ещё и просят в этот момент заплатить за возможность начать уровень снова. Для core-игроков, на которых и была ориентирована игра, это было ужасно.
Неверно была выбрана и площадка для теста монетизации — игра запустилась на Филиппинах и причина была максимально банальной — невероятно дешёвый трафик. Трафик идёт, инсталл-база растёт, как на дрожжах, но деньги не идут, а официальные площадки игры ломятся от криков о плохой производительности игры (как выяснилось в итоге, компьютеры филиппинцев по производительности недалеко обогнали тостеры).
Оффтоп: про опасности Data-Driven
Не забывайте, но и не злоупотребляйте Data-Driven. Вот лишь несколько примеров, основанных на реальных командах и проектах.
Пример 1. Команда делала сингл-ориентированную игру. Кое-как выпустили, установки пошли более чем хорошо, но денег всё нет и нет. Игру стали переделывать, но кому-то, к счастью, вовремя пришла в голову мысль посмотреть аналитику по Flurry. Оказывается, 90% установок шли из Китая, где нет физической возможности заплатить за внутриигровой контент. Оставшиеся 10%, как оказалось, платили очень даже хорошо и переделывать игру не было смысла, стоило лишь поменять источники трафика. Здесь data-driven, безусловно, помог.
Пример 2. Второй пример уже из личной практики — довольно долго команда считала, что с Rolling Retention всё здорово, данные из Flurry это подтверждали. Интуиция, впрочем, давала сигнал тревоги, и не зря — как оказалось, статистика выводилась ошибочно и не по нужным параметрам. Пришлось полностью пересчитывать своими силами. Ещё одна ошибка, которая стоила гораздо больше — неверный код, из-за которого уведомления о покупках в категории «предметы для улучшения амуниции» приходили два раза.
Это невероятно ударило по внутренней экосистеме игры и кардинально меняло представление о том, что покупали люди. А ведь именно на основе этих данных игра постоянно переделывалась. Стоит заметить, что подобная ошибка может всплыть в любой системе аналитики.
Пример 3. Проблема выплывает из слабой координации отдела маркетинга и разработки. Маркетологи в тестовом режиме закупали трафик с разных каналов и различным таргетингом и не вовремя информировали об этом разработчиков, которые неверно меняли игру в зависимости от поведения пришедшего трафика — оказалось, что пришло слишком много трафика женского пола, хотя раньше закупался трафик обоих полов. Слишком глупо, чтобы быть правдой.
Data-driven — страшно полезная вещь, но в умелых руках. Аналитик должен быть куда большим параноиком, чем весь отдел QA.
Шаг 6: God Bless USA!
Заливка качественного трафика из США тотально переломила ситуацию — игроки с радостью набросились на новый качественный продукт, прибыль потекла рекой. С производительностью их ПК тоже не было проблем — в итоге, было решено меньше ориентироваться на страны с малой стоимостью установки.
Но у качественной, платящей аудитории и требования к игре были куда выше — их интересовал проект, который постоянно и качественно обновляется.
В кратчайшие сроки была введена система гильдий, ежедневных квестов, кооперативных карт для топовых игроков и, куда без них, топовых предметов. Больше всего денег генерировали сценарии с новым контентом, ограниченные по времени — например, за участие в нём можно было получить уникальный меч или премиум-камень для заточки. Не успел поучаствовать или выиграть — не беда, покупай. Как оказалось, азартные игроки с восторгом приняли эту идею, главное — делать приз действительно стоящим.
Вместе с тем, награду за убийство монстра было решено сильно урезать — несмотря на протестующие крики игроков, это дало хороший прирост выручки, а ретеншн не упал. Но с таким решением всегда лучше быть осторожным — ваш проект должен быть действительно увлекательным, чтобы игроки могли стерпеть подобные трюки.
Что было сделано, дабы спасти игру
Подведём общий итог — что было сделано, дабы игра начала генерировать прибыль:
- Сильно урезали длину и структуру уровней игры — f2p-игрокам были нужны короткие игровые сессии, и они их получили.
- Навороченная система квестов тоже пошла под нож — осталась лишь одна цель, убить главного злодея. Причина та же — короткие игровые сессии.
- Увеличили количество карт с семи до тридцати, добавили по несколько уровней сложности на каждую из них. Ввели локацию «Город», где игрок мог отдохнуть, продать или купить предметы и прокачать снаряжение — исчезло чувство незаконченности проекта.
- Сделали три класса персонажей вместо одного — геймплей сильно разнообразился, процент отказов снизился.
Психологически сложнее всего было отказаться от продажи боевых предметов во внутриигровом магазине. Это повлекло за собой тотальную смену баланса и основной игровой цели — до вывода предметов из продажи, весь геймплей сводился к накоплению денег на очередной палаш или посох.
Игроки заходили в проект как на работу, тратили невероятное количество времени ради накопления денег и начинали всё сначала. А представлялось всё совершенно не так. В итоге, было принято решение ввести дроп оружия с монстров, и систему, которая позволяла улучшать предметы экипировки.
Главное, что сделали с системой монетизации — уменьшили время таймеров на возрождение игрока. Итог оказался хорошим — ретеншн вырос на порядок.
Итого
Юн не стал поднимать в своем докладе все аспекты разработки, рассказывать о сборе команды, этапах прототипирования и многом другом, что обычно описывают в подобных постмортемах. Вместо этого он озвучил более тонкую мысль, перечислив те факторы, которые могут загубить вашу игру в шаге от успеха, несмотря на опытную команду, незанятую нишу, хорошую аналитику и маркетинговый бюджет.
Многие студии, оказавшись в подвешенном состоянии, начинают паниковать, сливать средства на нецелевую рекламу и пытаться закрутить все гайки «монетизации», окончательно убивая проект. Юн вместо этого предлагает хладнокровно исправлять одну проблему за другой, не гонясь ни за кучей дешевого трафика, ни за сиюминутными огромными доходами.