• Скорость передвижения

• Прыжок

• Размеры лестниц

• Размеры дверей

• Размеры коридоров

• Размеры укрытий

• Wall Run

Почти все эти метрики уже были описаны на бумаге, но для наглядности и тестирования необходимо было собрать специальный уровень. На нем мы располагаем все объекты и проверяем, насколько их размеры сочетаются с текущими настройками.

На текущий момент наш уровень с метриками выглядит вот так:

Будь изобретателен

Основной проблемой в нашем случае оказалась физика передвижения, которую мы решили использовать для более динамичного передвижения.

При перемещении, прыжке и прочих действиях на игрока действует инерция, которая подталкивает его даже после завершения действия.

В силу небольшой команды и большой загруженности сделать техническую фичу, которая бы измеряла длину прыжка и прочие штуки, было бы слишком “дорого”. Поэтому мне пришлось быть изобретательным.

Для измерения длины прыжка собрал вот такую платформу, на которой можно было измерить длину прыжка при разных вводных. Стандартный прыжок, прыжок в спринте и прыжок с распрыжкой.

Уделив этому достаточно времени, я бегал, прыгал и все это записывал, чтобы понял оптимальную длину прыжка, чтобы в будущем на уровнях делать правильного размера “обрывы для перепрыгивания.

Также дополнительно собрал платформу для проверки, какие “обрывы” перепрыгиваются хорошо, а какие будут ощущаться некомфортно.

Похожая история была с механикой WallRun. На входе у нас есть только “время бега по стене”. Оптимальную длину стенки для бега и расстояния, которое можно преодолеть нужно было вычислять вручную на специальной платформе.

Плюс такого подхода в том, что я визуально видел размеры “обрыва” и расстояние, которое может преодолеть игрок. Поэтому мог легко крутить настройки времени “бега по стене”, чтобы добиться оптимального для нашего геймплея расстояния.

Выйди и зайди нормально

Одна из ключевых метрик, которая первой появится на вашем уровне это размеры дверей. Для каждого жанра размер дверей будет разный, поэтому правильного ответа тут нет.

Самое главное, что нужно понимать, в играх размеры объектов зачастую больше их реальных прототипов в силу того, что взаимодействие игрока с миром гораздо более поверхностное, чем в реальной жизни.

Это лучше всего заметно, как раз, на примере дверей. Зачастую двери в играх всегда в 2-3 раза больше их реальных прототипов. Это необходимо для того, чтобы дверной проем не ограничивал движение игрока и не давил на него.

В нашем случае мы остановились на четырех основных размерах дверей. Они будут использоваться в разных местах, но ключевые размеры будут оставаться неизменными.

На фоне дверей есть коридоры, которые также значительно больше реальных прототипов, и зачастую они также увеличены в 2-3 раза.

Также важно уметь “Выделить” дверь для игрока, особенно если мы хотим чтобы он в нее зашел.

Для этого используются различные способы, выделение светом и цветом считаются основными, но помимо них, нужно учитывать и пространство вокруг двери.

Зачастую дверь выделяют более мелкими объектами, которые как бы заранее демонстрируют размер дверного проема.

А если дверь находится “под” или “на” лестнице, важно создать “буферную зону” вокруг нее. Чтобы при входе в проем игрок мог сориентироваться что находится дальше.

Да кто эти метрики ваши?

Подводя итог важно повторить.

• Метрики крайне полезны и необходимы при разработке уровня и тестировании механик.

• Уровень с метриками ваша “игровая” где вы проверяете свои идеи, а другие члены команды могут вживую пощупать как должен играться тот или иной элемент.

• Без метрик можно собрать прототип уровня, но это займет гораздо больше времени.

• Имея уровень с метриками у вас есть наглядные примеры того, что вы можете использовать на уровне.

• Метрики это часть ГДД, но внутри движка, там наглядно отображено то, что вы описали на бумаге.

От идеи к полноценной схеме

Ну что, вот у нас уже есть какие-никакие метрики, достаточные для создания уровня.

Сразу же появляется желание запрыгнуть в редактор и начать собирать уровень, но это ошибка. В редакторе будет удобно работать с уже готовой идеей уровня.

Поэтому на первом этапе создания уровня наши главные друзья это листок и ручка, ну или любые другие способы рисования. В моем случае это был планшет.

Для начала стоит держать в голове, чего вы вообще хотите от уровня. Должен он быть линейным, может быть он закольцован и прочее. Также важно понимать общие размеры уровня.

Я начинал с базовых форм, которые в будущем превратятся в крупные комнаты/арены, а затем соединял их примитивными линиями, которые впоследствии переработаются в комнаты и коридоры.

Так у вас получается драфт уровня, от которого вы уже отталкиваетесь и добавите ему деталей, а возможно поймете, что не стоит продолжать и начнете сначала.

