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-игрокам были нужны короткие игровые сессии, и они их получили.
- Навороченная система квестов тоже пошла под нож — осталась лишь одна цель, убить главного злодея. Причина та же — короткие игровые сессии.
- Увеличили количество карт с семи до тридцати, добавили по несколько уровней сложности на каждую из них. Ввели локацию «Город», где игрок мог отдохнуть, продать или купить предметы и прокачать снаряжение — исчезло чувство незаконченности проекта.
- Сделали три класса персонажей вместо одного — геймплей сильно разнообразился, процент отказов снизился.
Психологически сложнее всего было отказаться от продажи боевых предметов во внутриигровом магазине. Это повлекло за собой тотальную смену баланса и основной игровой цели — до вывода предметов из продажи, весь геймплей сводился к накоплению денег на очередной палаш или посох.
Игроки заходили в проект как на работу, тратили невероятное количество времени ради накопления денег и начинали всё сначала. А представлялось всё совершенно не так. В итоге, было принято решение ввести дроп оружия с монстров, и систему, которая позволяла улучшать предметы экипировки.
Главное, что сделали с системой монетизации — уменьшили время таймеров на возрождение игрока. Итог оказался хорошим — ретеншн вырос на порядок.
Итого
Юн не стал поднимать в своем докладе все аспекты разработки, рассказывать о сборе команды, этапах прототипирования и многом другом, что обычно описывают в подобных постмортемах. Вместо этого он озвучил более тонкую мысль, перечислив те факторы, которые могут загубить вашу игру в шаге от успеха, несмотря на опытную команду, незанятую нишу, хорошую аналитику и маркетинговый бюджет.
Многие студии, оказавшись в подвешенном состоянии, начинают паниковать, сливать средства на нецелевую рекламу и пытаться закрутить все гайки «монетизации», окончательно убивая проект. Юн вместо этого предлагает хладнокровно исправлять одну проблему за другой, не гонясь ни за кучей дешевого трафика, ни за сиюминутными огромными доходами.
About the author