Стать геймдизайнером: ожидания и реальность

В двух предыдущих статьях моей целью было дать рекомендации желающим найти работу геймдизайнера. Теперь я буду активно вас отговаривать от этой идеи.

Стать геймдизайнером: ожидания и реальность

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

Кстати, рекомендую ознакомиться с двумя предыдущими статьями: раз, два.

Будет много неологизмов, вроде "фичекат" или "лид". Тем у кого подгорает предлагаю подорожник и лучи добра <3
Будет много неологизмов, вроде "фичекат" или "лид". Тем у кого подгорает предлагаю подорожник и лучи добра <3

Работа в движке

Начнем с того, что 90% вашего времени будет уходить на имплементацию. В любой крупной компании подразумевается, что дизайнер будет отлично знать игровой движок и сам реализовывать свои фичи. (Почитайте вакансии тех же Naughty Dog – там даже от рядового геймдизайнера ожидают наличие навыков левел- и техдизайна). К сожалению, слишком много моих бывших коллег всеми силами старались избежать работы с движком, обосновывая это тем, что «я чисто по креативу». Давайте взглянем правде в глаза – креативными директорами и лидами становятся единицы, для этого нужен колоссальный опыт и оригинальное мышление. И уж можете не сомневаться, большинство из них много лет проработали в движке, прежде чем получить высокую позицию.

Итеративность

Помимо имплементации, наша работа подразумевает итеративность: придумал, попробовал, переделал. Повторять пока не будет идеально. Звучит достаточно просто, но вот это «попробовал» подразумевает, что фича будет реализована и отлажена, а это стоит ваших усилий. За это время успеваешь к ней привязаться, и заставить себя отказаться от первоначальной идеи очень тяжело.

Отличный пример такой итеративной работы это Dota Underlords: пока игра была в бете, она претерпевала серьезные изменения. Взять даже самих андерлордов (юнит-командир, которого можно выставить на поле вместе с остальными). В одной из итераций у них была проработанная система способностей: заклинания на выбор, таланты, билды, иконки, описания. В следующий итерации они заменили систему ресурсов для андерлордов, что повлекло исправление некоторых заклинаний и предметов. А потом и вовсе убрали все таланты, и теперь ты просто выбираешь андерлорда с фиксированным набором способностей. И это только то, что мы увидели в релизных сборках. А на каждый релиз приходится несколько внутренних итераций, где идеи тестируются и вырезаются, так и не попав в билд. Даже для игроков, полюбивших ту или иную мету, такие перемены бывают болезненными, а представьте какую боль испытывают люди, которые делали эту фичу!

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

(с) Альберт Эйнштейн
(с) Альберт Эйнштейн

Компромиссы

Еще один момент, способный вызвать удивление и негодование – это необходимость компромисса с технической стороной проекта. Открою страшный секрет – программисты не хотят делать вашу фичу не потому, что они не понимают гениальной задумки, а потому что им нужно, чтобы игра работала. Хороший программист будет казаться неопытному дизайнеру ленивым бездельником: он выслушает, покивает головой, а потом объяснит, как реализовать желаемое через настройку данных, а не через написание кода. Для дизайнера это означает лишний день (или месяц) работы, и желание обругать коллегу нехорошими словами будет очень велико. Но задача программиста – сохранять системность игры, и он со своей задачей справился. Без подобных компромиссов, игра превратится в кучу костылей и некоторые баги будет невозможно исправить, а уж про оптимизацию и говорить не приходится.

Но есть и каста Тёмных Программистов, которые имеют своё видение игры, и будут пользоваться тем, что лучше знают техническую часть, чтобы резать фичи, которые им не нравятся, не пытаясь обсудить варианты. Чтобы такого не происходило, нужно набираться опыта и уметь задавать правильные вопросы, отличая субъективное мнение от фактов. Если все пойдет хорошо, вы будете расти, а Тёмные Программисты (сокращенно ТП 😉) – нет. И все останется в прошлом.

Иерархия

Ну вроде все идет неплохо – мы работаем в движке, сами реализуем свои фичи, не боимся отказываться от слабых идей, научились придумывать фичи так, что ведущий инженер просто кивает и говорит «ок, сделаем». А тут приходит руководство, и выясняется, что надо всё переделать. В такие моменты начинающий дизайнер может почувствовать, как под ним плавится стул. Да и опытный тоже, что уж греха таить. Но реальность такова, что такие ситуации происходят достаточно часто и это абсолютно нормально, и более того идет на пользу проекту. Тут надо понимать несколько моментов. Во-первых, этот человек несет основную ответственность, и будет отдуваться за возможные неудачи, поэтому он и принимает решения. Так работает иерархия. (Конечно, чем больше ты даешь свободы своим подчиненным, при условии, что им доверяешь, тем лучше для тебя самого, но этот момент мы тут опустим). Во-вторых, рекомендую исходить из того, что руководитель все-таки лучше видит ситуацию. Да, конечно, есть случаи, когда новичка-самородка не оценивают по достоинству, но в большинстве случаев, лид говорит дело и к нему стоит прислушаться. Все вышесказанное не означает, что не нужно пытаться защитить свою версию. Конечно нужно! Ведь именно в процессе обсуждения находятся самые лучшие решения. Просто нужно здраво оценивать ситуацию и открыто воспринимать обратную связь, даже если бывает больно.

Стать геймдизайнером: ожидания и реальность

Цикл разработки

На десерт я оставил самое сладкое: цикл разработки больших проектов. Ммм… Давайте вместе взглянем на собирательный образ.

