О командной работе в геймдеве

С прицелом на инди.

О чем эта статья?

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

Кроме этого, я буду очень много говорить о том, почему важно анализировать личные качества людей в начале пути, и только затем профессиональные знания и навыки.

В статье представлена точка зрения человека, который участвовал в различных гейм-джемах, хакатонах и разработке инди-игры (на протяжении почти 2 лет). Она может не совпадать вашей и даже вызвать ненависть. Теперь к делу.

О поиске людей в команду

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

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

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

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

Про поиск талантов

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

Если вас терзают сомнения после беседы, то поговорите ещё и уточните те моменты, которые показались неясными и даже пугающими. Смысл в том, чтобы выяснить, что вас отталкивает от совместной работы, а что - притягивает к ней. При значительном перевесе первого - проходите мимо. Сэкономите время обеих сторон и сбережете нервы. Разработка игры - не спринт, а марафон.

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

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

Про поиск команды

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

Если на первый взгляд всё хорошо, то начните узнавать информацию о тех сторонах проекта, которые вам интересны. Попросите рассказать о том, почему именно эта игра. Если в ответ - негатив и/или нежелание разговаривать - проходите мимо. Если в ходе диалога вы постоянно слышите “Я сделал фичу Х!”, а не “Мы сделали фичу Х!” - проходите мимо, особенно когда в команде уже 2-3 человека. С заносчивыми людьми работать себе дороже. Если от вас начинают требовать что-нибудь в самом начале (например, подписать мутные документы о неразглашении) - проходите мимо. Руководствуйтесь здравым смыслом, он вас не подведет. Если у разрабатываемой игры есть демка, то уточните, как команда собирается исправить все те моменты, которые выглядят откровенно плохо. Спросите про планы по рекламе игры.

Отдельного упоминания заслуживает общение на счет авторских прав. Уточните, как будет решаться юридический аспект, следите за реакцией. Тут важно четко понять, нет ли в команде отношений вроде “Я придумал - значит мне как минимум всё”. Если такое есть, то прощайтесь без лишних мыслей. Так ничего не работает. Идеи дешевы, бывают довольно бесполезными и, более того, вредными по отношению к финальному качеству продукта. Очень многое в результате сводится к реализации через кропотливую совместную работу.

Выяснили что-то, что вас серьезно отталкивает от совместной работы? Не пробуйте кооперироваться.

О распределении обязанностей и ответственности

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

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

Также такое распределение сильно помогает в поисках других талантливых людей, так как вы всегда знаете, что у вас получается делать хуже всего. За примером далеко ходить не надо: маркетинг почти всегда является большой болью для инди-команд. Обычно им занимается один человек, знакомый с ведением каналов в разных социальных сетях. Если у вас его нет, то это повод задуматься.

Если вам удалось распределить обязанности, не спешите расслабляться. Распространена ситуация, когда гейм-дизайном занимаются все (да-да!). Подводный камень в том, что вам всё равно нужен алгоритм разрешения спорных вопросов. Очень хороший вариант - это когда финальное решение за человеком с разносторонним опытом в геймдеве. Консенсус решений с учетом фактов (например, фидбека игроков) также работает, но более сложен в исполнении. Кроме этого, решения часто приходится улучшать/заменять по ходу разработки, и становится бессмысленно за них держаться, имейте это ввиду.

Об итерациях

Если вы нашли адекватную команду, то что делать дальше? Обсудите видение игры.

Как? Формализуйте всё по максимуму, т.е. задокументируйте согласно распределенным обязанностям (вы ведь это сделали, правда?). Гейм-дизайнер может максимально подробно описать особенности игры и даже заскетчить их, художник - нарисовать примерный образ персонажей, UI, игровой уровень, программист - реализовать самую важную механику игры “на кубиках”.

Далее начните это делать. Желательно уже вчера, не откладывайте до следующих выходных. Очень важно получить первый прототип максимально быстро. Исходя из него вы сможете принимать дальнейшие решения.

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

Какова связь данного процесса с личными качествами людей? Огромная, не побоюсь этого слова. Вам придется переделывать кучу работы - игровые уровни, код, графику, музыку, геймплейные механики, интерфейс - всё ради того, чтобы игра стала лучше. Важно понимать, что люди довольно прохладно относятся к переделкам, и это заметно влияет на психологическое состояние команды. Поэтому прежде, чем начинать что-то делать - убедите самих себя, что это правильное решение. Как именно? Через фидбек игроков, ощущения команды (консенсус решений) и общую планку качества игры. Всегда можно выделить те элементы игры, которые не дотягивают до остальных. Их и нужно улучшать, постоянно. Главное при всё этом помнить, что должна повышаться общая планка качества игры, а не какая-то одна из её составляющих.

О планировании работы и дедлайнах

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

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

Почему еще важно планировать разработку? Если вы будете активно выбираться на публику, то вас часто будут спрашивать, какие у вас планы на разработку, когда будет тестирование, когда будет релиз и так далее. Очень здорово, когда у вас уже готовы ответы на такие вопросы.

О важности совместной оценки результатов работы

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

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

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

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

О том, что делать

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

Задавайте вопросы, ответы на которые вам пока не удалось найти.

P.S. Отдельное спасибо инди-разработчикам, кто ознакомился с первой версией данной статьи и дал советы по улучшению!