Это вторая часть моей статьи с левел-дизайнерскими Tips and Tricks, которые разработчик может использовать, чтобы повысить общее качество своей игры. Это ни в коем случае не пошаговое руководство, а только сборник идей и полезных советов, основанных на моём личном опыте. Первая часть статьи была больше ориентирована на визуальную составляющую дизайна уровней, в этот же раз мы поговорим о ещё более фундаментальных вещах, начиная с прототипирования и заканчивая плэйтестингом с аналитикой.
Прототипирование
Не секрет, что уделив время прототипированию сейчас, вы сэкономите море времени и сил позже. Это очевидно, это важно, и почему-то часто мы пренебрегаем этим этапом. По моему опыту, чем дольше команда работает, тем сложнее переживаются правки и переделки, поэтому критически важно с самого начала заложить надёжный фундамент в виде прототипа игры, уровней, ключевых игровых механик. Если говорить в контексте дизайна уровней, ваша работа условно делится на четыре этапа:
- “Greybox”. Уровень собирается буквально из серых кубиков. Здесь вы закладываете фундамент всей последующей работы и выясняете размер уровня, требуемые графические и аудио ассеты, работаете над игровыми механиками и скриптовыми эвентами.
- “Whitebox”. Геометрия уровня уточняется, по возможности добавляются новые игровые механики, диалоги, заготовки синематиков, звук и так далее. Здесь же вы ещё лучше вытачиваете существующие игровые механики и скриптовые эвенты.
- Графический пасс. К моменту работы над этим этапом вы должны быть убеждены, что на уровне интересно играть, и он всем вас устраивает. Заменять прототипную графику финальными ассетами долго и дорого. Любые изменения на этом этапе крайне нежелательны.
- Завершающий пасс. Здесь наносятся финальные штрихи: добавляются летающие в небе птички, звуки костров и прочие приятные мелочи.
- Полишинг. Неизбежный этап, как правило происходящий уже после того, как работа над уровнем была завершена. Тут будут правки мелочей, пропущенных ранее, а также изменения по результатам новых плэйтестов и собранной статистики.
На картинке ниже вы можете видеть сравнение этапов “whitebox” и непосредственно финальной графики в игре “Mass Effect 2”.
Хочу ещё добавить, что слишком ранний переход к этапу работы с графикой — серьёзная ошибка. Вы можете легко обмануть себя и команду, сделав уровень с захватывающей графикой, но никакущим геймплеем, и всё потому, что визуально он выглядит хорошо. Посмотрите на это полутораминутное видео из мода для “Gears of War”, хорошо иллюстрирующее работу над геймплеем при отсутствии большей части графического контента.
На этапе прототипирования в здоровой команде или компании важно придерживаться правила “Failure is an Option”. Вы делаете прототип, оцениваете результат и, если он вас не устраивает, выбрасываете. Быстрые итерации позволяют эмоционально не привязываться к проделанной работы, поэтому процесс получается простым и приятным. На скриншоте ниже — кусочек прототипа уровня из инди игры, над которой я работаю.
Во время прототипирования важно выяснить и утвердить размер героя, масштаб окружения относительно героя, а также скорость бега героя. Подробности дальше.
Масштаб героя
Как можно раньше утвердите размер игрового персонажа. Я работаю в Maya в сантиметрах, и обычно устанавливаю усреднённый размер главного героя: 200см. в высоту, 100см. в ширину и 100см. в длину. Таким образом, создавая любой новый контент (куст, танк, дом), мы всегда знаем их размер относительно героя. Предполагается, что размер коллайдера персонажа будет иметь примерно такие же размеры, соответственно, проходы и двери в зданиях обязаны быть как минимум в полтора-два раза шире коллайдера.
Также если у вас несколько 3d-художников, настоятельно рекомендуется, чтобы все следовали единой системе измерений. Иными словами, если у одного человека размер героя выставлен в 200 сантимеров, а у другого — в 2 метра, то при импорте в движок, например, в Unity, вам скорее всего придётся дать моделям разную компенсацию масштаба (Scale Factor), так как для Unity 2 и 200 “майских” единиц измерения — это разные размеры. Ситуация усложняется, когда вы работаете с программами типа 3ds Max, где система координат оперирует абстрактными единицами измерения, поэтому придётся поэксперементировать в поисках общих размеров для всех пакетов трёхмерной графики, задействованных в вашей команде.
Масштаб окружения
Работа с масштабом окружения — крайне интересная тема. Следуя рассуждениям из предыдущего пункта, вам нужно работать в реальных масштабах, отталкиваясь от утверждённых 200см. И в то же самое время вам придётся лгать непросыхая. Соль в том, что временами объект реального размера ощущается слишком большим или слишком маленьким, и приходится корректировать его масштаб, пытаясь добиться достоверного, хоть и неправильного размера. Это хорошо прослеживается в играх со стилизованной графикой, например, “World of Warcraft”, где часто можно видеть объекты вроде каменных лестниц со ступеньками высотой чуть ли не с персонажа. Что интересно, в контексте стилизации это смотрится уместно и не вызывает вопросов, но если присмотреться — всё это чертовски странно.
Тем не менее, надо стремиться к тому, чтобы в среднем ваша сцена имела реальные размеры. Особенно это важно ввиду модного нынче тренда на физически корректные материалы и освещение. Известно, что интенсивность света уменьшается пропорционально квадрату расстояния. В таком случае, если в вашей сцене из-за ошибок в масштабе настольная лампа будет иметь размер под 5 метров, то неизбежно придётся подкручивать математику освещения, чтобы оно выглядело более-менее адекватно в этих условиях. В конечном итоге ваша сцена будет состоять из множества вот таких “хаков”, негативно влияющих как на саму работу физически корректного рендера, так и на качество картинки в целом.
Масштаб окружения как правило познаётся только в сравнении с человеком или очень знакомыми предметами. Предположим, что вы делается научно-фантастический шутер, действие которого происходит на странной чужой планете, где даже архитектура выглядит крайне необычно. Какой размер вон того… камня (или это растение?). Или какой размер у вот этого здания? Совсем не ясно. И только если раскидать по сцене фигурки людей, то вы сразу поймёте масштаб происходящего. В отдельных случаях сработают очень знакомые объекты: на картинке привычная форма автомобилей задаёт точку отсчёта для масштаба.
Есть ещё хороший метод, позволяющий лучше отобразить масштаб сцены в целом. Покажите некий объект вблизи, затем его копию расположите где-нибудь подальше, потом ещё дальше. Игрок понимает, что это однотипные объекты, и разницу в масштабе воспринимает как разницу в расстоянии до объекта. На изображении ниже объекты настолько большие, что все вместе не вмещаются в один скриншот. В итоге имеем эпичный размах локации. К слову расскажу ещё один классный трюк: если размер отдалённого объекта немного уменьшить, то он будет казаться дальше, чем он находится на самом деле. Этим часто пользуются для создания сцен колоссального размера, хотя на самом деле это всего лишь хитрая игра с масштабами и туманом.
Скорость движения героя
Масштаб окружения не имеет смысла без аккуратно выверенной скорости передвижения героя. Чем быстрее герой передвигается, тем сильнее сжимается пространство. Хорошим примером является введение летающих ездовых животных в “World of Warcraft”. Прежде мир казался достаточно большим: требовалось время, чтобы добраться из одной точки в другую. С появлением воздушного транспорта это перестало быть проблемой, скорость перемещения героя радикально изменила размер мира при том, что сами локации какими были, такими и остались.
Очевидно, что такая скорость передвижения влияет и на геймплей: прохождение квестов, энкаунтеры с монстрами, охота за сокровищами и поиск дороги куда-либо (одно дело взбираться на гору, и другое — просто взлететь и приземлиться на вершину). От скорости так же зависит детализация окружения. Прикиньте, как бы вы детализировали гору, по которой герой-альпинист будет карабкаться на вершину, и гору, мимо которой герой-лётчик бы пролетел на самолёте.
Таким образом скорость передвижения важно утвердить как можно раньше на этапе прототпирования, в противном случае вас ждут постоянные переделки.
Время прохождения уровня
В эпоху мобильных игр разработчики стали много внимания уделять продолжительности игровой сессии. В отличие от ПК и консолей, здесь критически важно выяснить, как долго игрок может находиться вовлечённым, прежде чем ему придётся вернуться в реальность — дождался очереди, доехал до нужной станции, кончилась перемена.
Как следствие, вы должны точно знать, сколько времени игрок может потратить на прохождение отдельного уровня, и на основе этих данных уже работать. В противном случае рано или поздно вам придётся перекраивать все уровни, подстраивая их под требования. В “Flappy Bird” с его мгновенными смертями игровая сессия может быть крайне короткой. В то же время открытый мир “Dragon Age: Inquisition” угрожает засосать вас на часы, причём всё действие будет происходить на одной локации.
Гладкие коллайдеры для гладкого геймплея
Предположим, у вас есть ряд мелких объектов типа коробок и бочек, каждый имеет свой коллайдер. Если герой побежит прямиком в группу объектов как на скриншоте ниже, он будет застревать и тупить ввиду хаотичности общей формы коллайдеров. Формально вы всё сделали правильно — коллайдеры корректно обыгрывают форму индивидуальных объектов. Однако представьте ситуацию в мобильной игре, где управление гораздо менее точное, чем на ПК или консоли. Игрок будет чаще втыкаться в объекты, и ему будет сложнее выбежать из окруживших его коллайдеров.
Возьмём ту же группу объектов и дадим им общий коллайдер. Теперь игрок не просто не будет втыкаться в углы, но контроллер персонажа автоматически будет обтекать группу объектов. Как результат — приятное плавное движение героя.
Для наглядности я сделал GIF с демонстрацией плавного движения вокруг обтекаемого коллайдера. Как всегда есть подводный камень. Общие коллайдеры не должны захватывать много пустого пространства. Невидимые стены жестко бьют по вовлечению. Если я пытаюсь отбежать от удара монстра и в ключевой момент втыкаюсь в невидимую стену, это сильно раздражает.
Не все коллайдеры одинаково полезны
Одна из важнейших задач дизайнера уровней — создать максимально приятный игровой опыт, на который коллайдеры оказывают колоссальное влияние, как можно судить из предыдущего раздела. Следует дважды подумать, прежде чем дать коллайдер маленькому объекту. В пылу боя игрок может пройти сквозь небольшой объект и совершенно не обратить на это внимание. Однако если он внезапно воткнётся в непроходимую невидимую стену, созданную крохотным объектом, пристроившимся в уголке, это неизбежно выбьет его из тонкого состояния потока.
Могу дать показательный пример из “Ведьмака”: вы видите группу коробок, с которых можно собрать добычу. Вы пытаетесь дотянуться до них, но Геральт вдруг начинается путаться в коллайдерах, втыкаться в невидимые стены, вертеться на месте и вообще вести себя как утопец на костре. Это напрочь ломает ощущение вовлечённости в игру, и вы невольно тянетесь за кружкой кофе, возвращаясь в реальность.
Occlusion Culling
Просто хочется напомнить об этой технике. Если коротко, она отключает рендер объектов, спрятанных за другими объектами. Unity, например, позволяет “запекать” Occlusion Culling, что оказывает существенное влияние на производительность. Причём как в лучшую, так и в худшую сторону, в зависимости от ситуации. Два примера:
- В мобильной игре с Top-Down камерой (как в Diablo) активация этой функции экономит 2-4 Draw Calls (DC). В то же время к работе процессора добавляется 5мс. на обработку кадра. Совершенно не стоит того.
- В ПК игре с First Person камерой, где действие происходит в узкой пещере, изначально имеется 450 DC. Активация Occlusion Culling уменьшает количество DC до 50 ценой тех же +5мс. Однозначно использовать нужно.
Параллакс и псевдо-3d
Любая 3d игра на экране монитора — это всё равно массив пикселей в 2d плоскости экрана, как ни крути (VR не в счёт). Но есть ряд трюков, позволяющих создать иллюзию трёхмерного пространства. В плане дизайна уровней, самым полезным инструментом будет осознанная разбивка картинки на передний, средний и дальний планы. Проще всего это реализуется в играх с Top-Down камерой а ля “Diablo” и “Path of Exile”, а также в сайдскроллерах (платформерах). Средним планом является ваш персонаж. Дальним может быть эпичный вид, как на следующем скриншоте, но чаще это просто отдалённые объекты.
Передний план интереснее. Как правило, здесь используются затенённые объекты типа свисающих верёвок, цепей, люстр и прочего барахла, создающего параллакс между фонами. Параллаксом называется различие в скорости движения планов относительно камеры. То есть передний план всегда сменяется быстрее, чем дальний, в целом остающийся статичным из-за его удалённости от обозревателя.
Сложнее всего показать передний план в играх от первого и от третьего лица. Разработчики идут на разные хитрости, вот несколько примеров:
- Грязь на стекле дыхательной маски, как в “Метро 2033”.
- Брызги крови прямо перед лицом, когда ради шкуры герой разделывает тушу зверя в “Far Cry”.
- Руки и тапки персонажа, как у Faith в “Mirror’s Edge”.
- Треснувшее стекло автомобиля во время вождения (”GTA”, “Far Cry”).
- Пушка перед лицом, особенно в режиме оптического прицела (любой шутер).
- Препятствие (бетонный блок, угол дома), за которым прячешься от противников. Игры специально поощряют такой геймплей. Например, в “Far Cry 4” можно прятаться за кустами, и противник вас видеть не будет.
- Помехи в расположенном на экране нейроинтерфейсе, как в “Black Ops 3” и “Deux Ex: HR”.
Невидимые стены
Это достаточно специфичный случай, но стоит упоминания. В инди проекте, где я работаю, мы применили такую механику: когда вы входите в определённую зону, за спиной у вас возникает магическая стена, и впереди начинают появляться монстры. После гибели всех монстров заколдованные стены пропадают. Мы сделали это по аналогии с другими мобильными проектами типа “Dungeon Hunter”, а также по аналогии с “World of Warcraft”, где при битве с боссами у вас за спиной точно таким же образом перекрывается проход.
Так вот, это дешёвый и ленивый способ, упрощающий и ускоряющий работу. Но и результат такой же дешёвый; игрок это чувствует. Старайтесь уходить от этого, пусть и классическим методом: спрыгнуть с уступа вниз, а обратно уже никак не забраться. Клише? Да, но всё лучше невидимых стен.
Есть ещё более непростительный подкласс невидимых стен — убивающие игрока границы уровня. Хуже, если разработчик строит геймплей вокруг этого ужаса. Яркий пример из “Destiny”: сундуки с сокровищами нередко ставятся возле самой границы уровня, да так, что часто неочевидно, где именно проходит граница. В итоге глупая смерть неизбежна, когда вы прыгаете на ровный камень в двух метрах под вами, а он в ответ мгновенно убивает героя. И да, это не смерть от падения в игре, где можно прыгать на 10 метров в высоту и приземляться на твёрдую землю без особых проблем.
Целевая платформа
Насколько это очевидно, настолько же часто это игнорируется. Всё, что вы делаете, должно проверяться на целевой платформе. Я не раз видел, как человек увлекается задачей, например, проектированием GUI, и забывает проверять свою работу на мобильном устройстве, где интерфейс будет использоваться.
То же самое с уровнями. Важно не лениться и регулярно тестировать свою работу на целевой платформе. Если вы создаёте игру для консоли, смотрите, насколько комфортно бегать и воевать с использованием геймпада. Если же уровень разрабатывается для мобильного устройства, то чем чаще будете смотреть свою работу на маленьком экранчике с крайне неточным тач-управлением, тем меньше головной боли получите в будущем. Впрочем, дело даже не головной боли, а в качестве работы. Вовремя заметив, что движетесь в неправильном направлении, вы сможете своевременно подкорректировать вектор работы и в итоге получить достойный результат.
Плэйтестинг
Плэйтестинг — совершенно сюрреалистичный экспириенс, уж простите за англицизмы. Трудно передать словами ощущения от наблюдения за игроком, взаимодействующим с вашим уровнем. Да и вообще увидеть игрока на своём уровне — это прилив мотивации, что всегда хорошо для инди разработчика, не получающего за свою работу ежемесячного денежного вознаграждения.
Тем не менее, главная задача — это проверить все свои гипотезы на практике, увидеть, где недотянули и где требуются правки. Как у любого творца, со временем глаз замыливается, и вы неизбежно допустите какую-нибудь ошибку или что-то недоглядите. Чем раньше будет адекватная обратная связь — тем лучше.
Аналитика
Плэйтестинг хорош, но наблюдение за 5-10 игроками — это не статистика, поэтому есть смысл отслеживать поведение сотен или тысяч игроков. Например, собираем данные с частотой и координатами точки гибели героя и понимаем, в каких местах игра слишком сложная, вносим правки в баланс и повторяем весь процесс.
Причём даже если вы ещё не релизнулись, но имеете несколько тестеров, либо у вас демка доступна ограниченному количеству людей (например, “бэкеры” с Kickstarter’а), всё равно имеет смысл собирать и анализировать данные уже на этом этапе.
Polishing
Старайтесь оставить чуть-чуть времени на “полишинг”, то есть на мелкие правки и закрытие небольших дыр, до которых раньше не доходили руки по той или иной причине. Например, на один из моих недавних уровней стоит задача со списком из 29 пунктов. Каждый из них требует от 5 до 15 минут работы. Поборов эти проблемные места, вы переводите уровень с этапа “полишинга” в статус “final” или “release candidate”. Проблемы, которые надо “полишить”, будут всплывать во время плэйтестинга и сбора статистики. Эффективнее не бежать сразу править каждую крошечную недоработку, а подготовить отдельный список, после чего поправить всё скопом. Помните, этот этап неизбежен, поэтому заранее оставьте на него время, даже если вы уверены, что сразу сделали всё круто, и “полишить” не придётся.
Заключение
На этом я завершаю эту статью, состоящую из двух частей. Если вы пропустили первую часть, то вот ссылочка. Также если вы интересуетесь освещением в Unity, вам может быть интересна моя недавняя статья тут же, на Хабре. Накопив больше опыта, вижу в статье некоторые неточности, но в целом она очень близка к реальности. Поэтому если вы только изучаете тему освещения в Unity, материал должен быть вам полезен.
Буду рад любым комментариям и предложениям. Кроме того, принимаю идеи для новых статей по левел-дизайну, а также освещению и постэффектам в Unity 🙂 Спасибо за внимание!
ссылка на оригинал статьи http://habrahabr.ru/post/274625/
Добавить комментарий