Как создаются игры. Основы разработки для начинающих игроделов - Григорий Радовильский
Шрифт:
Интервал:
Закладка:
На этом этапе у нас пока еще нет ничего, кроме механик. Нет графики, звуков.
Интерфейсы пребывают в зачаточном состоянии и выполняют только базовые, тестовые функции.
Производство графики для игры – процесс довольно сложный и продолжительный, а значит, в лучшем случае на этом этапе у нас будут какие-то скетчи, которые мы можем проверить примерно так же, как и настольную игру – собирая отзывы.
Для проверки некоторых механик может быть достаточно простых кубиков, которые могут выполнять роль персонажей и объектов сцены. Но в некоторых случаях могут понадобиться более сложные модели: например, если надо проверить какое-то сложное управление персонажем или для наглядности добавить анимации. При отсутствии собственных графических наработок можно использовать доступные в интернете ассеты и бесплатные модели, входящие в комплект игрового движка. Но не стоит увлекаться поиском подходящих ассетов – для этого еще придет время.
А еще для проверки механик игре вообще не нужен развитый контент. Нам пока не нужно придумывать и описывать отдельных персонажей, их характеристики, не нужно собирать уровни, не нужен сюжет.
Хотя над персонажами, уровнями и сюжетом можно начать работать так же, как над скетчами для развития концепции и проверки их прототипов. И все же пока нашей главной целью являются именно механики. А значит, в качестве персонажей могут использоваться стандартные модели, а уровни можно собирать из кубиков.
Блокаут (blockout) – это один из начальных этапов проработки уровня. Процесс блокаута состоит из двух частей: грейбокс (gray box – «серая коробка») и вайтбокс (white box – «белая коробка»). Грейбокс – это макет уровня, собранный из примитивов: кубов, шаров, цилиндров обычно серого цвета. Примитивы позволяют выстроить топологию уровня, проработать маршруты передвижения игрока и неигровых персонажей, расставить точки интереса и подчеркнуть их геометрией. Собранный таким образом уровень должен быть прежде всего проходимым и интересным. На этапе вайтбокса к примитивной геометрии добавляется более проработанный декор, который помогает визуально подчеркнуть важные для истории, сюжета и нарратива элементы уровня.
В финале третьего шага этапа прототипирования мы должны получить набор, возможно, разрозненных, но вызывающих уверенность механик. Однако уже здесь мы можем получить ответы на начальные гипотезы и осознать, если что-то пошло не так и придется вернуться либо на шаг назад, либо вообще начать заново и искать другую идею. Например, потому, что механика управления персонажем, передвигающимся по веткам дерева, оказалась слишком сложной для реализации, или потому, что механика менеджмента оказалась не такой интересной, чтобы вызвать отклик хотя бы у коллег.
* * *
Для окончания этапа прототипирования нам осталась сущая мелочь: собрать отдельные механики в более или менее законченную игру. На предыдущем шаге мы проверяли механики отдельно друг от друга, и теперь пришло время их соединить и добавить к ним механики, в которых мы были уверены и которые не проверяли. На этом же шаге нам важно оценить, получается игра в целом или нет. Все еще нет необходимости реализовывать вообще все механики, которые планируются в нашей игре. И да, здесь уже не получится проводить эксперименты на бумаге – нам нужно получить полноценную игру, которую смогут создать только программисты.
Если, например, отдельные механики перемещения можно объединить в одну, ничего особенно не меняя и не добавляя в игру, то механики менеджмента ресурсов могут потребовать разработать какую-то схему интерфейсов. Сам интерфейс может не иметь графики и продолжит выполнять тестовую функцию, но схема интерфейсов – это уже довольно серьезная часть игры. С технической точки зрения, интерфейсы не должны вызывать вопросов, хотя и тут возможны довольно сложные и оригинальные решения типа отображения какой-то важной для игры информации непосредственно на персонаже игрока. Но учитывая, что мы все еще проверяем, насколько интересна игровая концепция, неудачная схема интерфейсов может привести к тому, что игра покажется недостаточно интересной, даже несмотря на то, что отдельные ее компоненты работали хорошо.
К окончанию всего этапа прототипирования у нас должна быть игра со всеми реализованными основными механиками, показывающими ее суть, доказывающими интересность и перспективность концепции, а также возможность ее реализации. Эти доказательства могут потребоваться издателю или инвестору для финализации этапа и принятия решения о продолжении работы над игрой и переходу к следующему этапу.
Основной сложностью этой части этапа прототипирования является выбор механик, которые будут включены во всю игру, ведь они должны показать игру с лучшей стороны, быть важными, но не содержать ничего лишнего. Скорее всего, на этап прототипирования у нас будет ограниченный бюджет, а значит, и ограниченное время. Издатель будет смотреть не только на результат нашего труда – на прототип, но и на то, как мы распорядились выделенными нам средствами.
Даже если нет нужды в средствах и делаем игру в свободное от основной работы время, слишком затянувшийся этап прототипирования может оказаться серьезным препятствием на нашем пути к цели – привести к усталости и выгоранию из-за долгого времени без положительного отклика. Возможно, стоит набить руку на реализации отдельных механик в небольших проектах и переходить к чему-то серьезному уже с достаточным багажом опыта в разработке хотя бы основных компонентов: в создании интерфейсов, в настройке камеры и света, в создании механизмов управления.
И конечно, в финале всего этапа прототипирования мы или наши инвесторы должны принять решение: переходим к следующему этапу или возвращаемся. Если прототип оказался неудачным, то, скорее всего, придется вернуться на предыдущий этап и заняться поиском новой концепции.
Вертикальный срез
На прототипе подготовка студии к полноценному процессу производства игры может не закончиться. Есть еще один довольно важный аспект, требующий некоторого изучения.
До текущего момента мы работали только с механиками. Даже придуманный на коленке баланс и контент для менеджера мусороперерабатывающей фабрики создавался исключительно для того, чтобы проверить механику. Нет персонажей, нет цифр характеристик, нет локаций. Мы вроде бы доказали, что собранные нами механики могут составить хорошую (соответствующую нашим бизнес-целям) игру. И вот пришло время доказать, что мы можем не только собрать интересный набор механик, но сделать привлекательную игру и наполнить ее контентом: персонажами, цифрами характеристик и локациями.
Может показаться что данный этап ничем не отличается от непосредственного производства игры, но это немного не так. Здесь важно помнить, что производство – это конвейер. И он не терпит экспериментов, потому что это будет нарушать его работу, приводить к простою, за который придется платить, а бюджет не резиновый. Чтобы конвейер нормально работал, он должен быть очень хорошо отлажен. Должно быть известно, из каких этапов состоит производство отдельных элементов игры, сколько времени занимает каждый этап, сколько нужно произвести отдельных деталей для создания целого объекта – той же игровой локации, например.
Если у нас есть опыт управления проектами, мы можем сказать, из каких этапов в целом состоит производство конкретных игровых компонентов и какие навыки для этого требуются. Но, в зависимости от доступных нам ресурсов, отдельные исполнители для выполнения некоторых функций могут оказаться недоступны. Это означает, что в различных условиях конвейер производства будет работать по-разному и требовать настройки даже не для компании, а для каждого проекта отдельно. Более того, настройка нужна и при изменении количества доступных рук на тех или иных направлениях производства, учитывать как минимум отпуска, не говоря уже о возможном уходе кого-то из команды разработчиков.
Чтобы настроить конвейер, нам потребуется провести эксперимент и попробовать реализовать все элементы игры хотя бы в единственном экземпляре, чтобы замерить реальное время, необходимое для производства каждого из этих элементов. Идея заключается в том, чтобы получить хотя бы один уровень игры (если игра состоит из уровней), но финального качества. Со всеми необходимыми ассетами – персонажами и предметами – и выверенными параметрами.
Сам эксперимент, как и весь этап, называется вертикальным срезом. Кроме вертикального среза есть еще понятие горизонтального среза. Если вертикальный срез – это реализация всех механик с минимальным необходимым контентом, но финального качества, то горизонтальный срез – это реализация всего контента для какой-то одной механики, что в большей степени относится к самому производству.
Кроме помощи в настройке производственного конвейера, результат вертикального среза может принести пользу и даже быть необходим еще в двух случаях. Во-первых, финальное качество контента позволяет начать показывать игру за пределами студии: игру не стыдно отвезти на какую-нибудь выставку
