Не смейте ограничивать игроков! Или как я сделал собственный редактор уровней

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

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

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

Личный вызов.
Создание подобного ПО требует от разработчика достаточного уровня владения инструментом — кодом. Так как я не позиционирую себя в статусе программиста, хоть и невольно исполняю эту роль, реализация данной программы является моим собственным около профессиональным достижением.
Также, к большинству разделов статьи я оставил комментарии технического характера с поверхностным описанием реализации того или иного элемента. Надеюсь, это кому то пригодиться.

Мои успехи. На текущий момент(v:0.1), я реализовал минимальный набор инструментов необходимый для комфортного создания игрового уровня.

Инструмент: «null»

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

Инструмент: «move».

Стандартный инструмент, который осуществляет перемещения объекта по трём осям.

Инструмент: «rotation ».

Стандартный инструмент, который осуществляет вращение объекта по трём осям. На данной gif-ке у объекта немного смещён центр вращения, а само вращение осуществляется по глобальным координатам.

Инструмент: «size».

Стандартный инструмент, который осуществляет изменения размера объекта по трём осям и по главной(по всем одновременно).

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

Работа с объектами. Добавление, удаление.

Стандартный момент — для добавления объекта на сцену, выберите необходимый объект в списке префабов и с зажатым ЛКМ переместите мышь в область сцены.

Технический момент.
Создание и удаления объекта не является чем то сложным. Однако, для спавна нужного объекта необходима эксклюзивная ссылка. Я использовал следующий принцип присвоения ссылки/id: [*номер каталога*] + [номер объекта в этом каталоге]

Таким образом, легче всего реализовать поиск объекта для спавна. Также, чтобы каждый раз не выполнять перебор всех объектов на наличие нужной ссылки, при старте программы, все объекты(ссылка на них) помещается в двухмерный массив. P.S. Последние не является чем то гениальным, но решил всё же уточнить.

Ручное редактирование главного и второстепенного террейна.

С помощью манипуляторов можно вручную редактировать сетку как главного так и второстепенного ландшафта.

Технический момент.
В своём проекте, я отказался от использования стандартного компонента terrain предоставленного командой unity.Это было сделано для повышения стабильности, а самое главное, уменьшения вычислений связанных с обработкой меша стандартного ландшафта + это позволило добавить собственный nav mesh. Построение собственного terrain происходит аналогично процессу создания ландшафта в 3D редакторе, с одним исключение — моё решение автоматически даунгрейдит сетку террейна по мере удаления от главного фона.
Примерный способ реализации ландшафта хорошо показан в следующем ролике: хочу знать всё.

Редактирование с помощью кистей.

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

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

Компоненты.

Для взаимодействия со многими объектами, я добавил собственные компоненты. Примерный процесс взаимодействия показан выше.

Технический момент.
Ничего интересного. Простая привязка некоторых переменных к кнопкам, слайдерам и однотипным меню.

Иерархия.Дочерний объект и родитель.

Пользователю более не придется вручную воссоздавать строго-ограниченную последовательность объектов в иерархии. Всё это сделает сам редактор.

А заместо прямого влияния на дочерний объект, я реализовал систему компонентов, которые позволяют взаимодействовать с дочерними элементами посредствам кнопок и слайдеров.
Технический момент.
Для применения наших оптимизационных решений, важно соблюдать строгую иерархию. На этапе разработки демоверсии, соблюдение всех правил построения иерархии уровня отнимало слишком много времени у наших дизайнеров, поэтому, данный аспект подвергся «оптимизации», а оставшийся функционал, был навечно заточен в рамки специальной версии редактора. Также, благодаря данной «оптимизации» было легче организовать сохранение и экспорт файла.

Слои.

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

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

Продолжение следует…

Планируя написание данного материала, я хотел придерживаться строгих размеров статьи... Так вышло, что уже написанная часть, содержащая в себе лишь один из трёх разделов, составила 2/3 от общего, ранее планируемого материала. Осталось ещё много интересных моментов, мне бы не хотелось урезать уже неоднократной упрощённый текст. Поэтому, дабы не превращать данную стью в мини рассказ - я поделю весь имеющийся и предполагаемый материал на части.
Также, мне бы хотелось получить чуть больше фидбека от сообщества прежде чем я перейду к написанию финальной части статьи с рассуждениями о удачных или наоборот неудачных элементах программы.

Благодарю за внимание! Буду рад увидеть парочку комментариев. До скорых встреч.Ссылки на статьи ранее вышедшие в наших сообществах:

Статья приуроченная к выходу редактора:

Статья-инструкция описывающая основные моменты использования редактора. + ссылки на скачивание:

Будем рады видеть в наших сообществах.

#gamedev #indie #indiedev #unity #unity3d #devlog #3d