Текст книги "Игра как бизнес. От мечты до релиза"

1.6. Планирование препродакшена, прототипа и вертикального среза

Если вы обратили внимание, в глобальном смысле мы идем с вами сверху вниз с точки зрения планирования дальнейшей деятельности. И, в теории, сейчас стоило бы разобрать бизнес-планирование. Однако мы не можем приступить к этой части без измерения параметров проекта, так как без них мы не сможем определить затратную часть львиной доли нашего предприятия. В реальной практике тут обычно происходит интересный момент – эти процессы распараллеливаются. С одной стороны, начинается работа по оценке параметров производства, с другой – составляется бизнес-видение и запускаются в производство побочные документы. Как результат, не стоит опасаться того, что данные будут где-то неточны, – в нашем процессе вы их все равно перепишете несколько раз. Как минимум два: первый – когда готовы оба пакета документации и понятна общая картина, второй – когда произведены прототип и вертикальный срез и оказалось, что часть ваших прогнозов неверны. Мы же – для простоты восприятия – разместим раздел о препродакшене и документации о проекте перед разделом о бизнес-планировании. Еще раз: держа в голове, что это взаимозависящие вещи.

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

Полный концепт-документ проекта – существует примерно два десятка примеров для составления качественного концепт-документа, но во всех них ключевыми моментами являются следующие.

Краткое описание и рыночное позиционирование

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

Основная фишка проекта

Собственно, краеугольный камень игры, на котором стоит все остальное. Ключевая игровая особенность, основа концепции, то, как игру будут описывать между собой игроки, когда станут рассказывать о ней друг другу. В английском языке это называется elevator pitch, и из него растут ноги всего остального в игре. Как вариант, это может быть что-то вроде «астронавт возвращается на Землю, обнаруживает, что пока он где-то там летал, родную планету внезапно захватили инопланетяне – и вступает с ними в конфликт». Запомним этот пример, он нам еще понадобится.

«Столпы» проекта

Обычно их три. Это основополагающие элементы проекта, которые в процессе разработки не могут никоим образом компрометироваться, видоизменяться, приноситься в жертву и вообще являются определяющими константами игры. Продолжая наш пример инженера-астронавта (см. выше), давайте скажем, что в нашем случае эти константы: «герой», «исследование» и «восстановление/менеджмент баз». «Герой» – протагонист игры – является ключевым элементом, кем-то, кто вступает в конфликт с невозможной задачей, пытаясь бросить вызов целой расе инопланетян. Он обладает уникальными качествами, навыками и харизмой. За братву и двор стреляет в упор (т. е. в игре есть боевая система с применением огнестрельного оружия). «Исследование» – герой возвращается домой, например в Бостон, но после первоначальных конфронтаций операции разворачиваются в череде миссий по всему восточному побережью США. Миссии представлены точками на карте, внутри каждой подразумевается изучение местности (для простоты понимания скажем, что структурно это напоминает Mass Effect: Andromeda или Dragon Age: Inquisition). Герой находит информацию, других персонажей, оснащение, новое оружие и так далее, постепенно узнавая, что случилось, пока его не было, и противодействуя инопланетной оккупации. «Восстановление/менеджмент баз» – герой освобождает других персонажей, поселения, содействует сопротивлению, строит целую сеть разнообразных баз и мощностей, которые производят ресурсы, технику, новые игровые элементы и осуществляют тактические действия против врага. Для простоты понимания добавлю, что «менеджмент» относительно рудиментарен и напоминает то, что периодически любят проделывать в этой области в некоторых частях Assassin’s Creed. А по жанру у нас будет action/adventure от третьего лица. И это ПК и консоли. О чем, разумеется, будет написано с самого начала, в самом первом блоке, на самой первой странице.

Игровой сюжет