Не стоит недооценивать этот этап, проще понять что вам не нравится уровень после пяти минут с карандашом, чем после целого дня блокинга.

Имея на руках базовый набросок уровня, можно добавлять на него некоторые детали и логику поведения игрока. Стоит сразу на схеме отображать как и куда вы хотите вести игрока, это в дальнейшем позволяет детализировать схему и добавлять мелкие объекты или комнаты.

Как видно на гифках, уровень постепенно увеличивается и отходит от стартовых базовых форм. Как только вы становитесь уверены в своем уровне, можно начать его детализировать, подгонять под метрики и размерную сетку, для более удобной работы.

По итогу у меня получилась вот такая схема уровня. На ней я отобразил логику движения игрока, примерное расположение противников, а также пометил помещения, где игрок будет отдыхать, а где его ждет экшн.

И уже с такой относительно проработанной схемой мы можем пойти в редактор и начать собирать уровень.

Важно понимать, что над схемой я работал несколько дней и пробовал разные варианты, что-то ушло в мусорку на стадиях набросков, что-то еще позже после обсуждения с командой.

Но не страшно отказываться от идей и начинать заново, в будущем это сэкономит вам кучу времени на этапе блокинга.

Превращаем схему в осязаемый уровень

И вот у нас на руках уже есть готовая схема, теперь можно смело запрыгивать в редактор.

Для начала стоит определиться с инструментами. Мы работаем с движком Unity, поэтому инструменты советую именно для этого движка.

Лично я пользуюсь плагином ProBuilder для Unity и набором текстур Gridbox Prototype Materials.

ProBuilder позволяет быстро возводить элементы окружения и точечно настраивать каждый создаваемый элемент, а набор текстур позволит вам не забывать про масштабы и наглядно разделять цветом необходимые вам элементы.

Подготовили инструменты и начинаем работу. Как это делаю я?

• Закидываю нарисованную схему на уровень отдельным слоем

• Подгоняю размерную сетку на схеме к оригинальным размерам в редакторе

• Цепляю из уровня с метриками нужные мне элементы и откладываю в сторону для быстрого доступа

• Постепенно начинаю воспроизводить элементы уровня в редакторе прямо на схеме – Для шаблонных элементов пользуюсь заготовками уровня с метриками

Важно понимать, что во время создания блокаута вы сможете сразу-же тестировать уровень. Поэтому финальный вариант может отличаться от схемы, комнаты могут стать чуть шире, где-то пропадет или появится проход и так далее. Не переживайте, это не значит что ваша схема была плохой, просто в 3D пространстве вам станет гораздо понятнее логика вашего уровня, которая до этого была только в 2D и вашей голове.

Во время создания блокаута вы можете пренебрегать “красотой”, самое главное создать нужную геометрию уровня, для эффективного тестирования. Но и не стоит совсем упрощать окружение и делать его из пустых боксов.

Если ваш блокаут будет состоять из пустых комнат вы не сможете в полной мере понять как поведет себя игрок. Поэтому по возможности добавьте мелких и средних объектов в помещения, которые будут направлять или останавливать игрока.

Проверяем и исправляем

Просидев за редактором какое-то время вы получите на выходе блокаут вашего уровня. Но есть проблема, вы этот уровень знаете с пеленок.

Мы расставили на уровне направляющие, сделали заметные и незаметные двери, и полностью уверены в том, как поведет себя игрок. Но на деле все оказывается иначе и игрок ведет себя не так как вы хотели. Работа в пустую… Игрок теряется, а уровень не интересный. Как этого избежать?

Тестировать. Тестировать. И еще раз тестировать. Это залог того, что уровень будет понятен не только вам, но и игроку.

И тут мы подходим к интересному моменту. Если вы маленькая команда без бюджета, все ваши сотрудники превращаются в тестировщиков.

Важно чтобы во время работы над блокаутом, большая часть команды его не видела, тогда вы получите относительно честные результаты тестирования.

Но как же проводить тестирование?

Проводится оно в несколько этапов. Тестирование – Исправление – Тестирование (повторяйте до нужного результата)

“Тестирование” я провожу так:

• Даю коллегам пройти уровень – Можно дать ему определенное задание, которое например было бы у реального игрока.

• Молча наблюдаю за тем, как играет коллега и подмечаю как он себя ведет

  • Желательно записать на видео само прохождение.

  • На вопросы лучше не отвечать, у реального игрока за плечом разработчика не будет

• После прохождения заваливаю коллегу вопросами

  • Почему ты пошел сюда, а не туда?

  • Понятно ли было куда идти?

  • Скучный или интересный был уровень?

  • Ну и другие вопросы о том, как он себя вел, с учетом того, как вы представляли поведение игрока

