Unity vs Adobe Air, или Как я писал первую мобильную игру

Всем привет!

Сегодня я хотел бы рассказать о первом опыте написании игры для мобильных устройств. По специальности я флешер, и делать игры, хоть и простые — для меня это не ново. Однако мобильная разработка это другое и таит в себе много неизведанного.

Начало

С чего всё началось? Правильно, как и многие интересные и не очень истории, с увольнения с работы. Время освободилось, а занять себя было просто необходимо. Так как Flash в последнее время не сильно блистает востребованностью, было решено попробовать Adobe Air и его кроссплатформенность.

Идея

Как не парадоксально, я не большой любитель играть в игры, за исключением «гоночек» и «чего-то простого и забавного». Естественно, первой идеей было что-то типа «захватывающей гонки-путешествия на внедорожнике». Затем, вдохновившись такой игрой, как Color Zen ^[1], захотелось чего-то «интересного, красивого и успокаивающего».

Но, как говорится, 8-битное прошлое взяло вверх и было решено сделать пародию на только что удалённую и ненавистную многими Flappy Bird. Не банальную пародию, нет, было решено дать пользователям выпустить пар — создать нового персонажа, который взорвёт всё к чертовой бабушке. Название нашлось быстро — Rocket Toads, а главных персонажей стало двое (чтобы сделать название игры созвучным знаменитой 8-битной игре). Выбрана цель игры — разрушить как можно больше труб, точно бросая динамит, и при этом остаться в живых, уворачиваясь от осколков и взрывов.

Реализация

Персонажи, фон и основные элементы игры были нарисованы быстро, т.к. высоких планок по дизайну не выставлялось. Как, собственно, и в игре, на которую делалась пародия.

Иконка

Фон и главное меню

В качестве движков были выбраны:

— Starling ^[2] (отрисовка графики с использованием GPU)
— Nape ^[3] (самый шустрый физический движок)

Если за 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 ^[4]
— Основы создания 2D персонажа в Unity 3D 4.3 ^[5]
— Официальные видеоуроки ^[6]

Так же порадовало большое сообщество разработчиков Unity, благодаря которому практически на любой возникающий вопрос есть нормальный ответ.

Опять тестирование

Что ж, первые результаты тестов воодушевили — сильных тормозов не наблюдалось, и я принялся с уверенностью доделывать игру до конца. В последствии были обнаружены некоторые интересные баги, которые тормозили игру:

— «Первый взрыв» — первое выполнение скрипта, разрушающего трубу, было около 300 мс, последующие вызовы до 20 раз быстрее. Пришлось сделать первый взрыв автоматическим за пределами камеры (вне глаз пользователя), в то время, когда игрок еще щелкает менюшку.

— «Зажатость» — так как некоторые части от взорванных труб остаются статичными, а некоторые превращаются в динамичные осколки, бывают случаи, когда динамические осколки зажаты между статическими и генерируют множество коллизий и провоцируют «тормоза». Пришлось сделать счетчик, который при определенном количестве коллизий у статического осколка превращает его в динамический, и зажатости устраняются.

Итог

1. Игра готова и даже выложена на Google Play. Скорость работы на средних и продвинутых девайсах внушает оптимизм.
2. Приобретён опыт с замечательным движком Unity.
3. Unity vs Adobe Air — победила дружба. На примере моей игры, конечно, Unity был вне конкуренции и для требовательных к производительности кода и физики мобильных игр я бы советовал именно его. Однако и он не идеален — например, Unity WebPlayer и его периодические крэши, несрабатывание кнопки мыши в Chrome, зависание редактора при закрытии, невозможность быстрой и качественной публикации во Flash и некоторые другие вещи. Также, судя по скорости рендеринга, Unity местами проигрывает Adobe Air + Starling ^[7].Так что, если вы решили написать не слишком требовательную игру и опубликовать её для Android, IOS или Flash-плеер, Adobe Air + Starling будет хорошим решением.

Автор: LicVit

Источник ^[8]