В прошлой статье я описал технологии и подходы, которые мы используем при разработке нового мобильного fast paced шутера. Т.к. это была обзорная и даже поверхностная статья — сегодня я копну глубже и подробно расскажу, почему мы решили написать собственный ECS-фреймворк и не стали использовать существующие. Будут примеры кода и небольшой бонус в конце.

В мае вместе с CTO Pixonic Сергеем Ждановым (я — слева, он — справа) посетили Google I/O 2018 в Калифорнии. Хотелось посмотреть на тренды, технологии, пообщаться с разработчиками (я еще собирался поучаствовать в Codelabs, а то в прошлый раз не удалось туда попасть). В целом, если сравнивать с прошлым годом, Keynote был не такой впечатляющий, но все равно есть о чем рассказать по итогам конференции.

Не буду повторять, что и так уже все слышали, а расскажу, что заинтересовало меня, как разработчика мобильных игр, и что будет полезно знать другим. Начнем.

Год назад у нас в компании был один проект — мобильный шутер War Robots с относительно медленными, но красочными и напряженными боями. Игра продолжает развиваться, у нее десятки миллионов установок и игроков по всему миру, постоянно выходят апдейты. В какой-то момент мы захотели сделать динамичный шутер на Unity со скоростями, сравнимыми с Overwatch, CS:GO или Quake. Но реализовать задуманное для мобильных платформ (в первую очередь iOS и Android) на основе War Robots при текущих архитектуре и подходах было практически нереально.

Мы понимали, как это сделать в теории — есть много статей, презентаций на YouTube, детально рассказывающих о том, как написать шутер, как работать с сетью, какие возникают проблемы и как их решать. Здесь нет Rocket Science, все эти подходы придумали еще 30 лет назад и за это время они особо не поменялись. НО: у нас не было практики.

Забегая вперед, скажу — нам удалось реализовать задуманное. Мы создали для мобильных платформ динамичный быстрый шутер, который сейчас находится в бета-тестировании и активно дорабатывается. И мне очень хотелось бы всем этим поделиться. Это первая, обзорная статья с перечислением и кратким описанием практически всего того, что мы используем (прошу не путать с другим нашим проектом в разработке, технологии и подходы в котором похожие, но отличаются в деталях).

С переходом на новый проект на Unity с относительно большой командой разработчиков резко встала необходимость автоматической сборки и доставки приложения на устройства для тестирования. Вот как с этим обстояла ситуация, когда я пришел на проект (под iOS):

1. На отдельной mac-машине проект вручную выкачивался из репозитория (Asset Sever).
2. Вручную (File->Build Settings->Build & Run) запускалась сборка в xCode-проект.
3. Далее в xCode делался архив (Archive).
4. Архив экспортировался в ipa-файл, который вручную загружался в TestFlight.
5. Далее, уже в TestFlight доступ предоставлялся нужным тестерам.

Все описанное выше автоматизируется с помощью так называемой непрерывной интеграции (англ. Continuous Integration, CI). На моих предыдущих проектах для этих целей использовался TeamCity от JetBrains (создателей удобного инструмента рефакторинга кода Resharper). TeamCity (TC) — очень мощный программный продукт, выполняющий цели, поставленные перед системой непрерывной интеграции, на все 100%. Он умеет даже больше. Но речь в статье пойдет не о нем (о нем уже есть статьи на хабре), а о новом сервисе Unity Cloud Build, специально для разработчиков на движке Unity.

UPD. Unity выпустила Unity Cloud Build в свет, а я обновил статью :) Об изменениях и нововведениях читайте ниже.

Часто разработчики добавляют в приложение возможность отослать письмо другу с ссылкой на приложение. Обычно это возможно сделать штатными средствами конечной ОС. При портировании нашего приложения на Android мне пришлось потратить некоторое время, чтобы добавить эту функциональность. В последний раз я работал с языком Java лет 5 назад, и мне не хотелось лезть в дебри написания Android-плагина для Unity, установки Eclipse, сборки jar-файла, настройки AndroidManifest.xml и тд. Мне удалось это сделать на C#, не написав ни строчки кода на Java (если не считать в комментариях). Хочу поделиться с Вами, как я это сделал, чтобы Вы не тратили свое время. При этом указанный в статье метод можно использовать для вызова любого Java-кода.

