Всем привет,
Сделать хорошую игру — это далеко не вся работа. Для того, чтобы получить законченный продукт, который можно будет успешно распространять, необходимо интегрировать в игру разного рода маркетинговые инструменты: трекинг реферальных установок, баннерокрутилки и офферволлы, модули подписки на новостную рассылку и показа других хороших игр, различные партнерские SDK и т.д. и т.п. В этом посте я расскажу, какие инструменты для этого используем в Alawar мы и наши разработчики. Возьмем как пример наши iOS-проекты.
Проанализировав основные маркетинговые инструменты, которые используются на рынке, мы выделили некоторые группы инструментов, которые обладают общими признаками. Например, практически все такие SDK требуют инициализации сессии в методах application:didFinishLaunchingWithOptions: или applicationDidBecomeActive:. Там же отрабатывают все инсталл-трекеры.
Пуш-нотификации регистрируются всегда одними и теми же вызовами.
Реферрал-трекерам как правило нужна информация после успешного совершения ин-аппа. А сами ин-аппы нужно валидировать.
И еще обычно все эти же места хочется «обвесить» ивентами для сбора статистики, например, через Flurry.
Также стоит отметить, что эти задачи – общие для всех проектов, отличия только в айдишниках и прочих apiKey-ях для сторонних сервисов.
Геймдев под iOS устроен так, что без маркетинга – никуда. Но разработчики в первую очередь должны (и хотят) думать и работать непосредственно над игрой, а не заморачиваться «маркетинговым обвесом». Для того, чтобы это стало возможным, издатели предоставляют своим разработчикам различные SDK, фреймворки и т.п. Alawar – не исключение. Мы подготовили Alawar iOS Framework, который включает в себя все необходимые маркетинговые модули актуальных версий и «делает немножко магии».
За «немножко магии» отвечает замечательный рантайм Objective-C и его возможности по микшированию кода.
Так, например, чтобы стартовать сессии для нескольких SDK в методе application:didFinishLaunchingWithOptions: нам нужно «перехватить» этот вызов у Application Delegate и добавить к нему свою имплементацию. Для этого создаем категорию над UIApplication, ловим метод setDelegate:
Аналогичным образом подмешиваем работу со сторонними библиотеками в applicationDidBecomeActive, инициализируем пуш-нотификации и т.п.
Разработчикам же остается только добавить фреймворк к своему Xcode-проекту и выставить флаг линкера –all_load.
Несколько иная ситуация с ин-аппами, их валидацией и регистрацией в реферрал-трекерах и статистике. Здесь мы решали еще одну побочную задачу. Разработчики проводят первичное тестирование под своим Apple-аккаунтом и с одними айдишниками ин-аппов, а при прохождении QA в издательстве и публикации в стор используется другой аккаунт и другие айдишники.
Для решения этих задач мы реализовали свое API «обертку» над API StoreKit и дополнительные протоколы для уведомления делегатов о результатах валидации платежа. При этом все идентификаторы продуктов вынесены в отдельный настроечный конфиг.
Таким образом, разработчик использует API аналогичное StoreKit-у, но уже без необходимости обвешивать покупки статистикой, самостоятельно реализовывать валидацию и т.д.
В завершении статьи отметим, что аналогичный инструментарий мы предоставляем также для платформы Android.
Сделать хорошую игру — это далеко не вся работа. Для того, чтобы получить законченный продукт, который можно будет успешно распространять, необходимо интегрировать в игру разного рода маркетинговые инструменты: трекинг реферальных установок, баннерокрутилки и офферволлы, модули подписки на новостную рассылку и показа других хороших игр, различные партнерские SDK и т.д. и т.п. В этом посте я расскажу, какие инструменты для этого используем в Alawar мы и наши разработчики. Возьмем как пример наши iOS-проекты.
Проанализировав основные маркетинговые инструменты, которые используются на рынке, мы выделили некоторые группы инструментов, которые обладают общими признаками. Например, практически все такие SDK требуют инициализации сессии в методах application:didFinishLaunchingWithOptions: или applicationDidBecomeActive:. Там же отрабатывают все инсталл-трекеры.
Пуш-нотификации регистрируются всегда одними и теми же вызовами.
Реферрал-трекерам как правило нужна информация после успешного совершения ин-аппа. А сами ин-аппы нужно валидировать.
И еще обычно все эти же места хочется «обвесить» ивентами для сбора статистики, например, через Flurry.
Также стоит отметить, что эти задачи – общие для всех проектов, отличия только в айдишниках и прочих apiKey-ях для сторонних сервисов.
Геймдев под iOS устроен так, что без маркетинга – никуда. Но разработчики в первую очередь должны (и хотят) думать и работать непосредственно над игрой, а не заморачиваться «маркетинговым обвесом». Для того, чтобы это стало возможным, издатели предоставляют своим разработчикам различные SDK, фреймворки и т.п. Alawar – не исключение. Мы подготовили Alawar iOS Framework, который включает в себя все необходимые маркетинговые модули актуальных версий и «делает немножко магии».
За «немножко магии» отвечает замечательный рантайм Objective-C и его возможности по микшированию кода.
Так, например, чтобы стартовать сессии для нескольких SDK в методе application:didFinishLaunchingWithOptions: нам нужно «перехватить» этот вызов у Application Delegate и добавить к нему свою имплементацию. Для этого создаем категорию над UIApplication, ловим метод setDelegate:
@interface UIApplication(AlawarFramework)
@end
@implementation UIApplication(AlawarFramework)
+ (void) load {
method_exchangeImplementations(class_getInstanceMethod(self, @selector(setDelegate:)), class_getInstanceMethod(self, @selector(af_setDelegate:)));
}
- (void) af_setDelegate:(id<UIApplicationDelegate>)delegate {
Method method = nil;
method = class_getInstanceMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:));
if (method) {
class_addMethod([delegate class], @selector(application:AFDidFinishLaunchingWithOptions:), (IMP)AFdynamicDidFinishLaunching, "v@:::");
method_exchangeImplementations(class_getInstanceMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:)), class_getInstanceMethod([delegate class], @selector(application:AFDidFinishLaunchingWithOptions:)));
} else {
class_addMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:), (IMP)AFdynamicDidFinishLaunching, "v@:::");
}
// устанавливаем "родного" делегата
[self af_setDelegate:delegate];
}
BOOL AFdynamicDidFinishLaunching(id self, SEL _cmd, id application, id launchOptions) {
// вызываем "родной" метод, если был реализован
if ([self respondsToSelector:@selector(application:AFDidFinishLaunchingWithOptions:)]) {
result = (BOOL) [self application:application AFDidFinishLaunchingWithOptions:launchOptions];
} else {
[self applicationDidFinishLaunching:application];
result = YES;
}
// тут инициализируем библиотеки, стартуем сессии и т.д.
return result;
}
@end
Аналогичным образом подмешиваем работу со сторонними библиотеками в applicationDidBecomeActive, инициализируем пуш-нотификации и т.п.
Разработчикам же остается только добавить фреймворк к своему Xcode-проекту и выставить флаг линкера –all_load.
Несколько иная ситуация с ин-аппами, их валидацией и регистрацией в реферрал-трекерах и статистике. Здесь мы решали еще одну побочную задачу. Разработчики проводят первичное тестирование под своим Apple-аккаунтом и с одними айдишниками ин-аппов, а при прохождении QA в издательстве и публикации в стор используется другой аккаунт и другие айдишники.
Для решения этих задач мы реализовали свое API «обертку» над API StoreKit и дополнительные протоколы для уведомления делегатов о результатах валидации платежа. При этом все идентификаторы продуктов вынесены в отдельный настроечный конфиг.
Таким образом, разработчик использует API аналогичное StoreKit-у, но уже без необходимости обвешивать покупки статистикой, самостоятельно реализовывать валидацию и т.д.
В завершении статьи отметим, что аналогичный инструментарий мы предоставляем также для платформы Android.
