Всем привет!
Сегодня я хотел бы рассказать о первом опыте написании игры для мобильных устройств. По специальности я флешер, и делать игры, хоть и простые — для меня это не ново. Однако мобильная разработка это другое и таит в себе много неизведанного.
Начало
С чего всё началось? Правильно, как и многие интересные и не очень истории, с увольнения с работы. Время освободилось, а занять себя было просто необходимо. Так как Flash в последнее время не сильно блистает востребованностью, было решено попробовать Adobe Air и его кроссплатформенность.
Идея
Как не парадоксально, я не большой любитель играть в игры, за исключением «гоночек» и «чего-то простого и забавного». Естественно, первой идеей было что-то типа «захватывающей гонки-путешествия на внедорожнике». Затем, вдохновившись такой игрой, как Color Zen, захотелось чего-то «интересного, красивого и успокаивающего».
Но, как говорится, 8-битное прошлое взяло вверх и было решено сделать пародию на только что удалённую и ненавистную многими Flappy Bird. Не банальную пародию, нет, было решено дать пользователям выпустить пар — создать нового персонажа, который взорвёт всё к чертовой бабушке. Название нашлось быстро — Rocket Toads, а главных персонажей стало двое (чтобы сделать название игры созвучным знаменитой 8-битной игре). Выбрана цель игры — разрушить как можно больше труб, точно бросая динамит, и при этом остаться в живых, уворачиваясь от осколков и взрывов.
Реализация
Персонажи, фон и основные элементы игры были нарисованы быстро, т.к. высоких планок по дизайну не выставлялось. Как, собственно, и в игре, на которую делалась пародия.
В качестве движков были выбраны:
— Starling (отрисовка графики с использованием GPU)
— Nape (самый шустрый физический движок)
Если за Starling и его скорость я не волновался, то скорость просчета физики вызывала опасения — планировалось что на сцене одновременно будут присутствовать до 30-40 объектов — осколков от подорванных труб. Так же волновала скорость выполнения ActionScript-кода, в частности алгоритм разрыва трубы на осколки.
Первые тесты
Когда основная часть игры была готова, настал долгожданный момент тестирования на реальном устройстве.
В руки попался Samsung с одним процессором в 1000МГц и графическим ускорителем Andreno 200. Вообщем, по своим невысоким характеристикам — то что надо для тестов.
Запустилась игра отлично, герой радостно полетел вприпрыжку сквозь трубы, а фпс держался в районе 60! Но радоваться пришлось недолго, спустя некоторое время я попробовал шпульнуть динамит, и игра начала сильно подтормаживать, именно в моменты разрыва труб на осколки и при большом количестве физических объектов, чего я и опасался.
Последующие несколько дней настройки физ. движка и оптимизации кода ни к чему не привели. Профайлер (Adobe Scout) явно указывал, что скорость выполнения ActionScript-кода является камнем преткновения.
ANE, Unity2d и Haxe
Оплакивая Adobe Air, я пошёл и закопал его в своём саду принялся искать альтернативы. Как перспективные варианты улучшения производительности всплыли:
- ANE — нативные расширения для Adobe Air
- Haxe + Haxe версия Nape
- Unity3d со встроенным Box2d в качестве физ. движка
По первому варианту ничего толком не нашлось, т.к. не нашлось того «хорошего человека», сделавшего бы полноценный двухмерный физический движок на ANE.
Второй и третий вариант были хороши и было решено сделать пробные физические тесты, чтобы оценить производительность.
В итоге победил Unity, причем, если не изменяет память, при схожем фпс результаты приблизительно такие:
- Adobe Air + Nape — 50 кубиков
- Haxe + Haxe Nape — 70-80 кубиков
- Unity — 300 кубиков
Unity2d — переписываем игру заново
Освоение Unity далось относительно легко. Перейти с ActionScript на C# оказалось проще, чем виделось вначале. Редактор Unity также доставил удовольствие. Среди уроков посоветовал бы:
— Creating a 2D game with Unity
— Основы создания 2D персонажа в Unity 3D 4.3
— Официальные видеоуроки
Так же порадовало большое сообщество разработчиков Unity, благодаря которому практически на любой возникающий вопрос есть нормальный ответ.
Опять тестирование
Что ж, первые результаты тестов воодушевили — сильных тормозов не наблюдалось, и я принялся с уверенностью доделывать игру до конца. В последствии были обнаружены некоторые интересные баги, которые тормозили игру:
— «Первый взрыв» — первое выполнение скрипта, разрушающего трубу, было около 300 мс, последующие вызовы до 20 раз быстрее. Пришлось сделать первый взрыв автоматическим за пределами камеры (вне глаз пользователя), в то время, когда игрок еще щелкает менюшку.
— «Зажатость» — так как некоторые части от взорванных труб остаются статичными, а некоторые превращаются в динамичные осколки, бывают случаи, когда динамические осколки зажаты между статическими и генерируют множество коллизий и провоцируют «тормоза». Пришлось сделать счетчик, который при определенном количестве коллизий у статического осколка превращает его в динамический, и зажатости устраняются.
Итог
- Игра готова и даже выложена на Google Play. Скорость работы на средних и продвинутых девайсах внушает оптимизм.
- Приобретён опыт с замечательным движком Unity.
- Unity vs Adobe Air — победила дружба. На примере моей игры, конечно, Unity был вне конкуренции и для требовательных к производительности кода и физики мобильных игр я бы советовал именно его. Однако и он не идеален — например, Unity WebPlayer и его периодические крэши, несрабатывание кнопки мыши в Chrome, зависание редактора при закрытии, невозможность быстрой и качественной публикации во Flash и некоторые другие вещи. Также, судя по скорости рендеринга, Unity местами проигрывает Adobe Air + Starling .Так что, если вы решили написать не слишком требовательную игру и опубликовать её для Android, IOS или Flash-плеер, Adobe Air + Starling будет хорошим решением.
Автор: LicVit
