Сценарий вертикального среза

Документ, о котором пойдет речь, можно безвозмездно СКАЧАТЬ.

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

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

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

Игра и в каком-то смысле подготовительный период препродакшна — это сначала попытка рекомпозиции, а затем декомпозиции мира со своим языком, правилами и условностями.

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

А этот документ — это выжимка, или как говорит наш друг Андрей Белецкий: “Если это торт “Наполеон”, то это — кусочек, отрезанный на 5%”. Этот кусочек хорошо описан. И вот об этом мы сегодня поговорим, и я покажу, как это делается. 

Чтобы пояснить, как работает формирование бэкграунда документации и функциональных спеков, давайте снова обратимся к нашему многострадальному Bloodlines. Для тех, кто не в курсе — это такой сеттинг, по которому я придумываю всякое: от настольных игр до каких-то рассказов, блогов и т.д. Периодически мне с этим помогают разные люди. В какой-то определенный момент мы с моим товарищем Вовой Аникиным работали в Днепропетровске, и он был начинающим геймдизайнером (сейчас он делает мега мощный дизайн и работает в компании Wargaming). Вместе собирали команду и начинали делать игры. В какой-то момент мы сели и начали писать документ про мир Bloodlines и, собственно, дизайн-документ. Функциональная часть была написана в четыре руки. По ней можно понять несколько вещей. Первое, что мы отбитые упорыши, а второе — не нужно пугаться, потому что это написано за очень длительный срок, за большое количество свободного времени и часть вещей там далека от совершенства. 

Называется он BL_FULL и именно на этот документ мы опираемся, составляя следующий документ. Это — мастер документов, в который сведены все вещи. Первая крупная часть — суммаризация, функциональные спецификации, базовое описание, большой блок описания версий (как документ прогрессировал — на 45 страниц), описание сеттингов и всего-всего, что есть в игре. Способности, абилки, интерфейсы, сущности сеттинга, RPG-систем, исследований, сценарных элементов, разнообразных противников и различных спецификаций... Фактически, это декомпозированный мир, который состоит как из литературных, так и функциональных элементов. Я не буду никому этот документ отдавать, просто уточню, что тут где-то 470 страниц.

Важно понимать, что вот такой документ есть, чтобы начать смотреть следующий. Сначала нужно сделать весь этот объем работ.

Второй документ — VS_Document, который адаптирован и именно его мы сегодня разбираем (не забудьте его скачать с нашего сайта). Это режиссерский сценарий на 15 минут игры. Он кросс элементный: там уже собраны какие-то функциональные штуки (элементы сценария и описание персонажей), но основная фишка в том, что когда у вас есть функциональная спецификация со всеми элементами — это абстракция. Наверное, абстракция, иначе вы не опишете мир. Это должно существовать вне понятий пространственно-временного континуума. Это отдельные существующие элементы. Вот в этом документе они увязываются в эту самую последовательность, чтобы реализовать те самые 15-20 минут геймплея с учетом всего того, что написано до этого. В этом смысле это какая-то “набирайка”: этот документ не оперирует идеями, предположениями и гипотезами. Он оперирует только утвержденными и санкционированными в рамках препродакшена фичами, элементами, персонажами и так далее, которую уже размасштабировали документально на всю игру. Я буду повторять это несколько раз, это очень важно.

Если вы начинаете вбрасывать в демо элементы, которые не являются частью вашего плана — вы стреляете себе в ноги. 

Структура здесь примерно такая: Общее описание демонстрационной версии игры, общая длительность — 10 минут (мы планировали примерно настолько), что это такое, как это работает, какая общая преамбула, какое оружие, специальные навыки. За каждым из этих предложений стоит что-то в funcspec.

