Руководитель проектов Game Insight о типах игровых разработчиков: «Взрослый», «фестивальщик» и другие

Отправляем письма
с главными игровыми новостями недели

Руководитель проектов студии Game Insight Максим Вознюк написал для рубрики «Рынок игр» колонку, в которой описал основные типы игровых разработчиков (программистов, геймдизайнеров и художников), встречающиеся в игровой индустрии. Вознюк рассказал, в чём плюсы и минусы каждого типажа, и от кого лучше сразу избавляться.

Разработка, как это не избито звучит, — командная работа. Результат в первую очередь зависит не от технологий, идеи или планов. А от людей, которые работают над проектом, их навыков, характера и мотивации. Постараюсь коротко пройтись по основным типажам в разработке и оценить их полезность для проекта. Так как последние 12 лет я занимаюсь разработкой игр, то в основном речь пойдет о команде для игрового проекта.

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

Игровая разработка, по сути, имеет три основные составляющие: программирование, арт, геймдизайн. Рассмотрим специалистов по каждому направлению.

Программисты

Программист «код говно, я перепишу, и все будет хорошо»

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

Зачастую это поведение программиста, у которого мало опыта и ему сложно разобраться в чужом коде. Либо просто лень, и он считает, что проще переписать. Допускать его к переписыванию всего и вся не стоит, так же, как и к сложным задачам. Бывают исключения, когда действительно код — говно, и нужно отрефакторить, но тогда должно быть чёткое понимание, что это даст, и установленные сроки.

Программист «не шалю, никого не трогаю, починяю примус»

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

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

Программист-«живчик»

Любит интересные задачи, бросается на них и сидит допоздна, но быстро теряет интерес и киснет на рутине. Если у вас нет достаточно интересных задач и вы просто делаете клон Clash of Clans, то вам не по пути.

Программист-«геймдизайнер»

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

Программист-«идеальный код»

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

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

Программист-«взрослый»

Уже закаленный несколькими выпущенными проектами, многое видел и знает. Работать с ним приятно и полезно, не спорит по мелочам, дает взвешенную оценку и критику, не зарубается за «идеальный код», но винегрета на проекте не допускает, идет на компромиссы и понимает цели и задачи. Идеально подходит на роль техлида проекта, при том что может программировать хуже других. Есть небольшой недостаток — таких программистов мало.

Арт

Художник «напишите мне ТЗ»

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

Художник «вы мне скажите, что рисовать»

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

Художник «я творец»

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

Художник «не буду переделывать»

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

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

Художник-профессионал

Ему не нужно рассказывать, как должен выглядеть персонаж, достаточно описать образ, который в него закладывается. Сразу рисует несколько вариантов по задаче. Легко переделывает и дорабатывает, причем готов отрабатывать комментарии вида «какой-то он кривой», «не радует», «я не смогу его продать за $10». Чувствует игру и задает стиль.

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

Геймдизайн

Геймдизайнер-«генератор идей»

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

Брать таких имеет смысл, только если есть желание и силы заниматься долгим и трудным обучением, но я бы не рекомендовал.

Геймдизанер «я придумываю, вы делаете»

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

Геймдизанер «мой проект»

Очень щепетильно относится к своим решениям. Готов спорить до хрипоты, отстаивая, что этот юнит будет синим, а не голубым, а тут лучше коэффициент 1,5, а не 1,4. Считает проект своим детищем. Всё должно быть как он видит, иначе ничего не получится.

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

Геймдизайнер «толковый»

Понимает механики игр не на уровне «сделаем как у Clash of Clans», не понимая, как собственно у Clash of Clans это работает и почему решили так делать. Видит проект в целом, понимает, как устроена разработка (немного программист, немного художник), не чурается рутинной работы, пишет документацию и при переделках правит её. Много играет в разные игры, а не говорит «free-to-play-механики по выкачиванию бабла, я в такое не играю».

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

Общие типы разработчиков, которые встречаются на всех направлениях в равной степени

«Свой проект»

Человек работает с вами на проекте, но при этом грезит своим.

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

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

«Фестивальщик»

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

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

«Игры — для детей»

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

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

#продюсирование

Комментарии
Последние Лучшие
Прямой эфир
Лучшие материалы
Посмотреть все
Узнавайте первым
о важных новостях
Мы будем присылать вам только срочные уведомления в браузере
Хидэо Кодзима покинул Konami и перешел в Sony
Хочу знать!
Не нужно