Советы для молодых разработчиков, желающих собрать команду и создать игру
Автор: arte_de_mort
Последние два с половиной года я активно занимаюсь созданием игр как инди-разработчик. За это время накопилось много опыта, в том числе полученного путём хождения по граблям. В этой статье я хочу поделиться своими наблюдениями насчёт того, как правильно подготовиться к созданию игры, как лучше собирать команду «на энтузиазме», как организовать работу, расскажу о некоторых подводных камнях. Этот материал также является следствием наблюдения за пользователями, готовящимися делать свои первые проекты. Подавляющее большинство быстро разочаровывается в игрострое — в процессе работы допускает критический уровень ошибок, и неизбежно забрасывает своё детище. Особенно обидно, если такое происходит с действительно талантливыми людьми.
О подготовке к работе
Об оценке рисков
О сборе команды «на энтузиазме»
Об организации работы
О руководителе
О деньгах
В качестве заключения
О подготовке к работе
Этот этап принято называть «пре-продакшн» (pre-production), про него все знают, но часто забывают, не осознавая его критически важной роли в судьбе игры. Практически все люди, ищущие компаньонов на нашем форуме [речь о GameDev.ru, разумеется], допускают эту ошибку раз за разом. Если вы загорелись желанием создать собственный игровой проект, то первым делом я предлагаю создать «питч-документ», или «концепт-документ». Это короткий, на несколько страниц, текст, где изложена суть продукта. Вот примеры тем, которые должны быть описаны: поддерживаемые платформы, целевая аудитория, способы монетизации, основной геймплей (также именуемый core gameplay), уникальные фичи (unique selling points), непосредственные конкуренты и так далее. Этот документ будет вашей путеводной звездой. Если вы начнёте неосознанно дрифтовать от него в сторону — у вас, вероятно, проблемы. Однако хочу предостеречь. Пока занимаетесь этой работой, постоянно задавайте себе вопрос: «Что из написанного мною является непроверенным фактом?». Допустим, вы утверждаете: «Мой 3d-шутер с гигантскими человекоподобными роботами и орбитальными ионными пушками рассчитан на женскую аудиторию 25—60 лет, и будет публиковаться в первую очередь в «Одноклассниках». Тут вы задаёте себе указанный выше вопрос, и идёте в любимый поисковик собирать информацию, чтобы подтвердить, либо опровергнуть заявленное вами утверждение.
Следующим этапом будет постановка ориентировочной даты релиза. Как известно, работа занимает всё выделенное на неё время, следовательно дедлайн должен помочь избежать этой ловушки. Подумайте и решите сколько времени вы готовы потратить на разработку игры. К слову, «зная себя, за полгода мне этот проект надоест, и я захочу новый», - это достойное обоснование даты релиза. Если вы хотите завершить разработку через 6 месяцев, то нет смысла придумывать десятки навороченных фич, вы всё равно не уложитесь в срок. Это подводит нас непосредственно к оценке объёма предстоящей работы. Тут вы берёте весь проект, и начинаете методично раскладывать его на составные части. Вам нужно получить представление о том, как много кода придётся написать, сколько арта нарисовать, каких персонажей заанимировать... Чем детальнее и продуманнее ваш план работ, тем точнее вы можете оценить необходимое для выполнения задач время. Не забывайте, что вы не робот, вам понадобятся перерывы в работе, либо вынужденные (например, болезнь), либо просто передохнуть, ведь вы не хотите перегореть. Учтите это в своих планах.
В качестве упражнения могу предложить сделать такую вещь: берём готовую игру, похожую на ваш будущий проект, и начинаем её активно разбирать на детальки. К примеру, вы можете пройти первый уровень игры и посчитать, сколько там использовано моделей, текстур, декалей, 3д-анимации, уникальных шейдеров, спецэффектов, анимации GUI и так далее. Это может открыть вам глаза на реальный объём проделанной авторами работы. Откровенно говоря, даже опытный разработчик может недооценить сколько труда вложено в игру, пока не начнёт внимательно приглядываться к ней.
Об оценке рисков
Далее я предлагаю оценить все возможные риски. В действительности я ни разу не видел, чтобы кто-то из энтузиастов этим занимался. Скорее всего, люди считают это слишком серьёзным подходом, скучной бюрократией. Конечно, если игра делается исключительно как хобби — не забивайте голову. Но если успешный релиз для вас важен, я бы советовал не пропускать этот шаг, и хорошенько его обдумать. Что такое риски? По своей сути это список того, что может пойти «не так». Например, на этапе пре-продакшна вы решили, что помимо вас, программиста, в проекте нужен художник для рисования пиксель-арта и анимации персонажей. А что если вам не удастся найти художника? Что будете делать тогда? Закажите графику за деньги? Сделаете самостоятельно, тем самым урезав время на программирование? А если художника найдёте, но он не умеет анимировать? Будете искать ещё аниматора на энтузиазме, или готовы выделить на это деньги и нанять специалиста?
Другой пример: вы планируете запустить игру на Steam Greenlight, вся ваша маркетинговая стратегия строится на этом. Что, если этот сервис закроется и будет полностью заменён системой Steam Curation и самиздатом? Какие изменения вам потребуется внести в вашу работу, в частности, в план продвижения проекта? Таким образом вам нужно постараться предусмотреть все возможные проблемы и составить план «Б» на случай, если всё пойдёт по худшему сценарию. К тому же такой глубокий анализ может показать вас в хорошем свете перед потенциальными коллегами, не стоит пренебрегать такой возможностью.
О сборе команды «на энтузиазме»
Этот раздел основывается как на моих наблюдениях за российским и зарубежным геймдевом, так и на собственном опыте - мне удалось собрать команду из 5 профессионалов, причём заметно больше людей проявляли интерес к совместной работе, но мы не сошлись во взглядах на те или иные вопросы.
Первым шагом в формировании команды является серьёзный подход к пре-продакшну. Допустим, если вы зовёте к себе 3d-художника, то у вас уже должны быть готовы чёткие задачи, по которым он может незамедлительно начать работу. Вы не можете просто взять к себе человека, и сказать ему: «Э, ну, в общем, нам замок нужен, замок, — это с башенками который, сделаешь, не?». Вам нужно заранее продумать, сколько в замке понадобится моделей стен, пролётов, ворот, башен и проч. Также потребуется детальное техническое задание, указывающее требования к количеству треугольников на модели, текстурным картам, раскладке UV, и любую другую релевантную информацию. Если вы будете давать необдуманные задания, и не дай бог человеку придётся что-то переделывать из-за вашей ошибки — быть беде. Больше всего люди не любят выбрасывать свою работу на ветер.
Энтузиасты, уже обладающие неплохими профессиональными навыками, в свою очередь тоже (не)осознанно оценивают риски, просматривая объявления о сборе команд. Они изучают насколько автор заинтересован в своей собственной игре, не бросит ли её на полпути, умеет ли он вообще что-то делать или будет обузой? Если их что-то смутит (а они могут даже не понять, что это было), то пройдут мимо просто потому, что не хотят тратить бесчисленные часы на мертворождённый проект. Лично я бы посоветовал (а я поступал именно так) сначала в одиночку сделать существенный кусок работы, чтобы показать серьёзный настрой. Практически в каждом посте о сборе команды, что я видел, автор не демонстрирует абсолютно никаких наработок, а если и показывает, то какие-то ничтожные крупицы. Так не пойдёт. Я бы сказал, в зависимости от вашего уровня, для начала может быть достаточно вложить порядка 100—200 часов качественной работы. Ещё я бы отметил, что сценарий/сюжет/диздок сами по себе не имеют никакой ценности. За редким исключением, имея на руках только это, команду не собрать. Однако если вы гейм-дизайнер или руководитель проектов с реальным боевым опытом, то ваши шансы резко возрастают. Правда за всё время я видел всего 1 или 2 таких предложения, но они действительно выделяются своим профессиональным подходом.
Подбирая себе команду, помните, что люди — это самое главное в любом начинании. Процессы и методологии, документация, даже профессиональные навыки — всё это вторично (в разумных пределах). Если претендент на определённую роль в проекте недостаточно хорош как профессионал, но действительно работящий человек с горящими глазами, то это вполне может быть как раз то, что вам нужно. Прокачать навыки можно всегда, но изменить мировоззрение состоявшейся личности — практически нереально. В самом первом моём проекте, который быстро потерпел фиаско в первую очередь из-за отсутствия грамотного пре-продакшна, я работал в тандеме с программистом, который теперь является моим другом, хотя мы никогда не встречались в реале. Мы могли сесть за работу утром, переписываясь в скайпе, и вместе работать до поздней ночи, постоянно выдавая ощутимый результат. Целеустремлённость, желание добиться чего-то большего, внутренний драйв — командная работа с таким человеком по-настоящему окрыляет.
Об организации работы
Будучи человеком, который помимо непосредственно создания контента, занимался гейм-дизайном и координацией всего производственного процесса, хочу поговорить и об этом.
Не недооценивайте количество гейм-дизайнерской, организаторской, административной работы. Я объединяю все эти вещи в один раздел исключительно потому, что вы вряд ли найдёте себе в команду и гейм-дизайнера, и руководителя проекта, а вот совместить эти обязанности в одном человеке очень даже неплохой вариант. Работы этого типа вам придётся проделать неожиданного много. Однако это не является оправданием вашей лени, и не даёт вам право взять себе титул «executive producer», который будет только сидеть да раздавать приказы плебеям. Если кто-то пойдёт на форум создавать тему в стиле «я буду управлять проектом, ведь это целая куча работы, ищу себе исполнителей!», то он совершенно не понял смысла данной статьи.
Тому, кто будет координировать команду, я советую почитать пару книг по управлению разработкой программных продуктов. Хорошие книги всегда на виду, найти их не составит труда. Например, Том Демарко, «Роман об управлении проектами», читается очень легко, написано увлекательно, подаётся как художественная литература, а не учебное пособие. Теперь предлагаю постараться разобраться, чем же занимается в инди-геймдеве руководитель проекта. Если в двух словах, то основные цели такого человека — это проследить, чтобы задачи выполнялись, а люди были максимально довольны и мотивированны на работу. Управляя проектом, вы берёте на себя ответственность за эти сферы. Вы — якорь, на вас всё держится. Если вы ленитесь и пропадаете, то будьте уверены, ваша команда тоже станет бить баклуши. Стоит заметить, что в этом кроется фундаментальное отличие работы «за идею» от работы «за зарплату». В коммерческой разработке правильно построенные процессы и корректно делегированные полномочия позволяют руководителю избежать участи единственного связующего звена, без непосредственного участия которого всё рушится.
Скорее всего либо вы сами не захотите, либо у вас просто не получится найти в проект грамотного управленца, но есть смысл поискать хотя бы консультанта, у которого можно изредка просить совета, это может помочь избежать грубых ошибок. Как в России, так и на Западе многие не любят менеджеров, и не зря, однако если вам приходилось работать с профессионалом, вы знаете насколько он может упростить вашу работу, сделать её приятнее и эффективнее.
О руководителе
Вот некоторые обязанности, которые может выполнять руководитель в инди-проекте. Это убедит вас, что работы по-настоящему много, и если ей займётся, например, программист, то кода он напишет значительно меньше.
- Координация разработчиков. Со стороны может и не заметно, но рабочее общение отнимает бездну времени, особенно если основная его масса протекает в текстовом чате. Тут 10 минут обсудить вопрос, там 10 минут... вот и выходит, — вроде бы ничего не сделал, а времени ушло — мама не горюй! К тому же не забывайте, что чем больше ваша команда, тем больше времени потребуется на организацию.
- Организация проекта в целом, то есть: поддержка документации в актуальном состоянии, ведение трекера задач, отслеживание их актуальности и приоритета, работа с продакт бэклогом, и проч.
- Ведение scrum митингов, спринтов, демо, ретроспективы. Об этом подробнее напишу ниже.
- Исследования. Например, вам нужно продумать стратегию монетизации продукта. Это потребует поиск и анализ информации — статей, статистики, видеозаписей с конференций. Этим, конечно, может заняться кто угодно в команде, но не факт, что, скажем, программисту это вообще интересно («Я программист, я не хочу читать про f2p, я хочу программировать»).
- Маркетинг. Чёрная дыра, пожирающая всё ваше время. Сюда входят такие вещи, как: создание пресс-кита, общение с прессой, статьи в блог, ведение аккаунтов в соцсетях, договоры о кросс-маркетинге с другими командами, и прочее.
- Поиск новых сотрудников. Может занимать много времени, в зависимости от желания. Начиная с простых рекрутинговых постов на форумах и заканчивая самостоятельным поиском отдельных людей с попытками связаться с ними.
- Менторство. Например, в моей команде был совсем начинающий 3d-художник. Бесчисленные часы прошли в обсуждениях рабочего пайплайна, тонкостей создания моделей и текстур для реалтайма (например, почему в движке у модели вершин больше, чем в 3d редакторе), на фидбек и т. д.
- Юридические вопросы. Скажем, создание аккаунтов в мобильных маркетах, их верификация, налоги и проч. Бюрократия может принимать пугающий вид.
Кстати, ещё насчёт сроков. Вы можете иметь строгие дедлайны для самого себя, но для команды надо искать более мягкие решения. Ведь в жизни всякое бывает: сегодня после работы артисту надо съездить с дочкой в кружок, завтра — на работе завал, а послезавтра — пятничный отдых в баре. В итоге неделя выдаётся не особо продуктивной, и если бы был жесткий дедлайн, то он был бы провален. А это ведёт к конфликтам и падению мотивации. Исходя из своего опыта, я бы предложил очень мягкий scrum. Вы берёте 2-3 недели на спринт, выбираете задачи, которые исполнители точно смогут выполнить, даже если будут гулять по пабам, и работаете. Иными словами, вы изначально делаете щедрую поправку на коррективы, которые вносит жизнь. В конце спринта, разумеется, демо и ретроспектива. Но не надо бюрократии: никаких поинтов, никакого велосити, только здравый смысл, помноженный на количество свободного времени у участников.
Про софт есть много различных статей с детальным анализом плюсов, минусов, особенностей. Советую почитать. А что касается меня... Для командной работы мне нравится Trello, а вот программисту из моей команды — Asana. Чтобы отслеживать собственную (не групповую) продуктивность, я использую Pivotal Tracker, — изумительный инструмент, если вам нравится разбираться с вашим to-do list в ритме agile.
О деньгах
Большинство проектов на энтузиазме делается с расчётом на то, что участники получат процент от потенциальной прибыли. Здесь, в общем-то, всё просто и понятно. Но мне хочется обсудить краудфандинг. Откровенно говоря, в контексте сбора команды он меня раздражает, потому что чаще всего является (не)осознанным обманом. Если процент с потенциальной прибыли — тема известная, и ваши партнёры понимают, на что идут, то краудфандинг — вещь сравнительно новая, и позволяет обвести вокруг пальца человека, не особо следящего за событиями индустрии. Это совсем не значит, что таким мошенничеством занимаются все поголовно, но это и не редкость.
На бумстартере, как известно, практически нереально собрать деньги. На кикстартере с каждым днём становится всё сложнее — люди разочарованы, много низкосортных продуктов и бессовестного кидалова. Реальный шанс собрать достаточно денег есть исключительно у проектов, имеющих обширную базу наработок, качественного арта, зажигательного трейлера и красивой музыки. Иными словами, если человек на форуме собирает команду «сделать демку по-быстрому и пойти на кик», то стоит отнестись к нему с подозрением. Будьте аккуратны с такими предложениями. Исключения, конечно, тоже бывают. Тот же Superhot, пришедший с геймджема, собрал кучу денег на демке, но вероятность такого везения бесконечно мала, так что нет смысла даже надеяться (возвращаясь к теме рисков).
В качестве заключения
Надеюсь, что статья кому-то покажется полезной. Особенно хочется увидеть больше перспективных начинаний в разделе «Проекты». Если подходить к созданию игр не как к фантазии, а как к серьёзной работе, то и результаты будут на порядок лучше, чем имеющиеся на сегодняшний день.
Напоследок хочу напомнить, что у каждого из нас есть «игра мечты», тот большой проект, который мы жаждем реализовать. Как правило, начинать свой путь инди-разработчика с такой работы крайне сложно. Поэтому, читатель, задумайтесь над созданием нескольких маленьких игр, а дальше, имея достойный опыт за плечами, приступайте к «игре мечты». К слову, бытует мнение, что способность доводить начатое до конца, в том числе игры, - это навык, который можно прокачивать. Поэтому разработка маленьких игр до "игры мечты" поможет вам и на этом поприще.
Если есть желание обсудить затронутые в статье проблемы, то не стесняйтесь либо писать комментарии к статье, либо обращаться через личные сообщения напрямую к автору.
#геймдизайн, #indie, #основы, #создать игру, #управление проектами
15 января 2015