пятница, 15 ноября 2013 г.

Записки программиста #6. Что мы знаем о монетизации?!

Недавно я задался вопросом, что я вообще знаю о монетизации мобильного приложения.
Я думаю стоит выделить три группы:
  • Реклама в приложении
  • Продажа приложения
  • Покупки внутри приложения
Остановимся на каждой группе в отдельности.

Реклама в приложении
Я бы ее разделил на две большие категории:
  1. Реклама внутри приложения, как баннер как правило 480*80Это один из самых простых способов рекламы. Вы выбираете рекламного провайдера по региону в котором у него есть реклама, а лучше выбирать как можно больше и оставлять за собой возможность регулировать выбор без обновления приложения. Это необходимо делать для того, чтобы если у одного из провайдеров будут низкие цены на клики можно было переключиться на остальных.В плане получения денег, тут все просто, количество прибыли зависит от времени одной сессии и количества пользователей, ну и от цены за клик у конкретного провайдера.
  2. Большой фул скрин баннер.На текущий момент, я не видел провайдера для российского рынка которые торгуют такими баннерами. Как правило их вставляют в момент старта приложения, в момент выхода или после игровой сессии в играх. Цены за показ такого баннера как правило намного выше, но и недовольство пользователя тоже возрастает.
Добавление рекламы в приложение порождает ряд недовольных пользователей и иногда проскакивают гневные отзывы по поводу рекламы, но если приложение хорошее, а реклама не сильно навязчивая, то их почти нет.
И так, что по поводу денег, этот вопрос наверное интересует всех. Тут как я и говорил, все просто - 10 000 сессий в день * (10 минут на одну сессию / 30 сек показ баннера) = 200 000 показов баннера в день. Цена за 1000 показов в районе 6-10 рублей (это в переводе на клики, в текущих реалиях среди российских провайдеров рекламы на Windows Phone). 
200 000 / 1000 * (6-10)=1200-2000 рублей в день. Откуда брать статистику? Вы все еще не прикрутили не google analytics или flurry, ну вы даете…
Немного еще цифр, нахождение на первой странице в серединке, в разделе топ бесплатных среди российского рынка дает примерно в районе 1к загрузок в день.
И на последок, очень вкусным я считаю, заключение рекламных отношений с какой ни будь компанией, в рамках рекламы её или её продукции внутри вашего приложения, но все мои изыскания в этом пока потерпели неудачу, возможно просто мало этому уделяю времени.

Продажа приложения
Я использую ставшую уже классической схемой. Есть раскрученное бесплатное приложение с рекламой и есть платное без рекламы, которое рекламируется в бесплатном.
За все время существование платной версии, а это 8 месяцев было 183 покупки по 33 руб
– 30% магазину = 4183,20 руб. Бешенные деньги =)
Некоторые добавляют расширение функционала в платной версии, это приносит значительно большую прибыль, но в сравнении с рекламой в тех же приложениях она существенно меньше.
Также, если с триалом все просто, купил человек платную версию открылись новые уровни, а в вопросе покупки другого, платного приложения, то что-то нужно делать с игровым прогрессом, а то многие пользователи будут не довольны, что порождает лишний геморрой.
Если судить по магазину, то крупные издательские дома выпускают платные приложения, которые хорошо оттестированы и как правило не обновляются. Тут в первую очередь играет опыт издателей в плане, что они хорошо уже знаю, что нужно игрокам, знают, как правильно раскрутить игру и отбить свои затраты. Насколько это хороший способ в прибыли не возьмусь сказать однозначно, тк пока мало опыта в этом и нету понятия как у них устроит процесс выпуска игры на рынок.

Покупки внутри приложения
Название говорит само за себя и на текущий момент наверное самый вкусный кусок пирога, на нем я постараюсь остановиться побольше, во первых из-за своих коварных интересов в этой области, во вторых упорядочить то, что я уже знаю и немного подчерпнуть новых знаний.
Почему вкусный кусок пирога? Да потому, что переход игры с pay-to-play на free-to-play приносит довольно серьезный доход, а если привнести в реалии мобильной разработки то и продвигать бесплатные/условно бесплатные игры намного проще.
Исходя из этого, свою новую игру я буду монетизировать по схеме f2p.
Давайте попробуем разобраться, что это за зверь и что и как следует делать…
Про различные способы монетизации хорошо написано в статье на хабре «Мошеннические методымонетизации в free-to-play играх» и «Игры free-to-play: как сделать их успешными». Есть еще куча других статьей, но я считаю, что это наиболее полезные.
Из всего, что написано в статьях и крутилось у меня в голове, я выделил бы несколько аспектов:
  1. Первый уровень должен отлично выверен, чтобы пользователю с первых минут понравилось играть именно в эту игру, тк я считаю, что именно первая сессия определяет, будет ли он играть в нее в дальнейшем. Интерфейс должен быть максимально простым и понятным, чтобы как можно меньше шагов отделяло игрока от игры, а игровой хелпер коротким и не навязчивым.
  2. Плавный прогресс в игре, ведь чем дольше он будет играть, тем больше шанс, что он что-либо купит.

Вывод:
У меня пока очень мало навыков, чтобы создать эффективную модель монетизации по типу free-to-play, но оступаться я не собираюсь. Поэтому, пока, я решил довольствоваться малым. Игру я позиционирую как убийцу времени, поэтому игра должна быть интересной и иметь возможность пройти ее полностью без вложения денег. Вложение денег существенно упростит и ускорит прогресс в игре, но не более. Валюта в игре будет единая, вводить дополнительную валюту я не вижу смыслы. Так же если игрок покупает единовременно больше денег, то он получает скидку в виде дополнительной валюты.

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

среда, 13 ноября 2013 г.

