Автор курса Game Code Александр Балакшин, работавший над Rainbow Six Siege, Atomic Heart, Halo: Infinite, рассказал на стриме на примере Unreal Engine, чем визуальный кодинг отличается от классического, в чём может заменить его, а в чём — нет. Собрали главное.

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

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

— Второй уровень: инструменты, к которым относятся различные редакторы, конвертация и хранение ассетов.

— Третий уровень: геймплейный код. Это регистрация попаданий, перемещение, репликация, искусственный интеллект и другие реакции на действия игрока. Обычно он базируется на фреймворке, созданном разработчиками движка — в Unreal Engine это C++.

— Самый высокий, четвёртый уровень: скрипты. Их основная задача — максимально быстрое получение результата. Систему визуального программирования Blueprints можно назвать элементом скриптинга в Unreal Engine.

Когда подойдёт Blueprints, а когда нужно классическое программирование
Blueprints подойдёт для:

— создания быстрых прототипов и небольших проектов

— работы с визуалом

— проработки заскриптованных сцен

— работы в малой командеКлассический кодинг предпочтительнее, если вам важны:

— Производительность — в Blueprints производительность хуже из-за отсутствия машинной оптимизации компилятора

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

— Объединение изменений — Blueprints не код, а данные, которые нельзя легко объединить без дополнительных инструментов.

— Масштабирование

— Поддержка сторонних API и работа не с UObject

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

Для более глубокого изучения темы Александр рекомендует посмотреть эти материалы:

Курс EpicGames о том, как сбалансировать работу с Blueprints и C++

Та же тема, но кратко и в виде текста

И в формате краткой видео-лекции

Источник

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

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

Источник

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

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

Да и с точки зрения GOMS-анализа нажатие на клавишу клавиатуры оказывается быстрее, чем перемещение мышки. Это ни в коем случае не отменяет удобство визуального редактора, но, по моему опыту, с автодополнениями и прочими синтаксическими функциями современных IDE писать код удобнее и быстрее, чем создавать граф в блюпринтах. Хотя полезные сочетания клавиш и шорткаты в Unreal Engine тоже облегчают жизнь.

Источник

Я считаю, что если программисту нужно работать с Tick-функциями, или он использует какую-то сложную математику и пространственные запросы (например, LineTrace), всё это лучше вынести в С++. Отчасти из-за всех перечисленных особенностей Epic Games раздумывают над созданием отдельного скриптового языка для реализации игровой логики в Unreal Engine.

Тем не менее, блюпринты — достаточно мощный инструмент, который в Unreal Engine 4 используется не только для построения игровой логики, но и для работы с анимацией и системой эффектов Niagara. Поэтому каждая студия должна сама найти подходящий баланс между Blueprints и С++. Например, технические дизайнеры Riot Games использовали блюпринты в Valorant только для создания способностей игроков.

Valorant

Сами Epic Games рекомендуют использовать блюпринты, когда в проекте очень много ссылок на контент, а его логика работает в первую очередь на визуальную составляющую. Также они пригодятся в создании прототипов, прямолинейной или редко используемой логики, которая не является частью основной архитектуры. Всё, что не получит преимуществ в С++ с точки зрения производительности, масштабируемости и стабильности, тоже может быть создано в Blueprints.

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

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

Unreal Insights — профилировщик для Unreal Engine (Источник)

В оптимизации ААA-проектов важно, чтобы код «дружил» с кэшем. То есть, код должен минимизировать загрузку из оперативной памяти, а ещё — эффективно использовать то, что уже находится в кэше процессора. При этом порой приходится думать не только о кэше данных, но и о кэше инструкций.

Например, разработчики Sea of Thieves смогли избавиться от проблем с кэшем инструкций с помощью агрегации вызовов tick-функции по типу обновляемых компонентов. Это ещё и помогло им поднять FPS с пяти кадров в секунду до приемлемых значений. Крайне интересный доклад на эту тему можно посмотреть здесь.

Источник

Прошлое поколение консолей плохо справлялось с branch prediction, поэтому программистов заставляли минимизировать количество ветвлений в коде — тех самых branch, — чтобы избежать потенциальных проблем с кэшем. Сейчас чем-то подобным приходиться заниматься только при написании шейдеров — из-за особенностей архитектуры современных GPU, — или при создании совсем уж высокооптимизированных систем самого движка .

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

Источник

Если приходится работать с объектно-ориентированными фреймворками, лучше использовать как можно меньше динамических приведений типов. В игровых движках обычно используется своя версия RTTI (runtime type introspection) вместо стандартной из С++, — но это всё равно очень ресурсозатратный процесс. Под него трудно рассчитать время, а потом ещё приходится разбираться с парой-тройкой кэш-промахов.

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

Источник

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

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

Источник

В современных играх используются скелетные анимации. Работая с ними, нужно понимать и контролировать, когда «скелет» должен обновляться (например, если игрок видит врага), а когда это будет просто тратой мощностей (NPC находится в километре от героя, стоит за глухой стеной и вообще ничего не делает).

Обновление всех игровых компонентов можно делить на группы. Иногда каждый отдельный кадр требует запуск своего Update. В других случаях обновление достаточно производить раз в секунду — например, когда враги находятся далеко от игрока. А где-то его вообще можно отключить до активации нужных событий.

Кстати, в Unreal Engine 4 недавно добавили удобный функционал для таких задач — the significance manager. Он, наряду с функцией animation sharing, успешно доказал свою эффективность в Fortnite. На эту тему есть крайне интересное выступление с GDC 2018.

Источник

Для сетевых игр также нужно обращать внимание на объём реплицируемых данных. Когда на сервер отправляются 500 Кб в кадр, это кажется мелочью. Но при игре в 60 FPS трафик составит уже 30 Мб/сек (240 мегабит/сек) — и это если не считать репликации другим клиентам. А ведь дешёвый и быстрый интернет есть далеко не везде.

Процесс оптимизации включает в себя не только код, но и контент — он уже ложится на плечи художников. Им нужно следить за соответствием моделей и текстур бюджетам. Последние, в свою очередь, регламентирует технический арт-директор. А ещё нужно помнить о «сложности» скелетов и форме коллизий.

В коллизиях нужно использовать как можно более простые примитивы — капсулы, сферы и параллелепипеды (box’ы). Произвольные выпуклые многогранники лучше оставить до тех случаев, когда без них никак не обойтись. Если с ними не перебарщивать, то фаза обновления физики и определения пройдёт как по маслу.

Источник

Наконец, нужно помнить и о тех местах в коде, которые лучше не трогать. Для этого нужно опять обратиться к данным профилировщика. Бывает так, что какое-то место в коде работает идеально, но всё равно кажется неоптимизированным. Если тесты не выявляют в нём никаких проблем, то лучше не тратить на изменение кода неделю-другую, а оставить всё как есть. Получится экономия и личного времени, и денег работодателя. А это — самая главная оптимизация.

Если хочется сильнее углубиться в тему, можно посмотреть крайне интересный доклад Николаса Флёри на CppCon 2016 — там он рассказывает, как оптимизирована Tom Clancy’s Rainbow Six Siege. Ещё посоветую выступление Эрла Хаммонда на GDC 2018 года, — из него можно узнать о реализации определения столкновений в Titanfall 2. Это уже для тех, кто любит погорячее: в ролике присутствуют математика, векторизация и деление на 0.