Дальше движемся уже во времени и пространстве: мы находимся практически в ботинках игрока. Фактически, это ревью несуществующей версии, опирающейся на документацию: пробуждение, диалог, базовое описание, где это происходит, из каких функциональных элементов состоит, какие из этих элементов позволяют производить интерактивные действия, что конкретно там расположено, какая мотивация за этим стоит, что можно поделать. И здесь такая классика: мы приходим в себя, если кто играл в Deus Ex, то это квартира Адама и там можно делать разные штуки. Туториал зашит в эту историю, можно пойти в тренировочную комнату пострелять, можно пойти поразвивать персонажа: мы даем сразу какое-то количество очков. Можно использовать абилки, найти немножко лора, до момента диалога с персонажем и напарником — один из ключевых элементов игры. По триггеру, когда мы принимаем решение, происходит сцена с диалогом и рассказывается, что надо сделать.

Функциональный элемент — подготовка к заданию. Элемент 6 начинается после block-out block-in само задание. Происходит диалог на старте: есть улица, где мы подходим к этому всему. Дальше, когда начинается активная игровая зона, в которой происходит действие, есть схема, направляющие, описаны все функциональные элементы — все это отдельно расписано и прописано, что игрок может, а что не может. Пользуйтесь таким элементом, когда составляете такую штуковину, чтобы ставить себя на место игрока и проводить двойной чек того, что вы делаете. 

Далее идут пункты: главный вход, интерактивные объекты, диалоги, холл, как на его территории патрулируют противники, каким образом это коррелирует с фичей, которая отвечает за detection — это опять же все в документе. Потому что если у вас этого нет, и вы просто делаете эти штуки без описания механик и фичей — вы делаете некий wishful thinking: идете по обратному пути. И вместо решений, вместо того, чтобы собирать все вместе и фокусировать, вы наоборот расфокусируете. Затем идет второй этаж, еще один кусок карты, и завершение, фактически с полным описанием сцены, действий, возможных действий: что игрок может сделать, а что — нет. Также документ оперирует в своей базовой игровой части, трехактной структуры и есть кульминация. План карт, который нужно будет потом собрать в движке, есть концепт-арт всей этой истории, и на этом документ заканчивается. 

Этот документ вам нужен также как и чек-лист.

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

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

Я уже вижу, как кто-то шутит про 500 страниц. Скажу так: я не любитель больших бизнес-планов, потому что бизнес не запланируешь особо, это можно сделать только при наличии стратегии, тактики и и управления риском. Когда дело касается производства, каждая лишняя прописанная страница и детали возможно экономят вам 100 часов продакшена. После разнообразных опытов в сфере таких игр от третьего лица, которые мы все любим, вроде The Last of Us и Uncharted, считаю, что таким вот образом после вертикального среза должна быть реинтегрирована вся игра. Все игровое пространство должно быть разложено на такие сцены. 

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

Понятно, что будут переделки и что 30-40% этой работы будет изменено — игры так устроены. Но их наличие в изначальном плане способно сэкономить вам кучу нервов, денег и всего остального. Опять же это очень хорошо ложится на декомпозиционный пайплайн. Когда вы отрисовываете скетчи со специфическими ракурсами камер в черно-белые наброски — это все потом можно декомпозировать. Можно работать с пространственной частью, не натупить со скеллингом, примерно понять, как будет строиться восприятие, как камеры будут влиять на нарративное повествование и т. д. Поэтому именно в производственной части чем детальнее изначально написана вся документация обо всем, а в дальнейшем это все интегрировано в более крутой мастер-док при наличии кадрования, тем больше рисков вы снимаете и тем проще это все объяснить команде. 

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

Для меня в какой-то момент стало открытием, что даже при наличии документов вас никто особо не поймет. Во-первых, люди не любят читать 500 страниц текста. Для этого и нужны вот такие интеграционные стадии и сборки. Честно говоря, местами надо заставлять — по-другому просто не работает. Простой способ убедиться, что вы все на одной странице — это наличие документов, кадрования сцен, левел-дизайна, раскадровки и white-box прототипов. При этом, если вы работаете с историей, я также рекомендовал бы ультра модульную структуру, которая позволяет переставлять местами эпизоды, если это необходимо на ранних стадиях и стадиях прототипов. Этим пользуется большинство прямо таких больших студий, когда планируют какие-то истории на вайтбордах и так далее. И когда есть какие-то классические элементы повествования типа погони, кульминации, смены персонажей и т.д. Они по-разному складываются и получается, в принципе, все равно хорошо. Это перекладывание делается тоже на интеграционном уровне и сильно спасает даже еще до концептов. Я добавлю, что когда я говорю о раскадровках, то не имею в виду полновесные цветные скетчи. Направляющих цветных скетчей тоже должно быть нарисовано 50-100, а именно черно-белые раскадровки 2D-шный скетчер должен рисовать условно 20 в день. Раскадровщик — это не концептщик, если вы не в курсе этой разницы. Но наличие этой раскадровки спасает невероятным образом, особенно в случае с играми, связанными с повествованием. 