MD5Core старый баг...

Недавно на работе, работая над мобильным xmpp клиентом, столкнулся с такой забавной вещью при авторизации, никак не получалось авторизоваться на рабочем сервере, с корректными данными, используя md5. Unit tests с тестовыми данными проходят, путем долго дебага и сравнивания нашли проблему в либе MD5Core.
Оказывается - эта либа считает неправильно хеш, если длина равна 56, 120, 184, 248 и тд…
На это наткнулся после 2 лет успешного использования, мда, жизнь меня к такому не готовила…
Ошибка оказывается это известная от 5 июль 2011…
Лечиться путем изменения
if (cbSize <= 56) на  if (cbSize < 56)
Забавно до слез!

вторник, 12 ноября 2013 г.

Записки программиста #5. Концепт документ, да или нет?

Изначально, когда я только начинал делать игру, никакого концепт документа не было, все было в голове, постоянно появлялись новые фичи, которые внедрялись… и как-то процесс разработки был вечным. Спустя некоторые время я стал умнее и понял, что стоит создать его, тем самым ограничить функционал и утрясти все у себя в голове, а уж привлечь других людей на проект без него вообще очень тяжело.
И так, что это вообще такое «Концепт документ» и с чем его едят.
Концепт-документ (концепт) — это краткое и ёмкое описание концепции (идеи) игры, то есть, максимально сжатый документ, в котором рассказывается о том, какой будет игра, чем она будет интересна и как она должна выглядеть после разработки.
Такой документ составляется игровым дизайнером, но в моем проекта я и дизайнер и программист, и спонсор и кем я только не являюсь =))) Но трудности ведь закаляют;-)
Концепт-документ может строиться по следующей схеме:
  1. Введение
  2. Жанр и аудитория
  3. Основные особенности игры
  4. Описание игры
  5. Сравнение и предпосылки создания игры
  6. Платформа
  7. Контакты

Во первых определитесь, для чего Вы его пишете вообще, а если не можете ответить на этот вопрос, то зачем Вы его пишете?! Что бы было? Я думаю не стоит…
Во вторых, старайтесь писать его на «холодную голову» будьте честны с собой, отвечая на вопросы об особенностях игры и обозревая конкурентов.
После того как вы это сделайте, стоит взяться за «Дизайн-документ».
Типовой дизайн-документ может иметь следующую структуру:
1. Введение
2. Концепция
2.1. Введение
2.2. Жанр и аудитория
2.3. Основные особенности игры
2.4. Описание игры
2.5. Предпосылки создания
2.6. Платформа
3. Функциональная спецификация
3.1. Принципы игры
3.1.1. Суть игрового процесса
3.1.2. Ход игры и сюжет
3.2. Физическая модель
3.3. Персонаж игрока
3.4. Элементы игры
3.5. "Искусственный интеллект"
3.6. Многопользовательский режим
3.7. Интерфейс пользователя
3.7.1. Блок-схема
3.7.2. Функциональное описание и управление
3.7.3. Объекты интерфейса пользователя
3.8. Графика и видео
3.8.1. Общее описание
3.8.2. Двумерная графика и анимация
3.8.3. Трехмерная графика и анимация
3.8.4. Анимационные вставки
3.9. Звуки и музыка
3.9.1. Общее описание
3.9.2. Звук и звуковые эффекты
3.9.3. Музыка
3.10. Описание уровней
3.10.1. Общее описание дизайна уровней
3.10.2. Диаграмма взаимного расположения уровней
3.10.3. График введения новых объектов
Контакты

Примеров «Дизайн-документ» в интернете ходит много.
Я бы туда добавил бы еще календарный план разработки игры, а также ресурсы которыми обладаем и которые необходимы.
Выводы:
Написав все это, у Вас появиться довольно неплохое виденье проекта в деталях, а также поможет привлечь не достающие ресурсы.
Когда его стоит писать? Насчет того, что начинать стоит с него, если Вы инди разработчик, я не согласился, я его написал перед привлечение новых людей в проект, после редактора физики, к тому моменту идея окончательно созрела в голове;-)
Удачи в разработке;-) 

понедельник, 4 ноября 2013 г.

Записки программиста #4. С чего начать…

Начинать решил с редактора физики, по целому ряду причин: во первых хотел получше разобраться в выбранном физическом движке.
Изначально для редактора физики я собирался использовать связку Windows Forms + XNA.
Для редактора мне больше всего нравился метод, где XNA это панель, а остальная гуя это Windows Forms контролы. Но тк решил писать на Monogame, возникли проблемы, может конечно руки кривые, но не срослось. Нашел презабавную вещицу - OpenTK.GLControl.
Но чем больше я использовал подобные решения, тем больше у я убеждался, что нужны свои контролы, тк изобретать велосипед совсем не хотелось. Решил глянуть что появилось новенького в плане GUI for XNA, их довольно-таки много:
Также у меня были первые версии библиотеки generala GPF:
Очень жалко, что Дима через некоторое время закрыл и исходники и саму либу. 
Из всего этого многообразия мне понравилось два проекта GPF и XAMLite, правда оба они не дописаны и не обновляются в открытом доступе, что очень прискорбно.
Решено было остановиться на GPF и допиливать его по мере необходимости.
После того как я определился с GUI я взялся за сам движок и редактор физики.
Графический контент я объединяю в атласы текстур и там же сжимаю в .xnb с возможностью применить DXT сжатие.
Он конечно будет допиливаться по мере необходимости, но в целом уже не плохо, вот демонстрация возможностей (попозже запишу в качестве получше):
Пора браться за саму игру =)
Правда, по поводу игры возник небольшой нюанс…Но это сюрприз, напишу о нем в следующей статье :-)