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

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

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

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

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

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

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

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

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

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

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

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

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

Компромиссы

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

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

Иерархия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

224
130 комментариев