Roadmap Unreal Engine / C++ developer
Прежде чем начать перечислять технологии, давайте для начала определим, кто решил подойти к этому моменту:
- Программист из геймдева, Godot, Unity и т.д.
- Программист, меняющий стэк из другой области, не геймдев.
- Начинающий программист без какого либо опыта, в том числе с языками программирования.
Во всех трех случаях подход будет разный, однако, основные моменты будут такими же.
Важно понимать, что внутри позиции Unreal Engine / C++ Developer скрыто множество под-областей.
И это далеко не полный список. Можно включить физику, звуки, и даже рендер.
В разных командах вы можете встретить разные подходы к делению обязанностей среди программистов.
В моей компании часто приходиться заниматься всеми перечисленными пунктами.
Ниже я сначала опишу, как каждому типу людей стоит подходить к изучению топика, и далее уже укажу конкретные вещи, которые спрашивают на собеседованиях и полезные ресурсы.
Помимо прочего, я крайней рекомендую всем уделять внимание общедоступным проектам, из которых вы можете подчерпнуть best-practice'ы.
Их можно найти или на гитхабе, или на маркетплейсе Epic Games.
Неопытный
Вы не знакомы с языками программирования и не знаете, что представляет собой Unreal Engine.
Вам я исключительно советую прибегнуть к курсам и/или видео на ютубе, где с нуля пишут какой-то микро проект.
В вашем случае желательно подойти в первую очередь со стороны Blueprints, т.е скриптовым визуальным языком программирования. Он даст вам базовое понимание работы Actor'ов, Component'ов, сцены и т.д.
После освоения базы, можно пытаться переносить код на C++, параллельно вникая в устройство этого языка программирования.
Важно отметить, что в контексте скриптовки игровой логики для движка вам потребуется лишь небольшая часть этого языка. Поэтому так же советую смотреть гайды по нему в контексте Unreal Engine, чтобы не обнаружить себя на cppreference.com, вникающим в какой нибудь локальный ужас, который вас вероятнее всего отпугнет.
Лично я начинал с курса на Udemy и небольшого шутера на ютубе.
В процессе создания пет-проекта стоит вносить некоторые правки в предлагаемый код. Придумывать и изменять логику игры, чтобы лучше разобраться в механике работы движка и его сущностей.
Также, важно избегать типичных ошибок новичков: пытаться понять все и сразу. Если вам совсем не очевидно как работают Line Trace'ы или Behaviour Tree, и вы несколько часов копаетесь в исходниках или гайдах, стопаря процесс создания игры, то так не долго и выгореть.
Крайне советую оборачивать слишком непонятные вещи в абстрактные Кидает луч, или Выполняет действия по порядку с условиями, чтобы потом к ним вернуться и уже на базе написанного проекта с ними экспериментировать.
Как только освоите базовые понятия, указанные, например, в курсе на Udemy и напишете свой проект, можете начинать искать работу для собора фидбека, или устроиться в стартап на бесплатную основу, чтобы получать хоть какой-нибудь опыт.
Бывалый, не геймдев.
Для вас главной проблемой станет иерархия типов и структур в движке, и сама механика работы real-time движков.
Вы можете приступать сразу к языку и его основам. После - писать свой проект на базе того же курса на Udemy.
Поскольку для вас главной проблемой будут абстракции, которые предоставляет движок, и архитектура, я так же рекомендую почаще читать исходники движка, хотя бы на самом высоком уровне, и чужие проекты, чтобы схватывать паттерны работы и лучшие практики, которые использовали сами создатели движка и другие программисты.
В остальном все так же как и у начинающего: пишете свой первый проект на C++, и с ним можете идти на собеседования.
Бывалый, геймдев.
Советы тут будут похожи на предыдущий пункт, за тем исключением, что поскольку вы знакомы с общей абстракцией в виде Actor'ов, миров, уровней и компонентов, вам стоит в первую очередь ознакомиться с разницей в функциональностях движка, и тем, как с ними работать.
Советую все так же начать писать свой проект, но уже сильно больше внимания обращать на другие проекты, т.к вы найдете много пересечений с другими движками. Возможно даже вам не понадобится курс. Можете сразу скачать готовый проект и разбираться в нем.
Цели
Ниже приведен список компонентов и ключевых сущностей движка, порядочное изучение которых и составит своеобразную Road map'у.
Тип деления на абстракции я выбрал произвольно, так, как посчитал нужным на основании своего опыта.
Акторы
Самый простой компонент движка, который можно поставить на сцену: AActor и его производные: APawn и ACharacter. Нужно понять их схожести и различия. Как они работают с компонентами и репликацией.
Плюс, уяснить разницу с UObject, помимо того, что его можно поставить на сцену и напрямую уничтожить.
Компоненты
Компоненты являются строительными блоками для всех актеров. Нужно уяснить как они инициализируются, как уничтожаются и реплицируются. Так же у него есть свои наследники, каждый из которых реализует конкретную функциональность: USceneComponent и UPrimitiveComponent. Они являются базовыми классами для большинства компонентов. Их необходимо разобрать.
Важно во время изучения испробовать разных их наследников, вроде USkeletalMeshComponent или UWidgetComponent, чтобы изучить область применения.
Управляющие сущности
APlayerController, APlayerState, AGameMode, AGameState UGameInstance. Все это базовые игровые сущности, которые необходимо понимать. Их время жизни, работа с репликацией, область применения и смысл существования.
События
Следующим по важности следуют FDelegate и FEvent.
Они, по сути, представляют из себя сущность, на которую вы подписываетесь и ждете когда что-то произойдет (Execute или Broadcast). Кроме того есть Multicast Delegate'ы, Dynamic Delegate'ы и т.д с разными переменными параметрами.
Необходимо поэксперементировать с разными их вариациям для фиксации разных событий при входе в Collision Box'ы, нажатие на мышь/клавиатуру и т.д.
Они создаются через DECLARE_EVENTи DECLARE_DELEGATE.
Мир
Советую вам уделить отдельное внимание таким вещам как ULevelи UWorld. Как они вместе составляют игровое поле, как работать с их Blueprint'ом, классом, и что происходит когда вы переходите с уровня на уровень (UGameplayStatics::OpenLevel).
Базовые классы
Вам необходимо усвоить, что из себя представляет основной класс для всех сущностей движка UObject и UObjectBase. Как при помощи него работает сборщик мусора и, немало важно, как этот класс может работать с репликацией, т.е мультиплеером.
Коллизии
Поскольку вам часто понадобится фиксировать коллизии, то нужно поработать с разными их проявляениям.
- На уровне компонентов и Actor'ов: каждый
UPrimitiveComponentможет работать с коллизиями и детектить их, напримерOnComponentHit,OnComponentBeginOverlapиOnComponentEndOverlap. - На уровне кастов: вы можете создавать разные геометрически объекты (Лучи, Сферы и т.д) для фиксации тех или иных сущностей (геометрии).
LineTraceSingleByChannel,OverlapMultiByChannelи т.д
Они используются постоянно и являются частью физического движка.
Контейнеры
TMap, TSet, TArray, TList и т.д. Чем отличаются, чем схожи, в том числе с std::unordered_map, std::map и прочими.
На более глубоком уровне советую почитать про TSparseArray.
Рефлексия
Стоит подумать о жизни и смысле существования.
До этого момента вы вероятнее всего уже сталкивались с UCLASS, USTRUCT, UENUM и т.д.
Часто интервьеру, может быть интересно как вы понимаете рефлексию, т.е инструмент, который позволяет анализировать ваш код и генерировать еще больше инструкция для движка.
Те же свойства, прописываемые в UPROPERTY и UCLASS, вроде BlueprintReadOnly являются теми самыми ключевыми словами, по которым создаются дополнительные инструкции для движка.
Сборщик мусора и smart pointer'ы
Концепция эта не нова, однако часто интервьеру может быть интересно в чем вы видите различия std::weak_ptr и TWeakPtr из движка и как они работают со сборщиком мусора. Как последний ведет учет объектов, которые надо уничтожить, можно ли создать TSharedPtr на UObject и т.д.
Тут придется окунуться в стандарт C++ и часть изучить.
Репликация
Не все проекты включают мультиплеерную часть, но на собеседовании часто спрашивают.
Концепция сервера и клиента, RPC вызовы (Server, Client, Multicast), условия репликации переменных и т.д.
Все это важно осмыслить хотя бы на поверхностном уровне.
У меня уже есть статья, с которой очень советую ознакомиться.
Сессии
Этот топик - часть мультиплеера, но все же стоит отдельно из-за своей специфики: создание сессии. Является скорее приятным дополнением, нежели необходимостью.
Build Tool и модули
Весь движок состоит из модулей, конфигурации которых прописываются в корневых директориях ваших исходников в файлах .build.cs.
Важно знать, как их прописывать, чем приватный модуль отличается от публичного и так далее.
Этот топик более узкий и спрашивают его не часто.
Софт и хард ссылки. TSoftObjectPtr, TStrongObjectPtr
Уже более специфическая вещь, связанная с загрузкой и сохранением объектов в памяти.
Нередко интервьюеру интересно, как вы понимаете возможности движка для менеджмента ресурсов, особенно если память устройства сильно ограничена.
Заключение
Список выше далеко не самый полный и весьма абстрактный. Каждый из пунктов можно поделить на несколько частей и добавить деталей, однако тогда и статья вылилась бы в учебник.
С большинством пунктов вы столкнетесь пока будете писать pet-проект, какие-то из них будете нагонять после, т.к не в каждом проекте задеваются все перечисленные концепции.
Только то, что указано, является необходимой базой (кроме Сессий), в которой важно глубоко разобраться.