Продолжаем разбор темы «прототипирование игр». мы рассмотрим примеры ловушек, в которые попадают геймдизайнеры на начальном этапе разработки игр.
Статья основана на выступлении Алексея Савченко (Epic Games) в рамках открытой конференции-квеста по игровым механикам в онлайн-формате, в виртуальном здании Вышки, воссозданном в Minecraft. Мероприятие было организовано проектом HSE Minecraft и руководителями образовательных программ по игровой индустрии ВШБИ – «Менеджмент игровых проектов» и «Основы создания игр».
По поводу обманчивости
Первый шаг, который в голове обычно щёлкает, о том, что буквы дурят — надо визуализировать. Очень часто, преодолев этот момент, люди начинают использовать какие-то прикладные инструменты, начинают много рисовать. В моём личном опыте, я настолько разочаровался в паре результатов, что был долго при мнении, что игру вообще всю нужно раскадровать, как в кино, что только после этого ты будешь уверен, что всё будет хорошо. Но это дорого, достаточно сердито и мрачно. Здесь момент такой: когда вы выходите на стадию визуализации, начинаете использовать какой-нибудь SketchUp, какие-то картинки, карту и т.д. вы переходите от слова к 2D, ваше понимание лучше, но оно не финальное. 2D- и 3D-мышление настолько разное, и настолько оно по-другому будет работать в движке, что нужно всё равно прототипировать в нём. (Под 2D здесь подразумевается визуализация/зарисовки/схемы, а под 3D — прототипирование в рабочей среде. Прим.ред.)
Из рабочих примеров. Мы когда-то делали с командой товарищей MOBA, но с военной техникой. Казалось бы, ну что может пойти не так? Профессиональные дизайнеры, люди с десятилетним опытом работы в индустрии. Нарисовали 2D карту: карта понятная, три лайна, техника; из инноваций — военные базы, которые располагаются в промежуточных точках (небольшой элемент Battlefield в этом всём); пересечённая местность, чтобы сделать это всё интересней; юниты типа «Hero of vehicles» — всякие танки, броневики, у которых по 4-5 абилок; цель — уничтожить базу. На бумаге всё прекрасно выглядит. Карта для MOBA, как вы наверное понимаете, не может выглядеть как-то по-другому, она может быть немножко вариативна, но в целом там тяжело ошибиться.
Собираем прототип. Причём делается это супер-быстро, используя те же blueprint’ы, скрипторы и т.д. Вы элементарно лепите карту тулзами ландшафта, размечаете разный тип terrain’а разными цветами, чтобы не заморачиваться. Условно, сделать абилки юнитов — тоже очень легко, практически всё работает по tick’ам, по нажатию кнопки срабатывает какой-то модификатор, который меняет либо health, либо создаёт какой-то VFX, либо делает какое-то действие — в инструментах визуального скриптования можно прототипировать по 20 абилок в день. Как-то это базово настраиваем, запускаем… и что?
Во-первых, ты понимаешь, что 3D тебя жестоко гнобит тем, что (вспоминаем Paragon) наличие любого вертикального аспекта в геймплее мобы — челлендж крайне дурацкого и невероятного уровня. Учитывая, что это ещё и техника, а у техники есть ограничения, например, поворот башни, дуло может смотреть выше или ниже (хотя это можно в игровых условностях отменять, но это плохая идея, потому что фанаты техники в целом за то, что ничего не должно меняться в hardware’ных характеристиках юнитов). Плюс абилки, по своей динамике, и по скорости, которую будет игрок ожидать от визуализации танка в 3D пространстве, просто не работают. И мы бились над всем этим ещё три недели, но идеальный бумажный план был проверен базовым приближением в визуальном отображении. В итоге сделали несколько вариантов, которые подходили под всё это лучше. Изменили сеттинг на фантастический, потому что можно будет вводить понятие hover-юнитов. Вспомнили игру Warzone, ту часть, где можно было ещё и юнитов немного модифицировать самостоятельно. Придумали прикольную историю с тем, что количество лайнов варьируемое и техника разнообразная, вплоть до вертолётов и т.д. Но в целом, без каких-то таких проб, ошибок и проверок гипотез в 3D пространстве, ты не поймёшь, что врут не только буквы, но и картинки. Пока руками не попробуешь — вообще не понятно. Когда начинаешь пробовать в 3D, то понимаешь, что уровень базовых настроек сожрёт большое количество времени.
Хорошая история была, когда выложили исходники игры Gears of War на UE3, чтобы разработчики могли посмотреть, как она устроена. Когда ты смотришь, как там всё сделано, ты понимаешь, что там, простите, кишки дизайнера размотаны по всей игре. Потому что там такое количество версий и импровизаций, что это может быть достигнуто только процессом проб и ошибок. Например, вы наверняка все наслышаны о таком понятии, как камера игрока. В любой успешной ААА-игре используется 16 таких камер и есть процессы блендов и переключения между этими камерами. Плюс специальные камеры ивентов. То есть это сложная задача, которую иногда можно решить только объемом работы.
Вместо заключения
В завершение темы, я могу вам сказать, как людям, которые, вероятно, прошли какие-то базовые курсы геймдизайна, людям которые собираются делать игры, что даже если вы больше стремитесь к авторскому подходу, к теоретике, к около-научному, фундаментальному разворачиванию своих концепций, это никак не мешает вам освоить базовые практические навыки технического дизайна. Технический, с точки зрения сборки руками прототипа и т.д. Поверьте, не существует лучшего способа, как минимум, устроиться на хорошую, престижную работу, условно, junior-геймдизайнером, чем прийти со своим собственным прототипом своего видения какой-то игры на одном из движков. Это козырь, прямо сразу видно, что вы что-то умеете, помимо того, чтобы просто буквы писать. И по этому контенту видно, что вы как-то разбираетесь в предмете.
Нет никакого другого, более ценного упражнения, кроме подобного прототипирования, чтобы наладить диалог с прочими отделами в компании. Мы все кодифицируем язык, и геймдизайн — это некоторая каста, своеобразный Гриффиндор в игровой индустрии, потому что есть ещё программистский Слизерин, артовый Пуффендуй, и бизнес — Когтевран. Все разговаривают немного на разном языке, а использование одной среды разработки и одного и того же языка очень сильно сближает. В движке подобным уравнителем арго часто является tool-set, который будет использоваться в движках. Есть странное противопоставление в головах людей. Говорят, вот, «нарративщики». Нарратив — это же не про сценарий в широком смысле, это способ интерактивной передачи концепции в мозг другого живого двуногого. Я когда-то по прототипам за 2 недели собрал этакий ATBRPG, типа Final Fantasy VII, где нужно бегать по карте, можно было разговаривать с другими персонажами и брать квесты (этот кусок я честно подмотал на маркетплейсе), можно было переходить на экран боя, у меня там было четыре персонажа, у которых были разные абилки, штук восемь, которые все тоже работали по такому принципу смешному, из области, «при условии необходимого количества маны, по выбору данной функции отрабатывает VFX, который наносит такой-то damage в зависимости от характеристик другого персонажа» и т.д. И это всё очень быстро собирается. То есть если вы хотите оттранслировать какую-то историю посредством прототипирования в движках — это очень просто.
Продолжение следует.
Я постарался как можно точнее законспектировать рассказ спикера, и надеюсь, что вам понравился такой формат.
Полное видео того, как эта лекция проходила в Minecraft можно посмотреть на Youtube-канале разработчиков игр, сама лекция здесь>>>
Следующая часть статьи будет в формате Q&A, в ней Алексей Савченко ответит на вопросы слушателей конференции касательно таких аспектов разработки как UI/UX, сложности оптимизации и многое другое.
Пишите комментарии – мне очень важно знать ваше мнение.
Возможно у вас будут какие-то пожелания или вопросы?
Автор статьи – Андрей Мишаев.
Статья создана при поддержке ВШБИ НИУ ВШЭ