Чем на большем количестве людей вы проверите уровень, тем лучше. Так вы сможете исключить вариант того, только один человек “Пошел не туда”, а это массовая проблема.

Но не перестарайтесь, нужно чтобы часть людей готовых тестировать остались на “новую итерацию”. Те кто уже играл знают уровень и уже не так объективно подойдут к тестированию.

По итогу тестирования вы поймете, как на уровне поведет себя игрок, который впервые на него попадет.

Я исправлюсь, честно

В моем случае вышло так, что 100% людей повернули во второстепенный коридор и просто пропустили основную арену и заблудились на уровне.

Я отправился в редактор это исправлять. Сделал уровень более линейным. Второстепенный коридор напрочь перекрыл односторонней дверью, чтобы игроки туда не шли. Периодически пересматривал видео ребят и смотрел за тем, как они передвигаются и куда смотрят, чтобы переставить объекты и точки интереса.

Исправив недочеты я снова отправился к остаткам команды с новой версией уровня.

В этот раз результаты были гораздо лучше. Из-за закрытой двери все игроки отправлялись по нужному пути, а грамотно расставленные точки интереса не позволяли им свернуть в другую сторону. По итогу почти все кто проходил новую версию уровня двигались именно так, как я и задумывал.

К тому моменту уровень всех устроил. Поэтому он отправился в 3D отдел, чтобы превратиться из серой коробки, в настоящий яркий уровень.

И что по итогу?

Вот я вам и рассказал историю о том, какой путь проходит один уровень в руках геймдизайнера проекта Bleeding. Я постарался рассказать вам и о своем личном опыте создания, так и в целом описать процесс, чтобы было понятно сколько этапов требуется для создания базового блокаута.

Выходит так:

• Мы закладываем фундамент нашего левел-дизайна еще на стадии метрик.

• Укрепляем этот фундамент и создаем чертеж на стадии схемы

• На стадии прототипирования мы закладываем основы дома и его внешний вид

• А на стадии тестирования дорабатываем его напильником и исправляем кривую навигацию

Создание уровней, да и в целом игры нелегкий, но очень интересный процесс. Но самое главное, чтобы по итогу от всей этой проделанной работы получили удовольствие игроки.

Довольные игроки, самый лучший показатель хорошей работы разработчиков. Надеюсь наши уровни понравятся игрокам, а вам понравился мой рассказ. Всем удачи и всех благ!

Как нас поддержать

Если вам заходит то, что мы делаем, вы сильно поможете проекту парой простых действий:

• Добавьте игру в вишлист на Steam — это правда влияет на приближение релиза.

• Залетайте в наш Discord — там новости, апдейты и обсуждения по разработке.

Спасибо, что вы с нами!

Еще чуть больше контекста о портале: игрок находя камень приключений, касается его, камень, сам по себе типа как ключ для перехода между мирами, касаешься перемещаешься. И стартовая локация для перемещения, в самом начале игры, это главное меню.

Выглядит вот так:

Это пока драфт, но для понимания думаю будет достаточно, для понимания контекста

После того как мы победили местного босса локации, портал снова открывается, мы туда прыгаем, появляемся в другом мире, с другими врагами населением и тп.

Вообщем это достаточно такой важный элемент, хочется сделать его максимально крутым.

Поведение противников, переработка слоев и меню паузы.

Когда я начал добавлять противников в игру, возникло сразу несколько проблем. Точнее парочка возникла, а остальные я не замечал. Все они связаны со слоями. Игра 2д, но я пытался создать иллюзию того что игрок может быть перед деревом, а может быть и за ним. Так было с каждым элементом ландшафта. Это работало так: есть условное дерево-родитель от которого наследуются все остальные деревья, у родителя есть скрипт, который проверяет, если игрок выше, то выходим на передний план, то есть прибавляем +1 к слою, в ином случае уходим на задний план, то есть -1 к слою.

Так это работало до определенного момента, как раз пока я не начал добавлять противников. Ведь противники тоже должны иметь возможность заходить за дерево или ходить перед ним. Я учел этот момент. Но потом обнаружил, что за деревом может быть игрок, а перед ним противник. А потом я столкнулся с ситуацией когда множество деревьев в одной точке работают некорректно. Таким образом один несчастный скрипт дерева был на абсурдные 120 строк кода.

В один момент я психанул и начал думать как это исправить (На самом деле я напиздел, я просто психанул и ушел пить кофе, идея пришла сама по себе). В общем вместо всех этих проверок элементы ландшафта просто при запуске сцены получают свою координату Y и делают ее слоем. Всё. Вот так просто получается целая куча слоев. Карты не бесконечные, не большие, поэтому в производительности это не упадет. А вот игрок обновляет свой слой постоянно. 120 строк магическим образом превратились в просто 2 строки.