Недавно наша студия завершила разработку большого обновления — Captain Antarctica: Endless Run — для устройств на iOs. Кропотливая работа над обновлением затронула производительность, которая оказалась очень низкой на слабых устройствах. Я боролся с этим целую неделю и добился как минимум 30 FPS, а также значительного сокращения размера приложения. Хочу рассказать, как я это сделал, ну и как делать не стоит.
Статья пригодится любым разработчикам на Unity (причем не только менеджерам проектов и техническим специалистам, но и просто программистам, художникам и дизайнерам), потому что она затрагивает как оптимизацию на Unity в целом, так и конкретно оптимизацию 2d-приложений для мобильных устройств.

Преамбула

В конце лета прошлого года мы решили сделать продолжение нашей игры Папа Пингвин как полноценную новую игру. Вначале мы хотели лишь слегка изменить имеющуюся идею и выпустить на основе нее более серьезный проект, использующий наши наработки, однако мы недостаточно основательно подошли к вопросам препродакшена и не определили достаточно четко фокус и базовый геймплей проекта с самого начала. В результате игра получилась не такой лаконичной и цельной, как могла бы, а разработка игры затянулась. Причем не все запланированные фичи были реализованы, а в процессе разработки приходилось несколько раз останавливаться, пересматривать полученные результаты и упрощать как саму идею, так и дизайн уровней, интерфейс и т.д. Последние упрощения были сделаны после проведенных тестов и отзывов. В итоге получился именно Капитан Антарктика, а не Папа Пингвин 2. Результатом, откровенно говоря, я не совсем доволен. Хотя игра получилась очень интересной, многое в ней можно упростить и улучшить (что мы и постараемся сделать в ближайших обновлениях).

Встал вопрос о создании новой небольшой игры. И дабы не повторить опыт предыдущей, я сел и написал список требований, которые нужно держать в голове при запуске в производство небольшого проекта для iOS. Конечно, он учитывает, что у разработчиков уже должен быть некий опыт и свои наработки. Без них некоторые пункты не имеют смысла. К тому же, список ориентирован не на все жанры, и во многом определен нашими играми. Но что-то для себя из него, думаю, может почерпнуть каждый.

В свое время, в начале разработки двухмерной игры на Unity3d, мне пришлось перерыть кучу документации, сайтов, проштудировать answers.unity3d.com и forum.unity3d.com на тему: как сделать 2d-игру на этом 3d-движке. Самыми первыми вопросами были: как правильно настроить камеру, как сделать 2d-спрайт так, чтобы он отображал текстуру «пиксель в пиксель». На то время уже существовал SpriteManager (далее – SM) и даже SM2 с его мощной поддержкой редактора. Судьба сложилась так, что я не мог его тогда купить, да и пробной версии не было. В итоге, мне пришлось самому написать несколько полезных скриптов для реализации 2d на Unity3d. О том, как это сделать, пойдет речь в этой статье.

"

В статье «Игра за 2 дня» я на примере проекта Папа Пингвин рассказал о том, как сделать игру для iOS, используя Unity, за двое суток.

В продолжение этой темы — статья о том, каким образом можно малыми силами сделать небольшой мультфильм в поддержку игры. Текст статьи подготовил Алексей Лунин (type_2), наш художественный директор. Данная статья может пригодится маленьким студиям-разработчикам и просто энтузиастам, делающим небольшие игрушки для мобильных (и не только) платформ.

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

Как-то здесь на хабре была заметка о мероприятии про игру за два дня. Предлагалось зарегистрироваться, найти себе команду (всех тех, кого раньше не хватало), вспомнить старые залежавшиеся задумки, укрыться от внешнего мира на два дня и реализовать игру. Идея мне понравилась, и мне сразу захотелось попробовать ее на практике.

Вот что у нас получилось.