Теперь ответим на вопросы. 

— 500 страниц на первую спеку.. *бросает клавиатуру о стену*

Не расстраивайтесь. Реакция на это у всех примерно одинаковая. Но это же самые интересные первые 500 страниц, ведь это и есть творческая часть. Она должна заканчиваться на препродакшне и это именно место, в котором можно это прорабатывать, перерабатывать, переделывать. Мне кажется, в этом плане кино повезло. С играми случилось то, что злую шутку сыграли даже не интерактивные технологии, а вышло немного наоборот. Компьютерные игры с самого начала позволяли при наличии какого-то тулсета относительно быстро что-то начать лепить и пробовать. Итерационность — большой плюс нашей сферы. И еще дали движки и реал-тайм. Кино изначально было построено как пайплайн с настолько жестким упором в безумную проработку на уровне препродакшна по очень простым причинам: оборудование даже сейчас стоит больших денег. Оно арендуется большинством студий как на продакшен, так и на съемки на определенное количество дней. Поэтому киношники с самого начала очень сильно ориентированы на пре-продакшн. Из бумаги, лепки персонажиков, расстановки их в безумное количество артов, раскадровок, концептов — из всего этого они выжимают максимум. Человек, который просирает день съемок по своей вине — это человек, который лишает какого-то количества миллионов долларов. Я бы к препродакшну относился максимально серьезно и ценил бы его как возможность проработки любых доступных сценариев, рисков и т.д. У нас почему-то все хотят сразу с шашкой в бой. А нужно бросаться в прототипирование фичей каких-то и так далее, когда у вас базово все написано. Особенно с большими играми. 

— Правильно я понимаю, что вот эти документы делаются после законченного пре-продакшн, то есть есть готовый кор, базовые механики, движения, камеры, они утверждены? Уже прошло несколько месяцев работы только после этого пишутся такие доки?

Нет, неправильно. В финальной спецификации, особенно первичные, пишутся в принципе с самого начала параллельно с прототипированием, тестированием и R&D. Пайплайн — он сам по себе такой, что вы пишете базовый funcspec, он тестируется. Вы проводите R&D на взвеси разнообразные: взвешивается, сколько полигонов вмещается в кадр и в камеру, какие эффекты работают или не работают, отбираются технологии, технический директор заканчивает полностью свою работу и говорит, что можно, что нельзя. Это очень важная substantial data, которая есть на старте. После этого рисуются war части, рисуются направляющие концепт-арты, формируется арт-стиль, арт-библия (называется по-разному, в общем такой базовый документ). Вырабатываются технологии спецификации, и перед тем, как приступать от базовых проб к демке, на этом моменте делается интеграционный документ, вертикальный срез. Он может делаться даже после каких-то внутренних демо-версий, где персонаж просто бегает и стреляет, использует какие-то абилки, но это все вразброс, даже не на боевых уровнях, а на каких-то тестовых картах. То есть просто тестируются фичи, по большому счету. У вас есть карта, которая называется cover system и на ней причудливым образом в 20 конфигурациях расставлены разнообразные укрытия, бегает примитивный искусственный интеллект, который донастраивается и персонаж там конкретным циркачеством занимается вокруг этой фичи. Такие вещи должны быть в процессе и до. Потом делается интеграционный документ и по нему делается вертикальный срез, который впервые похож на игру и является по сути от 0.1-0.5%-5% от финальной игры. Процент зависит от того, кто как делает, и смотря по какому мерилу мерить. 

