Продолжаем разбор темы «прототипирование игр». В этой части мы поговорим о прототипировании, как основном методе проверки гипотез, а также рассмотрим вопрос доступности прототипирования.
Статья основана на выступлении Алексея Савченко (Epic Games) в рамках открытой конференции-квеста по игровым механикам в онлайн-формате, в виртуальном здании Вышки, воссозданном в Minecraft. Мероприятие было организовано проектом HSE Minecraft и руководителями образовательных программ по игровой индустрии ВШБИ – «Менеджмент игровых проектов» и «Основы создания игр».
Прототипирование — как основной метод проверки гипотез
Когда вам рассказывают, что «можно сделать механику на кубиках, graybox’ах или whitebox’ах» — это хорошо только внутри студии. Потому что когда вы выносите наружу какой-то результат, когда все эти системы не сведены вместе в базовое представление для какой-то общей репрезентативности, получается в итоге не очень хорошо. То есть основная теза, которую нужно держать в голове, заключается в том, что после того как документация, состоящая из ваших гипотез появилась, вы войдёте в процесс, который выглядит как декомпозиция на проверяемые гипотезы. Он выглядит как одна глобальная история: прототипирование, итерация этих прототипов, сборка, пробы, проверки, ошибки и повторения. Что не плохо, хотя и может звучать достаточно грустно или скучно.
Вам скажет любой функционирующий геймдизайнер из средней или большой компании, что когда ваши гипотезы пройдут проверку игровыми сеансами, вашей собственной критикой, критикой вашей команды и критикой play-тестирования, фичи, которые планировались, как какие-то определённые, будут видоизменяться в совершенно другие, но, возможно, намного лучшие, чем вы себе представляли сначала.
Хороший пример по этому поводу из личной практики: 12 лет назад я работал над игрой под названием Salvation (консольный 3D adventure). Там был блок, посвященный stealth-механике. Вроде на бумаге всё хорошо: нарисованы карты того, как расположены вражеские персонажи в портовой зоне; примерно прописано базовое первое приближение их конусов видения; понятен главный персонаж; понятны условия победы/поражения; примерно понятно наличие двух режимов передвижения противников; плюс прописан базовый набор скриптов того, как они поворачиваются и смотрят по сторонам; прописано, как реагируют противники на мертвые тела и шум; у главного героя есть снайперская винтовка с глушителем и нож, которым можно совершать бесшумные убийства. Вроде бы, стандартный набор механик, который позволяет собрать достаточно крепкий stealth и довольно интересную сцену, если правильно всё рассчитать, разрулить. Это работает в миллионе игр, и нет никаких причин, почему бы это не сработало бы здесь.
Собрали билд на движке. После первых тестов произвели техническую подстройку: изменили бленды анимаций; переработали часть системы укрытий; ограничили количество боеприпасов снайперской винтовки, потому что стало очевидно, что это некий «ульт»; изменили стрельбу, чтобы было интересней стрелять — всё равно скучно. В процессе дополнительного тестирования стало ясно, что очевидно не хватает как минимум системы рейтинга, чтобы эту сцену необходимо было проходить на время, чтобы был какой-то внешний фактор-индикатор, который позволяет простимулировать действия игрока. Ввели ещё несколько механик, которые сделали эту сцену в принципе интересней. Но придумать и продумать всё это на стадии планирования, до того, как в игру переиграло 10-20 человек по 12-20 часов — не представляется возможным. Таким образом, идеализирование того, что на бумаге всё можно с самого начала предугадать — не правда. Возможно и есть в индустрии какой-нибудь супер-опытный дизайнер, который 50 лет делает игры и 30 лет работает с одной и той же командой, и они друг друга телепатически так хорошо понимают, и у них практически одинаковый tool-set в голове и в настройках скриптов, и в прочих элементах, которые в совокупности позволяют им такое делать, но мы все — не эти люди. Поэтому тестировать придётся много и достаточно плотно.
Также важная теза, что тестировать нужно на preproduction'е и прототипировать все базовые фичи нужно до прототипа отдельно, затем в базовом прототипе игры, а потом — в вертикальном срезе. Есть такая сентенция: на preproduction'е происходит всё творчество и креативная часть. Это 20-25% всего времени разработки. А остальные 75% производства — это выполнение заложенных планов на preproduction'е. Не знаю, насколько это очевидно, но после того, как всё выдумано и задокументировано, собран вертикальный срез, который показывает, как это всё должно выглядеть в итоге (вертикальный срез игр всегда включает в себя основной игровой цикл и базовые механики, основных персонажей и субмеханики, которые будут отрабатываться), после всего этого, когда проект уходит в производство, вбрасывать какие-то “идеи-на-лету”, если вы работаете где-то в какой-то компании, никто не даст. А если вы строите свою студию, то сначала вы, скорее всего, будете это делать, а потом поймёте, что это ломает все ваши планы и перестанете это делать сами.
О доступности прототипирования
Прототипировать можно очень по-разному. Раньше было сильно сложнее. Эта история с дизайн-документом и проверкой гипотез на бумаге, с сессиями настольных игр и прочим, тянется ещё с тех седых времён, когда способов проверки было существенно меньше. Сейчас каждый современный движок, будь то Unity, Unreal или CryEngine, обладают внутренними нативными, либо внешними системами прототипирования и визуального программирования, что очень помогает. Я начинал с UE3, там для этого использовался Kismet, сейчас уже используются Blueprint’ы, которые намного удобнее, понятнее и проще. Раньше было совсем тяжело: ты пишешь документ, отдаёшь его в программный отдел, как правило, это происходило в компании, где использовался свой собственный движок. Чтобы геймдизайнеру что-то сделать, необходимо было, чтобы программисты отвлеклись от какого-нибудь своего рендера и написали для дизайнера какие-то тулзы, а они этого делать не хотят и т.д. Потом геймдизайнеру отдают эти тулзы, а они не работают и их нужно ещё настраивать. В итоге, из грязи и палок лепится что-то страшное, но симпатичное, и, можно сказать, что это базовый прототип.
Сейчас всё настолько проще, что для прототипирования базовых вещей вам даже не обязательно составлять половину скриптов, потому что на маркетплейсах практически любого движка уже лежат готовые темплейты, которые стоят копейки. Например, «система персонажей», «система камер», «система диалогов» и т.п. Можно это брать, комбинировать и смотреть, что получится. Очень важно прототипировать руками, потому что только прототипируя руками вы начнёте разрабатывать свой личный tool-set и понимание того, как работают механики, понимание грани между кросс-дисциплинарными языками и мышлением, которое вам нужно, чтобы заработала синергия внутри компании. Вы, например, придумаете оружие, как геймдизайнер-новичок: оружие такое-то, класс такой-то, стреляет из ствола, если нажать на курок, в обойме 30 патронов, выглядит как в игре Uncharted и т.д. Если вы прокаченный геймдизайнер, вы уже делаете систему оружия. Вы плотно поработали с настройками внутри движка и приходите уже с другой постановкой задачи: вот снайперская винтовка, она использует instagib — моментальная отметка цели поражения, скорость пули не существенна, баллистики нет, физика плоская и прочее. А вот эти три вида оружия используют баллистическую модель Projectile, скорость пули такая-то, нужно ещё дополнительно 8 характеристик. Внутренний редактор оружия давайте соберём на blueprint’ах, чтобы я вас не отвлекал. Вот такой уровень интеграции очень сильно помогает и вам, и отделу, и компании в целом.
Продолжение следует.
Я постарался как можно точнее законспектировать рассказ спикера, и надеюсь, что вам понравился такой формат.
Полное видео того, как эта лекция проходила в Minecraft можно посмотреть на Youtube-канале разработчиков игр, сама лекция здесь>>>
В следующей части мы рассмотрим примеры ловушек, в которые попадают геймдизайнеры на начальном этапе разработки игр.
Пишите комментарии – мне очень важно знать ваше мнение.
Возможно у вас будут какие-то пожелания или вопросы?
Автор статьи – Андрей Мишаев.
Статья создана при поддержке ВШБИ НИУ ВШЭ