Глубокая прожарка: как я пытался совместить полноценную разработку игры с тимлидством

Всем привет! На связи Виктор Борисов, тимлид и разработчик игры I, Toaster. Работа над «Тостером» нас не отпускает — а звук перезарядки хлебомета, кажется, навсегда останется в наших сердцах. Мы решили выпустить серию материалов, в которых разные члены нашей команды поделятся своим опытом создания игры. Я начну первым! Буду рад, если описанные мною вещи кому-то откликнутся, или же если у кого-то появится желание поделиться советами на будущее по этой теме.

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

Именно один месяц длился первый поток практической работы в игровой студии GameBox — в рамках которого и был создан наш I, Toaster. Здесь я не буду подробно рассказывать о GameBox и том, как проходит первый поток — при желании можете погуглить.

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

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

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

Agile методология

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

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

I, Toaster - география команды

Климат в коллективе

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

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

I, Toaster - with love

Пиши всё, пиши обо всём

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

I, Toaster - запомнил

Тайм-менеджмент важно, но не панацея

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

I, Toaster - учёный учитель

Как усидеть на двух стульях

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

Главное — это, конечно же, недостаток времени. Я ни в коем случае не хочу обесценивать труд остальных членов команды, но очень важно понимать, что зачастую разработка игры — процесс, требующий полноценного вовлечения именно человека, работающего с движком. Всё, что сделали другие члены команды, будь то модели персонажей, окружение, UI, анимация или звук, нужно корректно импортировать и настроить в самой игре. А помимо этого не забыть про свой пласт работы: про разработку архитектуры, механики, оптимизацию, сборку (тесты, конечно, но мы просто не успевали автотесты влепить =)). Поэтому в куче всех этих задач порой сложно выделить и минутку на обсуждения. А общаться нужно со всеми, подробно и в свободные для этого часы, которые у всех имеются в разные периоды дня. В общем, в тот месяц я крайне мало спал))

I, Toaster - хочу спать

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

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

Не доработал, не доиграл

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

А еще в рамках работы над игрой я особенно прочувствовал свой недостаток наигранности. Мы делали игру в жанре арена-шутер, а я раньше почти не играл в игры подобного жанра, так как люблю совсем другое. Но нашей команде — и в частности мне, как тимлиду — очень повезло с геймдизайнером, который доходчиво объяснял, чем выделяется этот жанр, чем он цепляет. Он собрал несколько игр в качестве референсов и даже постримил, как играет в них =) Я ему безумно благодарен за это.

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

I, Toaster - спасибо за внимание!