Облегчаем жизнь разработчику мобильных игр

Сделать хорошую игру — это далеко не вся работа. Для того, чтобы получить законченный продукт, который можно будет успешно распространять, необходимо интегрировать в игру разного рода маркетинговые инструменты: трекинг реферальных установок, баннерокрутилки и офферволлы, модули подписки на новостную рассылку и показа других хороших игр, различные партнерские 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.