Собрать команду мечты, на одном дыхании запилить игру-шедевр, которая взорвет топы. Или, как подобает гению-одиночке, за ночь сконструировать и выпустить в мир игру-феномен, игру — магнит для денег и славы. Как выяснилось в курилке и на разнообразных IT-митапах, подобные темные фантазии терзают не только младшекурсников, но и солидных дядек. Просто им сложнее в этом признаться.

Как быть разработчику, чья карьерная тропа так же далека от геймдева, как Хоббитон от Черных Врат? Отмахнуться от навязчивой идеи и доделать, наконец, ту библиотечку, которая так козырно смотрелась бы в резюме. Но если хоронить собственные мечты — не ваш путь, добро пожаловать под кат. Вас ждет честная история о том, как Пипец от мира IT упражнялся перед зеркалом и набивал синяки. История игры, от набросков до релиза.

От смутных мыслеобразов к готовой концепции

В первом приближении план звучал так: за минимальное время пройти цикл разработки игры, финальный этап которого — выпуск полноценного релиза.

Разумное ограничение времени и необходимость публикации игры способствуют избеганию типовой ловушки, поджидающей нубов в геймдеве: погони за образом «игры мечты»! Чаще всего «идеальная» концепция при конкретизации превращается в неподъемный для инди-команды проект. Сама же идея становится недоделкой, которая рано или поздно будет стыдливо запрятана «в стол».

Во избежание бесславного провала с разработкой симулятора подводных лодок или онлайн 3D-шутера лучше повременить и выпустить простую игру. Между прочим, простота не означает примитивную хелло-ворд аркаду, урезанный клон змейки и другие вариации неиграбельных и неоригинальных поделок.

«Четыре в ряд», ферма с дворецкими, Plants vs. Hamsters… Какую экзотическую идею выбрать в качестве пробного шара? Может, что-нибудь про шары. А так как это первый блин, то пусть игра будет плоской, в 2D. Девиз любых сомнительных мероприятий – меньше рассуждений, сразу к делу. Поэтому первая же относительно вменяемая задумка была зафиксирована. Итак, эскиз дикой смеси бильярда и эарохоккея в сеттинге древней цивилизации:


Концепция игры

Это расстановка шаров (зенгов) в разгаре игры. Игрок целится зенгом-котиком в зенга-крокодила, чтобы забить его в одну из шести луз и лицезреть мощный спецэффект взрыва. Кто первым выбьет с поля все зенги противника, тот и Эцвацепхала (большой молодец). Ах, да. Сеттинг древней цивилизации пока остается за кадром.

Муки выбора: целевая платформа и инструментарий

После того как в общих чертах нарисовалась концепция игры, не составило труда определиться с платформой и инструментарием.

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

Сотрудничество инди-игродела с GOG.com, еще одним гигантом цифровой дистрибуции, начинается с заполнения анкеты об игре. Некоторое время уходит на рассмотрение игры магазином, и риск отказа в публикации довольно высок: игра может показаться недостаточно уникальной, низкопробной или не устраивать по другому критерию…

Здравый смысл подсказывает, с монстрами типа Steam или GOG.com имеет смысл связываться при наличии готового (или почти готового) продукта соответствующего качества. А вот выпуск игры для мобильной аудитории – более быстрый и доступный вариант. Разумеется, я намекаю на Android: единоразовая оплата в 25$ за активацию аккаунта разработчика и доступ в Google Play Developer Console – бюджетнее, чем ежегодные 99$ в копилку Apple за возможность публикации в Apple Store. Аккаунт разработчика Google Play у меня есть с незапамятных времен, и это склонило чашу весов в пользу Android.

Что касается Android, то смельчаки, сворачивающие на скользкую дорожку разработки под эту платформу, часто оказываются на распутье: городить ли игру в Canvas, изучать API OpenGL, либо разбираться с полноценным игровым движком. Для меня выбор даже не стоял: непринужденно возить мышкой в красивом GUI движка – куда заманчивее, чем ночевать в дебаггере и расследовать, почему сцена то не масштабируется, то зависает.