Краткое описание всего игрового сюжета на страницу-две. Лучше всего это делать, собственно, по ключевым элементам в рамках трехактовой структуры или же набором эпизодов и/или миссий. Продолжаем и развиваем пример. В нашем случае вы, предположим, распишете, как герой возвращается на Землю, вступает в конфликт, терпит поражение, его пытают, его спасает Сопротивление. Он вступает в противоборство, зарабатывает репутацию, далее выступает как лидер, влюбляется в персонажа из Сопротивления, финал в виде глобальной атаки на базу в Нью-Йорке. Оказывается, что все это происходит в параллельной реальности. Главный инопланетный злодей крадет девушку главного героя и – с душераздирающим криком «Встретимся в сиквеле!» – бежит через портал на настоящую Землю нашего персонажа. Тонкий заход на вторую часть.

Основные игровые механики

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

Краткое описание игрового сеанса

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

Визуальное оформление

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

Музыкальное и звуковое оформление

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

Рыночная модель/монетизация

Здесь вкратце необходимо описать, как игра станет зарабатывать деньги. Вариантов тут достаточно много. В нашем выдуманном продукте это будет продажа в цифровой и физической рознице. Скажем, по $39.99.

Прочие особенности проекта

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

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

Сейчас я хотел бы кратко резюмировать проект-пример, описанный в пунктах выше. Это action/adventure от третьего лица с элементами менеджмента локаций. В сеттинге, ближайшим аналогом которого можно назвать, скажем, Homefront или телесериал V. Это ПК/консоли (и соответствующая аудитория) и отпускная цена в $39.99 – что само по себе диктует определенный уровень качества и требования к контенту (т. е. это не бюджетный продукт за $10). В игре есть сюжет, есть кат-сцены (и их режиссура). Я снова заостряю внимание на этом импровизированном относительно абстрактном примере (на самом деле являющимся амальгамой нескольких реальных проектов, в которых я принимал участие) не потому, что он как-то ценен сам по себе. Просто нам нужна отправная точка для расшифровки ряда последующих пунктов. Делать это в вакууме неудобно. Поэтому – для наглядности – нам нужна какая-то основа для расчетов. В том числе в прямом смысле – если мы говорим о бюджетировании и этапах разработки (а именно этим мы и займемся), то у нас должен быть ясный образец, который диктует сроки и цифры бюджета.

Кроме того, здесь нужна дополнительная оговорка. Я специально беру как базовый пример (как продукта, так и его расчета) офлайновую игру для ПК/консолей. А не онлайн, гиперказуальный проект или мобильный продукт. Эти направления так или иначе будут упоминаться и затрагиваться в тексте, но фокус на традиционном премиум-проекте для традиционной (читай: неказуальной) аудитории. Именно потому, что это консервативно, здесь больше ярко выраженных сложных компонентов (продвинутый кор-геймплей, дополнительные механики, контент достаточно высокого качества и так далее), и заложенные в этой парадигме принципы применимы – в той или иной степени – для разработки практически любого продукта. Если же мы возьмем как пример что-то вроде «мобильного match-3», то нам будет крайне сложно (при всех очевидных пересечениях) отмасштабироваться и спроецировать установки на другие типы разработки.

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

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

Вы и ваша команда (если таковая уже имеется) на данном этапе можете приступить и к полному написанию дизайн-документа. Однако с точки зрения практики и задач, которые сейчас стоят перед вами, гораздо более целесообразно сфокусироваться на 5–10 % игры, которые, впрочем, будут содержать 70–80 % функционала запланированного проекта. То есть так называемого вертикального среза. Этот документ будет состоять из следующих блоков.

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

Честно говоря, я рекомендую командам на этом этапе для старта написать максимально полный «режиссерский» сценарий 15–20 минут игры с точки зрения игрового сеанса в максимальной детализации. Данный документ также должен содержать следующие элементы: зарисовки и скетчи, левел-дизайн карт локаций, где происходят действия, идентификация всех активных сущностей (от персонажей и противников до оружия), сценарную часть кат-сцен, сценарную часть диалогов и взаимодействия персонажей с миром. По сути, это максимально детальное описание всего, что должно происходить в игре. И эта часть документации предназначена для декомпозиции в последующих разделах. Существительные из этого документа станут объектами, прилагательные – атрибутами объектов, глаголы – функциями и действиями.

