Четыре попытки обучить геймдизайнеров: опыт HeroCraft

Экс-директор компании о том, как воспитать специалистов.

Бывший креативный и исполнительный директор HeroCraft Георгий Ерхан написал для DTF статью, в которой описал четыре метода подготовки геймдизайнеров и сложности, встречающиеся на этом пути.

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

Мне никогда не нравилось то, как устроена игровая индустрия. Особенно угнетало нежелание крутых готовых спецов (геймдизайнеров в частности) ехать к нам в Калининград работать в HeroCraft. Они непременно капризничали, раз за разом выбирая Wargaming'и и Game Insight'ы.

Середняки-геймдизайнеры (два-четыре года в индустрии и столько же выпущенных проектов) ситуацию не спасали. Они обычно хотели ультра-комбо: высокая зарплата, «интересный проект» (на русский это переводится, как «хардкорная RPG») и полная свобода (от рамок бюджета, сроков, начальства и здравого смысла).

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

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

Численность набираемых новичков напрямую зависела от популяции геймдизайнеров в компании. Оптимальным количеством рекрутов я считал 20% от общего числа. 30-40% — допустимой величиной. При 50% и выше новичками будет просто некому заниматься.

С 2010 по 2014 годы в HeroCraft существовал специальный отдел геймдизайна. Из шести-семи сотрудников отдела двое обычно были джуниорами.

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

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

Поэтому весь курс сводился к нехитрому набору навыков:

— Ориентирование на местности (за полгода джуниор должен в первом приближении понять, как в HeroCraft делаются игры, и как в этом процессе задействован геймдизайнер).

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

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

80% обучения шли на реальных проектах и реальных задачах. А вот оставшиеся 20% добивались специальными практиками, которые должны были (по задумке) позволить быстрее раскрыть потенциал талантливых сотрудников. Кроме того, у каждой из применённых методик были более узконаправленные специальные цели.

Методики я пробовал поочерёдно одну за другой, анализируя результаты и запуская следующую на основе полученных выводов.

Идея и цель

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

Методика должна была вырвать человека из рутины его обычных задач и дать возможность проявить себя. Полная свобода в самореализации. Задача максимум — принести пользу компании, вдруг человек придумал бы новый Agar.io.

Как это работало

В отличие от того же Google, мы в HeroCraft не могли еженедельно выделять сотрудникам целый день. У каждого геймдизайнера в отделе были свободные полдня в неделю для работы над его собственным проектом.

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

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

Результаты

Мы проработали по этой методике более полугода. Результаты оказались хуже ожидаемых:

1. Все геймдизайнеры стали писать концепты, только концепты и ничего кроме концептов. Никто не захотел сделать свою настолку или поэкспериментировать с игровыми редакторами.

2. Вследствие первого пункта, сотрудники приобретали ограниченное количество новых навыков: написание концепта, создание презентации, выступление перед аудиторией с защитой проекта.

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

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

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

Выводы

Я ошибся с начальной вводной.

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

Сама идея свободного времени и собственных проектов также дискуссионна. Тот же Google, по слухам, отменил это «правило 20%» ещё в 2013 году. О жизнеспособности этой идеи в иных форматах, например, внутристудийных геймджемах советую послушать всем известный подкаст.

Так или иначе, уровень свободы я решил уменьшить.

Идея и цель

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

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

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

Как это работало

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

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

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

Поначалу собрания были обязательными для геймдизайнеров и тестеров, люди из других отделов приходили добровольно.

Результаты

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

Тем не менее, результатами я остался доволен. Геймдизайнеры начали играть на смартфонах и планшетах систематически. Даже после отмены докладов, привычка у них эта сохранилась.

Выводы

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

Нужно было что-то более долгоиграющее, не вызывающее привыкания.

Идея и цель

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

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

Как это работало

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

Почти всегда озвучивался какой-то официальный инфоповод: текущая или запланированная на ближайшее будущее реальная проблема одного из проектов компании. Иногда проблема ставилась более отвлечённая, в области R&D или долговременного планирования. Так или иначе, главной задачей собрания оставался тот опыт, который люди получали непосредственно при проведении мероприятия. Решение проблемы имело второстепенное значение.

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

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

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

Результаты

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

Что полезного делают брейнштормы для обучения геймдизайнеров:

— Учат разным подходам в решении задач;

— Показывают разные задачи и проблемы в геймдизайне, о которых джуниор может даже не подозревать;

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

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

Что брейнштормы точно не делают:

— Они не учат конкретным геймдизайнерским навыкам и не передают конкретный опыт решения гд-задач.

Брейнштормы нельзя проводить в формате «привет всем собравшимся, у нас есть вопрос, давайте придумаем возможные ответы».

Структура, формат, тайминг – за всё это отвечает ведущий собрания, и от его подготовки и квалификации во многом зависит успех мероприятия. Я не повторял один и тот же формат собрания чаще одного раза в полгода.

Выводы

Брейнштормы показали себя полезной, но ограниченной практикой.

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

Плюсом также является отсутствие требований к подготовке сотрудников к собранию. Человеку заявлялась заранее тема брейншторма, время на подготовку он не тратил. Однако это компенсируется серьезной подготовкой ведущего.

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

Идея и цель

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

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

Как это работало

Раз в неделю геймдизайнеры собирались, чтобы рассказать об одной из задач, над которой они работали в течение недели. Выступало столько человек, сколько было готово к конкретной встрече (если у человека не было новой или интересной задачи, он пропускал свою очередь).

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

После презентации шли уточняющие вопросы, выливающиеся в небольшие дискуссии.

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

Результаты и выводы

Этот вид собраний я проводил последние свои полгода работы в HeroCraft. На данный момент – это самый эффективный способ передачи знаний внутри компании между геймдизайнерами из тех, что я организовывал.

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