Очевидно, нужно было подобрать движок, удовлетворяющий требованиям:

• Возможность портирования игры для выпуска под Android
• Бесплатность
• Низкий порог вхождения
• Быстрота прототипирования
• Свежая, внятная документация, либо активное сообщество

После некоторых поисков интерес вызвали три движка: Cocos2D, Unreal Engine и Unity. Cocos2D подкупает легковесностью и C++ в качестве языка разработки, но написание игры на нем не обещает быть скоростным. Непростой выбор между Unreal Engine и Unity закончился победой Unity: при первом знакомстве сложилось впечатление, что в этом движке новичку разобраться попроще. Чего стоит хотя бы шикарный онлайн-туториал по созданию 2D-игр!

Для инди-разработчика Unity доступен по тарифному плану Personal, то есть бесплатно. Компаниям же, чей годовой оборот либо объем привлеченных средств превышает 100 000 $, предлагается использовать платную подписку. Что ж, как только, так сразу, а пока запускаем Personal.

О разработке игры в одиночку: куда исчезает время

В результате метаний между разными платформами и движками на компе прописались Unity 2017, Visual Studio Community и Android Studio. Кстати, официальные билды Unity доступны для установки на Linux, и на мой openSUSE Leap установились без особых проблем. Тем не менее, большая часть разработки игры велась под Windows, потому что там есть Photoshop. А единственный разработчик проекта по совместительству является и единственным дизайнером, что привносит в процесс геймдева особую перчинку.

Например, приходилось часто переключаться между двумя задачами: написанием кода и рисованием графики. Как только процесс разработки блокировался необходимостью добавления новой графики на сцену, нужно было все откладывать и заниматься дизайном. Для распараллеливания этих процессов активно использовались изображения-«заглушки», набросанные кое-как и до последнего заменявшие полноценную графику.


Поэтапная проработка графики

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

В любом случае огромное количество арта не войдет в финальную сборку игры, и это нормально. Ибо из тонны неудачных набросков рождается тот, на который все смотрят и говорят: «Да, это она. Та самая альпака».


Та самая альпака

А вот игровое поле после многочисленных итераций переделывания:


Скриншот игрового поля

Получилось, что из 72 часов около 40 было потрачено только на рисование и дизайн. Оставшееся время ушло на цикл разработки-тестирования, ускорению которого поспособствовали три фактора:

Контрольная точка готовности игры к релизу. Игру с каким функционалом не стыдно считать завершенной, готовой к прохождению пользователем, видящим ее впервые? Перестает ли она быть таковой, если отказаться от одной-двух фич? Если бы не заранее составленное и мысленно переведенное в состояние read-only ТЗ, игру можно было бы улучшать и развивать целую вечность. По мере обсуждения с игроками их впечатлений и появления собственных идей новые «хотелки» появлялись чуть ли не ежечасно, тут-то и спасал список фич для контрольной точки.

Отказ от красивого кода. С этим можно спорить, эту практику можно считать вредной как для проекта, так и для разработчика, и с большинством доводов я соглашусь… Но факт налицо: если проект маленький, а время поджимает, то чистота кода отходит на второй план. Главное, чтобы в исходниках по-прежнему можно было разобраться. А спагетти-код и жирная копипаста не так уж вредны, если не заказывать двойную порцию.

Полигон для обкатки деталей. На взрыв потрачено порядком времени, а он все еще не тянет на премию за лучшие визуальные эффекты? Странности в анимации спрайта стали видны только сейчас, потому что другие объекты перетягивали на себя внимание? Отладка сложных участков, тюнинг спецэффектов, прогон анимации… Для подобных мероприятий хороший подход — максимально обособить интересующий блок и вынести его в чистый проект (или как минимум в отдельную сцену). Во-первых, это исключает побочное влияние на него других игровых сущностей. Во-вторых, помогает сконцентрироваться на текущей задаче, экспериментировать без риска накосячить и поломать что-то по соседству. Например, в отдельной сцене удобно было настраивать параметры эффектов взрывов при попадании зенга в лузу, а в тестовом проекте подбирать варианты текстурирования фона.

