Что за биологический вид этот пресловутый «геймдевелопер»? Вопреки расхожему мнению, далеко не всегда это породнившийся с X-box’ом чудак, коммуникативная активность которого сводится в рабочее время к рукопожатию или кивку при встрече с коллегами. Оказывается, это разносторонний и неравнодушный человек, всё время ищущий что-то новое. Мы выяснили, что с недавнего времени команда zGames по собственной инициативе организует тренинги, во время которых программисты делятся друг с другом опытом, ценными идеями и прочими феерически полезными благостями, которые впоследствии активно применяются в работе.

Читать далее

Итак, зачем геймдевелоперам заниматься самообразованием? Отчего не угасает их пламенная любовь к землистому вкусу гранита науки? 

Мы выловили нескольких инициаторов идеи тренингов и с пристрастием допросили их — что, зачем и почему. На вопросы отвечали: Артём Воробьев (технический руководитель zGames — на фото в центре), Артём Мерц (ведущий программист — на фото справа) и Иван Березовский (ведущий программист — на фото слева).

Как зародилась идея тренингов

Артём В.: Я точно помню день, когда мы решили, что нужно ввести обучающие занятия. Кто-то из junior-разработчиков показал нашим лидам кусок кода и спросил, когда будет удалён из памяти объект. Ребята стали объяснять, к обсуждению подтянулись другие разработчики, и выяснилось, что многие в принципе не знали, как работает сборщик мусора. Этот пробел достаточно критичен для разработчика, потому что, если он пишет игры на .NET и этого не понимает, то он, скажем так, машет лопатой, не загребая земли. Мы поняли, что вопрос с обучением команды надо решать комплексно, и уже на конец недели назначили первое обучающее занятие. Начали с тех тем, по которым у нас уже были материалы.

Артём М.: Стали выяснять, какие ещё у нас есть проблемные места, и накидали сразу же сходу штук 30, а в процессе добавилось ещё около 15.

Артём В.: В итоге сейчас висит уже штук 45 тем, из которых 8 мы уже рассмотрели. Плюс после каждого тренинга одна-две темы добавляются. Сначала мы планировали собираться раз в неделю, но уже после первой встречи поняли, что это слишком редко — нужно как минимум дважды.

«Выборы, выборы…»: о спикерах

Артём В.: Если тема узкая и новая, но в ней под силу разобраться junior-разработчику, то её готовит он. И сам поймёт лучше, и объяснить сможет более понятно, прямо с азов.

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

— А на тренингах на простые темы типа сборки мусора сильные программисты тоже присутствуют?

Артём В.: Да, присутствует вся команда по возможности. Это бывает полезно. Плюс ещё очень важна качественная обратная связь.

«Но я стараюсь быть лучше»: от эскаписта к энтузиасту

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

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

«А вы чьих будете?»: о формате встреч

Артем В.: У нас уже есть опыт организации мероприятий в объединённом формате, когда на внутренние тренинги мы приглашали гостей из числа желающих. Года два назад мы делали подобную обучающую встречу в рамках «Душевного четверга», это такой хобби-клуб в Softeq. На неё пришли люди не только из нашей команды, но и из других отделов. Тогда мы и выяснили, что не получится эффективно работать с разношерстной аудиторией, потому что неизвестно, на каком уровне детализации раскрывать тему. Люди из нашей команды — достаточно сильные, им можно всё рассказать быстро и на глубоком уровне. А для людей, работающих в других областях разработки ПО, привычная для геймдевелоперов тема может быть абсолютно новой. И тогда, если начать подстраиваться, оказывается, что разговор либо непонятен одним, либо не интересен другим. Поэтому тренинги в том формате, в котором они проводятся сейчас, мы планируем делать только для нашей команды.

— Тренинги вы проводите в рабочее время?

Артём В.: Нет, и подготовка, и проведение — всё это в наше свободное время. Но я ни разу не слышал недовольства от ребят. Видимо, всё-таки ценность тренингов перевешивает. Хотя, конечно, хотелось бы внести самообучение в рабочий график, потому что для компании это нужно не меньше, чем для работников лично. И для клиентов это скорее будет плюсом в нашу «карму», если мы скажем, что zGames проводит обучение за свой счёт и повышает квалификацию специалистов.

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

Артём М.: Да, когда к нам обратились 21 Monsters, их технический эксперт на звонке спросил нас: «А как вы планируете делать динамическое изменение правил игры?» И мы прямо на ходу расписали им технические аспекты архитектуры. Это даёт клиенту понять, что мы знаем, о чём речь.

Программисты vs. художники: о когнитивном диссонансе

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

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

«Праздник урожая во дворце труда»: что собрали и как это «есть»

Артём В.: Наш первый тренинг был о unit-тестах. Это технология, скажем так, не настолько «обязательная», но очень полезная. С помощью unit-тестов можно в автоматическом режиме находить ошибки в коде без лишних трудозатрат.

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

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

Иван Б.: После тренинга по архитектурным паттернам, который проводил Борисыч (Артём Мерц. — Прим. авт.), я просто пересмотрел свой код, и нашёл, где и как использовал эти паттерны. И сделал для себя выводы на будущее.

Иван Б.: Или вот, например: в работе над одним из наших проектов я использовал технику, с которой никто из нас тогда не был знаком — Light Mapping. Это запекание света в текстуру, техника оптимизации освещения. Когда источников света слишком много, они оказывают слишком большой эффект на видеокарту, и производительность «проседает».

Артём В.: Освещение — достаточно дорогая операция, которую сложно реализовать на мобильных устройствах, так как они не имеют возможности быстро просчитывать свет. А при помощи Light Mapping можно сделать красивый свет, причём недорого.

