5 трудностей реализации игровых проектов на примере “Rocket X — Галактический шутер”

Два года назад мы решили развивать внутри компании игровое направление. S Media Link — аутсорсинговая компания, которая занимается заказной мобильной и web разработкой, поэтому нам было крайне сложно придумать стоящий проект. У меня уже есть опыт создания мобильной игры Карл — король жуков (King of Bugs). Игра была зафичерина на главной Appstore и получила неплохой отклик на конференции DevGAMM. Однако создание мобильной игры — это огромные финансовые и временные ресурсы, из-за чего новый проект приходилось откладывать до недавнего времени. Сейчас наша космическая аркада “Rocket X — Галактический шутер” находится на этапе тестирования и проверок игровых механик и гипотез. Она уже вышла на рынок, а с недавних пор доступна и в России. Мы попали в подборки Аркады и Приключения в Appstore. Этот небольшой, но мотивирующий успех дался нам огромными усилиями, чередой ошибок и трудностей, о которых расскажем ниже.

Изначально мы определили, что задачи будут звучать так:

1. Научиться создавать собственные продукты и доводить их до релиза.

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

3. Самостоятельно пройти все этапы, касающиеся продвижения мобильных продуктов на рынке СНГ и дальнего зарубежья.

4. Научиться продвигать мобильные игры.

5. Вернуть вложенные инвестиции и вывести в плюс проект.

Так как ранее, в случае с King of Bugs, мы подключали к проекту издателя, эти аспекты геймдева так и остались для нас темным лесом. С Rocket X нужно было делать все самим. Игра позиционировалась как инди-проект. И в соответствии с законами жанра, ее команда была небольшой (два постоянных участника), но крайне мотивированной. На наш совместный с другими учредителями компании клич о поиске желающих заняться игровым направлением откликнулся один из разработчиков. У Макса был опыт в геймдеве, а также огромное желание делать игру на Unity. Он настоял на том, что будет выступать и в роли разработчика, и в роли руководителя проекта. Макс взял всю ответственность на себя, тогда как я был в роли консультанта. И здесь мы допустили первую ошибку. Уже через 2 месяца он сообщил, что больше не может разрываться на два направления и решил полностью уйти в разработку в проекте “Rocket X — Галактический шутер”.

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

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

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

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

Внутри инди-проектов особенно сложно удержать взаимоотношения между участниками команды на том уровне, который бы способствовал максимальной продуктивности рабочего процесса. Так получается, что находятся люди, готовые надеть себе на голову если не корону, то шляпу с перьями, провозгласив себя д’Артаньяном, который может то, чего не может никто. Глобально, “д’Артаньян” конечно ошибается, но в рамках маленького коллектива это приводит к тому, что проект разваливается. Прав он или нет — уже не важно. В случае с Рокетом нам удалось избежать подобной ситуации. Во многом благодаря тому, что отношения в коллективе были строго регламентированы — все мы сотрудники одной компании, со своими должностями и со всеми вытекающими. Говорю об этом, потому что с головой окунулся в подобные истории на своем предыдущем проекте. С Rocket X мы этого не допустили.

Разработка арта для игры — это не просто иллюстрация. Здесь мало красиво нарисовать. Необходимо знать огромное количество технических моментов, требования к графике. При разработке дизайна игры мы использовали ресурсы компании. Очень многое приходилось изучать в процессе — путем проб и ошибок, поисков знаний в сети. В рисовании арта для игр действительно частенько нужно хитрить в том, как объединить слои, чтобы избавиться от ненужной прозрачности, которая создаёт лишний вес приложения, как сделать ту или иную анимацию маленьким количеством кадров или совсем заменить ее на ту, которую может сделать движок самостоятельно. Именно из-за технических особенностей нужно уметь держать баланс между красотой и весом картинки, количеством слоев и объектов на одном экране и, в общем, хитрить разными способами, чтобы все мобильные устройства могли беспроблемно воспроизводить игру, а она при этом оставалась красочной и имела большое количество объектов и эффектов. Труднее всего было нарисовать картинку, полностью соответствующую техническим особенностям игрового движка, не потерять общий стиль, красоту и живость изображения.

Этот пункт — скорее совет. Косвенно он является продолжением предыдущего. Возможно это не очевидный и не критичный момент, но очень желательно, чтобы билд весил не более 100 мб. Если он превышает данный объем, то игру будет невозможно загрузить через мобильные сети. Результат — теряем пользователей. Необходимо помнить об этом на протяжении всего проекта. Мы потеряли много времени на оптимизацию графики, чтобы уложиться в заданные параметры. Разумеется, мы помним про подгрузку ресурсов с серверов CDN. Но это дополнительное звено, которое иногда дает сбой, в результате чего получаем возмущенных игроков, баги и, как следствие, потерю интереса. На данном этапе развития проекта мы не хотим перегружать игру дополнительными звеньями и проблемами.

Перечисленные выше пункты — не исчерпывающий список. В сети достаточно статей, где разжеваны и разложены по полочкам все аспекты геймдева — от состава команды до монетизации. Практика же неизбежно преподносит сюрпризы. Перед написанием статьи я не ставил себе задачи озвучить все возможные проблемы, с которыми вы можете столкнуться при разработке мобильной игры. Их было гораздо больше. Это именно те трудности, которые сильно замедлили нашу работу над Rocket X. С ними может столкнуться любая начинающая инди-команда.

#игры #gamedev #инди_игры