Ошибки, так и не ставшие фатальными

Бескомпромиссные падения на открытом бета-тестировании, null reference ¬- пасхалочки возле строк с фразой «//TODO», ускользающие, как вода сквозь пальцы, баги… Печальный факт: большинство ошибок – следствие невнимательности и недостаточного владения инструментом. У Unity подробная документация, и это неспроста. Многие технические решения Unity не очевидны. Забивание на документацию порождает лишние часы отладки и блуждания по гуглу… который возвращает к онлайн-документации.

Дамы и господа, перед вами «Топ-3» самых смачных и затратных про времени ошибок, украсивших процесс разработки El Zengo. Они любопытны тем, что являются частными случаями типовых проблем, возникающих при быстрой разработке отсутствии времени на подробное изучение предметной области.

3. Оно не работает как я хочу

Оох, сколько же времени было убито на отладку моделирования столкновений зенгов… Конечно, в Unity весь расчет движения тел работает «из коробки». И в сыром прототипе игры это жадно эксплуатировалось: зенги катались по сцене с нулевой гравитацией, отскакивали друг от друга и от бортиков, и вопрос об их траекториях после столкновений не стоял. Но настал ответственный момент отрисовки векторов зенгов, и внезапно вскрылось, что фактическое отскакивание зенгов друг от друга (серая дуга на скриншоте) отличается от ожидаемого (белая линия):


Ожидаемая и фактическая траектории отскакивания зенга

Зенг отклонялся от намеченного пути из-за слишком сильного трения и возникающего из-за него момента кручения, причина которого до поры оставалась загадкой. Дело в том, что каждый зенг – это сгенерированный при загрузке сцены gameObject, к которому добавлены компоненты Rigidbody 2D и Circle Collider 2D.

Rigidbody, «твердое тело», определяет физику поведения объекта в игровом мире: массу, сопротивление, гравитацию и другие полезные характеристики. Collider – компонент, ответственный за расчет границ объекта и столкновений с другими телами. У обоих компонентов присутствует свойство «материал» для задания коэффициента трения и упругости.

Итак, исправление некорректного отскакивания зенгов свелось к вопросу: если к gameObject привязаны два компонента, Collider и Rigidbody, и у каждого из них есть свойство «материал», то какой из материалов применится?


Свойства «Материал» у Collider и Rigidbody в Unity

Так вот, если у Collider не задан материал, то применяется материал Rigidbody. Если же задан, то приоритетнее свойство Collider’а. При не указанном явно материале Rigidbody используется материал со значениями упругости и трения по умолчанию. Таким образом, ошибка заключалась в ошибочном предположении, что применится свойство Rigidbody с околонулевым трением при указанном материале Collider. И стоила она потраченного вечера субботы.

2. Оно ведет себя по-разному на разных устройствах

Различное поведение на устройствах с разными версиями API проявилось невзначай, при отрисовке теней текста. На сцену был добавлен текст с названием игры. К тексту прицеплен компонент «Тень»:


Компонент «Тень», добавленный к тексту в Unity

Темный цвет, прозрачность. Отлично оттеняет текст на всех устройствах… кроме старенького Android с API 15, на котором тень упорно выглядела бледно-голубой вместо синей:


Некорректно отрисованная тень в интерфейсе игры

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

Вывод: сохраняйте бдительность. На разных устройствах даже тривиальные элементы игры могут выглядеть и работать по-разному. Это зачастую проявляется в труднозаметных мелочах.

1. Оно не запускается на конкретном девайсе

В ночь перед релизом (или как принято начинать такие истории?) было обнаружено, что на одном из смартфонов игра принципиально не хочет стартовать. Пришлось срочно цеплять отладчик и смотреть, что же пошло не так.