Иван Б.: Для одной из наших игр c дополненной реальностью нужно было сделать картинки красивее, естественнее — там лес, много деревьев, бродячие зомби и все такое. Девайсы типа Moverio Glasses просто «загнутся» — производительность видеокарты низкая. В таких случаях без Light Mapping не обойтись: свет прямо «рисуется» на текстуре, имитируется.

Я сделал доклад о технике Light Mapping, и, когда остальным понадобится такая штука, — они смогут использовать её в работе.

Артём В.: И вообще, у нас накопилось довольно много кода, который мы писали на протяжении 5-6 лет. Для новичков, которые в этом пока не разбираются, хотелось бы создать некую документацию, нормальным языком написанную, о том, как это работает. Но времени пока нет.

Во время моего доклада о нашей общей библиотеке кода ребята некоторые вещи подсказали. Например, что нам стоит переименовать, чтобы было понятнее особенно для новичков. Плюс на последнем тренинге один из разработчиков спросил, почему оформляем события в C# через свойство и private-переменную. Действительно, оказалось, что уже достаточно давно в .NET появился более удобный способ — через public-переменную. И мы поменяли наш guideline.

А коды летят…

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

Артём В.: Да, это на самом деле очень актуальная тема. Я как-то делал доклад на конференции MobileOptimized — как качественнее писать код. Но не с точки зрения алгоритмов, а с точки зрения каких-то простейших вещей, маленьких хитростей и наблюдений из опыта — из разряда как можно писать лучше, проще и быстрее. Так вот, самое интересное, что подобного материала я нигде не нашел.

Люди рассказывают о чём угодно: о том, как они писали код, когда у них протекал потолок. Или начинают писать код прямо при людях — как они создают простейшее приложение на Xamarin. Но смотреть на это довольно утомительно.

А вот каких-то практических советов, рождённых по результатам code review, нигде не было.

— Типа лайфхак — как сделать лучше то, что делаешь каждый день?

Артём В.: Да. Много вопросов возникает именно тогда, когда не свой код смотришь, а чужой.

— А в своём коде видите «бревно»?

Артём М.: Если подскажут. В своём очень сложно найти что-то.

«Так жить нельзя»: о групповом review

Артём В.: Вряд ли мы это будем делать. У нас было несколько попыток принятия групповых решений в команде. Как-то нам потребовалось придумать новое название для одной подсистемы, потому что старое было двусмысленным и вызывало много нареканий. Так вот, обсуждение в большой группе сводилось к двум вещам: люди либо ругали старый вариант, либо отстаивали новый, немногим лучший. Сложно заставить большую группу мыслить конструктивно. За час митинга 7 человек ничего не решили и разошлись. Я посидел 15 минут, придумал новый вариант названия, написал в чат, и все сказали: «Ок, давайте».

Если нужно собрать качественный feedback, то пусть лучше это сделает один человек, а потом презентует группе конкретное предложение, чтобы решение принималось в формате «да или нет».

Сейчас мы так и поступаем. Например, когда приходит проект на оценку, занимается им, исследует требования один человек, полностью ответственный за анализ. Группой это сделать сложнее, потому что трудно договориться, и самое главное — ответственность «размывается».

Вузы готовят «неликвид»? 

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

Артём М.: К сожалению, в вузы далеко не все попадают осознанно. Для людей, ищущих своё место в этой профессии, конечно, польза была бы. Но перенести под копирку формат наших тренингов не получится.

— А в качестве закрепления академического материала можно проводить такие тренинги? Как бывший преподаватель что скажешь?

Артём М.: Да, есть темы, которые будут непонятны без практического опыта. Вот, например, паттерны проектирования: если ты их не использовал и не начнешь использовать сразу после занятия, то нет смысла в теории о них рассказывать. Своим студентам я старался задания по программе адаптировать так, чтобы у них возникли проблемы, для решения которых придётся использовать эти паттерны. Конечно, есть смысл проводить практические занятия: с домашним заданием, с реальным проектом, работая над которым можно чему-то научиться.

Иван Б.: Теория в вакууме мало что даёт. Нам тоже в универе рассказывали про паттерны, но мы даже не с первой пары поняли, зачем они нам.

Пока не «накосячишь» в первый раз, и пока тебе не покажут, как можно сделать лучше, ничего не поймёшь. А то, что универ оторван от бизнеса, — да, увы, так и получается. То, чему там учат, либо не пригодится на реальных проектах, либо успеет устареть к моменту старта работы.

— В перспективе планируете снять отдельное помещение и приглашать туда людей из геймдев-комьюнити на курсы?

Артём В.: Да, но материал тогда должен быть уже «обкатан» на внутренних тренингах. Запишем видео и на их базе будем готовить занятия. Опять же, докладчики уже наберутся опыта.

Ещё важный момент: студентов, посещающих курсы, нужно обязательно контролировать. Люди придут разные, об их опыте и заинтересованности судить будет сложно. Прийти просто послушать для ознакомления — это точно не работает. У себя мы тоже собираемся вводить контроль, давать «домашку». Но для студентов это должно быть реально жестко, в виде какого-нибудь зачёта.

Самых способных возьмём на работу

Иван Б.: Участие в таких «живых» тренингах — это отличная мотивация для тех, кто хочет попасть в хорошую компанию. Поэтому мы планируем «эволюционировать».

Артём В.: В планах — модерация докладов, создание базы материалов. У нас есть документ, где расписано, кто и что делает. Мы стараемся равномерно распределять нагрузку спикеров.

— А если кто-то увидит список тем грядущих докладов и напишет в комментах о том, что хотел бы поучаствовать в тренинге? 

Артём В.: Зависит от опыта этого человека. Конечно, если это школьник, который писал на Паскале один месяц, то, естественно, смысла особого нет. А если он достаточно компетентен — то можно и пригласить в качестве поощрения.

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.