Чуть позже я столкнулся с новой проблемой касаемо слоев, но решил все еще одной строкой. Что в любом случае лучше, чем первое решение, которое к тому же не работало как надо.

Потом я приступил к поведению противников, что бы они преследовали игрока, атаковали, наносили и получали урон. Спустя где-то пол часа, когда были настроены все сцены, написан код, я запустил игру и получил вот такой забавный "душ" из снарядов для слайма.

Потом уже начал все полировать, убирать лишнюю физику и т.д. Добавил меню паузы, а то как это, игра без паузы не игра. В общем результат ниже.

Да, работы еще вагон и маленькая тележка, но процесс мне пока что только в радость, так что со временем все станет выглядеть лучше.

Дальше планирую набросать баланс-табличку, что бы понимать, что именно я хочу что бы игрок ощутил от процесса, и полировать что уже есть. Например, когда противники умирают, у них еще какое-то время остаются тени, хотя сам спрайт уже начал исчезать, таких мелочей еще много можно найти.

Больше процесса можно видеть у меня в ТГ:

https://t.me/CapybardCollege

Мой сайтик:

http://capybard.ru

Зачастую в трейлерах просто показывают, как используются переключатели, кнопки и всякие механизмы, и, возможно, есть какой-то закадровый голос, но в итоге всё это оказывается совершенно бесполезным.

Я не говорю, что просто демонстрация механик и атмосферы - это плохо! Для тизер-трейлера или для одного из трейлеров - вполне себе можно даже обычными пролетами обойтись и капелькой геймплея, но помните:

Всегда при создание трейлера задавайтесь вопросом "Зачем" и "Почему"

Постарайтесь ответить в трейлере на эти вопросы:

Зачем Главный Герой взламывает этот замок или зачем он решает эти головоломки. Почему-бы, ему просто не уйти, и какова его цель!

Ответив на эти вопросы в трейлере, Вы уже будете на голову выше большинства своих конкурентов, так-как иногда даже крупные студии пренебрегают этим правилом.

Это лишь один из способов сделать Ваш трейлер лучше. Есть множество вариантов для создания качественного и цепляющего трейлера, для которых данный способ может не подходить.

Пользуйтесь этим правилом с умом!

А пока, можете добавлять мою игру (Sh)Мару в Вишлист: Страничка в Steam

• Настройка рига: Ассет требует специфического подхода к скелету персонажей. Нам пришлось перепроектировать существующий скелет, что потребовало значительных временных затрат. Дополнительно, мы столкнулись с проблемами при изменении иерархии внутри персонажа. Зачастую все приходилось настраивать поновой. Эту проблему нам ещё предстоит решить в будущем.

• Ограниченная документация: Документация ассета оказалась недостаточно детальной, что вызвало необходимость в проведении множества экспериментов и поиске решений. К счастью, разработчик Samson проявил оперативность в поддержке, предоставляя необходимые разъяснения и советы через Discord, что значительно ускорило процесс.

• Интеграция с ECS: Связь между ассетом и нашим фреймворком потребовала разработки дополнительных систем для связи IK с миром ECS. Это оказалось непростой задачей из-за концептуальных различий между объектно-ориентированным подходом и нашей архитектурой, ориентированной на данные.

Результаты

Мы достигли значительного прогресса в улучшении реалистичности и отзывчивости анимаций. В частности, нам удалось:

• Улучшили анимации прицеливания и выхода из прицела.

• Сделали отдачу оружия более естественной и добавили тряску камеры.

• Обеспечили более правдоподобное покачивание оружия при движении мышью.

• Реализовали реалистичное раскачивание оружия во время движения.

• Усовершенствовали анимации смены оружия.

Результат действительно впечатляет!🙂 Убедитесь сами:

Следующие шаги

Мы только в начале пути. Впереди нас ждут новые вызовы, но мы уверены, что сможем справиться с ними. В ближайших выпусках блога мы планируем рассказать о наших успехах на художественном поприще.

Спасибо за вашу поддержку и интерес к нашему проекту. Мы продолжим делиться новостями и достижениями, раскрывая наше видение следующих этапов разработки.

Ваше мнение важно!

Мы стремимся сделать наш блог полезным и интересным для вас. Поэтому нам важно ваше мнение: какие темы вам наиболее интересны? Хотите больше технических деталей о сложных фичах, таких как инверсная кинематика и архитектура ECS? Или предпочитаете лёгкие и забавные моменты из процесса разработки?

Оставляйте комментарии и делитесь своими мыслями — каждый отклик помогает нам стать лучше!

Как нас поддержать

Если вам заходит то, что мы делаем, вы сильно поможете проекту парой простых действий:

• Добавьте игру в вишлист на Steam — это правда влияет на приближение релиза.

• Залетайте в наш Discord — там новости, апдейты и обсуждения по разработке.

Спасибо, что вы с нами!