После прошлой статьи про «испанских синьор-программистов» в комментариях и личных сообщениях было много вопросов о том, как выглядит работа в игровой студии изнутри. Некоторые даже в линкед вопросы закидывали. Эта статья про то и начиналась, но быстро стало понятно, что получается скучно — таких уже с десяток точно есть и не только на хабре. Поэтому решил рассказать не столько о процессах, сколько о людях их творящих, с примерами из жизни, чтобы было поинтереснее. Ведь игры делают именно люди, и очень надеюсь, чатик не скоро отберёт у нас эту работу. А пока, я перечитываю в четвертый, наверное, раз «Мифический человеко-месяц» Брукса, которой в этом году стукнет 50 лет, только подумайте — книга была написана полвека назад, но она по-прежнему актуальна.
Люди — это всегда про общение. Это взгляды, жесты, разговоры на кухне, в чатах, в курилке и на террасе. Хочешь работать в команде и делать игры? Прокачивай софт-скиллы. Кто бы мог подумать, что для программиста это настолько важно. Лет десять назад я бы посмелся на тем, кто скажет, что половина моего времени будет уходить на обсуждения, убеждения дизайнеров делать «как надо», а не «как хочется», код-ревью, обучение новичков и решение задач, которые вообще не связаны с программированием.
Тогда мне казалось, что важна только разработка: писать код без аллокации, придумывать крутые алгоритмы, пилить собственную «идеальную» STL. Я ошибался! Понимание, что надо уметь взаимодействовать с людьми, договариваться и находить общий язык — это не менее важно, чем знание алгоритмов или оптимизация кода. Игры делают люди, и каждая команда — это уникальный клубок идей, конфликтов и компромиссов, а прогер в студии — это не только и не столько про код. С кем-то и в бар сходить, да НГ отметить, а с кем-то только на созвонах и услышаться, да на ревью пересечься.
Все люди — человеки
Работая над игрой, вы неизбежно столкнетесь со всеми: рендерщиками, аниматорами, звуковиками, дизайнерами уровней и многими другими, я тут посчитал получается что-то около 100 специальностей. Теперь у нас даже промт-инженер есть, как минимум для драфтовой озвучки, кто там смеялся про это года полтора назад? Многие из них совмещаются обычно одним человеком, но всеже. Даже если вы обычный программист игрового движка, а не лид, то поведение, подход к задачам и общение с соседями напрямую влияют на атмосферу в команде и то, как все вокруг воспринимают не только вас лично, но и проект. Это командная работа, и настрой каждого человека сказывается на общем результате, проверено не раз на личном опыте.
Игровой программист (а это на минуточку — рендер, анимации, ui, редактор, ии, gameplay, звук, скрипты, оптимизации, ачифки, платформенный код и сторы, тесты, физика, сеть и собственно сам движок) часто находится в самом центре этого взаимодействия, потому что создаёт основу, на которой строится всё остальное. Этот код становится платформой для художников, аниматоров и дизайнеров, и от того, насколько он удобен, понятен и гибок, зависит их продуктивность. Но технические задачи — это только половина дела. Вторая половина — это коммуникация, и тут начинаются интересные моменты.
Одним из самых частых источников споров становится взаимодействие с дизайнером (ИИ, левел, звука, света, окружения, нарратива, систем). Дизайнер не всегда точно знает, чего хочет, это как в том анекдоте про большую красную кнопку «Сделать зае….», но знает как оно должно выглядеть в игре — чтобы игра выглядела и ощущалась определённым образом — как еще говорят «жила» или «дышала», а мы, загнанные в рамки игровых движок и строчек кода, не всегда знаем, как это перенести в движок, подружить с железо и временем разработки. В такие моменты важно не просто отмахнуться с фразой «это невозможно» или «это слишком сложно», а объяснить, почему это так, и предложить компромисс. Компромисс на который согласится и твой лид, и диз, который пришел с фичей, и ты сам. А еще учесть как новая фича, инструмент или система повлияет на остальных, художников или аниматоров, и насколько это замедлит их работу и создаст напряжение в команде, дизайнер это не видит, да и программист зачастую тоже.
Однажды мы переделывали мини-катсцену, где главная героиня падала в пропасть, если вышла за пределы уровня. Програмеры сделали реалистичное ускорение для модельки и сваливали её в регдолл перед этим, падала, что называется, по физически правильной траектории. Пришел дизайнер и говорит: «Неправильно падает, а я знаю, как люди красиво падать должны!» В итоге героиня падала, размахивая руками, как в мультике, а звуковик на это все наложил звуки нашей умирающей кофемашины, потому что они были похожи на «Ааааа!» с эхом в горах. На релизе все думали, что это так и надо.
На другом проекте дизайнер уровней придумывал сложные головоломки, которые сам-то проходил с трудом. Попытки донести до него сложность прохождения его творений приводили к нервному срыву у дизайнера, и неделе, а то и двух больничного. В итоге мы плюнули на это, и половину додумывали и меняли сами, чтобы фокус группы могли их осилить. Оно конечно приводило к обидкам в духе — «Вы поломали весь замысел, это было идеально, а сейчас просто красиво» и спорам о смысле разработки игр, но уже без больничного.
Только не по голове
Спорить можно по-разному: громко в курилке, едко выражая своё недовольство каким-то решением агрессивными шутками в чате, или даже незаметно — своим хмурым видом наводя тоску на соседей по опенспейсу. Некоторые вообще не спорят, а просто реджектят ревью, если сделано не так, как это им видится, и слова «Переделайте тут, это неправильно» звучат не менее резко, чем их более короткий аналог. Негатив всегда найдёт способ проявиться.
Иногда достаточно бывает просто пообщаться один-на-один и спросить об отношении к тому решению, без занесения в личное дело. И хорошо, если этим занимается штатный HR (вот они, оказывается, для чего нужны, а не только резюме в корзину выбрасывать). Внимательно выслушанный человек может не только выплеснуть эмоции, но и зачастую спокойно и аргументированно объяснить свою точку зрения. Иногда даже сам факт, что коллега может просто выговориться, уже решает проблему, а потом уже можно будет наставить человека «на путь истинный» и объяснять, что вы с разных планет. Другим просто важно знать, что вы не просто закрыли глаза на их доводы и рассуждения, а приняли решение с учётом разных мнений. Было бы круто ещё спросить, как можно уменьшить риски или проблемы, и выслушать ответ, но это уже вершина мастерства, которая приходит с возрастом. Но чаще возраст приходит один (с).
Как и обещал — примеры из жизни: дизайнер уровня постоянно был недоволен тем, как работает система триггеров. Я уже устал защищать своё решение, чинить мелкие придирки и получать раз в неделю пару новых хотелок, пока не случился разговор на кухне. Эту фичу должен был делать он сам, как тестовое для перехода в технические дизайнеры. А лид посчитал, что тот не справится и таску отдал программерам. Может быть он и справился бы, мы уже этого не узнаем, но как минимум у него было бы желание работать. А получилось, как получилось.
Другой пример: на симсах был программист, за полтос, опытный, очень… начинал еще со спектрумов и программирования в машинных кодах — он никогда не спорил. Он просто реджектил ревью с комментарием: «Нет/Убрать/Память течет/Плохо/Bad design/Не по-понятиям«. Без объяснений, без вариантов. Это почти всегда было правдой, ослушавшиеся позже находили в тех местах баги. Как-то более молодой коллега, который получил такой реджект, пошел к нему лично на разговор. Через минуту после начала спектрумист молча встал, подошёл к доске, нарисовал огромный круг и написал внутри: «Почему это плохо». Потом обвёл его ещё большим кругом и подписал: «Потому что я прав». И ушёл. Ту фотку я долго хранил на телефоне, как пример непробиваемой уверенности. Он кстати был прав, мы нашли потом баг в том месте.
Грустный пример: не мой, но из доверенных уст. На проекте была ситуация, когда из-за разных взглядов на техническое состояние рендера в команде началось «недопонимание». Лид рендера считал, что его надо переделывать, что собственно и делал, техлид, что новый получился слишком сложный и не стоил усилий и всячески это дело тормозил. В итоге техлид в отместку подмахивал все комиты от рендерщиков не глядя. Команда на все это смотрела со стороны, никому не хотелось стать «случайно виноватым». Вместо обсуждения один-на-один всё свелось к пассивной агрессии: лид рендера в итоге ушел, не доделав начатое, а команда получила нерабочий старый и новый полумертый рендер, который пришлось кое-как залатывать лишь бы работало.
Споры — это не плохо, просто люди в команде хотят видеть, что их слышат. А это, зачастую, иногда важнее, чем писать идеальный код.
Общение 1:1
Игровая студия — это почти всегда опенспейс. На какое-то время тренд на удалёнку захватил индустрию, но уже около года идет обратный процесс — сотрудников возвращают обратно в офисы с помощью плюшек, кофе и мандаринов, иногда зп. Так что теперь мы снова за своими «цепями и батареями» «клавами и мышками». Разговоры в таком пространстве слышат многие, у американцев есть даже термин для этого — «the floor» (зал, арена), это такое пространство, где ты всегда на виду, как-бы не пытался уединиться. В таких условиях важно понимать, что и когда можно обсуждать на публике, а что стоит оставить для приватного разговора. Иногда лучше вообще “удалиться с арены” и обсудить что-то один на один.
Игровые дизайнеры вобще люди творческие, часто могут быть громкими или эмоциональными, что не всегда способствует комфортной работе окружающих. Конечно, шутки про “пошли выйдем” остаются шутками, но напряжение в коллективе — это реальная проблема, с которой мноние сталкивались. Вот тут-то разговоры тет-а-тет становятся настоящей находкой. Это классная практика из менеджерского арсенала, которую я без раздумий перенял для своей команды. Такие беседы позволяют людям открыто говорить, не торопясь и не боясь, что их перебьют или что кто-то будет подслушивать. Правда, предложение пообщаться 1:1 может вызывать, хм, опасения, особенно у девушек, но у нас в студии такие случаи редки, это я про девушек-программистов (программисток?). Тем не менее, в игрострое хватает историй о притеснениях и буллинге (#MeToo и прочие инициативы), особенно в сторону женщин и оных уязвимых групп. Слышал советы, что при договорённости о встрече тет-а-тет стоит уточнить, где собеседнику комфортнее: переговорка, кухня, терраса или даже опенспейс. У нас чаще всего выбирают переговорку, потому что все привыкли к ней — там проходят летучки и планёрки, как говорится и стены помогают.
А еще оказалось, такие разговоры помогают перед большими собраниями или сложными обсуждениями, например, когда решается что-то важное вроде проведения новогоднего корпоратива. Наш ПМ перед такими встречами общается с некоторыми участниками отдельно, чтобы заранее прояснить позиции и сгладить острые углы. Это помогает избежать “рукопашной” на общем собрании, когда мнения разные, а половина участников вообще не понимает тонкостей работы того, что обсуждают. Конечно, разговор с глазу-на-глаз не решит проблем, но позволит разобрать хотя бы часть вопросов, увидеть пересечения, и если повезет, даже настроить кого на конструктивный разговор.
Однажды в нашем опенспейсе дизайнер и программер о чем-то громко спорили, вроде что в игре одежда персонажей отражает свет «как у тазика». Дизайнер кричал что-то вроде: «Я художник, я так вижу!», на что программист отвечал: «Это математика, оно так не работает!». В разгар спора мимо проходил ПМ с коробкой мандаринов, остановился и сказал: «Ребята, если вы продолжите так шуметь, я отдам мандарины другой команде!». Ржач стоял по всему опенспейсу. Еще с месяц на столах участников появлялись разного вида мандарины, а в общем чате гуляла картинка с Гринчем с подписью: «Тихо, а то останетесь без мандаринов», которая на время стала мемной фразой чтобы утихомирить слишком уж громких товарищей.
Каждая фича — это чей-то «ребёнок»
Что-то в текущих решениях проекта вам на 110% будет казаться глупым, недоработанным или глючным. Но любой вклад в игру — это чей-то “ребёнок”. Я знаю пару команд где есть правило насчёт шуток, которые обесценивают или уменьшают чьё-то время или усилия. За подобную шутку можно отправиться к HR за внеплановым отпуском. Даже абсолютно непробиваемые и спокойные “слоны”, отмотавшие не один проект, могут сильно переживать из-за какой-то конкретной фичи. Можно и даже нужно критиковать код и фичи, и среди программеров шутки и подколы в порядке вещей, но, конечно, надо предложить и как исправить. Нельзя смеяться над работой человека, потому что он в большинстве случаев ассоциирует эту работу с собой. Особенно это касается игровых фич и людей с ними связанных. У меня был случай, дизайнер придумал сложную механику по уворачиванию монстров от ударов игрока, и на пару с программистом они внедрили её в сжатые сроки, неидеально, но всё-таки заставили работать. Есть предположения, что произошло когда лид своим волевым решением просто отревертил эту сотню комитов одним днем.
Хороший лид чужой комит не откатит
Дизайнер просто положил заявление на стол, а в игре повисли два монстра, которых он вёл, там конечно набралось проблем и это действие стало последней каплей. Прогер остался, но ушел в другой отдел. Прогер — не автор статьи, если что, просто довелось наблюдать за этим со стороны.
Были и смешные истории: AI дизайнер сделал фичу, чтобы враги при получении удара получали физический импульс и немного сдвигались, импульс можно было настраивать и конечно кто-то выкрутил его до упора, так что враги отлетали в разные стороны, будто в них попала ракета или ядро из пушки, а не нож или баночка. Да так и закомитил в игру. На тестах это выглядело уморительно, в сочетании с быстрой смертью и переключением в регдол физику, прям сражения как в «Горячие головы» с разлетающимися во все стороны врагами. С неделю этот фичебаг гулял по студии, кто-то даже хотел оставить как пасхалку. Не смеялся только автор фичи, который в чат выложил обиженное: «Пофиксил. Теперь враги отлетают по законам физики, а не вашего юмора.». Фичу в итоге убрали, не подходила она все-же под игровые механики, а за человеком закрепилось кличка мастера — «мастера ядреной физики».
Жалобы оставь ПМу
Чтобы говорить о важных вещах, нужны авторитет, прокачаная харизма или специальный «плохой парень». Без негатива работать не получится — вечно ясного неба не бывает. Иногда решения сваливаются сверху, и они, мягко говоря, не всегда выглядят круто. И это приходится принимать. Я знал нескольких ПМов (и парней, и девушек), которые говорили только на безопасном для себя языке. Они никогда не говорили ничего, что могло быть передано дальше в негативном ключе, ни в личной беседе, ни в корпоративной переписке. Это особый навык, который сложно развить — скорее, это дар. Да, такая позиция демонстрирует верность студии и её идеалам, но обсуждать с такими людьми что-то сложное или конфликтное практически бесполезно. Также как и говорить с ними о каких-то новых фичах и идеях, тоже желания не было, тонуло как топор в болоте.
С другой стороны, были и люди, которые настолько срослись с командой, что могли делиться своими личными переживаниями прямо в общий чат. Но вот что действительно работает — это принцип «Жалобы оставь ПМу». Если нужно донести плохую новость или решение, с которым я лично не согласен, это надо делать через менеджера.
Иногда мне даже жаль нашего ПМа, потому что именно он часто становится «громоотводом». Я тоже был лидом на проектах и всё это испытал на своей шкуре. Честно говоря, больше не хочется. В тот период пришлось читать мануалы по управлению командой, и неудачно попалась неправильная книга, что-то вроде «Будни пикапскрам-мастера», где советовали стратегию хамелеона: подстраиваться под каждого собеседника. На практике это всё с треском провалилось. Как только пришлось собрать всех участников конфликта в одной комнате, оказалось, что они уже пообщались друг с другом и всё выяснили. В итоге моя «гибкость» выглядела как попытка угодить всем, и это выглядело довольно странно. Зато старушка «Как пасти котов» Рейнвотера, которой тоже кстати почти четверть века будет с момента выхода, зашла на ура, через всю книгу красной нитью проходит работающая идея: в офисе нет места повышенным тонам. Если на вас оборачиваются люди, надо переводить разговор в формат 1:1. Бывает, все мы люди, самое правильное решение — извиниться и покинуть обсуждение.
Тут тоже есть, что вспомнить смешное, наш ПМ куда-то пропала на два месяца, толи заболела, толи курсы какие, и вместо неё прислали совсем пацана, 21 годик, может на стажировку, может сынок чей. И этот пацаненок, похоже начитавшись до потери сознания книг из серии «будней срам-мастера», начал внедрять тот самый метод хамелеона, хм думаю оно не работало десять лет назад, почему оно вдруг станет работать сейчас? Начиналось пристойно с вежливых разговоров, а закончилось тем, что он стал ходить, одеваться и разговаривать как директор студии. Было знаете-ли несколько палевно играть в фифу, когда не можешь контролить появление клетчатой рубашки. Нет, никто не запрещал, даже пара плоек с большими телеками спецом для этого и стояла в студии, но таски закрывать тоже кому-то надо было. Его так и прозвали — «Босс-хамелеон», пару месяцев он не дотянул до выхода мультфильма «Boss-baby», а то кличка бы у него была совсем другая.
Были и грустные истории, соседняя команда, условно Маша была условно идеальным ПМом — всегда спокойная, дипломатичная, говорила только «безопасным языком», не помню от неё случайного матерного слова, даже когда сзади неё почти впритык рухнул, зацепленый кемто, стол. С таким поведением она стала реальным громоотводом для команды, принимая на себя все жалобы и негатив как внутри группы, так и от руководства. Но тут пришел не совсем удачный софтланч. Добавьте сюда, что это была её первая команда, и первый сорваный софтланч, как обычно с криками, патчами наживую, ночными фиксами и едой в офис. Более опытные коллеги нормально пережили не первый аврал, а Маша как обычно терпиливо молчала, делала отчеты и раздавала задачи, как всегда политкорректная, боясь сказать что-то «небезопасное». Игру запустили через пару месяцев в прод, и на следующий день Маша уволилась, не пришла даже в офис попрощаться. ПМа не могли найти с полгода, а потом тот проект и вовсе прикрыли, профит был ни о чем.
Как пасти котов
В ЕА мне довелось работать с очень грамотной ПМ (Лена, привет), потом она ушла в Larian продюсером, но связь мы иногда держим. Некоторые из её «финтов» я разгадал значительно позже, некоторые не разгадал совсем. Если она замечала, что кто-то на встрече выпадал из обсуждения или откровенно скучал, то спрашивала их мнение, иногда таким человеком был я и приходилось участвовать в обсуждении. Не всегда это получалось, правда. Если человек смущался — передавала вопрос другому, но после обсуждения отвечать все же приходилось, но уже в формате 1:1. Если кто-то прерывал говорившего, тормозила его и возвращала докладчика в разговор, и только потом разрешада остальным продолжить. Большинство собраний в разработке происходит в виде лекции с парой тройкой вопросов из зала, что возможно круто и комфортно для посвященных в тему, а остальные, и это относится, как правило если собирается разношерстная команда программеры-дизайнеры, остаются за бортом, пока одни обсуждают вторые тихонько скучают и чем более разные команды, тем больше скучающих с каждой стороны. В этом случае, если кто-то из команды делал успехи или предложения, которые почему что не мог озвучить, не важно на проекте, или вне его, об этом обязательно упоминалось на митинге. “Перед собранием Иван рассказал мне, что…” — или “после собрания я пообщалась с Василием, и он предложил …”. Простые и понятные каждому вещи, но они работали, хотя — тут конечно можно опять сослаться на харизму, потому что одни и теже вещи у одних работают, а у других не всегда.
Текущие задачи
Не первый раз замечаю, что большинство задач решаются на 70% в первые полчаса. Если же «подзабить» и отложить её, решение может растянуться на сутки или даже больше. Погружение в задачу требует фокуса, и если на столе не стоит помидорка, я стараюсь уделить подошедшему всё своё внимание или прошу вернуться через несколько минут. Иногда вобще бывает полезно просто выйти на кухню, заварить чай и дать голове немного переключиться.
Возможно, это последствия «детской травмы». Мой первый начальник, немолодой человек ещё советской закалки, постоянно был чем-то занят — или делал вид, что занят, раскладывая что-то там у себя на компе. Через какое-то время люди просто переставали к нему подходить и были вынуждены решать проблемы самостоятельно, но формально он был начальником отдела. В итоге задачи отдел решал как умел, а на планёрках «начальник маджонга» раздавал «звёздюли» за проблемы и жалобы заказчиков.
Неважно, кто вы — программист, дизайнер или лид. Если к вам подошли с вопросом, вы становитесь тем самым «бутылочным горлышком», bottleneck, от которого зависит продолжение работы других. Устраняя препятствия в проекте, проще всего начать с себя. Когда к вам подходят люди, это важнее любого письма, которое вы сейчас печатаете. Конечно, если только на столе или в чате не стоит красная пирамида или помидорка, сигнализирующие, что сейчас не лучшее время для разговора.
Тут стоит вспомнить Брукса с его «Мифическим человеком-полумесяцем«, где он прямо пишет, что плохая коммуникация внутри команды — одно из главных препятствий на проекте да рекомендации по сокращению числа участников в ключевых обсуждениях. Не помню уже, кто из бывших коллег предложил ограничить количество участников на технических созвонах до трёх, но это действительно сделало их быстрее и продуктивнее. Вместо часа всё решалось в пределах 15 минут. А вопросы, которые не удавалось закрыть за полчаса, отправлялись архитекту или техлиду, который уже и принимал финальное решение, уменьшая энтропию и экономя время.
На одном из последних проектов достаточно известной игровой студии, которая сделала не один фентезийный стелс-экшен, довелось своими глазами довелось увидеть подтверждение другого закона Брукса: «Добавление людей на проект, который отстаёт от графика, только замедляет его«.
В команде было действительно сильное отставание в AI: поведение NPC и оркестровка событий на уровне. Вместо того, чтобы дать время на решение проблем, отдел просто «залили» людьми. К шести опытным спецам (2 программиста и 2 дизайнера) добавили «группу поддержки» из восьми смуглых мидлов: четыре программиста и четыре дизайнера. Это привело к тому, что всё наше время уходило на обучение новых сотрудников, добавьте сюда еще временной лаг и работу на ремоуте. Про усложнение коммуникации я уже молчу. За первый месяц я не сделал ни одной своей крупной задачи, и это был первый раз в жизни, когда пришлось объяснять плюсовому «мидлу», чем статическая функция отличается от обычной и это был еще толковый «мидл», ну т.е. не очень лажал с кодом и логикой. Во всем остальном это был фейл. У дизайнеров, кмк, было еще хуже, так что через несколько месяцев такой «работы» старички дизы просто положили болт на работузаявления на стол директору. Хотя может в этом и был смысл? По финансам эта обученная группа обходилась заметно дешевле двух матерых канадских лесорубов ветеранов.
Игра таки вышла, он вышла бы в любом случае — крупные проекты, которые перевалили за дцать лямов, вообще фейлятся очень редко и в каком-то виде, но доезжают до релиза. Игра вышла с опозданием почти на год и серьёзными потерями в людях и качестве. А баги? Ну что баги — они всегда есть, и всегда будут.
На этом пожалуй всё, о чем хотелось рассказать. Спасибо за внимание! Надеюсь, эти байки не отвернут вас от славного мирка игростроя, а кто хочет знать внутреннюю кухню разработки найдет для себя чтото новое. Конечно, читать об играх и вариться в реальных проектах — это совершенно разный опыт, но умение слушать, объяснять и находить компромиссы позволяет не просто быть хорошим программистом, но и быть в команде, и работает не только для gamedev’а’. В конце концов, люди игры делают для людей и среди людей, а код лишь средство, чтобы донести идею.
