Разработка
Rocket X: как мы собирали команду на игровой инди-проект
Создание мобильной игры требует огромного количества времени, ресурсов, в том числе (и особенно) финансовых, качественной команды разработчиков и менеджеров. Понимая это, мы, внутри нашей компании S Media Link, долго ждали подходящего момента. Так получилось, что все это стало возможным два года назад. У меня уже был опыт создания мобильной игры — King of Bugs, но оставалась одна проблема — у нас не было готовой команды. Зато среди разработчиков компании были желающие делать игры на Unity. Так мы решили убить двух зайцев — “прокачать” наших сотрудников, передать им опыт и открыть наконец-таки игровое направление, о которым мы думали с момента появления S Media Link.
Изначально мы определили, что задачи будут звучать так:
- Научиться создавать собственные продукты и доводить их до релиза.
- Научить и подготовить команду разработчиков, художников и других специалистов в геймдеве.
- Самостоятельно пройти все этапы, касающиеся продвижения мобильных продуктов на рынке СНГ и дальнего зарубежья.
- Научиться продвигать мобильные игры.
- Вернуть вложенные инвестиции и вывести проект в полный плюс.
Т.к. ранее, в случае с King of Bugs, мы подключали издателя, эти аспекты геймдева так и остались для нас темным лесом. В Rocket X нужно было делать все самим.
1. Руководитель/разработчик
Игра позиционировалась как инди-проект, и, в соответствии с законами жанра, ее команда была малочисленна (два постоянных участника), неопытна, но крайне мотивирована. На наш совместный с другими учредителями компании клич о поиске желающих заняться игровым направлением откликнулся один из разработчиков. У Макса был опыт в геймдеве и огромное желание делать игру на Unity. Он настоял на том, что будет выступать и в роли разработчика, и в роли руководителя проекта. Макс берет всю ответственность на себя, а я выступаю в роли коуча, консультанта. И здесь мы допустили первую ошибку. Уже через 2 месяца он сообщил, что больше не может разрываться между назначенными ролями и решил полностью уйти в разработку.
Более того, незадолго до нашей поездки в Минск на Devgamm с первой версией игры, я попросил своего знакомого сделать код-ревью. Результат: ошибки в архитектуре. Сказался недостаток опыта и времени на получение компетенций. Так мы потеряли полтора месяца на рефакторинг проекта.
Сейчас мы понимаем, что менеджер проекта должен заниматься именно менеджерским задачами (он должен думать на 3-4 шага вперед). Объединить в одном лице управленца и разработчика (еще и без опыта) — не самая лучшая идея.
2. Дизайнеры
Дизайнеры стоят дорого. Даже (или особенно) если это дизайнеры твоей компании. В работе над игрой участвовало несколько специалистов. Так как мы аутсорсинговая компания, выдергивать сотрудников пришлось с платных проектов. Это большая проблема. Во-первых, необходимо время, чтобы вникнуть в проект, а во-вторых, подстроиться под стиль предыдущего дизайнера, тем более что видение игры постоянно менялось. Нарисовать планеты, космические корабли, звезды так, чтобы игрок не заметил участия в процессе разных людей — это возможно, и у нас это получилось. Только специалист, при детальном рассмотрении, может понять, что разные элементы дизайна созданы в разном стиле.
Разработка арта для игры — это не просто иллюстрация. Здесь мало красиво нарисовать. Необходимо знать огромное количество технических моментов, требования к графике. При разработке дизайна игры, мы использовали ресурсы компании, однако опыта в геймдизайне у наших сотрудников не было. Очень многое приходилось изучать в процессе, путем проб и ошибок, поисков знаний в сети. В рисовании арта для игр действительно частенько нужно хитрить в том, как объединить слои, чтобы избавиться от ненужной прозрачности, которая создаёт лишний вес приложения, как сделать ту или иную анимацию маленьким количеством кадров или совсем заменить покадровую анимацию с использованием спрайтов анимацией, которую может сделать движок самостоятельно. Именно из-за технических особенностей нужно уметь держать баланс между красотой и весом картинки, количеством слоев и объектов на одном экране и, в общем, хитрить разными способами, чтобы все мобильные устройства могли беспроблемно воспроизводить игру, а она при этом оставалась красочной и имела большое количество объектов и эффектов. Труднее всего было нарисовать картинку, полностью соответствующую техническим особенностям игрового движка, не потерять общий стиль, красоту и живость изображения.
Вывод: с самого начала необходимо разработать дизайн документ при участии опытного геймдизайнера, который в дальнейшем будет в проекте на постоянной основе.
3. Level-дизайнер/Расширение команды
После софт ланча Rocket X в Канаде мы решили привлечь к работе над игрой Марка — одного из разработчиков компании, которому был интересен геймдев. Так мы надеялись получить свежий взгляд со стороны. Он сделал несколько уровней, результат нам понравился, и мы взяли его на парт тайм. Теперь в нашей команде были не только руководитель, разработчик и несколько сменяющих друг друга дизайнеров, но и level-дизайнер. Это было правильное и своевременное решение, так как уровни стали более интересными и самодостаточными.
4. Не издателем единым
Идеально, если в команде есть продюсеры, сценаристы, звукорежиссеры, музыканты и прочие позиции, о которых скорее привычно читать в титрах высокобюджетного сериала. В геймдеве все эти люди тоже имеют место быть. Более того, сложно найти статью в интернете, где бы ТОП-менеджеры крупных игровых студий или издатели не говорили о том, что без этих людей невозможно ничего сделать в принципе. Но в случае с Rocket X, мы не могли позволить себе такую роскошь. Режиссера и копирайтера привлекали по мере острой необходимости. Уверены, что с продюсером (или вовсе с издателем) нам удалось бы избежать многих ошибок, но мы поставили перед собой задачу — вывести Rocket X на рынок полностью самостоятельно. Это больно, но полезно, если у вас грандиозные планы и ограниченные ресурсы.
5. Как строить работу
Особенность инди-проектов — это небольшое количество участников (до пяти человек, в случае с Rocket X — три). С одной стороны, сделать большой проект с такой командой сложно, с другой — высокая гибкость рабочего процесса. В начале и в конце каждой недели мы проводили собрания, работали по SCRUM, ставили спринты, формировали требования к ним, в пятницу подводили итоги, а иногда пили пиво. Собирали билды (спасибо функционалу Unity за это) и вносили корректировки быстро.
Еще одно преимущество инди-проекта — высокая вовлеченность. Разработчик и дизайнеры задерживались на работе до тех пор, пока не была закрыта задача, до 11-12 часов. Непосредственно перед софт-ланчем в Канаде нам и вовсе пришлось просидеть в офисе сутки. Для этого не приходилось задействовать мотивировать или давить на членов команды. Это органический процесс, который присущ многим разработчикам, как бы не хотелось его избежать.
В конечном итоге можно выделить одну мысль: команда под игровой проект должна иметь опыт и навыки в конкретной сфере деятельности. В противном случае — смело закладывайте риски в 50%.
