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

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

В прошлом году я работал над своим первым проектом Unreal, GasLight. Сначала меня отталкивало отсутствие надлежащей поддержки языка сценариев. (Единственным поддерживаемым языком был C++). И хотя поначалу мне приходилось преодолевать препятствия, в конце концов я полюбил систему Unreal Blueprint.

Для тех, кто не знает, Blueprint — это визуальный скриптовый язык, который Epic внедрил в UE4, чтобы заменить и выполнять функции языка Kismet из UE3. В Blueprint вы, по сути, можете выполнять любые действия, которые вы ожидаете найти в типичном языке сценариев, хотя формат, как и ожидалось, совершенно другой, по крайней мере, с точки зрения его представления. У Epic есть обширная серия руководств о том, как начать использовать визуальный язык (см. ссылку выше), и, как правило, довольно хорошо собрана документация для начинающих.

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

Введение: контроллеры игроков

Чтобы открыть обсуждение, я специально приведу примеры из двух разных контроллеров игроков, которые я создал: один из 2D-проекта Unity, а другой — из 3D-проекта Unreal. В качестве примера на C# я возьму скрипт из своей 2D-игры на Unity: девушка, я вижу тебя насквозь.

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

Организация достаточно прямолинейна. Действие содержится во вложенной проверке if. Переменная-переключатель «iIsAlpha» — это то, что проверяется, чтобы определить, в каком состоянии находится игрок в данный момент. После того, как это определено, устанавливаются коллайдеры и соответственно воспроизводятся звуки и анимация. Я обнаружил, что вы можете организовать чертежи в очень похожем формате.

В этом примере, взятом из GasLight, показана простая функция движения. Слева находятся события Blueprint, которые отслеживают входные данные от игрока. Если ввод был нажат, он будет продолжаться по строке слева направо. События выделены красным цветом. Следующий блок — это то, что известно как «Ветвь». Ветки, по сути, являются проверками if с прикрепленным логическим условием. После того, как функция проверила погоду или отсутствие движения было отключено, функция движения вызывается из родительского класса контроллера пешки. (Помните, Unreal основан на наследовании!) Также примечательно, что функции обозначены синими блоками.

Тогда возникает правильный вопрос; «Где, черт возьми, эти средние цепи вступают в игру?» Давайте посмотрим поближе.

Хотя это не всегда так, я называю эти зеленые блоки «геттерами», поскольку они часто выполняют эту функцию. Часто они используются для получения переменных или компонентов векторов. В этом примере в крайнем левом блоке управление вращением получено от целевого «я», ссылки на игрока. Следующий блок разбивает вращение на составляющие Pitch, Yaw и Roll. Затем создается новый поворот с изолированным компонентом Yaw. (В контексте этой игры сохраняется только рысканье.) Наконец, векторы вперед и вправо получаются из вращения, и эти векторы передаются в функции движения.

Организация вашего проекта: экономия пространства

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

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

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

Выше приведен пример из «Схемы уровней» в GasLight, демонстрирующий улучшенную организацию. (Чертежи уровней — это сценарии, прикрепленные к данному уровню или сцене). Функциональность, продемонстрированная выше, вращается вокруг механики движения, основанной на цвете, и я подумал, что наличие большей части сценария, содержащегося в более крупной форме, упростит соединение блоков, а также упростит их работу. глаза. При движении слева направо сегменты «VO» и «Door» помещаются в крайнее левое положение, поскольку они не ссылаются на другие части сценария.

В центре находится логический цикл под названием «Проверка желтой стены», который проверяет коллизии на соответствие триггерам событий, а также функция инициализации «Включены бонусы». Поскольку «Желтая стена» — самый большой блок, казалось, что имеет смысл организовать его вертикально, чтобы соответствовать другим меньшим горизонтальным блокам. (Опять же, сохраняя общую квадратную форму). Он также напрямую связан с «Желтым обновлением», поэтому его необходимо централизовать. Между «Проверка желтой стены» и «Включены бонусы» находится ссылка на игрока, похожая на осьминога. В какой-то степени понятно, почему это также централизовано, поскольку ссылка на игрока используется во всем скрипте для активации триггеров. «Пурпурный объем» работает аналогично «Проверке желтой стены», взяв ссылку на игрока и проверив триггеры.

Наконец, самые правые «Kill Volume» и «End of Level» работают аналогично «VO» и «Door», поскольку они не ссылаются на многие другие сегменты. Причина их правильного размещения заключается в том, чтобы сохранить удобочитаемую форму, а также обеспечить удобочитаемый и простой путь для ссылки на игрока для ввода в проверки триггеров Kill Volume.

Выводы

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