Интегрировать ли полностью функциональные спецификации со сценариями вот в такой функциональный сценарий — это вопрос. Издатели любят, когда вы так делаете, потому что это хороший инструмент контроля и формирование работы с ожиданием. Команда любит, когда так делают, потому что в целом примерно понятно, как это должно выглядеть в финале. При этом если команда более-менее опытная, она понимает, что на 30-40% все поменяется при нормальной разработке. Если команда неопытная — может вообще все поменяться. Если команда очень опытная — может измениться на 20%. В целом, это позволяет еще нормально построить итерации, отталкиваясь от горизонтального производственного процесса. Вы можете делать white-box’ы, наращивание контента, наращивание фичей слоями, добавлять в конце усовершенствованных фичей, катсцены — все после вертикального среза вплоть до беты и до заморозки релиза, тестирования, возврата и так далее. 

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

— Я в шоке, но теперь понимаю свои проблемы. Я мог сэкономить много времени и делать головоломки интереснее, а не переделывать их десятки раз.

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

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

И у всех этих фичей есть зависимости. Это означает, что если вы где-то что-то потянули — у вас в пяти местах отвалилось. Если это дорогие элементы, то это крупные потери по бюджету. Переделки становятся очень дорогими. Поэтому планирование должно быть максимальным. Именно поэтому самые дорогие элементы оставляются на финал. Если у вас игра оперирует супер реалистичной графикой и у вас стоимость производства финального персонажа с анимациями стоит $100 000 на одного и если считать все вместе, миллионы зашкаливают, то такие вещи делаются только после всех предварительных телодвижений. У вас должны быть описание, функциональные спецификации, прототипы, прототипы второй стадии, прототипы взаимодействий фичей внутри рабочего энвайронмента, превизы, сессии тестирования и только потом финал и компонентная наработка. Потому что стоимость этих компонентов может быть очень высокой по разным причинам. Почему озвучка делается в последнюю очередь, особенно если ее выполняют какие-то известные люди? Переписать ее — очень дорого. Не только из-за гонорара актеров, а из-за того, что “выдернуть” актера во второй раз, чтобы переписать какие-то реплики, особенно если их зачитывает селебрити — очень дорого.

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

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

— Где почитать такие документы?

Проблема в том, что нигде. Во-первых, это все под NDA, во-вторых — это не единственная методология. Например, та же система, которая используется в крупных компаниях, наподобие Electronic Arts, принципиально делает подход к функциональным спецификациям совсем по-другому. Там brief-based подход. Когда пишется креативный бриф, который делится на креативный дизайн-бриф, технический бриф, прописываются все взаимосвязи фичей на документальном уровне и только потом отдают в прототип. И там, в принципе, сведения как такового из-за опытности команд часто может и не быть. При этом есть не фанкспек, есть просто сценарий. Или ресурсов настолько много, что все сразу делается и сводится в какие-то прототипы, которые живут вместе. 

У меня в “Автостопе по игровой индустрии” много расписано по этому поводу. В “Автостопе” написана технология очень похожего процесса, связанного с итерациями в том числе и так далее. Она выйдет в сентябре, в худшем случае в октябре. Но я считаю, что нельзя давать готовые решения и шаблоны. Подразумевается, что все вот эти документы, которыми я делюсь, и практики, которые я рассказываю — их все обдумают, покурят и адаптируют в свой контекст. Попытка встраивать именно в том виде, в котором есть готовые фреймворки и готовый пайплайн, не будет в документальном смысле никогда работать. У всех разные композиции команд, у всех немного разные подходы и слишком много ниш и жанров. Вот возьмем вышеописанную ситуацию про головоломки. Я работал с играми, в которых много головоломок, они, кстати, оказались слабым местом, потому что функциональная спецификация в головоломке — это такой элемент, который на бумаге часто может быть хорошим, а в реальности, когда это еще заточено и на мобильные устройства, оказывается, что там UX очень подводит. Поэтому это просто набор таких направляющих идей, которые у вас как-то должны сложиться и вы должны потом самостоятельно построить свой пайплайн. 

