Всем привет! На связи Виктор Борисов, тимлид и разработчик игры I,Toaster. Работа над "Тостером" нас не отпускает — а звук перезарядки хлебомета, кажется, навсегда останется в наших сердцах. Мы решили выпустить серию материалов, в которых разные члены нашей команды поделятся своим опытом создания игры. Я начну первым! Буду рад, если описанные мною вещи кому-то откликнутся, или же если у кого-то появится желание поделиться советами на будущее по этой теме.
Месяц — вовсе не срок для геймдева. Многие игры создаются годами, а выход новых частей постоянно откладывается. Тем не менее мне кажется, что на начальном этапе работы в геймдеве месяц — вполне решающий срок, который, в первую очередь, помогает многое понять о самом себе, своей мотивации и силах.
Именно один месяц длился первый поток практической работы в игровой студии GameBox — в рамках которого и был создан наш I,Toaster. Здесь я не буду подробно рассказывать о GameBox и том, как проходит первый поток — при желании можете погуглить.
Сначала, в рамках уже упомянутого GameBox, мы все прошли отбор по своим специальностям, а затем были определены в команды, в случайном порядке. Такой рандом — тоже своего рода испытание. Неспроста из нашей команды в первый же день отсеялся один человек.
Главный удар пришелся по геймдизайнеру, которому требовалось как можно скорее, хотя бы в общих чертах, придумать концепт игры. Подробнее о том, как к нему пришла идея противостояния тостера пылесосам, стиралкам и более увесистым врагам, мы расскажем в дальнейших постах. Я же пока перейду к своим ожиданиям и болям: как всё успеть, учитывая, что у всех членов команды есть основная работа, а живем мы в разных городах, странах и, что важно, в совершенно различных часовых поясах.
Мы старались работать по Agile методологии — опять же, гугл, тема классная, кому интересно, советую ознакомиться. На эту тему написано много умных книжек и статей.
Изначально я не хотел быть тимлидом. Постоянные созвоны, принятие сложных решений, урегулирование всевозможных конфликтов, как и работа с людьми в целом, это самое сложное. К тому же задач по разработке и без этого было море. Но мы сильно зависели от времени, а я — от своей легкой степени control-freak и желания всем помочь))
В прошлом у меня был опыт управления сотрудниками. Но в условиях, когда у всех много задач, а денег никто не платит, взаимодействовать с членами команды совсем непривычно. У кого-то сегодня единственный выходной за неделю, у кого-то — суточная смена, а у кого-то в среднем на 8 часов больше времени, чем у всех остальных.
I, Toaster — география команды
В принципе нам с коллективом изначально повезло, поэтому у нас почти сразу сформировались доброжелательные и доверительные отношения между членами команды.
Это не значит, что не было ссор или недопониманий — конечно, без них никуда.Но именно в такие моменты особенно важно было мне как тимлиду находить время, отвлекаться от остальных задач и уделять время на решение спорных вопросов, чтобы не доводить их до точки кипения. Это, конечно, раздражает: особенно, когда ты сидишь и ломаешь голову над очередной строчкой кода. Но тут важна оперативность! Иначе все разругаются, а работа встанет или (что ещё хуже) кто-то эмоционально выгорит и не готов будет продолжать работу над игрой в таком же высоком темпе.
Тут я в принципе изначально понимал, что нужно конечно стараться вести записи в блокноте во время митингов.
Единственное чего я не ожидал, так это объем)))
Особенно когда мы созванивались командой и обсуждали задачи по всем направлениям разработки игры.
Запомнить это в голове просто нереально, поэтому всегда имейте под рукой блокнотик и ручку, чтобы тезисно конспектировать ваши созвоны.
Тайм-менеджмент важно, но не панацея
Конечно тайм-менеджмент супер важная вещь. Задачи надо оценивать, планировать и ставить.
Но не стоит сильно переживать, если что-то не успели. Да это всегда неприятно, но это не повод останавливать рабочий процесс и негодовать.
Важно всегда держать руку на пульсе и стараться выделить наиболее важные направления. Например то без чего игра не будет играться.
А уже отталкиваясь от этого уделять время на какие-либо доп. механики.
Лучшее враг хорошего))
Но это конечно не значит, что не нужно стремиться к лучшему, хехе))
I, Toaster — учёный учитель
Как усидеть на двух стульях
Сразу скажу: опыт совмещения тимлидства с разработкой многое мне дал и, надеюсь, закалил меня на будущие рабочие вызовы. Тем не менее рассказ об этом опыте мне хочется начать с существенных минусов.
Главное — это, конечно же, недостаток времени. Я ни в коем случае не хочу обесценивать труд остальных членов команды, но очень важно понимать, что зачастую разработка игры — процесс, требующий полноценного вовлечения именно человека, работающего с движком. Всё, что сделали другие члены команды, будь то модели персонажей, окружение, UI, анимация или звук, нужно корректно импортировать и настроить в самой игре. А помимо этого не забыть про свой пласт работы: про разработку архитектуры, механики, оптимизацию, сборку (тесты, конечно, но мы просто не успевали автотесты влепить =)). Поэтому в куче всех этих задач порой сложно выделить и минутку на обсуждения. А общаться нужно со всеми, подробно и в свободные для этого часы, которые у всех имеются в разные периоды дня. В общем, в тот месяц я крайне мало спал))
При этом из этих минусов возникают важнейшие плюсы! Так как непосредственно ты, как разработчик, собираешь работу всей команды в игру, тебе становится более понятно, когда, в какой последовательности, а главное — в какие сроки — нужно выполнить задачи, чтобы получить оптимальный результат. Ты начинаешь видеть примерный итог задолго до финала — так как учишься оперативно решать определенные проблемы и иметь уже какой-то промежуточный, но показательный результат.
Кстати, в связи с этим я научился говорить геймдизайнеру и другим членам команды особенно четкое "нет": когда нужно что-то отменить в рамках разработки, потому что понимаешь, что это может занять достаточно много времени, и в рамках месячного спринта достичь удовлетворительного результата не получится.
Хоть я и являюсь разработчиком с опытом, но в геймдев перешел недавно. Из-за этого в рамках работы над игрой я часто сталкивался с задачами, решить которые быстро и привычными путями не получалось. Поэтому вот парочка советов для начинающих:
— не ленитесь читать документацию к движку на котором разрабатываете игру
— конечно, гугл, он знает всё)) как и индусы, if you know what I mean
— ищите сообщества разработчиков игр. И не бойтесь спрашивать! Я не буду говорить, как там всё радужно и как всем рады. Разработчики тоже люди, токсичность никто не отменял — как и внезапное желание помочь в 2 часа ночи (проверено на себе). Если вопрос действительно нетривиальный, его всегда интересно разобрать! И это идёт в плюс и людям задающим, и людям отвечающим. Зачастую, когда объясняешь, то и сам лучше начинаешь понимать тему. Особенно, когда вопрос сложный и с подковырками. К тому же иногда именно с обсуждения вопросов начинается продолжительная коммуникация между членами геймдев-сообщества, которая может привести к продуктивному сотрудничеству.
А еще в рамках работы над игрой я особенно прочувствовал свой недостаток наигранности. Мы делали игру в жанре арена-шутер, а я раньше почти не играл в игры подобного жанра, так как люблю совсем другое. Но нашей команде — и в частности мне, как тимлиду — очень повезло с геймдизайнером, который доходчиво объяснял, чем выделяется этот жанр, чем он цепляет. Он собрал несколько игр в качестве референсов и даже постримил, как играет в них =) Я ему безумно благодарен за это.
Тем временем для себя я четко понял простую, но ранее как будто недоступную истину: если ты делаешь игры, то ты должен как можно чаще играть в них - причем не только в своих любимчиков, но и во что-то непривычное, непонятное и даже некомфортное. Конечно, было бы круто получить оффер в компании, выпускающей твои любимые игры. Но для начала нужно расширить кругозор, изучить фишки различных жанров, а главное (для меня как разраба) — познакомиться с новыми механиками и научиться их реализовывать в своей игре.
I, Toaster — спасибо за внимание!
