На прошлой неделе компания Pixonic в своем блоге начала публикацию итогов (по сути, конспектов) обучающих семинаров, которые она проводит для собственных сотрудников. Теперь ознакомиться с ними можно и на наших страницах.
Внутри компании Pixonic мы организуем обучающие семинары, на которых рассказываем сотудникам о том, каких принципов в разработке игр мы придерживаемся и почему. По итогам встреч я рассылаю всем выжимку ключевых идей с примерами. Данные стенографии хранятся в гугл-документе, где с ними могут ознакомиться работники компании. Хотя данный материал составлялся для внутреннего пользования и является частью контекста, я решил, что он может быть интересен и более широкому кругу читателей.
Семинар 1
Чаcть [1/3] — Определения
Единого правила определения и замера метрик нет, поэтому возможны различные названия одной и той же метрики, либо наоборот — разные по способу замера метрики называют одним и тем же словом.
Нижеследующие показатели используются для одного и того же: они призваны сообщить, сколько проект получает с одного пользователя, установки, скачивания. С той разницей, что:
- LTV (Life Time Value) — чаще смотрят по когортам (мы, например, смотрим доход за 180 дней жизни);
- ARPI/ARPD (Average Revenue Per Install/Download) — это просто сумма заработка деленное на количество установок/скачиваний (за все время);
- ARPU (Average Revenue Per User) — в некоторых случаях может означать доход с активного пользователя за день или за месяц (т.е. за какой-то период, а не за всю жизнь). В этом случае, доход с активного пользователя за день лучше называть ARPDAU (Average Revenue Per Daily Active User), считается, как доход за день деленный на количество уникальных пользователь за этот же день.
- CPI — Cost Per Install. Обозначает стоимость одной установки, так же может обозначать способ покупки рекламы (при котором платят за факт установки, а не за кол-во показов банеров, например). Может считаться как все потраченные деньги на привлечение деленные на всех привлеченных пользователей (включая или не включая органику).
- ARPPU — Average Revenue Per Payng User. Средний доход с ПЛАТЯЩЕГО пользователя, он же размер среднего чека. Может считаться как за всю жизнь, так и за определенный период (день, месяц, неделя и т.п.).
- Retention X — возврат пользователя на Х день после установки. Пример подсчета: 31 декабря пришло 1000 установок, ИЗ НИХ 350 человек зашло 1 января (Retention-1 = 35%), 7 января — 150 (Retention-7 = 15%) и т.д.
Часть [2/3] — Прибыльность
Как для нас важным условием работы является оплата труда, так и для компании важным условием проекта является его прибыльность. Представьте, что вам предложили участвовать в разработке игры полный рабочий день бесплатно , согласились бы вы? Ведь только в таком случае мы могли бы делать игры чисто для удовлетворения амбиций, обучения, в качестве эксперимента и для проверки своих самых необычных идей. До тех пор, пока отказаться от заслуженной заработной платы мы не готовы, то и думать в первую очередь мы должны о том, как именно проект будет приносить деньги, ведь именно так вы обеспечите себе заработную плату.
Для создания прибыльных игр важно хотя бы в общих чертах понимать, как игра зарабатывает.
1. Profitable = LTV > CPI
Обращаю внимание на важную вещь: прибыльность в глобальном смысле зависит от двух метрик. Это значит, что можно (и нужно) работать по двум направлениям:
1) Понижение цены установки (CPI) — зависит от оригинальности идеи проекта, сеттинга, его нишевости, востребованности и т.п.;
2) Повышение дохода с одной установки (LTV, оно же ARPU/ARPI/ARPD) — зависит от механик (жанра), внутриигрового баланса, целевой аудитории и т.п.
Соответственно, когда вы выбираете концепцию проекта, вы должны исходить из того, какие значения показателей можно ожидать.
На тему выбора ниши проекта, из интервью Филиппа:
“На заре появления социальных и мобильных игр считалось правильным делать как можно более массовый, казуальный продукт, который бы был нацелен сразу «на всех». Сейчас же, при большом обилии похожих друг на друга игр, мы считаем правильным делать нишевой продукт под довольно конкретную аудиторию. Поэтому после двух с половиной лет работы над казуальными играми мы сфокусировали свои усилия на достаточно хардкорных проектах, таких как Walking War Robots.”
2. О том, почему сложно добиться прибыльности.
Рекомендую к прочтению статью Олега Якубенкова — коллеги-аналитика из ZeptoLab, в которой довольно исчерпывающе описываются трудность создания прибыльного проекта.
Как же заработать на рынке мобильных приложений?
Вариант 1: Приложение зарабатывает со скачивания хотя бы 3$
Вариант 2: Сильный бренд
- Ранний мобильный бренд;
- Порт консольной или PC игры;
- Лояльная база пользователей в вебе;
- Выпуск приложения под фильм.
Вариант 3: Виральность продукта
Что точно не сработает:
- Мы закинем наше приложение в топ, и пойдет органический трафик;
- Нас зафичерит Apple;
- Про нас напишут блогеры и журналисты;
- Виральность.
Часть [3/3] — Риски
Хотелось бы обратить внимание, что при формировании концепта (и выборе сеттинга/механик) необходимо учесть два часто противоположных условия:
- Нужно попасть в нишу, где есть деньги, но пока что невысока конкуренция (низкий CPI);
- Суметь сделать продукт, который и нам и игрокам был бы понятен (привычен).
Попробую визуализировать выбор в виде шкалы:
Левая часть — чистой воды клоны.
В целом, клонирование — вполне успешная модель, но для этого нужно:
- Успеть стать 2-ым, а не 102-ым;
- Суметь повторить не только идею, но и качество, что тоже очень сложно;
- В идеале, все-равно следует найти незанятую нишу (клон хитов из FB — для ОК, хита из AppStore — для GooglePlay).
Чуть правее — находятся идеи вроде переложения игры на более оригинальный сеттинг, небольшое изменение механик, добавление каких-то дополнительных фичей. Возникают риски:
- Изменения могут оказаться бесполезными или даже вредными;
- Все-равно требуется повторять качество продукта, т.к. игроки так или иначе будут выбирать между схожими продуктами.
На другой стороне, в правой части, находится абсолютное “неизвестно”, такая игра может представлять собой, что угодно, может даже не являться игрой. В этой неизвестности копошатся “независимые” разработчики. Ярким примером являются Flappy Bird и еще 999,998 других игр, о которых никто никогда не слышал. Риски в данном случае настолько высоки, что проще сыграть в казино (вдобавок, многие известные инди-игры имеют гораздо менее известные причины своей популярности, которые часто не имеют отношения к геймплею).
И, наконец, где-то по середине находится область компиляции — это совмещение известных и проверенных механик, геймплея, сеттинга, UI (user interface) и т.п., но в непривычном виде. Таким примером является Clash of Clans, игра совместила:
- популярный жанр стратегий,
- оказуалила его привычным менеджментом в стиле ферм,
- и сдобрила все это не менее популярной и не менее привычной механикой Tower Defense
Тут же для примера следует рассмотреть вторую игру компании — Hay Day. Тут компиляции не было, они просто сделали качественную ферму, добавив новаторское управление и несколько механик (кораблик, рыбалку).
Так что:
- В первую очередь нужно придерживаться проверенных временем решений, новшества могут возникнуть только при реализации USP*;
- USP вводятся только для того, чтобы попасть в незанятую нишу (понизить CPI) и/или повысить LTV с пользователей;
- Чем больше у вас опыт, тем больше USP (и фичей) вы сможете реализовать, без необходимости изобретать велосипед. И описать: “это будет игра, как WoT, только для мобилок. И сражения будут на роботах, которых ты конструируешь, как в MechWarrior, только казуальнее”.
- В 99% вы должны стоять перед выбором из нескольких уже существующих вариантов и решать какой из них лучше всего подойдет для вашей игры;
Иными словами, не стоит увеличивать риски проекта, создавая оригинальные биллинги в банке (например, оставив только $0,99 и $99), или какое-то необычное решение по интерфейсам.
*USP (Unique Selling Proposition) – Уникальное Торговое Предложение, т.е. конкурентное преимущество продукта.
Комментарии
Ответить