— Реально нужно сначала поиграть игру в текстовом редакторе, а дальше как по минному полю медленно продвигаться?

Минное поле — это все-таки преувеличение. Потому что пробовать прототипирование по разнообразным блокам, особенно вне игрового билда, чтобы получить результаты, надо много и постоянно. При этом я сильно пропагандирую так называемое “грязное” прототипирование. Это когда вы прототипируете, пробуете какие-то геймдизайнерские подходы, но не в игровом билде. Я знаю случаи, когда эта практика реализовывалась геймдизайнерами на компьютерах, которые даже не были подключены к сети development core группы, чтобы они, не дай бог, не закоммитили оттуда и это не ушло в билд. Этого надо делать много, но когда дело доходит до работы конкретно, и вы выходите в производство после препродакшна (по сути, выход в вертикальный срез) — действовать нужно все-таки аккуратно. 

У нас в индустрии и вообще в творческом бизнесе продюсирование подразумевает, что мы не солому стелим под процессы, а бумагу, прототипы, пробы и итерации.

— Просто неплохо бы составить спеку по написанию такого документа и попробовать их писать. 

Дело в том, что пробовали. Но повторюсь еще раз: даже тот пример, который я сейчас даю, он очень хорош для некого среза игр, а именно для приключенческих игр от третьего лица с глубокой проработкой нарративной составляющей. Но я вообще не уверен, что подойдет, например, для гоночной игры. Если вы делаете гоночную игру, у вас будет принципиально другой пайплайн. Там R&D прототипирование и тестирование физической модели (при наличии физики) будет в разы больше, чем чего-либо другого, например. А повествование? Ну, не знаю, вряд ли оно нужно. Вы же не будете писать, что машина едет по трассе, а рядом пролетел дирижабль… 

Поймите, мы существуем в игровой индустрии: в поле подходов и практик. Это одна из проблем образования, в том числе. И это одна из проблем сложностей в написании методичек. Мы можем со своей стороны расписать большое количество разных сценариев, эффективных подходов, методологий. И если нужно подсказать способы объединения их в производственные процессы и каким-то образом писать постоянно какие-то статьи по этому поводу и какие-то исследования проводить там и так далее — это один из элементов с МГУ, да и в Вышке этим тоже занимаются. Но придумать универсальный подход с точки зрения препродакшна сколько раз пробовали — не получалось вообще никогда. Здесь как с советами: нужно смотреть на пример, который тебе подается, брать паузу, переваривать и потом настраивать процесс у себя, исходя из базовых общих принципов, которые проверены. 

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

Это одна из причин, почему чистый аджайл в играх не работает. Вернее работает, но с маленькими командами, или, например, мобильными играми, которые можно постоянно дорабатывать. Или с инди-играми, которые тоже делаются маленькими ультра профессиональными коллективами, особенно онлайновые, которые можно постоянно докручивать. Если игра большая — все иначе. Разница продукта и линейной игры которую можно начать и закончить в том, что они структурированы по-разному. Нельзя в синглплеерной игре, у которой есть история с прохождением, возвращаться и делать патч, который эту историю просто ловко меняет на ходу и все будет нормально. Именно поэтому история всегда доминирует в таких продуктах, где она является одной из кор-фичей. В этом их сложность. Когда реализованы вещи, связанные с повествованием, повернуть их обратно очень тяжело. Я был участником историй, в которых запоздавший на две недели, но справедливый фидбэк от издателя (там не было других вариантов, так сложилась рыночная ситуация) приводил к правкам на четыре месяца общей стоимостью примерно $400 000-500 000. 

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

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

— Мы просто уже обожглись.

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