Ты попадаешь на большой проект – колоссальная удача! Ведь многие месяцами рассылают резюме по студиям – и безрезультатно. Если тебе достается фича на разработку – это вообще праздник, ведь мог бы заполнять таблички три года. Ты садишься, собираешь референсы, формулируешь для себя основные ориентиры и пишешь первый диздок. Его зарезают, ты плачешь. Повторить 2-3 раза. Теперь диздок готов. Начинаем имплементировать.

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

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

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

Результатом первого этапа разработки является альфа-билд – вертикальный срез игры, демонстрирующий основные фичи. (В некоторых студиях таким билдом является «first playable», а альфой называют более проработанную версию. Предлагаю тут не углубляться в терминологию).

Когда говорят, что «проект прошел альфу», это означает, что люди, отвечающие за финансирование, верят, что проект интересен аудитории и способен заработать денег. Поэтому принимается решение двигаться дальше в заданном направлении. Дальше следует основной продакшн. Для дизайнера это означает разработку фичи вширь. То есть если за альфу ты реализовал как игрок дерется с мечом, молотом и луком, то теперь тебе нужно поддержать копье, глефу, кинжалы, и кучу другого оружия; если за альфу ты сделал пять танков – теперь делаешь остальные тридцать. Этот этап завершается бетой, и как правило он длится дольше альфы. Он уже не так интересен – все фичи придуманы, нужно планомерно клепать контент, что бывает достаточно скучным занятием. Тем не менее в нем есть некая прелесть, ведь этот период, пожалуй, самый спокойный в разработке: границы определены, глобальных переделок не предвидится, а новый контент ты все еще производишь… Но это лишь затишье перед бурей, ведь дальше следует багофикс.

​Чистая правда
​Чистая правда

О, багофикс… Тут мне следовало бы написать стихи, чтобы добавить драматизма, ведь это самое страшное что есть в геймдеве. Каждый день ты приходишь, и пытаешься заставить свои фичи работать как надо. Беда в том, что параллельно инженеры занимаются оптимизацией и какие-то куски кода могут просто переставать работать. И тебе приходится заново настраивать то, что не должно было ломаться. А потом… «Знаешь, мы поняли, что отображать больше пяти NPC одновременно слишком затратно по производительности, поэтому групповой бой придется вырезать». А у тебя на этом строился бой с боссом. И в течение последний полутора лет ты был уверен, что так и будет.

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

А еще тебе нужно найти и починить потенциальные эксплоиты. Как игрок я их просто обожаю: протиснуться через текстуры, сократить кусок игры, добраться до лута на десять уровней раньше, чем хотел дизайнер… Кайф! Чувствую, что обманул систему! Но как дизайнер я ненавижу всех вас (и себя-игрока) за то, что мы на это способны. Такие баги очень специфичны и правятся труднее всего и иногда ломают основную логику.

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

Мне повезло - мой самый долгий багофикс длился всего год (ВСЕГО), и у нас почти не было кранчей. Я уходил спать домой, счастливчик. Как выглядит настоящий кранч, вы можете почитать в статьях про тот же Naughty Dog. Так что в следующий раз, когда будете в церкви – поставьте свечку за тех, кто кранчует, ну либо накатите стопочку в баре, в зависимости от вероисповедания.

Стать геймдизайнером: ожидания и реальность

Что же я могу тебе сказать в итоге, друг? Это тяжелая и неблагодарная работа. Тяжелее чем у яжматерей, но, впрочем, гораздо легче, чем у шахтеров. Очень много креатива попадает в мусорное ведро, очень часто придется отстаивать своё видение, а потом очень долго и мучительно его реализовывать. Бессонные ночи, подгоревший пукан – ради чего? Чтобы увидеть в титрах фамилию с опечаткой? Да брось ты это ерунду.

Но вот если от прочтения у тебя не опустились руки, а загорелись глаза, возможно, стоит попробовать.

2727 показов
15K15K открытий
155 комментариев

тут надо понимать несколько моментов. Во-первых, этот человек несет основную ответственностьВообще, ответственность на ПМ'е.
Конечно, чем больше ты даешь свободы своим подчиненным, при условии, что им доверяешь, тем лучше для тебя самого, но этот момент мы тут опустимПрограммист не в подчинении у ГД, они напарники. Да и в общем и целом, все работающие должности - напарники.
Беда в том, что параллельно инженеры занимаются оптимизацией и какие-то куски кода могут просто переставать работать. И тебе приходится заново настраивать то, что не должно было ломаться.Такого не должно быть, если фичи пилятся в отдельных ветках. Нужно смотреть стабильную ветку.
А потом… «Знаешь, мы поняли, что отображать больше пяти NPC одновременно слишком затратно по производительности, поэтому групповой бой придется вырезать». А у тебя на этом строился бой с боссом. И в течение последний полутора лет ты был уверен, что так и будет.Интересный процесс разработки, если об этом узнали лишь через полтора года.

Ответить

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

Ответить

сам реализовывать свои фичи. (Почитайте вакансии тех же Naughty Dog – там даже от рядового геймдизайнера ожидают наличие навыков левел- и техдизайна)Ну всё, в Naughty Dog не попасть, расходимся)

Ответить

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

Ответить

  всеми силами старались избежать работы с движком, обосновывая это тем, что «я чисто по креативу»

Ответить

Комментарий недоступен

Ответить

Забыл сказать что в рашке, ты даже эти "шаги" работы геймдизайнера - невыполнимы. Точнее их просто не будет. Ваша судьба дорогие мечтатели... Это выдрачивать очередные мач3 клоны до потери пульса по заезженной схеме. Любой отказ = увольнение. Удачи.

Ответить