Литмир - Электронная Библиотека
A
A

Я это делаю не только в порядке ликбеза, но и для того, чтобы зафиксировать некоторые термины. Дело в том, что в индустрии есть определенные проблемы с терминологией и одни и те же слова порой интерпретируются по-разному. Определение одной и той же специальности может гулять от компании к компании. Как в силу сложившихся практик в конкретном месте в конкретное время, так и из-за въевшихся в мозг ошибочных представлений – причем даже на уровне руководящего состава, а не только среди HR-менеджеров. Я допускаю, что с некоторыми моими определениями согласятся далеко не все. Но как минимум мы их проговорим и обозначим. И не будем путаться в ролях. Это как, например, можно услышать: «У нас команда из трех человек, нам не нужен продюсер, зачем он вообще». Нет, один из вас принимает на себя роль продюсера – просто он об этом почему-то не знает. А вот нужен ли вам кто-то еще на эту роль – это уже совсем другой вопрос. И тут как минимум стоит понимать, что это вообще такое и как это может выглядеть на практике.

Ниже возможные роли на производстве.

Геймдизайнер (Game Designer)

Возможно написание «гейм-дизайнер» (и оно вполне корректно). Придумывает и описывает игровые механики (или детализирует на основе брифов/указаний сверху), отлаживает их, выстраивает баланс, в некоторых случаях может писать скрипты.

Во free-to-play проектах такой человек может иметь сильный математический уклон. Вплоть до того, что является не столько геймдизайнером, сколько узкоспециализированным математиком.

В рамках структуры могут быть свои градации, например: Lead Game Designer, Senior Game Designer или Junior Game Designer. И может быть разное приложение усилий геймдизайнера: от высокоуровневого дизайна до низкоуровневого. Низкоуровневый – это когда человек руками настраивает, скажем, параметры выстрела с точностью до тысячной доли. А потом тестирует. А потом меняет одну цифру. И снова тестирует.

Левел-дизайнер (Level Designer)

Хотя многие считают эту специализацию родственной или вспомогательной по отношению к геймдизайну, на самом деле это отдельная, важная роль, основным полем деятельности которой является аспект взаимодействия игрока (напрямую или же через героя/действующее лицо/протагониста) с игровым окружением и все закладываемые в этот процесс принципы и механики. Если очень сильно упростить, то левел-дизайнер создает дизайн уровней/локаций (потому он и называется левел-дизайнером). То есть он, как правило, руками копается в редакторе и расставляет объекты.

Программист / Разработчик / Developer

Будет безумием запихивать сюда словарное определение программиста – вы и так понимаете, о чем идет речь. Но нужно сделать пару важных пояснений. Программист работает не в вакууме и не является знатоком всех языков мира. У него есть специализация – и возможность ее изменить и расширить. Самые распространенные языки в игровой индустрии – это C++ и C#. Можно еще упомянуть Java, но в целом это все производные от С.

Программисты работают в программной среде и – если не пишут собственный движок – то внутри какой-то конкретной технологии. И, соответственно, владеют инструментарием этой технологии. Во-многом поэтому их зачастую и называют девелоперами – их работа сводится не только к написанию кода. Более того, существуют девелоперы, которые, строго говоря, не совсем программисты. Например, они хорошо понимают Unreal Engine 4, но скриптуют на Blueprints, а C++ не просто не используют, но даже и не умеют.

Как уже будет отмечено далее по тексту, если вы ищете программиста, то вам следует учитывать конкретную специфику и нюансы. Например, если у вас Unreal Engine 4, то может быть целесообразнее искать программиста на C++, а не «UE4-программиста». С технологией, если что, познакомится, освоит.

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

Технический директор

Может называться CTO (Chief Technical Officer). Как правило, сам является программистом/разработчиком высокого уровня (ну или как повезет). Хорошо знает технологический стек и, собственно, формирует его. Это главный «технический» человек на вашем проекте.

Product Owner

В случае Product Owner и Project Manager используется, в общем-то, терминология методологии SCRUM (и производных от нее). Product Owner (условный «владелец продукта») формирует задания (фичи, user stories[9], называйте как хотите) и отдает их человеку-функции с названием Project Manager («проектный менеджер» или «управляющий проектом»). Тот рубит это все на мелкие куски, ставит в план и раздает задания конкретным специалистам.

Должности Product Owner почти никогда и нигде не существует. Это именно роль. Ее в том или ином виде почти всегда принимает главный идеолог проекта.

Проджект-менеджер (Project Manager)

См. выше. В голом виде является прорабом. Или ответственным секретарем редакции газеты. От него требуется понимать пайплайн производства – кто чем вообще занимается. В стандартной конфигурации от него совершенно не требуется что-то выдумывать или во что-то играть. Он реально может быть человеком со стройки, которого хорошо проинструктировали по поводу специфики отрасли. В некоторых IT-компаниях вам могут рассказать, что это не совсем так, и вообще ему желательно иметь техническое образование и сертификаты PMBOK или типа того. В целом это неправда.

В реальности многие компании подразумевают под проджект-менеджером что-то свое, иногда уходящее в мультикласс. Или даже называют этих менеджеров как-то по-другому. Зафиксированы случаи, когда издатели мобильных игр называли проджекта с элементами аналитика «продюсером оперирования».

Продюсер (Producer)

Загадочная специальность, функционал которой бывает очень разным в зависимости от компании и даже конкретного проекта. Упрощенно – это арбитр в спорах между всеми другими специалистами/отделами на проекте или же в конкретном секторе проекта. Человек, который говорит, «что такое хорошо, а что такое плохо».

На практике внутри физического человека-продюсера может быть зашито еще несколько ролей. Например, он очень часто (а в маленьких студиях – всегда) бывает в той или иной степени геймдизайнером. Обычно высокоуровневым. Вплоть до совмещения в своем лице должности главного геймдизайнера. Он может быть носителем vision (видения) и, соответственно, нести на себе функционал описанного выше Product Owner и описанного ниже креативного директора. Отчасти он может заниматься работой арт-директора (или человека, который корректирует работу арт-директора). Во многих случаях он может превращаться в персонажа «в каждой бочке затычка». Иногда это хорошо и удобно, потому что быстро устраняет проблемы. Иногда это очень плохо, потому что он попросту начинает мешать людям работать, вместо того чтобы периодически их направлять и вообще поменьше отсвечивать.

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

Внешний продюсер

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

вернуться

9

User stories (пользовательские истории) – способ описания требований к разрабатываемому продукту. Это 1–2 предложения, что называется, на языке пользователя. – Прим. ред.

5
{"b":"698866","o":1}