Чтобы сделать действительно крутой правдоподобный звук для вашего персонажа, условно говоря, ходьбы, вам нужно сначала просто сделать разные типы ходьбы (звуки) по определенной методологии. Затем взаимодействия с разным типом материалов этой ходьбы. Потом взаимодействие в других каких-то условиях. Это все мультипликаторы, которые умножают ваше предыдущее число на количество ситуаций и контекстов. Аналогичная ситуация с анимациями и со спецэффектами. Дело в том, что если это не учтено на системном планировании, как и говорили до этого, вам придется это все потом переделывать. Любое слово, любая ошибка в планах и все, где есть приставка “до”: дозаписывать, доделывать, это обычно стоит в лучшем случае в 2 раза дороже, особенно сейчас. Особенно если речь идет о том, что вы заказали какому-то специфическому аутсорсеру 10 персонажей, а потом поняли, что их нужно 16 и нужно дозаказывать, а ваш аутсорсер уже ушел на другой контракт, а вам срочно надо. Ох, с вас сдерут денег!

— Меня беспокоит 500-страничный документ. Не теряется ли при таком подходе возможности для креатива специалистов? Мы, конечно, талантливые и верим в свои документы, но каждый крутой специалист приносит крутые идеи, которые просто крамольно выбрасывать и ложатся в feel-vision жанра. Возможно, я немного не понимаю, что он из себя представляет.

Здесь целый ряд поправок. Еще раз: документ для конкретной игры, которая богатая сеттингом, при этом игра достаточно модульная. В ней много фичей, много персонажей, плюс документ является тоже живой сущностью. Там первые 45 страниц занимают логи изменений за год. У любых документов, как и у любой работы должны быть бэклоги. Пока вы находитесь на стадии до вертикального среза, потом непосредственно вертикальный срез, потом будет еще обязательно акклиматизационный период перед производством. Пока вы не ушли в это самое производство, у вас могут проходить любые изменения в любом из аспектов и документации и функциональных спецификаций, и т. д. Далее, я считаю, что когда процесс разработки начался — время для креатива закончилось. 

Если команда начинает креативить в процессе производства, это всегда плачевно заканчивается. 

Есть один компромиссный способ, который вводят очень многие студии. Время планируется таким образом, что у проекта между стадиями есть бэклог. Если выполнен полный план, в этот бэклог складываются идеи команды, которые не вошли в основной документ функциональной спецификации, которые можно рассмотреть, и которую можно, если осталось время, имплементировать. Такое делают особенно в конце проекта, если там это как-то нормально живет и можно это как-то инкорпорировать. Придумывать на ходу в производстве? Есть хорошая гифка, когда поезд едет и перед ним рельсы кладут. Я понимаю ценность креатива, знаю, что есть случаи, когда вот такого планирования не производят и делают на ходу, порой даже как-то получается. Но когда речь идет о работе двух или более компаний, когда на это все еще накладывается фидбек и когда этой креативности становится еще очень много, шанс игры попасть в ад продакшена и дополнительные затраты просто чудовищен. Это одна из причин, почему разработчики тратят все деньги, а потом приходят и говорят издателю: “Надо еще.” Издатель спрашивает: “Почему?” Они отвечают: “Ну мы еще не все сделали, но в процессе у нас возникло много прекрасных идей, мы считаем, что это круто и, естественно, не посчитали этого в бюджете. Мы же не знали, что это придумаем...” И подобные аргументы издателей дико бесят. Потому что если это еще отскакивает на компонентной отработке на бете, стоимость подобного безответственного поведения может быть очень высока. 

Скажу в конце самое главное. Это — рекомендации. Вы можете работать принципиально по-другому. Я надеюсь, что эти рекомендации попадут в контекст и будут полезны вам для разработки. Если вы хотите разрабатывать какие-то большие, сюжетные игры, наверное, это будет вам полезно. Если у вас есть проблемы, которые я перечислил внутри команды, вроде непонимания между участниками, или из-за быстрого роста люди не могут втянуться в материал проекта, или слишком много изменений в процессе, что постоянно меняет игру — наверное, это тоже будет полезно. Если вы делаете игру в каком-то принципиально другом жанре — просто послушайте, порефлексируйте по этому поводу и возможно вы извлечете из всего сказанного 5-10% полезной информации, которые адаптируете под свою конкретную ситуацию. Никогда не слушайте никаких советов, ни от меня, ни от всех остальных. Никто толком ничего не знает, но у всех есть уникальный опыт. Если все это соберете, интегрируете, возможно, вы как-то сможете улучшить свои истории.