Три кейса о том, как мы адаптируем игры для iOS и Android
Привет! Меня зовут Олег Федоренко, я СТО компании Pingle Studio. Мы создаем продукты для международных лидеров игровой индустрии — Embracer Group, Square Enix, Qualcomm, tinyBuild, Revolution Software, Egosoft и других.
У нас большой опыт как в разработке игр полного цикла, так и в совместной разработке. Мы уже 13 лет создаем для клиентов графику и анимации, тестируем игры, а также портируем их на разные платформы. О последнем я и хочу рассказать подробнее на примере нескольких наших проектов. Все три игры, о которых пойдет речь ниже, мы адаптировали для мобильных устройств на iOS или Android.
В статье поговорим о том, какие сложности возникают при портировании, как уложиться в оговоренные сроки, не жертвуя качеством игры, и чем интересны такие проекты с точки зрения разработки.
Иллюстрация создана при помощи Awesomic
Hello Neighbor
Год: 2018.
Команда: 10 человек.
Сроки: два месяца.
Клиент: tinyBuild.
Задача: портирование с UE4/PC на iOS и Android.
Hello Neighbor — это большая игра, и главная сложность заключалась в том, что нам предстояло ее портировать под устройства iOS и Android за два месяца. Дело в том, что издатель игры, компания tinyBuild, придерживается четкого графика выпуска проектов. Под дату релиза планируется маркетинговый бюджет, который включает, например, договоренности о рекламе с блогерами на YouTube и Twitch. Поэтому если мы договорились о дате, то обязаны уложиться в сроки.
Как известно, девять женщин не родят одного ребенка за месяц. Так же и в разработке: нельзя критически сократить время проекта, если просто увеличить команду. Поэтому в начале проекта мы обсудили с издателем критические требования, которые реалистично воплотить в жизнь за 8 недель.
Графика. Прежде всего мы оговорили список поддерживаемых мобильных устройств, на которых должна запускаться игра. От характеристик «железа» напрямую зависит итоговое качество «картинки», которого мы сможем добиться. Нужно выбрать: либо — хорошая графика на ограниченном числе устройств, либо — посредственная, но зато игра запускается условно везде.
Мы с издателем нашли компромисс и решили отказаться от поддержки слабых и старых устройств с оперативной памятью до 2 Гб. Например, iPhone 5s и iPhone 6 и аналогичных Android-смартфонов. Благодаря этому можно было не сильно урезать графику и добиться того, чтобы игра хорошо выглядела.
Итак, перед нами стояла задача воспроизвести графику консольного уровня на мобильных устройствах с памятью 2 Гб и выше. Но даже у новых смартфонов и планшетов много ограничений по сравнению с ПК: более слабые процессор и графический ускоритель.
Чтобы мобильные устройства потянули нужное визуальное качество, мы определили наиболее ресурсоемкие элементы игры и часть из них убрали. Например, вырезали некоторые интерактивные объекты и взаимодействия, которые не важны для прохождения игры.
Из-за особенностей Unreal Engine пришлось повозиться с фичами, которые на тот момент не работали на мобильных устройствах. В частности, спотлайты. В версии для ПК их было много, и у нас не оставалось выбора, кроме как переносить динамический свет на мобильную платформу вручную. К слову, в более новых версиях UE эта фича уже есть — и делается одной кнопкой.
Производительность. Изначально разработчики Hello Neighbor не планировали, что игра будет работать на мобильных устройствах. Поэтому, чтобы разгрузить CPU и GPU, мы занялись оптимизацией ассетов.
С этим помогли инструменты из 3D-пакетов. Мы выгружали туда часть карт, перенастраивали их и затем импортировали назад в движок. Один участок карт настроили вручную, а на остальные просто применили эти настройки. Такая автоматизация сэкономила много часов ручного труда.
Управление. Оригинальный Hello Neighbor для ПК управляется с помощью клавиатуры и мыши. Игроки привыкли, что в проектах такого типа левой рукой можно с клавиатуры управлять передвижением персонажа, а правой, с помощью мышки — всеми интерактивными объектами.
На мобильных устройствах все по-другому. Во-первых, в нее играют буквально двумя пальцами. Во-вторых, нужно сделать так, чтобы область, из которой игрок управляет персонажем, камерой и всеми интерактивными объектами, не перекрывала центр экрана.
Мы решили повторить в мобильной версии логику управления в игре для ПК. Слева разместили виртуальный джойстик: он отвечает за передвижение персонажа. Если отклонить палец от его центра, меняются дополнительные характеристики, например, скорость. А в правой части экрана — все возможные взаимодействия в игре: с объектами, другими персонажами и так далее.
На разработку прототипов нескольких решений по управлению у нас было две-три недели. Чтобы уложиться в сроки, делали их в виде мокапов — без детальной прорисовки. Затем провели с издателем совместные плей-тесты, выбрали лучший вариант — и его реализовали.
Закрытое бета-тестирование. Перед официальным релизом издатель собрал на своем сайте фокус-группу: всех желающих пригласили поучаствовать в закрытом бета-тестировании. Игроки оставили свои почты, и мы открыли им доступ к игре — до того, как она вышла в магазины мобильных приложений.
Также все бета-тестировщики получили анкету. В ней мы спрашивали, насколько комфортно и интересно было играть. Критических замечаний не было. По результатам опроса мы только немного донастроили управление камерой.
Монетизация. Оригинальная игра Hello Neighbor для ПК платная. Издатель планировал выпускать мобильную версию с такой же схемой монетизации, но мы предложили клиенту другое решение.
Мы много работаем с похожими проектами и знаем: за последние годы мобильные игроки привыкли, что игру можно скачать бесплатно. А монетизируется она за счет встроенных покупок, рекламы или же становится платной, начиная с n-го уровня. Последний вариант нам и показался самым подходящим для Hello Neighbor. Издатель с нами согласился.
Beyond a Steel Sky
Год: 2019.
Команда: 6 человек.
Сроки: четыре месяца.
Клиент: Revolution Software.
Задача: co-dev и портирование с UE4/PC на Apple Arcade.
Этот проект мы делали в со-разработке с издателем игры, британской студией Revolution Software. Команда со стороны клиента создавала версию для ПК, а нам поручили портировать ее для Apple Arcade. Это специальный раздел в App Store с премиальными играми. Если пользователь покупает подписку на Apple Arcade, он получает безлимитный доступ ко всем приложениями, которые там размещены.
В свою очередь Apple платит бонус издателю игры, чтобы его заинтересовать. При этом если проект выходит на Apple Arcade, разработчики не имеют право размещать его в других мобильных магазинах приложений, пока не пройдет оговоренное время.
Главная сложность этого проекта — адаптировать игру для всех мобильных устройств из списка требований Apple Arcade. Самым слабым по техническим характеристикам из них на тот момент был iPad mini 4.
Производительность. В разработке на Unreal Engine используют два подхода:
- код на С++ — его пишут программисты;
- визуальное программирование — его используют гейм-дизайнеры и люди, у которых нет опыта в программировании, так как заскриптовать игровые механики можно с помощью перетаскивания блоков.
Второй вариант чреват потерей производительности приложения. А оригинальный Beyond a Steel Sky как раз и был почти полностью реализован с помощью визуального программирования. Поэтому мы одновременно работали над портированием и консультировали команду из Revolution Software по поводу оптимизации. Было важно, чтобы она не поменялась с точки зрения качества визуала, но стала более производительной.
Сильно менять игровые уровни мы не могли, так как обе версии — для мобильных устройств и для ПК — разрабатывались в одной ветке системы контроля версий. И изменения с нашей стороны повлияли бы и на ПК-версию. Это нас немного ограничивало, но мы нашли компромисс: кое-что оптимизировали и перенесли в специальные уровни, которые доступны только в мобильной версии.
Также мы переделали много оригинальных ассетов — структура проекта это позволяла.
Графика. Оригинальная игра для ПК была стилизована под комиксы, в ней использовались многочисленные эффекты обводки. Мы не могли перенести это в мобильную версию: там большинство таких эффектов просто не поддерживается. Поэтому пришлось переписать почти все шейдеры. Это позволило сразу поднять производительность без видимого ухудшения качества картинки.
Сначала визуальной частью проекта занималась Revolution Software. Но в компании торопились вовремя выпустить версию для ПК, так что ближе к концу проекта всю «визуалку» отдали нам.
В частности, мы переносили освещение. С этим было много нюансов: игра очень атмосферная, с избытком динамического света. Мы не могли себе позволить перенести его на мобильные устройства, поэтому местами «запекали» свет. Пришлось повозиться, чтобы добиться сходства с оригинальным характером освещения.
The Survivalist
Год: 2020.
Команда: 11 человек.
Сроки: пять месяцев.
Клиент: Team17.
Задача: co-dev и портирование с Unity/PC на Apple Arcade.
The Survivalist — это игра в стиле «песочница», в формате пиксель-арт. Здесь нет большого количества геометрии и текстур, все выглядит в духе старых приставок из
Издатель, компания Team17, решил, что проект должен выйти одновременно на всех платформах. Оригинальные разработчики игры занимались версией для ПК, еще одна команда работала над консольными версиями, а нам доверили портирование на iOS/tvOS/macOS для размещения в Apple Arcade.
Apple Arcade подразумевает разработку не только для мобильных телефонов и планшетов, но также для Apple TV и компьютеров с macOS. Эти требования и несут большую часть всех проблем.
Общая код-база. Изначально все платформы — ПК, Switch, PlayStation, Xbox и Apple Arcade — были в одной код-базе и никак не разделялись в системе контроля версий по отдельным веткам.
Команда разработчиков выделила нам отдельную «песочницу», где мы могли экспериментировать со своей версией. Все шло хорошо, пока через полтора месяца разработчики версии для ПК не начали вносить в свой код обновления, которые затронули логику нашего кода.
Опыт показывает, что если в системе контроля версий несколько команд работают над одним файлом, то всегда наступает такой момент, когда одной из команд приходится что-то переписывать заново. Зачастую это приходилось делать нам.
В результате во второй половине проекта мы перешли в режим постоянного мерджа — подхватывали изменения из оригинальной ветки, где идет разработка для ПК, непосредственно в нашу ветку.
Но движок — это не только код. Он генерирует большое количество файлов для хранения разной информации: как выглядит модель, персонажи и так далее. Причем эти файлы создаются в сложночитабельном виде. Если разработка идет в разных ветках, эти файлы зачастую вызывают конфликты при мердже. Поэтому приходилось постоянно принимать чью-то сторону. Мы брали за основу файлы оригинальных разработчиков и обновляли свои.
Производительность. Разработчики The Survivalist решили сделать генерацию всего игрового мира при первом запуске игры — это занимает до 800 Мб. Для большинства платформ это не проблема. Но вот Apple Arcade требовала поддерживать все устройства с версией iOS 13+, включая
Поэтому нам пришлось заняться оптимизацией используемой памяти. Мы урезали некоторые элементы игры, геометрию, графику и дополнительные эффекты. При этом каждое такое изменение нужно было согласовывать с издателем и изначальными разработчиками. Чтобы не оказалось такого, что мы вдруг что-то вырежем, а это окажется фичей, на которой на самом деле держалась вся игра. К сожалению, процесс согласований неизбежно увеличивает время разработки.
Кооперативный режим. Чаще всего игры для нескольких платформ создают с помощью кроссплатформенной разработки. Но в нашем случае каждая платформа использовала нативную реализацию. Для нас как для разработчиков под Apple Arcade одним из таких нативных сервисов был Game Center. Мы его использовали, чтобы реализовать кооперативный режим игры, когда четыре игрока создают общий матч и вместе подключаются к нему по сети.
Проблема Game Center в том, что он уже не очень хорошо поддерживается со стороны Apple. Большое количество функциональности, которую мы хотели использовать, оказалось устаревшим. Другими словами, мы были ограничены только теми решениями, которые предоставляет Apple.
Поэтому нам пришлось сильно изменить систему поиска матча с точки зрения гейм-дизайна: как пригласить друзей, как присоединяться к существующему матчу и так далее. Прежде всего мы отказались от системы, когда у человека есть экран со списком серверов, на которые он может зайти. Оставили два сценария:
- быстрый матч — игрока подбрасывают к другим игрокам случайным образом;
- приглашение от друга — игрок его принимает и подключается к матчу со своим знакомым.
У разных мобильных устройств, которые мы вынуждены покрывать, была разная версия операционной системы — от iOS 13 до iOS 14. И многие фичи Game Center в каждой версии отличались. Это приводило нас к проблемам, когда один человек может найти матч, а другой — нет.
К примеру, четыре игрока сидят в одной комнате. Они запускают игру, вызывают поиск быстрого матча — и находят кого-то с другой страны, но не друг друга. Или же разделяются по парам — но только не присоединяются все вместе к одной игре, как мы бы того хотели. Чтобы решить эти проблемы, пришлось писать «костыли».
Поддержка геймпадов. При разработке управления для игры нужно предусмотреть разные варианты: управление с экрана, джойстиком, клавиатурой и так далее. Для этого используются стандартные фреймворки, которые помогают это все объединить и у себя «под капотом» распределяют управление. Мы получили такое решение от оригинальных разработчиков.
С мая до августа, пока мы портировали игру, Apple Arcade дважды менял свои требования насчет поддержки геймпадов. Сначала платформа требовала поддерживать Standalone-геймпады: джойстик DualShock от PlayStation и Controller от Xbox.
Как оказалось, наш фреймворк не в полной мере поддерживал на iOS-устройствах все кнопки этих геймпадов. Пришлось в обход фреймворков «отлавливать» кнопку Touch на DualShock, а также Option и Select на Xbox Controller.
В июле пришло еще одно требование от Apple Arcade — поддерживать джойстик Nimbus. От других он отличается тем, что у него меньше кнопок. Это серьезная проблема, ведь на других геймпадах все кнопки используются для покрытия игровой функциональности. Поэтому для Nimbus мы ввели комбинацию кнопок. Их мы «отлавливали» тоже в обход фреймворка, перехватывая события.
Вместо итогов: почему интересно портировать игры
Когда люди идут в геймдев, в большинстве случаев они мечтают делать непосредственно игры. Но само написание кода игры занимает примерно полгода, а все остальное время разработчики его шлифуют и реализовывают дополнительные фичи. На это уходит еще полтора-два года.
Портирование — более динамичная сфера. В среднем наши проекты длятся по пять месяцев. Поэтому такие задачи интересны людям, которые не хотят долго сидеть на одном проекте.
К тому же нам каждый раз приходит что-то новое. Разработчики могут увидеть и пощупать разные механики реализации и быстро получить опыт.
А еще нам не приходится работать с играми, у которых нет шансов на успех. Если издатель вкладывает деньги в портирование, значит, игра уже принесла ему прибыль и он верит в ее потенциал на других платформах. И наша команда уже через полгода увидит результаты своей работы: число загрузок, а также отзывы и рейтинг игры в магазинах мобильных приложений.
