На прототипе подготовка студии к полноценному процессу производства игры может не закончиться. Есть еще один довольно важный аспект, требующий некоторого изучения.
До текущего момента мы работали только с механиками. Даже придуманный на коленке баланс и контент для менеджера мусороперерабатывающей фабрики создавался исключительно для того, чтобы проверить механику. Нет персонажей, нет цифр характеристик, нет локаций. Мы вроде бы доказали, что собранные нами механики могут составить хорошую (соответствующую нашим бизнес-целям) игру. И вот пришло время доказать, что мы можем не только собрать интересный набор механик, но сделать привлекательную игру и наполнить ее контентом: персонажами, цифрами характеристик и локациями.
Может показаться что данный этап ничем не отличается от непосредственного производства игры, но это немного не так. Здесь важно помнить, что производство – это конвейер. И он не терпит экспериментов, потому что это будет нарушать его работу, приводить к простою, за который придется платить, а бюджет не резиновый. Чтобы конвейер нормально работал, он должен быть очень хорошо отлажен. Должно быть известно, из каких этапов состоит производство отдельных элементов игры, сколько времени занимает каждый этап, сколько нужно произвести отдельных деталей для создания целого объекта – той же игровой локации, например.
Если у нас есть опыт управления проектами, мы можем сказать, из каких этапов в целом состоит производство конкретных игровых компонентов и какие навыки для этого требуются. Но, в зависимости от доступных нам ресурсов, отдельные исполнители для выполнения некоторых функций могут оказаться недоступны. Это означает, что в различных условиях конвейер производства будет работать по-разному и требовать настройки даже не для компании, а для каждого проекта отдельно. Более того, настройка нужна и при изменении количества доступных рук на тех или иных направлениях производства, учитывать как минимум отпуска, не говоря уже о возможном уходе кого-то из команды разработчиков.
Чтобы настроить конвейер, нам потребуется провести эксперимент и попробовать реализовать все элементы игры хотя бы в единственном экземпляре, чтобы замерить реальное время, необходимое для производства каждого из этих элементов. Идея заключается в том, чтобы получить хотя бы один уровень игры (если игра состоит из уровней), но финального качества. Со всеми необходимыми ассетами – персонажами и предметами – и выверенными параметрами.
Сам эксперимент, как и весь этап, называется вертикальным срезом. Кроме вертикального среза есть еще понятие горизонтального среза. Если вертикальный срез – это реализация всех механик с минимальным необходимым контентом, но финального качества, то горизонтальный срез – это реализация всего контента для какой-то одной механики, что в большей степени относится к самому производству.
Кроме помощи в настройке производственного конвейера, результат вертикального среза может принести пользу и даже быть необходим еще в двух случаях. Во-первых, финальное качество контента позволяет начать показывать игру за пределами студии: игру не стыдно отвезти на какую-нибудь выставку или конференцию. Даже при том, что формально наша игра еще не дошла даже до стадии «альфы», в таком виде она сможет привлечь внимание потенциальных игроков и издателя, если у нас его еще нет. Во-вторых, если издатель у нас уже есть, то реализация этапа вертикального среза может быть одним из условий финансирования проекта и способом доказать, что у студии есть все необходимые ресурсы для реализации проекта.
Начало производственных экспериментов требует определенной подготовки – даже если нашей целью является создание всего одного уровня с ограниченным набором противников. С одной стороны, мы уже не можем использовать бесплатные ассеты, как на этапе прототипирования (если, конечно, использование бесплатных ассетов не является частью концепции), а с другой, мы не можем тратить ресурсы на создание графики финального качества, которая не станет частью финальной игры, – это расточительно.
Значит, прежде чем начать хоть какое-то производство, нам необходимо решить фундаментальные вопросы устройства нашего игрового мира. Они зависят от жанра и типа игры, например сколько и какой продолжительности у нас будут уровни, как они будут устроены и какими объектами наполнены, как игрок будет с этими объектами взаимодействовать, какие будут противники, в чем их особенности, какие у них и у персонажа игрока характеристики, как это все будет отображаться и так далее. При этом надо понимать, что конкретных деталей мы пока еще не знаем, так как разработка деталей и является процессом производства, к которому мы только приближаемся. Мы можем дать лишь несколько более детальное описание, чем было на этапе проработки концепции. Оно должно пополнить разрабатываемый нами диздок игры.
Количество уровней может быть прописано в концепции. Это несколько рискованный шаг, но это в любом случае какой-то фундамент, от которого мы можем отталкиваться.
Если такого фундамента нет, то, возможно, придется его искать в других источниках. Если наша игра сюжетная, разработчики часто исходят из того, что игра определенной ценовой категории должна иметь продолжительность, сравнимую с другими подобными играми в магазине приложений. Еще на этапе прототипирования мы могли получить скорость передвижения персонажа и примерный размер уровня, удовлетворяющий критерию интересности. Делим продолжительность игры из магазина на время прохождения уровня из прототипа и получаем примерное количество уровней.
Если игра не сюжетная, то количество контента можно получить из расчета игрового баланса. На этом этапе следует серьезно погрузиться в механики и ресурсы, которые будут в нашей игре: определить, сколько деталей нового автомобиля будет получать игрок за каждый заезд, сколько ресурсов за прохождение каждого подземелья. Конечно, баланс важен и для многих сюжетных игр, вопрос лишь в том, что мы выберем в качестве основы для составления списка необходимых ассетов.
Как правило, мы довольно сильно ограничены в ресурсах и нам придется сводить эти доступные ресурсы с ресурсами, необходимыми для производства нашей игры. Возможно, нам придется уменьшать количество оригинальных объектов на уровнях, время, затрачиваемое на создание каждого отдельного ассета, а значит, и их качество. Количество методов, позволяющих сэкономить ресурсы, довольно велико, например предметы, располагающиеся на уровнях, могут быть одни и те же, а действие игры может происходить вообще в одной локации.
Очевидно, что без довольно детальной проработки игрового мира у нас не получится понять, что и в каком количестве нам предстоит сделать. В результате процесс эксперимента по созданию контента для игры превращается в серьезную работу по планированию вещей, до разработки которых проекту еще довольно далеко. И более того, проект может просто не дожить до стадии непосредственного производства, если он, например, потеряет финансирование из-за неудачного результата текущего этапа. Но уже здесь, на этапе вертикального среза, нам нужно знать, какие в игре будут машины, какое будет оружие, сколько будет заклинаний.
Из проработки игрового мира следует еще один важный аспект. Учитывая, что в результате этой работы мы должны получить список всех объектов нашего игрового мира, как выбрать те ассеты, которые составят необходимый для этого этапа минимум? И тут на помощь должно прийти понимание, для чего результат вертикального среза может быть использован: для презентации игры на выставках. Соответственно, выбирать надо те ассеты, которые смогут дать самую эффектную картинку: красивые доспехи, интересную локацию, впечатляющих противников с яркими спецэффектами.
Игровые ассеты (game assets) – это материалы, ресурсы, данные в цифровом виде, которые имеют определенные однородные характеристики. Их используют в качестве контента при разработке игр. Ассетов требуется достаточно большое количество даже для одного проекта. Это могут быть 3D-модели, спрайты, фоны, текстуры, звуковые эффекты и музыка, части готовых проектов, механики с кодом и т. п. Эти ресурсы продаются или распространяются бесплатно в специализированных ассет-сторах, а также могут быть разработаны внутри студии или получены из внешних источников, например от аутсорсеров.
Небольшой, но важной хитростью при выборе ассетов для реализации на этапе вертикального среза является то, что уровень вообще может не быть частью будущей игры – частью игры будут именно ассеты. Если, конечно, уровень сам не является ассетом, а состоит из них. У нас еще будет возможность в более спокойной обстановке собрать соответствующие игровому сюжету уровни, на которых мы сможем использовать созданные ранее объекты. Сейчас это не главное. Тем более что сюжет игры может еще не быть готов в необходимой степени, ведь до этого момента мы могли лишь создать его прототип и нам только предстоит его полноценное производство.
• Если мы делаем гоночную игру, то нам необходимо сделать буквально одну машину и одну трассу – ведь противники могут ездить на той же машине.
• В шутерах должно быть достаточно одного монстра, но с оружием будет сложнее. Оружие может наносить урон просто при попадании противника в перекрестье прицела, а может иметь снаряд. Причем это не вопрос выбора между простым прицеливанием и реалистичной баллистикой пули для пистолета, ведь в шутерах также встречаются гранаты и ракетницы, для которых придется делать какую-то физику, независимо от механики выстрела пистолета. И если в нашей игре будут и пистолеты, и гранаты, значит, для этого этапа необходимо будет реализовать и то и другое.
• Если в нашей игре все монстры будут передвигаться по поверхности и вести себя одинаково, то достаточно реализовать одного такого персонажа, независимо от того, будут ли они иметь разные уровни и параметры. Но если в игре предполагается наличие разных механик передвижения монстров, например у нас планируются еще и летающие противники, то необходимо реализовать хотя бы одного такого.
Даже при том, что мы выбрали минимальное количество ассетов, они не являются совсем разрозненными объектами и связаны друг с другом, а значит, у нас будет некая последовательность производства. С одной стороны, мы занялись вертикальным срезом, чтобы эту последовательность и выработать, с другой стороны, основные детали этой последовательности должны быть и так вполне очевидны. Например, чтобы получить финальную игровою локацию, нужно не только спроектировать ее, но и дождаться, когда художники создадут все предметы, которые там должны располагаться. В результате работа даже над единственным уровнем превращается в довольно затейливое дерево зависимостей, например дизайнеров уровней от сценаристов и художников.
Практически все элементы игры можно так или иначе сгруппировать по процессу производства, свойственному именно этому элементу. Он есть у отдельных предметов на уровне, у персонажей, даже у графической части работы над ними. Процесс, свойственный производству какой-то группы элементов игры, называется пайплайном (pipeline – «трубопровод»). Однако это не просто путь из точки А в точку Б.
Пайплайн работы над каждым отдельным элементом разделен на этапы, которые позволяют не просто передать работу от одного специалиста к другому, но также добавить процессу итеративности, очень похожей на производство всей игры: разработки концепции, проверки прототипом и производства. Это позволяет вернуться на шаг назад или начать все сначала для каждого отдельного объекта игры, пока он не станет удовлетворять нас.
Если продолжать аналогию с этапами производства, наш список объектов, которые необходимо реализовать, является списком идей. Они должны быть оформлены в концепцию с четким описанием того, как объект выглядит, работает, какие имеет параметры, а также концепт-арт, помогающий другим участникам команды буквально увидеть место объекта в игровом мире. Когда концепция будет утверждена, начинается процесс прототипирования. Как и у прототипа игры в целом, цель прототипирования отдельного объекта не только попробовать, насколько этот объект интересен, но и можем ли мы вообще его реализовать. Даже при том, что все, например, автомобили в целом делают по одному и тому же пайплайну, при производстве какой-то отдельной модели вполне может возникнуть какая-нибудь непреодолимая проблема.
Это особенно важно на этапе вертикального среза, ведь может так получиться, что мы просто не обладаем необходимыми навыками и ресурсами для реализации какого-то объекта в соответствии с разработанной концепцией. А значит, нам нужно либо восполнить пробел в виде недостающих навыков – нанять исполнителя, обратиться к помощи аутсорса, подучиться, – либо что-то изменить в концепции объекта, а может быть, и всей игры.
Если этап прототипирования отдельного объекта пройдет успешно, то можно заняться его финализацией. И вот тут есть довольно важное отличие от более масштабных этапов разработки самой игры. Учитывая, что каждый отдельный объект создается с целью наполнить игровой мир, а сам этот мир, по сути, претерпевает итерационное развитие, получается, что нам необходимо делать все одновременно. К тому моменту, когда у нас будут готовы прототипы мебели для уровня, у нас должен быть готов концепт самого уровня со схемой расположения этой мебели, чтобы мы смогли сразу попробовать расставить ее по уровню. Механики, разработанные еще на этапе прототипирования игры, позволят взглянуть на уровень очень близким к финальному образу. Мы должны сразу увидеть, насколько прототип или даже концепция вновь созданного объекта соответствуют тому, что мы в конечном итоге хотим показать игроку.
По мере принятия этапов реализации отдельных элементов игры наш прототип начнет обрастать «мясом». Кубики будут заменяться предметами и персонажами, простые механизмы взаимодействия – более сложными. Разработка одного объекта игрового мира может требовать большого количества разноплановых навыков. Так, для создания простой двери может понадобиться работа не только художника, но и программиста, не говоря уже о дизайнере уровней. Идея итеративности и здесь должна нам помочь. Ведь чтобы расположить дверь на уровне и заняться разработкой механизма взаимодействия с ней, нам не нужен финальный арт этой двери. Все, что нам требуется для начала, – это финальные характеристики: какого она будет размера, как будет открываться, с какой скоростью, в какую сторону.
Метод итеративности разработки отдельных элементов игры позволяет не дожидаться финальных результатов работы отдельных специалистов для начала работы над отдельным элементом. В результате время создания того же уровня не складывается из времени работы над всеми его составными частями, а в значительной степени пересекается с ними, что несколько усложняет планирование таких сложносоставных компонентов. Чем проще и независимее элемент, тем легче определить время, необходимое на его реализацию.
В результате работы над вертикальным срезом мы должны получить финальную документацию проекта и набор пайплайнов для разных групп элементов нашей будущей игры. Документация может остаться на уровне глубокой деконструкции: со списком, например, механик, регионов и монстров, – но необязательно должна содержать финальную декомпозицию: схемы работы механик, макеты интерфейсов и цифры характеристик оружия. По итогу вертикального среза у нас должна получиться документация того, как будет реализовываться игра: описание графического стиля и палитры основных графических элементов игрового мира и интерфейса, описание используемых технологий, технических ограничений, размеров и масштабов, инструкции, которым должны будут следовать исполнители каждой конкретной задачи.
Остается лишь удостовериться в том, что выбранные нами методы разработки игры сходятся с доступными нам ресурсами. Может так случиться, что производство всего намеченного для игры контента не умещается в ограниченный бюджет или лимит времени. Есть два решения этой проблемы: либо резать контент, либо оптимизировать производство. Оба варианта подразумевают, что мы откатываемся лишь к началу этапа вертикального среза, а результаты этапов концептирования и прототипирования остаются неизменными. Первый вариант может потребовать переделки многих концептуальных моментов типа сценария и устройства создаваемого в игре мира. Второй же вариант может касаться качества ассетов, сложности игровых систем или необходимости обратиться к аутсорсу. Вместо высококачественных моделей персонажей можно использовать низкополигональную стилизацию. Чтобы избежать проблем с лицевой анимацией, можно нарядить всех персонажей в маски. Можно упростить боевую систему и сократить количество анимаций и оружия.
Одним из самых опасных аспектов вертикального среза является то, что мы можем ошибиться с выбранными пайплайнами и в конце, проводя финальные подсчеты, узнать, что они совсем не вписываются в доступные нам ресурсы. К этому моменту бюджет, выделенный на проведение этого этапа, может уже закончиться и на новые эксперименты просто не останется денег.
Важно не забывать, что финальное качество подразумевается не только для отдельных игровых механик, объектов и ассетов, но и для игры в целом. Количество багов должно быть сведено к минимуму. А значит, на этом этапе проекту будет требоваться полноценное тестирование, а команде – тестировщики. И сам процесс тестирования, вероятно, нуждается в изучении и разработке собственного пайплайна, встраивания его в пайплайны других компонентов, что может повлиять на продолжительность их производства. При этом, учитывая имеющиеся ограничения по времени и бюджету, очевидно, что вычистить из игры все баги, скорее всего, не получится, они будут накапливаться и переходить на следующие этапы производства.
Если же все закончится удачно, мы получим первую версию игры, которой можно будет хвастаться перед коллегами и игроками, а также план дальнейших действий, которому спокойно сможем следовать на этапе производства.