Мне повезло работать Саровском Технопарке – секретном месте на границе Нижегородской области и Мордовского заповедника, где среди снегов и умных девушек, которых не соблазнишь iPhone’ом, создает свои нетленные произведения свободный художник, мастер малых форм и адепт iOS-программирования PapaBubaDiop.
Здесь я получил благословление Папы Бубы на игрописание, а вместе с ним золотой запас исходных кодов игр «Чапаев» и «Башни» для iPhone. Всё это богатство было получено под обещание посеять доброе и вечное на полях Android и WP7.
Под хаброкатом привожу историю освоения небольшого, но активно удобряемого редмондским и эспоовским гигантами участка Windows Phone.
Игра
Шашечная игра Чапаев знакома многим с детства. Одно из виртуальных воплощений игры было представлено Папой Бубой полтора месяца назад. Сегодня раскрываю некоторые особенности реализации, задающие начальные условия для повторения Чапаева на платформе WP7:
- Игровой движок собственного производства, легко морфируемый под каждую новую игру;
- Использование стандартных элементов пользовательского интерфейса для построения сцены;
- Комбинирование анимации, выполняемой в игровом цикле (движение фишек после удара) со стандартной анимацией, предоставляемой SDK (для начального построения фишек, поворота доски или перехода хода).
Windows Phone
Поскольку мы сторонники эволюции, а не революции, для воплощения затеи были выбраны нативные средства программирования под Windows Phone, предлагаемые Microsoft. А задача переноса игры разделена на две части:
- Ретрансляция физического движка и модели игры в C#
- Реализация графического представления игры средствами Silverlight
Первый тонкий момент в реализации приложений для Windows Phone, с которым пришлось столкнуться, – это необходимость сохранять и восстанавливать состояние приложения и отдельных его страниц. Жизнь мобильного приложения коротка и даже невинная блокировка экрана приводит к закрытию страницы, а при некоторых условиях и вытеснению приложения из памяти. Разблокировка, соответственно, возвращает приложение и активную страницу в исходное состояние. В нашем случае состояние страницы есть состояние игры, включая расположение шашек и выполняемую анимацию.
Далее, не смотря на существенное упрощение жизни разработчика за счет предопределенного разрешения экрана для всех устройств Windows Phone, было решено различать виртуальный размер игрового поля и фактическое разрешение экрана. Как дань уважения Папе Бубе, система координат игровой модели приведена в соответствие экрану iPhone. В перспективе в этой же системе координат будет жить сетевая игра.
C#
Ретрансляция кода физической модели и модели игры, в основном, свелась к замене синтаксических конструкций вызова функций и конструирования объектов в Objective-C, не считая объединения декларации и определения методов класса в один файл исходного кода.
В результате, благодаря простоте используемых языковых конструкций и схожести языков C# и Java, полученный код моделей можно использовать на 98% при переносе приложения на Android. Один непереносимый процент – имена функций Windows Phone SDK, второй процент – свойства (properties) класса. И, если от платформно-зависимых имен можно избавиться, завернув их в переходники, то отказываться от использования свойств оказалось неразумно.
Properties существенно упрощает задачу сохранения и восстановления состояния игры, как того требует жизненный цикл приложения. В приведенном ниже фрагменте кода определяется элемент игры «шашка» и её свойства:
public class CheckerItem
{
public int color { get; set; }
public double x { get; set; }
public double y { get; set; }
}
В игре используется набор шашек:
public class GameObject
{
public CheckerItem[] checkers;
}
А так происходит сохранение состояния игры в изолированное хранилище приложения:
IsolatedStorageSettings settings = IsolatedStorageSettings.ApplicationSettings;
settings["checkers"] = checkers;
И восстановление:
settings.TryGetValue<CheckerItem[]>("checkers", out checkers);
Silverlight
Для графического представления состояния игры и диалогов настройки выбор сделан в пользу Silverlight. Основной причиной применить неигровой фреймворк для игрового приложения стало желание вписать приложение в стиль Metro, насколько это возможно. Да и геймплей не предполагал серьёзных нагрузок на процессор, что впоследствии было подтверждено экспериментально – счетчикам производительности краснеть за выбор фреймворка не пришлось.
Однако не обошлось дело и без наступания на грабли.
Для реализации звуковых эффектов в игре использовался класс SoundEffect из набора средств XNA, что потребовало подключения XNA Framework и «ручного» проворачивания игрового цикла XNA. Но, самое печальное выяснилось уже после публикации: вместо основного меню телефона, приложение из магазина размещается в разделе Xbox Live. Надеюсь у пользователя достаточно желания и доброй воли его там найти после установки.
Еще одной неожиданностью стал глобальный для всего приложения обработчик касаний. Оказалось, однажды зарегистрированный обработчик события продолжит своё существование и после закрытия игровой страницы, будет радостно откликаться на тапы по странице настроек, например. Решение одно: минусовать обработчик событий при покидании страницы.
protected override void OnNavigatedTo(NavigationEventArgs args)
{
Touch.FrameReported += OnTouchFrameReported;
}
protected override void OnNavigatedFrom(NavigationEventArgs args)
{
Touch.FrameReported -= OnTouchFrameReported;
}
Вдобавок для моего случая потребовалось останавливать анимации при покидании страницы для синхронизации с состоянием игры, поскольку покидание страницы не всегда означает её разрушение, а возвращение возможно минуя конструктор страницы.
Публикация в Marketplace
Цикл рассмотрения приложения в Windows Marketplace экспериментально определен как 4 рабочих дня, в выходные движения нет. Причем рассмотрение повторной заявки после исправления замечаний длится всё те же четыре дня.
С момента одобрения до начала работы прямой ссылки на приложение прошло еще не менее суток, и дополнительно часов 10-12 понадобилось для индексации внутри магазина. После чего приложение начало появляться в результатах поиска.
Таким образом, минимальное время, требуемое для публикации приложения, составляет 5 дней, при условии, что приложение идеально, а заявка отправляется в понедельник.
Процедура рассмотрения приложения дополнена забавной интригой – сообщение об отказе в публикации доставляется почтой, но причину отказа можно узнать только из pdf-отчета, который необходимо получить через портал AppHub. Система стройная, но на практике проделать это с помощью телефона, собираясь на работу в 7 утра, совсем не просто.
Результат труда можно оценить на видео (спасибо Толику из известной торговой сети за предоставленный Nokia 710):
Можно загадывать желание
Когда делаешь что-либо первый раз в жизни, можно загадывать желание, и оно обязательно сбудется. Программист мыслит рационально и для повышения вероятности сбычи мечт делает одновременно три дела в первый раз в жизни: пишет игру для Windows Phone, впервые кодит на C#, и впервые публикует статью на Хабре. Я загадал.
Автор: BrerBeer