По замыслу игра принудительно запускается в альбомной ориентации. В Unity 2017 за это отвечает настройка Default orientation (Edit -> Project settings -> Player -> Orientation):


Настройка ориентации экрана в Unity

При экспорте в проект для Android Studio настройка Default orientation превращается в свойство screenOrientation, указанное в манифесте:

android:screenOrientation="landscape"

Казалось бы, что может пойти не так? И действительно, на всех устройствах полет нормальный… Кроме Android 8.0.0 (API 26), на котором приложение при запуске падает с исключением:

java.lang.IllegalStateException: Only fullscreen opaque activities can request orientation

Чинится отключением прозрачности в стиле, указанном в styles.xml:

<item name="android:windowIsTranslucent">false</item>

Абсолютно случайно обнаруженное падение, наталкивающее на мораль: корректность работы нужно проверять на всех поддерживаемых приложением API.

О раскрутке и монетизации, или «Сегодня я многое понял»

После подготовки толстой пачки промо-материалов для размещения в магазине Android, под радостные выкрики программиста и дизайнера состоялся релиз. Однако вскоре выяснилось, что кроме как по названию игру в Play Store отыскать невозможно. El Zengo, будто затонувший галеон с золотыми дублонами, покоился где-то на дне океана игр и ждал своего водолаза… Судя по всему, настолько глубоко водолазы не погружаются.

Нулевое количество скачиваний за неделю шло в разрез с ожиданиями. Ремарка: ожидания не были беспочвенными фантазиями, а основывались на реальном, хоть и устаревшем опыте. В далеком 2014 году, когда Google Play активно разрастался и заманивал новых разработчиков, автором была опубликована ни на что не претендующая логическая игра. И хотя главной целью публикации было личное использование для партий с друзьями и коллегами, а дизайн оставлял желать лучшего, дела у игры пошли на удивление гладко. Она маячила в разделе с новинками, откуда переползла в топы игр по категории в России и странах ближнего зарубежья. И все это без малейших усилий.

С тех пор Google Play переполнился приложениями, разработчики начали выкладывать огромные суммы за эвакуацию со дна продвижение в топ, а попытки сделать игру известной, чтобы для начала потенциальный пользователь мог бы ее хоть как-то найти, уперлись в бизнес.


Слон Бизнес. Князя ждет незапланированное приключение

Фирмы, предлагающие услуги по раскрутке, видео-обзоры от ютюберов, рецензии на геймерских порталах, реклама на разнообразных площадках… Если вы категорически не отметаете платное продвижение, то будете приятно удивлены количеством способов с шиком избавиться от парочки зарплат. Но насколько они результативны, в каких комбинациях и пропорциях дают наилучший эффект для конкретной игры? Вопрос остается открытым.

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

Эпилог

Реально ли за пару месяцев выпустить игру самому или небольшой командой, не в ущерб работе и личной жизни? И чтобы без самопреодоления и «триумфа воли» над недосыпом. Да, вполне! А с использованием современных движков, IDE и stackoverflow это легче, чем когда-либо.

Но если разработка инди-игры – не самоцель, и встают вопросы о ее продвижении и монетизации, то… есть нюансы. Раскрутка – монстр о трех головах: отдельная наука, в которой небольшой просчет – уже убыток; непрерывный процесс, нуждающийся в неустанном контроле; черная дыра для времени, сил и денег.

И напоследок. Инди-разработка – это не только код, графика и курс геометрии, который неплохо бы перечитать. Это еще и общение с увлеченными людьми, готовыми оставлять фидбэк и даже участвовать в проекте на чистом энтузиазме. Например, тонну советов и критики по геймплею и UI дал разработчик, в целом с прохладцей относящийся к казуальным времяубивалкам. А музыку ко второй версии El Zengo создал композитор, которому игра пришлась по вкусу. Если поднапрячься и поискать, обязательно найдутся желающие потестировать игру и оставить ревью. А при удачном выборе инструментов и соблюдении нехитрых правил фан от разработки, окрыленность релизом и неслабая прокачка опыта просто обеспечены.