Changeover: Решение быть разработчиком игр [Часть III] ⁠⁠

Предыдущие части

Часть I: https://pikabu.ru/story/changeover_reshenie_byit_razrabotchikom_igr_chast_i_5899735

Часть II: https://pikabu.ru/story/changeover_reshenie_byit_razrabotchikom_igr_chast_ii_5903637

И снова здравствуйте!

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

Диалоговая система.

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

Любой внимательный человек, который читал мой предыдущий пост, может спросить: “А что, собственно, изменилось?”. Отвечаю:

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

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

{эмоция}Какой-то текст|{другая_эмоция}Какой-то текст с новой строки

И, если приводить пример на скриншоте, то будет такой диалог:

{normal}We’ll learn communicating first.

В таблице это выглядит так:

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

С этой новой фичей, в игре стали присутствовать элементы визуальной новеллы.

PlayMaker

Расчудесный PlayMaker смог сохранить нам немало нервных клеток своим функционалом. Система состояний и переходов помогла в построении логики происходящего на экране. Начиная от того, кто сейчас говорит, как реагирует и что при этом делает, заканчивая формированием всего геймплея.

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

Допустим, что игрок решил пойти в одном из направлений, по пути встретил нескольких НПС, они его предостерегают, чтобы он никуда не пошел (сказали несколько реплик), но игрок послал их на все 4 стороны и решил пойти по опасному пути. Там на него нападают и происходит битва.

Через код, чтобы реализовать такую небольшую ветку, нужно было бы сделать множество условий или написать свою реализацию системы состояний, но представьте, что у вас 20 таких веток, некоторые ветки сливаются и нет визуального представления происходящего. Здесь на помощь и приходит PlayMaker. Все действия записаны в стейтах (состояниях) и выстроены в нужной последовательности:

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

Однако, среди множества преимуществ есть и ряд недостатков. Например, PlayMaker не поддерживает обычные скрипты. Максимум, что он умеет делать с твоими кодом - это вызывать функции и задавать переменные. Из-за этого нашему программисту приходилось (тихо матерясь) писать оболочки для собственных скриптов. Хоть этот процесс занял время, но зато он упростил написание логики в разы.

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

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

...позволяя выполнять разные задачи, например, заставить двигаться к цели:

Но для нас одним из основных недостатков PlayMaker’а стала система сохранения текущего состояния логики. Её просто нет!

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

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

Рисование тайлами

С выходом Unity 2018.1, любой может рисовать тайлами без проблем, но...

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

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

Динамическое освещение

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

Не.. не эту, а эту:

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

Боевая система

Если коротко:

•  Решили отказаться о казуальщины

•  Не делать управление на клавиатуре

•  Не делать заскриптованные удары

•  Оружие у персонажа следует за курсором

•  Игрок сам выбирает стиль игры (как ему атаковать и защищаться)

•  В данный момент ведется обсуждение улучшения боевой системы

А* или алгоритм нахождения пути

Для того, чтобы НПС могли свободно передвигаться по карте, в игру был добавлен модифицированный (под 2d) алгоритм А*. Если коротко, создается прямоугольная сетка на основе уровня, в нее заносится и хранится информация о каждой ячейке, а именно:

• Пустая ячейка - проходимый блок (пример, воздух);

• Красная ячейка - непроходимый блок (пол, стена);

• Зеленая ячейка - односторонняя платформа (лестницы, столы и стулья).

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

Персонаж сам определяет препятствия на своем пути при помощи RayCast’а (например, двери) и, если это возможно, обходит их. Зеленая линия перед персонажем - его путь.

Вместо заключения

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

Я оттягивал “рекламу” игры до самого конца своей истории, но ее релиз - хороший повод оставить ссылочку:

https://store.steampowered.com/app/788480/

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

С вами был @Enerlo, до скорой встречи и удачи!