Список ключевых механик и элементов игры

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

Полный список функциональных объектов и сущностей

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

Общий фичер-лист вертикального среза

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

Арт-документ вертикального среза

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

Концептная часть

Здесь важно провести линию между двумя такими понятиями, как концепт-арт и функциональные, служебные концепты, которые используются внутри проекта для передачи видения между его участниками. Под этим разделом я по факту имею в виду раскадровку вашего режиссерского сценария игры: достаточно быстрые и грязные скетчи, которые можно в последствии разобрать на объекты, отдельно детализировать и отдать в работу как задачи – с инструкциями из арт-документа.

Арт-ассет-листы

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

Звуковая режиссура, анимация, специальные эффекты

Аналогичные арт-документы спецификаций по данным дисциплинам.

Ассет-листы для музыки, звуков, озвучки и специальных эффектов

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

Окончательное определение производственного пайплайна

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

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

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

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

Игровой цикл

Прототип с самого начала должен подчиняться правилам игрового цикла: от открывающего экрана, начала игровой сессии, ее закрытия и возможности все это повторить. Вы можете – и будете – менять логику исходя из того, что вам нужно показать ключевые моменты игры, а не окончательный продукт, и в процессе оттестировать основные механики. Но в этом пусть и промежуточном результате должна быть заложена кольцевая логика. Не стесняйтесь ее модифицировать. К примеру, если вы делаете action RPG, и у вас ключевая фича – класс и способности персонажа – каждый игровой сеанс может начинаться с выбора класса и изменения характеристик.

R&D фичей

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

Производство основных фичей

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

Производство второстепенных фичей

После того как готов core gameplay, вам необходимо рассчитать процесс второстепенных фичей. И тут главным вопросом является приоритизация. Стандартно рекомендуется выбирать 5–7 фичей данного уровня, которые на сто процентов работают на основные столпы проекта. В примере из нашего «концепта» – это, скажем, будет пара гаджетов, подчеркивающих тот факт, что герой – инженер.

Производство арт-ассетов и компонентов

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

Настройка итерации процессов

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

Промежуточное тестирование

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

Чтобы не возникало недопонимания, я добавлю небольшое пояснение об упоминавшихся выше «основных» и «второстепенных» фичах – они нам еще понадобятся и еще не раз встретятся в тексте.

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

Второстепенными фичами (второго порядка, tier 2 feature – называйте, как хотите) тут будут особенности, очень важные для проекта, которые регулярно видит игрок и от отсутствия которых продукт существенно потеряет, но при этом они не являются стержневыми. Соответственно, в фичи третьего порядка попадут – в широком смысле – «декоративные» элементы. Встречаются они редко – возможно, даже всего один раз за игру. Это вообще может быть мини-игра на 3 минуты. С ней весело, она имеет смысл, но без нее продукт вполне проживет.

Теперь, сделав пару необходимых пояснений, мы можем подвести итог этого раздела. Основная мысль здесь: несмотря на то что у вас в расчетных планах о разработке вертикальных срезов учтены сроки и затраты на все компоненты и высокоуровневые процессы, сам процесс разработки гарантированно добавит большое количество побочной деятельности (зачастую очень неявной для неопытных команд), да и вообще местами будет напоминать «шаг вперед – два назад». Чем лучше вы это учтете, тем в итоге точнее и полезнее будут ваши планы. Также, мы об этом поговорим в дальнейшем, в разделе о непосредственно производстве, сами практики и общую дисциплину процессов вам необходимо заложить именно на стадии прототипа, потому что перестраиваться потом бывает очень тяжело и дорого.