Пользователь
0,0
рейтинг
8 июля 2014 в 16:04

Разработка → Unity vs Adobe Air, или Как я писал первую мобильную игру из песочницы

Всем привет!

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

Начало

С чего всё началось? Правильно, как и многие интересные и не очень истории, с увольнения с работы. Время освободилось, а занять себя было просто необходимо. Так как 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 раз быстрее. Пришлось сделать первый взрыв автоматическим за пределами камеры (вне глаз пользователя), в то время, когда игрок еще щелкает менюшку.

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

Итог

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

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (24)

  • +3
    Видя с какой скоростью Adobe убивает flash и air, заменяя html5+js и phonegap -ом, я бы не делал ставок на Air, лучше уж сразу на Unity.
    Вангую, что скоро от Flash Pro редактора останется только экспорт в канвас анимаций и подготовки спрайтишитов.
    • 0
      Думаю, они не убивают flash, а делают ставку на более перспективные технологии.
  • 0
    А что вы имели в виду под «Haxe + Haxe Nape»?
    OpenFL?
    • 0
      Да. Имел ввиду «Haxe + OpenFL + Haxe версия Nape»
      • 0
        Хм, по идее «Haxe + Nape» должна больше отличаться от AIR и меньше от Unity…
        • 0
          Возможно, маленькая выборка была, да и всего один тип теста — падение группы кубиков на платформу. Но в любом случае, думаю, связка «Haxe + Nape» будет где-то посередине между Unity и Air
  • 0
    Присоединяюсь к выбранным урокам по Unity. Они действительно хороши. То что надо для изучения 2D в Unity.
  • +2
    Однако и он не идеален — например, Unity WebPlayer и его периодические крэши

    При чем тут WebPlayer, если речь про мобильные игры? Вообще, крэши часто получаются из-за каких-то глюков в коде. То что, WebPlayer в какой-то мере нестабилен — я могу согласиться. С другой стороны, это весьма продвинутая технология и хорошо, что Юнити смогли его реализовать.

    зависание редактора при закрытии

    Это исправлено в последней версии. Советую обновиться!

    несрабатывание кнопки мыши в Chrome

    Мм? Я думаю, вы просто не до конца разобрались.

    А вообще — с релизом и хороших отзывов!
    • 0
      зависание редактора при закрытии

      Это исправлено в последней версии.


      Побежал обновляться, т.к. это уже надоело, особенно если ожидаешь окошка с вопросом о сохранении изменений))
  • 0
    Спасибо за статью, сам думаю переходить с нативного Sprite Kit в стан юнити, кросплатформенность — отлично
    • 0
      Пожалуйста!
  • +2
    При чем тут WebPlayer, если речь про мобильные игры?

    Я выбрал Unity, в частности из-за его кроссплатформенности — создавая игру для мобильных, иногда не грех подумать и о версии для Web

    По поводу кнопки мыши, возможно и не разобрался, но не только у меня были вопросы по этому поводу forum.unity3d.com/threads/web-player-mouse-input-bug-on-chrome-only.240562/#post-1634283

    В целом просто хотелось отметить, что любая технология не идеальна, а не только хвалить в одностороннем порядке.

    Спасибо за комментарий!

  • 0
    Попрошу предоставить общественности такие данные, прежде чем я напишу свой комментарий:

    1) Количество draw calls у Starling, когда проседал FPS
    2) Количество итераций скорости и положения у Nape. По умолчанию стоит 10, 10
    3) Версию Adobe Air
    4) Версию Starling

    Спасибо!
    • 0
      1) 3-5 dc, антиалиас = 0, использовался один атлас 2048x2048,
      2) Velocity Iteractions = 1, Position Iteractions = 1
      3) 3.9
      4) 1.4.1

      Для примера полностью готовая игра на Юнити:
      1) 12-15 dc в среднем, антиалиас = 0, четыре атласа 1024x1024
      2) Velocity Iteractions = 3, Position Iteractions = 2

      Эйр + Старлинг + Нэйп вполне подошел бы для злых птичек, но сильные подергивания во время взрыва, когда ты на грани пытаешься персонажем не врезаться в трубу, очень напрягают
      • +3
        Извините, если для кого-то в очередной раз покапитаню :)

        А не пробовал с 14й версией Adobe Air и 1.5.1 Starling?

        Дело в том, что старлинг — это фреймворк с тараканами. Он кушает ресурсы процессора ввиду несовершенного кода. Такие жертвы окупаются максимальной идентичности обычному DisplayList. В сравнении с 1.4.х там много чего поменялось. Видел реальные примеры на работе, где переход с 1.4 на 1.5 дал солидное ускорение. Тот же Genome2D на порядок меньше нагружает CPU. А это дает шанс больше потратить на физику, что в очередной раз подчеркивает несовершенства движка Starling.

        Что касается Adobe Air — рантайм для тестов надо брать самый последний всегда (можно даже с labs). Часто что-то в нем фиксится. Грубо говоря «вчерашняя» и «сегодняшняя» версии могут иметь заметный разрыв в производительности. Все тесты на устаревшей версии лично у меня вызывают сомнения. А они не беспочвенны :) Были случаи, когда после оптимизации тестов производительность поднималась существенно. Еще ребята ставят типы сборок любые, но не AppStore и получают понижение производительности.

        У FP медленно avm работает, согласен на все 100% Сейчас её пытаются прокачать. Буквально недели 2.5 назад была инициирована очередная попытка:) Но для большинства игр — много физики и не требуется. Я для себя вижу применение Air чисто по категориям, когда мне нужна скорость разработки в чем-то для меня привычном, где нет надобности в перегрузке процессора. Порог перегрузки у Unity3D конечно же выше, т.к. движок создавался изначально не под «баннерок показать» :) Но ничего. Сейчас Adobe имеют желание сделать физику подключаемую, которая будет работать шустро.

        Что же касается Nape — у меня к нему тоже много вопросов. Так уж повелось, что я не математик. Но могу серьезно что-то улучшить чисто по коду. Когда игрался с Nape — я его ускорил немного. Там есть еще куда копать, но меня и так всё устраивает :) Делать Батлфилд на флеше я не планировал.

        Ну и да — на чем делать игру не так важно, как суметь её раскрутить. Что Adobe Air, что Unity3D или даже UDK — это всё мелочи. Если у автора нет магии (денег) — стать очередным автором Flappy Bird удается единицам.

        Спасибо, что прочитали мой монолог!
        • +1
          Ого, даже зарегались ради комментирования этого поста =) Добро пожаловать!
        • 0
          Если игра будет тормозить, то её будет проблематично раскрутить =)
          Если не мучаться с поиском нужной версии «фреймворка с тараканами», а просто использовать Unity3D, то можно сэкономить время на раскрутку…
          Мне очень нравится работать c AIR, но тенденции делают своё дело и для разработки я выберу Unity.
          • 0
            Если игра будет тормозить, то её будет проблематично раскрутить =)

            Сделать не тормозящую игру на Adobe Air куда легче, чем раскурить любую игру, не взирая на технологию её написания :)

            В сторе очень много не тормозящих игр на Unity3D, которые публика обходит стороной. Многие разработчики заблуждаются на счет выбранной технологии (любой), когда думают, что сейчас быстро сделают игру на самом модном движке и всё в шоколаде. Когда начинается раскрутка — приходит понимание, что технология чуть ли не последнее, на что следует обращать внимание. Игроки даже на подтормаживания согласятся ради «вкусного» геймплея.

            Взять тот же Flappy Bird. Игра без проблем могла бы быть реализована даже на html обычном 4м. И это никак бы не изменило то, что она взлетела благодаря геймплею, а не технологии.

            и для разработки я выберу Unity.

            Хороший выбор. Я положительно отношусь к данной технологии.

            Но такие игры как делали на Adobe Air, так и будут продолжать делать. Ведь не везде нужна физика мощная :)

            itunes.apple.com/app/monster-legacy/id652151375
            itunes.apple.com/app/groove-racer/id619207087
            itunes.apple.com/app/id727666012
            itunes.apple.com/app/empire-four-kingdoms/id585661281
            itunes.apple.com/app/csi-hidden-crimes/id762131394
            itunes.apple.com/app/1849/id840299641
            itunes.apple.com/app/botanicula/id853706620
            play.google.com/store/apps/details?id=air.pzuh.Shotgun_vs_Zombies
            itunes.apple.com/app/outernauts-monster-battle/id820455911
            • +1
              Вы правда думаете, что Flappy Bird взлетела именно из-за геймплея?
              • 0
                А из-за чего она взлетела по Вашему мнению :)
                • 0
                  Вас не смущает, что с таким геймплеем было уже слегка более 9000 игр до флаппи берд?
                • 0
                  имхо: судя по всему была найдена уязвимость в топе эппла

                  это хорошо объясняет и взлет. и настоящую причину почему убрали из стора доходное приложение.

                  Вообщем если вам правда интересно — погуглите подробности
          • 0
            И почему-то все опускают такой не маловажный момент для маленьких игр, как стоимость.
            Да, у юнити есть бесплатная версия. Но там есть существенные ограничения.
            На первый взгляд все ок. Но потом оказывается например, что большой билд в сторе, ограничивает рынок устройств, его надо делать как можно меньше и потом догружать контент, а это есть только в платной версии.
            Потом у вас появляется напарник, и надо мержить работу где-то в гите.
            Игра подтормаживает и непонятно в чем проблема? Профайлер только в платной версии. А ведь по началу, пока не разберешься в движке, он ну просто незаменим.
            Опять попадаем на деньги и т.д.
            В общем все это пофиг, когда вы «делаете бизнес» с хорошими вложениями. Или у вас уже есть лицензия.
            Но для большинства небольших игр, особенно первые разработки, Unity выглядит дороговато.

            P.S. Конечно же можно придумать сценарии, в которых ограничения бесплатной версии не мешают. Но для большинства проектов это не так.
        • 0
          А не пробовал с 14й версией Adobe Air и 1.5.1 Starling?

          Нет, но если будет время на новую игру, то уж точно попробую). Все-таки Air роднее, так сказать.

          Сейчас Adobe имеют желание сделать физику подключаемую, которая будет работать шустро

          Естественно, будем ждать только хороших новостей.

          Ну и да — на чем делать игру не так важно, как суметь её раскрутить

          Подумываю в следующий раз просто сосредоточиться на качестве игры и попробовать передать игру издателям, т.к. самому раскрутиться — это да, та ещё задачка.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.