От геймдизайна до геймплея
Итак, после долгих трудов и размышлений, чтения статей, может быть даже моей предыдущей, после анализа опыта конкурентов, общения с коллегами-геймдизайнерами за чашечкой кофе (или кружкой пива?), прототипов и итераций — дизайн-документ небольшой фичи или целой игры готов. Победа?! Как бы не так. :)
В этой статье речь пойдет о том тернистом пути, который проходит геймдизайн от документа до реализации в игре, причем как раз с позиции самого геймдизанейра. Как и в прошлой статье, не ставится задача детально показать весь процесс. Текст ориентирован на тех, кому интересен опыт работы геймдизайнера в крупной команде.
Если геймдизайнер не является креативным директором либо руководителем игрового направления, то есть так или иначе главным в относительно независимой студии-разработчике (иначе нередко нужно одобрение издателя), то его документу предстоит пройти этап одобрения. Работает это везде по-разному. В Allods Team, например, после устного обсуждения на почту отправляется письмо (с оформленной по шаблону темой) с дизайном. В Obsidian Entertainment креативный директор ставит одобрение в JIRA. Бывают и устные одобрения, и обязательные собрания для «приемки дизайнов», в которых участвуют геймдизайнеры, а также продюсеры и руководители команд.
В любом случае, стоит помнить три правила.
- Если некий процесс «одобрения» существует, то лучше постараться ему следовать.
- Необходимо расставлять приоритеты. Нередко на рассмотрении у одобряющего находится десяток «сложных и спорных» дизайнов, и не всегда возможно выделить время на рассмотрение всего объема. Поэтому про дизайн, важный для проекта, стоит напоминать чаще, а вот дизайн небольшой фичи на следующий год может подождать. Но совсем забывать о последнем не стоит, иначе он может вообще никогда не реализоваться.
- Воспринимать критику конструктивно, понимать ее предпосылки и устранять проблемы системно, а не просто делая «как сказано». Часто начинающие геймдизайнеры вместо того, чтобы вникнуть, почему это неправильно и как сделать лучше, работают по принципу «скажите, как сделать, я все посчитаю», либо наоборот — спорят просто из любви к спору. Подобное поведение мало способствует профессиональному и карьерному росту. Если в дизайне имеется какая-то ошибка, необходимо понять, почему она допущена, чтобы больше не повторять. Только накопив достаточный опыт, вполне можно дискутировать с «принимающими», если, конечно, есть весомые аргументы. В конце концов, ошибаться могут все.
Срок прохождения данного этапа может занимать от нуля (когда одобрение не нужно) до нескольких недель, в зависимости от ситуации. Любопытно, что в некоторых компаниях устанавливаются жесткие временные рамки на ответ о принятии или об отказе в дизайне. Если ответа в течение, скажем, пяти рабочих дней не последовало, то дизайн считается принятым и может идти в работу. Конечно, эта система приводит к курьезным ситуациям, но количество дизайнов в непонятном статусе резко уменьшается.
На этом этапе часто полет фантазии сталкивается с жестокой реальностью спринтов, майлстоунов, заболевшими программистами, отсутствием ресурсов и проч. О процессе планирования написано много статей и книг с позиции менеджера, и, к счастью, обычно простому геймдизайнеру досконально в нем разбираться не нужно, а когда потребуется — опыта будет достаточно. Тем не менее даже на простом уровне стоит уметь избегать некоторых крайностей, или хотя бы поднимать тревогу при их обнаружении.
«Давайте отрежем пару человекомесяцев разработки» — нередко геймдизайнер слышит такие слова от «мясника» — руководителя или продюсера в условиях нехватки ресурсов, необходимости тестирования и прочего. Здесь правило простое: к ним надо быть готовым. Еще до фазы планирования нужно понять (а лучше задокументировать), какие компоненты фичи/игры критически необходимы, какие стоит отрезать только при крайней необходимости, а какими можно и вовсе пожертвовать. Зачастую для понимания этого нужно хотя бы минимальное представление о стоимости разработки той или иной части, потому как бывает и так, что часть средней важности стоит столько же, сколько десяток менее важных, и в такой ситуации нередко десять частей перевешивают одну.
Аналогично надо понимать, какие части действительно необходимы (так как без них запускаться не стоит) и уметь сохранять это понимание в тяжелых условиях. С позиции формальной логики, если фича объективно не функциональна без части А, то она не начнет работать при ее отсутствии, даже если «иначе сорвем сроки» или «есть более важные задачи на этой команде». На практике, конечно, не всегда существует возможность полноценно отстоять фичу при наличии множества «мясников» (особенно внешних относительно команды разработчика), но предпринимать попытки получения работающего и эффективного варианта это не отменяет. При этом такое «отрезание» (фичекат) — чаще необходимый и полезный процесс, чем вредный.
Существует еще один аргумент: «Слишком дорого, давайте дешевле». Конечно, для геймдизайнов удешевление не всегда означает потерю качества (и в этом случае все хорошо — за счет еще одной итерации удалось получить тот же результат эффективнее), но часто это просто другой вариант «отрезания», когда вместо удаления целой части уменьшается объем сохраняемых. Но правила здесь, по сути, те же.
«Давайте разобьем фичу на 10 фаз»
Альтернативой «отрезания» нередко выступает «разделение», когда сначала игрокам отдается некая базовая часть фичи, через какое-то время — ее расширенный функционал, и т.д. Такой подход весьма рационален, так как помимо общего удобства планирования и более ранних сроков попадания игры к игрокам появляется больше времени на «живое» тестирование и возможность вовремя сменить курс разработки. Но в нем легко допустить ошибки.
В отличие от геймдизайнера и продюсера, игрок не будет задумываться о том, что стены замка строить пока нельзя, потому что программисты обещают функционал в движке через два месяца. Вместо этого он напишет на форуме: «Зачем ввели эти замки? Только построил, а стены возвести нельзя… Какие-то школьники пришли и все снесли. Верните деньги!». Грамотное разделение на части дает игрокам интересный геймплей на каждом этапе и заставляет с нетерпением ждать следующего. Сделанное неправильно — вызывает только раздражение недоделкой и разочарование в каждом последующем этапе, с комментариями вроде «уже год сделать как надо не могут».
Feature Creep (https://en.wikipedia.org/wiki/Feature_creep) — да, он существует и на этом этапе!
Удивительно, но иногда для крупных фич возникают ситуации, когда «есть свободные ресурсы у художников, и занять больше нечем» или аналогичные «ресурсные». Причины могут не быть связаны с ценой разработки напрямую, например, «это же крутая фича, нужно рассказать о ней маркетологам, надо вот тут добавить, чтобы выглядело лучше!» или «на этой механике мы еще призванную нежить у некроманта соберем!».
Такое можно обратить в пользу, а можно и во вред. Главное — сохранять целостность фичи, дополняя ее полезным, а не раздувая фичекрипом, требующим больших усилий при отсутствии пользы для проекта. Помните: фичекат близко!
Нарушение взаимосвязей и причинности
В идеальном мире фича будет распланирована так, чтобы ни одна команда не блокировала другую, а приступать к тестированию можно было бы как можно раньше. Реальность же темна и полна ужасов. Хотя подобное — прерогатива менеджеров разного рода, геймдизайнеру участвовать тоже нужно, по крайней мере, чтобы проверить последовательность отдачи компонентов фичи. Потому что часто только он полностью понимает все внутренние связи и может поднять тревогу: «пока не будет функционала для фундамента, стены строиться не будут!».
После преодоления вышеописанных и других проблем на этапе планирования, наконец, может начаться разработка. Здесь наступает первый «порог Франкенштейна»: надо трезвым взглядом окинуть фичу, подвергнувшуюся «удешевлению», «отрезанию» и «добавлению еще функционала сбоку», и понять, что же в итоге получилось. И, при необходимости, попытаться что-то исправить. А затем, когда все готово, не забыть обновить документацию по итогам всех принятых за время планирования изменений.
Для геймдизайнера реализация геймдизайна состоит из двух частей — труда программистов, художников, и других коллег, и работы, собственно, самого геймдизайнера. Второй пункт может показаться со стороны неожиданным, однако, и во многих российских компаниях, и в западных (к примеру, в Obsidian Entertainment, Raven Software, The Workshop Entertainment автор лично наблюдал это явление), геймдизайнеры сами вносят все данные в игру: урон заклинаний, бронирование танков, количество побед для получения достижений и прочее. Помимо данных, на внутреннем инструментарии собираются и скрипты вида «облил маслом — поджег для дополнительного урона». Иногда бывает, что есть отдельный геймдизайнер, вносящий данные в игру, но это скорее исключение, чем правило. Даже в западных компаниях, где очень сильна специализация геймдизайнеров по направлениям, обычно придумавший идею сам вводит данные для нее (конечно, с помощью программистов, где это необходимо). В маленьких командах это тоже распространено, но, как ни удивительно, меньше, нередко можно встретить случаи «исключительно придумывающих» геймдизайнеров.
В крупной же компании обычно всем геймдизайнерам рангом ниже креативного директора (а иногда и ему!) предстоит осваивать инструментарий, разбираться с коммитами в репозиторий, в системах отслеживания ошибок и с прочей технической частью. Описать все это кратко довольно затруднительно, поэтому интересующимся стоит прочитать подробнее самостоятельно, либо прослушать курс «Основы технической разработки проектов», являющийся частью комплексной программы «Менеджмент игровых интернет-проектов».
Что касается работы коллег — программистов, художников и других специалистов, то стоит помнить два основных правила:
- Проверяйте поставленную задачу на соответствие вашему дизайну, читая ее как бы со стороны, и представив, будто вы ничего не знаете об игре в целом или о ее дизайне. Нередко технические специалисты (в том числе, хорошие) могут и не догадываться о существовании в игре каких-то фич, принятых практик и т.д. И если задача не сформулирована с учетом этого, результат крайне отличается от предполагаемого.
- Вопросы исполнителей «что именно сделать» — это хорошо, и отвечать на них стоит быстро и точно. Есть, конечно, обратная ситуация, когда уточняющих вопросов задается слишком много. В этом случае стоит понять, где именно проблема — в написанном дизайне, в донесении видения игры и конкретных фичей до исполнителей, или в конкретном сотруднике? Только поняв это, можно осознанно решать проблему. Чего точно не стоит делать, так это игнорировать подобные вопросы или советовать разобраться самим.
По мере реализации нужно как самому тестировать то, что получается, так и помогать в этом вопросе QA, указывая на слабые места, которые нуждаются в дополнительной проверке, и отвечая на вопросы. Раннее тестирование позволяет легко определить потенциальные проблемы и устранить их.
Нередко в компаниях существует практика, когда геймдизайнеры, по крайней мере не самые младшие, также становятся своего рода «владельцами фичей», придуманных ими, и поощряется наблюдение за их разработкой. К примеру, геймдизайнер может подойти к любому исполнителю по задачам для его дизайна, запросить статус, узнать текущие приоритеты и даже свободно менять их внутри задач по своей фиче (к примеру, «сделай сперва поддержку в коде для новой абилки босса, чтобы мы ее потестили, а потом уже чини баг с лутом с него»). Таким образом, геймдизайнер становятся немного продюсером для своей фичи.
В итоге однажды настает день, когда фича сделана, протестирована, и готова к отдаче игрокам. На этом этапе, однако, есть еще несколько задач для геймдизайнера: проверить процесс ее представления аудитории (в Patchnotes, в статьях «в разработке», в превью игры и т.д.) и затем следить за тем, как она работает по собираемой статистике. Некоторые фичи делаются однократно еще до запуска игры и потом практически не меняются. Но многие, включающие в себя понятия вида «баланс игровых классов», «внутриигровая экономика», «социальные активности», могут меняться много раз за весь срок жизни проекта. Для них нужно уметь работать и со статистикой, и с отзывами игроков, чтобы принимать правильные решения.
Читатель может увидеть своего рода противоречие: если геймдизайнер одновременно должен уметь технически работать с инструментарием, понимать приоритеты как продюсер, находить потенциальные проблемы как QA, воспринимать настроения игроков и разбираться в статистике — как можно все это совмещать? И при этом, собственно, писать дизайны?
Здесь и кроется второе по важности умение геймдизайнера (после умения придумывать игру) — не пытаться быть одновременно всеми участниками разработки, а правильно понимать ситуацию, управлять ею, в меру своих сил, и исправлять проблемы.
Очень сложная в понимании для игроков механика, которую нельзя упростить? Стоит помочь коммьюнити-менеджеру написать статью о ней.
Фичу сложно протестировать? Стоит помочь QA-отделу.
В фиче множество компонентов со сложными взаимосвязями, в плане как последовательности разработки, так и возможности запустить фичу без них? Стоит проследить за приоритетами этих компонентов у исполнителей.
Даже у сложных фичей в конкретный момент времени редко бывает более двух проблемных направлений, и если не распылять силы там, где все складывается само, то доведение фичи до готовности не столь уж трудоемко.
Нужно также уметь справляться с психологическим искушением «пусть делают, как хотят, я все круто придумал, а если что не так, виноваты они». Да, может быть, психологически удобно не вмешиваться в реализацию дизайна, а потом сказать: «все сделано не как в моем дизайне, сроки провалены — неудивительно, что все плохо», но… Такое обычно не срабатывает в долгосрочном плане.
Конечно, утверждается, что в маленьких dream-team-командах бывает так, что исполнители понимают все с полуслова, сроки не срываются (или свободно отодвигаются), QA находят все проблемы баланса сами, а в патчноутах нет ошибок — можно просто творить! Однако слово «dream» здесь ключевое, и практически в любой крупной компании, как российской, так и западной, придется столкнуться с суровой действительностью. Но даже попав в «команду мечты», вышеописанные навыки разработки рано или поздно пригодятся. Ведь как писал Лао-Цзы: «Под небом все лишь временно бывает».
В заключение хочется добавить простое наблюдение: хотя вначале практическая работа геймдизайнером кажется сложной, но если все делать правильно (что на начальном уровне и описывают предыдущая и эта статья), все трудности преодолимы. Главное их не бояться.
