This article assumes significant experience with C++, but not necessarily within the Unreal Engine ecosystem. Some C# is also required.<\/p>\n\n\n\n
Although most of your knowledge will carry right into Unreal, there\u2019s a lot that I had to find out the hard way. Some things are either not documented at all, or only \u201cdocumented\u201d in the form of unstructured multi-hour Twitch livestreams archived on YouTube.<\/p>\n\n\n\n
That said, this<\/a> series of videos from the official learning site is relatively good, even if the title of this course is somewhat misleading.<\/p>\n\n\n\n As of writing, the latest Unreal Engine version is 5.3.0 preview 1.<\/p>\n\n\n\n Blueprints or C++? The only correct answer is both<\/strong>. BP is not limited to the spaghetti node graph but also provides essential features such as providing references to assets, configuration, or runtime types that don\u2019t exist in C++.<\/p>\n\n\n\n Don\u2019t get frustrated looking for C++ resources and finding that most of the documentation or online resources target BP. Most of those nodes are wrappers of some C++ engine function that you were really looking for, and are often found by searching for It\u2019s very common to build a C++ base class and a BP subclass together that form a single logical unit, especially with actor classes. C++ is great at core architecture, performance, and being source controlled; BP is great at asset references, visuals, ease of programming, fast iteration, and async code. Good luck replicating a Timeline node in C++ without special extensions such as C++20 coroutines. It\u2019s far simpler to define a BlueprintImplementableEvent (more on this later) and call it from C++.<\/p>\n\n\n\n Since BP is essentially unmergeable, you\u2019ll need to consider this for your version control setup. The most common approach is to use exclusive checkouts and file locks.<\/p>\n\n\n\n There is a thing as too much C++. Do not ever hardcode an asset path into C++, these often lead to broken references and packaging errors. This includes a total ban on There\u2019s an official coding standard<\/a>. It\u2019s relatively unusual in that it overuses PascalCase to the extreme. Some studios follow it, some don\u2019t; both approaches have merit. Not even the engine follows it consistently.<\/p>\n\n\n\n Windows is the primary (arguably only) platform fully supported for development. Linux and macOS do not have Epic\u2019s full attention for the Editor, but support is better for them as target platforms for shipped games.<\/p>\n\n\n\n There are two practical choices for an IDE, Visual Studio and JetBrains Rider. As of writing, Rider on Windows requires you to have a license for Visual Studio according to JetBrains (which may be Community if you\u2019re eligible). For the other two platforms, you\u2019re left with only Rider.<\/p>\n\n\n\n Visual Studio is only viable starting from 2022 version 17.7; avoid everything earlier. Rider gained Unreal support in version 2022.1. Visual Studio Code<\/strong> is an entirely different product and is considered broken for Unreal development. CLion, despite being the C++ IDE in the IntelliJ world, does not support Unreal.<\/p>\n\n\n\n The decision between Visual Studio and Rider mostly boils down to price and GUI preference. If your computer has 16 GB of RAM or less, you might also want to consider that VS generally uses less RAM than Rider.<\/p>\n\n\n\n VS Community can\u2019t be beaten on its zero price, and essentially all of Rider\u2019s features are available as a VS add-in in the form of ReSharper for slightly cheaper. If you\u2019re not eligible for Community, having a VS license needs to be factored into Rider\u2019s price on Windows. Although JetBrains is heavily pushing for subscriptions, perpetual licenses are still available in a hybrid scheme<\/a>.<\/p>\n\n\n\n Out of the box, VS does not understand Unreal macros or the build system, and IntelliSense will often break, displaying nonsensical errors. The Error List is essentially useless for Unreal; you\u2019ll always want to look at the Output panel for the full, unabridged errors. Here<\/a>\u2019s how to turn it off and prevent it from coming back.<\/p>\n\n\n\n While VS2022 17.7 is a massive leap in usability compared to earlier versions, it\u2019s still not perfectly stable and IntelliSense will sometimes \u201cgive up\u201d on some files. This usually manifests in the files losing highlighting, or getting red squigglies on everything. To fix this, there are two popular commercially-available extensions that add full Unreal support and various other convenience features:<\/p>\n\n\n\n Visual Assist\u2019s quality has been declining for a while, and its development lags behind ReSharper. Its users also report the purchasing\/renewal process as being annoying. As such, I cannot recommend it, but if you\u2019re already using it, you know what to expect.<\/p>\n\n\n\n UE ships with a VS extension called UnrealVS (found in Engine\/Extras\/UnrealVS), which is highly recommended. Even for non-Unreal projects, it provides a convenient way to set command-line arguments for debugging. The third-party Unreal Wizard<\/a> extension is also strongly recommended for additional\/replacement functionality where UnrealVS is broken.<\/p>\n\n\n\n Since the .sln that Unreal generates doesn\u2019t have real folders in it (only \u201cfilters\u201d), attempting to create new files using built-in methods will cause them to default to somewhere in Intermediate where they won\u2019t build. Use one of the extensions above to create new files, or create them \u201craw\u201d in the filesystem and regenerate your solution to pick them up.<\/p>\n\n\n\n If you\u2019re using VS without Visual Assist or ReSharper, I highly recommend having Unreal Wizard\u2019s toolbar on your main toolbar for the \u201cGenerate Project Files\u201d button. When IntelliSense breaks, pressing that and reloading often resolves the issue. If that doesn\u2019t work, the next step is deleting the Check if you have accidentally installed IncrediBuild from the VS installer. If you don\u2019t have a license and a server farm set up for it, it will only slow your builds down, so get rid of it. It\u2019s also been reported to break shader compilation in this case.<\/p>\n\n\n\n Since Rider contains ReSharper out of the box, it mostly Just Works\u2122. Although it can work with Unreal-generated .slns, it also supports opening the .uproject file directly as a project, meaning that you\u2019ll never need to bother with (re-)generating a solution.<\/p>\n\n\n\n The Error List advice from VS partially applies to Rider, as it also likes to discard useful parts of error messages in its pretty display. Where and how you get to the raw textual output varies between versions and the classic\/new GUI: the button could be \u201cToggle Console View\u201d next to \u201cBuild Output\u201d or \u201cToggle Tree View Mode\u201d to the left of the errors. 2023.2\/new GUI seems to default to showing both, which is a nice compromise.<\/p>\n\n\n\n For Rider, EzArgs<\/a> can replicate some of the functionality of UnrealVS. Contrary to Rider\u2019s claims in the pop-up that you will almost certainly see, the RiderLink plugin is NOT<\/strong> required and only provides some minor features. It may be used, of course, but if you ever have build errors referring to When you create a new Unreal project, you\u2019re given a set of options, notably including a toggle between a BP or C++ project. This has misled many people. There\u2019s only one kind of .uproject: picking either is not a commitment but simply a set of default settings and starter code that can be changed entirely.<\/p>\n\n\n\n BP-only projects do not contain a Source folder by default, but one can be added by creating any C++ class from the editor. Projects with a Source folder can return to being BP only by deleting Source and editing the .uproject file (which is JSON) to no longer refer to the modules that are now gone.<\/p>\n\n\n\n The generated Visual Studio solution and its accompanying vcxprojs exist only for IDE compatibility and are not used in the build process aside from invoking Unreal\u2019s custom build system. As such, it\u2019s pointless to try and change compiler\/linker\/nmake settings in them. Unreal\u2019s own build tool is the creatively-named UnrealBuildTool (UBT), which makes heavy use of the UnrealHeaderTool (UHT) for code generation.<\/p>\n\n\n\n Your actual build files are the Target.cs and Build.cs files you get when you create any starter C++ project template or add a C++ class to a BP-only project. Here<\/a>\u2019s the official documentation on them.<\/p>\n\n\n\n Target.cs files govern building your entire project. Targets are things such as editor, standalone, dedicated server. These get mixed with the familiar \u201cdebug\u201d and \u201crelease\u201d configurations (but more nuanced in Unreal) to form your overall list of project configurations. See the documentation here<\/a>.<\/p>\n\n\n\n Build.cs files govern an individual module (.dll or static lib, C++20 modules are not supported or used), not unlike .asmdefs in Unity. An All of these .cs files in a project get compiled together, therefore you can, e.g., define an intermediate base class or extension methods to apply common build settings. Approaches to manage this include adding extra functionality to Target.cs files or defining an empty C++ module for nothing else but its C# functionality.<\/p>\n\n\n\n Modules may be part of your project directly or belong to plugins. In addition to modules, plugins may also contain content (assets, blueprints) and have extra control for being toggled and their loading order in the corresponding .uplugin file. Content-only plugins are also possible and all plugins may be installed directly into the engine and shared between projects.<\/p>\n\n\n\n BP classes are considered content, but C++ classes are not. As a result, the Unreal editor\u2019s \u201cC++ Classes\u201d folder in the Content Browser is mostly useless and should be ignored.<\/p>\n\n\n\n The Public\/Private folder structure commonly seen is a convention directly supported by the build system and the editor, but it\u2019s not strictly required. Include paths default to a module\u2019s Public folder when it\u2019s added as a dependency. Otherwise it\u2019s a longer path relative to the Build.cs file.<\/p>\n\n\n\n Launching your project via the .uproject file runs the To update C++ code while the editor is running, Unreal Engine comes with not one, but two methods for live patching, and both are broken in different ways. ?<\/p>\n\n\n\n It\u2019s recommended to have Live Coding ON and reinstancing OFF as safe settings, which will prevent accidental Hot Reloads even if you do not use Live Coding.<\/strong><\/p>\n\n\n\n Note that restarting the editor is not enough to get back to a clean state if you used either of these. You\u2019ll need to build (not rebuild, it\u2019s a waste of CPU time) while Unreal is closed<\/strong>.<\/p>\n\n\n\n The only 100% reliable and stable method of building C++ is treating Unreal like you would any other C++ program and compiling while it\u2019s NOT<\/strong> running. Launching it for debugging from your IDE of choice is the best workflow for this, as it avoids both outdated binaries (assuming your IDE is set to build before running), and one method of triggering Hot Reload.<\/p>\n\n\n\n Don\u2019t use Unreal\u2019s built-in C++ class wizard, it tries to compile and load the new class \u201clive\u201d. There\u2019s a setting to disable this, but the editor needs to be closed in order to compile the new class safely anyway. Use an \u201cadd Unreal class\u201d feature from your IDE instead. This section<\/a> has a few suggestions for both paid and free addons with such functionality, in case you scrolled past it. Ultimately, you\u2019re just creating two text files and compiling; anything will do.<\/p>\n\n\n\n Launching in a debugger has the added benefit of immediately catching rare issues that sadly do happen during development. I have regretted NOT<\/strong> running in a debugger on multiple occasions. The Epic crash reporter will grab your call stack, but you\u2019ll lose runtime state. I\u2019m personally using This is Unreal\u2019s own implementation that predates the Visual Studio hot reload feature.<\/p>\n\n\n\n It\u2019s enabled by default on UE4 and suppressed by Live Coding on UE5. Live Coding may be enabled on UE4 to suppress it there as well.<\/p>\n\n\n\n It can corrupt data in memory that may get persisted if you save any .uassets after it happens. This can corrupt these files permanently, requiring a revert or having to recreate them from scratch to recover. Copy-pasting nodes or data from one to another can carry the corruption with it.<\/p>\n\n\n\n Hot Reload can also cause random crashes and misleading results while debugging due to the aforementioned corruption.<\/p>\n\n\n\n It kicks in automatically if you compile from your IDE while Unreal is running unless disabled or suppressed. If you accidentally did this, quit the editor and do not save anything when it asks. Technically, using Hot Reload while ensuring that no .uassets are ever saved once it has happened in a running process is \u201csafe\u201d but also highly error-prone and thus not recommended.<\/p>\n\n\n\n Tools \u2192 Debug \u2192 Modules<\/em> in the Unreal editor is an interface to Hot Reload with the same issues.<\/p>\n\n\n\n Enabled by default in UE5, disabled but available in UE4. Windows only. Also known as Live++<\/a>, named after the underlying tech that Epic licenses.<\/p>\n\n\n\n With reinstancing on (default enabled in UE5, unavailable in UE4) it exhibits corruption similar to Hot Reload, and the same recommendations apply.<\/p>\n\n\n\n With reinstancing turned off, it \u201cmerely\u201d causes crashes and runtime corruption, but your BPs\/uassets remain safe. This is often considered a worthwhile tradeoff for the speedhack-like iteration benefits it provides. At the first sign of things going wrong, quit the editor, build, and start it anew.<\/p>\n\n\n\n UBT supports automatically-managed Unity builds<\/a>, which is enabled by default. This dramatically speeds up clean rebuilds, and UBT\u2019s adaptive unity system tries to strike a balance between this and not slowing down incremental builds.<\/p>\n\n\n\n However, unity can hide #include problems and even break otherwise-correct code that, e.g., uses unnamed namespaces. This can surface as code that\u2019s assumed to be correct \u201crandomly\u201d breaking due to UBT rearranging what .cpp files belong to what unity translation unit.<\/p>\n\n\n\n Debugging these issues should start by turning unity off: add There\u2019s a similar Unreal has its parallel, garbage-collected world that\u2019s heavily inspired by the .NET type system. These types are required for anything the engine needs to reflect, such as usage in Blueprints, automatic serialization, DYNAMIC delegates (see later), etc.<\/p>\n\n\n\n Their macros (also It is automatically enforced to #include the This type system is limited in what it can do, e.g., it\u2019s enforced that UFUNCTIONs can only pass UObjects by pointer or reference-to-pointer, and struct pointers are disallowed. Templates are essentially whitelisted to some built-in containers such as TArray, TMap, etc.<\/p>\n\n\n\n UFUNCTIONs must have a unique parameter list, \u201coverloads\u201d need to have a different name.<\/p>\n\n\n\n The Epic naming convention (USomething, ASomething, FSomething, \u2026) is enforced for classes participating in this type system.<\/p>\n\n\n\n Sadly, these types are incompatible with namespaces. The common workaround is to use namespaces for your \u201craw\u201d types that can be in one and a short (3-6 characters) prefix based on your project\u2019s or company\u2019s name otherwise, to avoid name collisions with the engine and third-party plugins.<\/p>\n\n\n\n UObjects are UE\u2019s .NET The most important subclass of UObject is AActor, it even has its own class prefix. AActors have a complex lifecycle<\/a> that goes beyond mere garbage collection and reachability analysis, and even come with their own creation function, The garbage collector only \u201csees\u201d members marked with Currently, objects can be explicitly marked as \u201cpending kill\u201d, automatically setting UPROPERTY pointers pointing to them to nullptr when they\u2019re garbage collected. This also applies to destroyed actors, but there\u2019s a newer GC operation mode where this is no longer the case. The new mode fixes some issues such as formerly-different TMap keys now all being nullptr. Currently, this is opt-in with the inversely-named gc.PendingKillEnabled 0 setting, with Lyra notably opting in. Epic employees on social media hinted that this would eventually become the default GC behavior. It\u2019s worth considering this if you\u2019re starting a new project, as it has fewer surprises in store and will save you porting work if\/when the engine switches.<\/sub><\/p>\n\n\n\n See Lyra<\/a> itself.<\/p>\n\n\n\n There are smart pointers that let you reference UObjects from a \u201cregular\u201d C++ object that cannot have Classes with only Object and non-object pointers may not be mixed in either direction. Unreal is compiled without exceptions or RTTI so dynamic_cast is not available. It\u2019s #defined as a horrendous macro hack that\u2019s better avoided entirely. Unreal will default construct (for the sake of discussion, this includes constructors taking For this reason, USTRUCTs and UCLASSes must come with a default constructor. You can use other constructors with USTRUCTs, but this is not the case with UCLASSes where you have virtually no control over what constructor gets called.<\/p>\n\n\n\n The replacement for copy constructors is the Subclasses, UPROPERTYs, etc., are serialized as deltas from CDOs. This is how the \u201crevert arrow\u201d works in the editor\u2019s Details panel. This serialization process is brittle and requires you to get some things right, detailed below.<\/p>\n\n\n\n Blueprint classes also have CDOs but these are only created when the BP is loaded.<\/p>\n\n\n\n Classes might have default subobjects, that is, additional objects that get created together with them when instantiated. The most common practical usage of this is an actor constructor creating its components.<\/p>\n\n\n\n For these, use Never use Edit<\/strong> specifiers (EditAnywhere, etc.) for these properties. That leads to incorrect serialization and BP corruption. The component\u2019s properties will still be editable; it\u2019s the pointer itself that\u2019s affected here.<\/p>\n\n\n\n You\u2019ll often see the TEXT() macro used for CreateDefaultSubobject in questionable learning resources and tutorials. This is a pure waste of CPU if your FName is ASCII (as it should be) and should not be used. Not even Epic employees are fully aware of how this works. TEXT() is for FString literals.<\/p>\n\n\n\n Constructors use At runtime, components are made by NewObject+RegisterComponent+AddInstanceComponent. SetupAttachment may be used only before calling RegisterComponent; after that, components are attached with the \u201cusual\u201d functions that are also available in BP. Engine code randomly forgets to call AddInstanceComponent, which leads to, e.g., your component existing but not being visible in the inspector.<\/p>\n\n\n\n A BP Construction Script\u2019s C++ equivalent is the OnConstruction method, not the constructor. Components are made with NewObject in this case, and to match BP behavior, you\u2019ll need to set this flag manually: There\u2019s another \u201cconstruction script\u201d concept in the engine, called a simple construction script. This is what contains BP-added components in actor blueprints.<\/p>\n\n\n\n UClass (not to be confused with The two most common ways of obtaining these objects are This wrapper is often used instead of UClass* to limit the potential values that may be set or used. It implicitly converts from\/to UClass*.<\/p>\n\n\n\n In the editor, UPROPERTYs of this type will limit what options are offered. At runtime, if a TSubclassOf contains a \u201cwrong\u201d class, it will be returned as nullptr:<\/p>\n\n\n\n .NET\u2019s delegates and events (member function pointers + their Dynamic delegates work based on the reflection system and can only call UFUNCTIONs. This limitation is required for them to work in BP. These are declared with the various Dynamic multicast delegates can be UPROPERTY(BlueprintAssignable) and unicast ones can be taken and returned from UFUNCTIONs, among other things.<\/p>\n\n\n\n Regular delegates come with additional features over something like std::function+std::bind, such as being able to weakly reference a UObject and auto-unbind if it gets garbage collected. There are These macros have issues with types having commas in them, such as TMaps. The fix is trivial in the non-dynamic case (don\u2019t use the macros), but dynamics require wrapper USTRUCTs to avoid the comma.<\/p>\n\n\n\n Events are worth mentioning ( Do not bind to delegates in UCLASS\/USTRUCT constructors. That will include the CDO that probably shouldn\u2019t respond to broadcasts.<\/p>\n\n\n\n UPROPERTY delegates get serialized, which is an even bigger problem as it leads to corruption and weird behavior. Use an appropriate overload, such as BeginPlay or PostInitProperties, to bind early at runtime instead.<\/p>\n\n\n\n BP can access the reflection information built by UHT and \u201csees\u201d types and members marked with the various UMACROs. There\u2019s often an extra specifier required, such as UPROPERTY(BlueprintReadWrite) or UFUNCTION(BlueprintCallable), to expose something to BP.<\/p>\n\n\n\n Conversely, C++ is compiled before BP is even loaded and cannot access anything without brittle, slow, and string-based runtime reflection hacks of desperation. You might have guessed that this approach is best avoided.<\/p>\n\n\n\n The main way for the two languages to talk to each other is for C++ to offer values or hooks that BP uses or implements.<\/p>\n\n\n\n There are multiple competing naming conventions indicating that something is intended for BP. The most commonly used is Kismet was the original visual scripting language of Unreal Engine 3. It only worked for levels, and its direct UE4 equivalent is a level blueprint (ALevelScriptActor). It still exists in UE5 but has issues when World Partition is involved.<\/sub><\/p>\n\n\n\n UPROPERTY is the main method of sending runtime data to and from blueprints. A helpful trick is having UPROPERTYs as Accessor UFUNCTIONs can also be provided (along with full encapsulation), but use BlueprintGetter and BlueprintSetter for this to keep your designers happy and not leak \u201cC++-isms\u201d into BP.<\/p>\n\n\n\n BP has its own take on classes, enums, structs, etc.<\/p>\n\n\n\n Classes are great, use them as much as you want, but BP enums and BP structs have bugs and are considered essentially unportable to C++. Define a C++ UENUM or USTRUCT instead from the get-go.<\/p>\n\n\n\n One of the most important usages of BP is to provide assets and configuration values to UPROPERTYs. This is most commonly done through literal blueprints (e.g., actor subclasses), but there are other similar systems to achieve this, such as UDeveloperSettings.<\/p>\n\n\n\n Raw pointers (including TObjectPtr, which is mostly useless) are force loaded before you have a chance to read them, while soft pointers (TSoftObjectPtr) are loaded on demand by your code. Soft pointers store a path to the asset and act as weak pointers after they\u2019ve been loaded.<\/p>\n\n\n\n They\u2019re great for reducing editor startup time and ingame loading screen times: you can issue a load well in advance and only do a last-resort synchronous block when your player was unexpectedly quick. For instance, you could have an invisible trigger leading up to a boss room, that started loading the textures of the boss while the player is traversing the last corridor.<\/p>\n\n\n\n Note that UPROPERTYs are set AFTER<\/strong> your C++ constructor has returned. Therefore, you cannot read their values just yet. Various callbacks are invoked after properties have been written, such as OnConstruction, PostInitProperties or PostLoad. You can use these to react to the new values. The editor has additional callbacks for \u201clive\u201d editing of properties in the Details panel once an object has been constructed and loaded, such as PostEditChangeProperty or PostEditChangeChainProperty.<\/p>\n\n\n\n It can be a little confusing what UBlueprint even is, since blueprints can have a parent class that you decide, and that class doesn\u2019t inherit from UBlueprint at all.<\/p>\n\n\n\n In the case of Data assets (UDataAsset, UDataTable, etc.) are saved directly.<\/p>\n\n\n\n UFUNCTION(BlueprintImplementableEvent) functions are only declared in .h files and not implemented in C++ but may be called from there. They will become an overrideable function (or \u201cevent\u201d if not returning anything, i.e., a coroutine) in BP.<\/p>\n\n\n\n UFUNCTION(BlueprintNativeEvent) functions may have a C++ implementation, which is nearly always virtual. For Always call Using a BIE instead of a BNE can be beneficial if you want to ensure that BP cannot possibly forget to call the parent implementation. Have a BlueprintCallable function (Example) do its mandatory C++ thing, then call a BlueprintImplementableEvent version of itself (K2_Example) to provide the \u201coverride\u201d opportunity for BP. This is how AActor::BeginPlay() itself is written, for instance.<\/p>\n\n\n\n UPROPERTY(BlueprintAssignable) delegates are also implementable in BP, despite being properties. The BP event will be bound to the delegate automatically.<\/p>\n\n\n\n Going in the opposite direction, UFUNCTION(BlueprintCallable) and UFUNCTION(BlueprintPure) let C++ functions be called from BP. Callable functions have an \u201cexec\u201d (white) pin in BP and run only if that line transfers control, while Pure functions don\u2019t have one. This invokes the idea of purity from languages such as Haskell, but in practice, it only<\/strong> means that pure functions are called every time data is pulled out of them. BlueprintPure is frequently misused for functions that are technically impure.<\/p>\n\n\n\n The C++->BP and BP->C++ specifiers may be combined, e.g., Unreal has a bizarre implementation of interfaces. In concept, they\u2019re similar to C# interfaces (UObjects may only have one UObject parent class but may inherit any number of IInterfaces, Purely C++ interfaces ( If BP is involved though, it becomes entirely different: This will correctly call C++ or BP regardless of where the interface was implemented. Use TScriptInterface to hold objects that might implement an interface this way since they are not IMyInterface* in this case.<\/p>\n\n\n\n Epic decided to be friendly to designers by forcing all game code to one thread, called the game thread. This is the thread that the garbage collector pauses when collecting, the one that runs most engine Tick()s, etc. and is key to many threading scenarios.<\/p>\n\n\n\n There are other important threads named by the ENamedThreads \u201cenum\u201d, which is a namespace, a common workaround for UENUMs before The most common way to interact with this system is with the Task Graph, which can be used via the AsyncTask() wrapper, or TGraphTask for more explicit control. This is great for small tasks (usually within a frame) but avoid overloading these threads, or you\u2019ll compete with the engine.<\/p>\n\n\n\n There\u2019s a newer frontend to the low-level tasks system called UE::Tasks<\/a>, which is relatively unused by engine systems, mostly due to its relative youth. It has a better API for chaining, dependencies, etc.<\/p>\n\n\n\n Full threads are usually made with the FRunnable interface and launched with, e.g., Barring a few exceptions, UObjects should be considered to live on and be owned by the game thread. The garbage collector expects to be able to scan their UPROPERTYs and delete them without any notice or synchronization. This will only ever happen cooperatively on the game thread, meaning that if your code is running, you own the entire thread and need not worry about local \u201cun-propertied\u201d raw pointers to UObjects. Returning or suspending (return, co_await, co_yield, co_return) a function gives it a chance to run, though.<\/p>\n\n\n\n This setup naturally leads to threading setups where expensive operations are offloaded to other threads, but the results are applied on the game thread in, e.g., an AsyncTask.<\/p>\n\n\n\n It is your responsibility to ensure this will run correctly. Common techniques include arranging that the UObject will be referenced and not GC\u2019d while the off-thread computation is running, or checking if it\u2019s gone before attempting to pass results back (giving a TStrongObjectPtr or a Weak one to the other thread can achieve this), canceling the task and blocking until its completion in the UCLASS\u2019s destructor, etc.<\/p>\n\n\n\n Useful things that don\u2019t really fit any other category.<\/p>\n\n\n\n Unreal comes with a rich set of assertion macros, none having It often surprises people that the \u201cSlow\u201d assertion macros do NOT<\/strong> run in DebugGame configurations, only full Debug.<\/p>\n\n\n\n You can \u201cfix\u201d this if desired by adding this to your Target.cs:<\/p>\n\n\n\n Or per module into a Build.cs:<\/p>\n\n\n\n Unreal\u2019s take on singletons. These inherit from In BP, these receive pure getter nodes, but you might want to provide a BP function library with statics that get the subsystem individually to reduce the spaghetti.<\/p>\n\n\n\n BP subsystems require hacks to even function and are considered infeasible. Assets may be referenced through a UDeveloperSettings subclass.<\/p>\n\n\n\n This plugin<\/a> extends editor functionality for them.<\/p>\n\n\n\n Unreal\u2019s built-in support for \u201cgame\u201d things such as skills, stats, status effects, etc., in a generic system. Used by Epic in games such as the Lyra starter game and Fortnite itself.<\/p>\n\n\n\n It\u2019s officially not released as a feature but still shipped with the engine on a \u201chere, it\u2019s useful, but you get no support\u201d basis. It\u2019s great for single- and multiplayer both, but especially powerful in multiplayer, simply because it has more things to deal with on your behalf.<\/p>\n\n\n\nLanguage choice<\/h1>\n\n\n\n
ExampleName<\/code> or \"Example Name\"<\/code> in the engine source code.<\/p>\n\n\n\nConstructorHelpers<\/code> and similar functionality. Configuration is also better done using the engine\u2019s functionality instead of piles of #defines.<\/p>\n\n\n\nDevelopment environment<\/h1>\n\n\n\n
There\u2019s also a discounted ReSharper+Rider bundle. Some people like using both at the same time, generally preferring Rider for editing code and VS for debugging in this case.<\/p>\n\n\n\nVS2022<\/h2>\n\n\n\n
.vs<\/code> folder in your project.<\/p>\n\n\n\nRider<\/h2>\n\n\n\n
module rules named 'RD'<\/code>, it should be the prime suspect. The fix is to delete every Rider plugin from your project and\/or engine.<\/p>\n\n\n\nProject structure<\/h1>\n\n\n\n
Example<\/code> module would live in the Example folder under Source with an Example.Build.cs<\/code> file in it, its exported classes would be marked with EXAMPLE_API<\/code> (the dllimport\/dllexport macro is automatically defined), and other modules would reference it as \"Example\"<\/code> in, e.g., their PublicDependencyModuleNames. These all correspond to each other.<\/p>\n\n\n\nCompiling<\/h1>\n\n\n\n
Development Editor<\/code> configuration. By default, Unreal will check if a build for this exists<\/em>, but not if it\u2019s up to date<\/em>. This is the source of many \u201cwhy is my code not doing what it should?\u201d issues, serialization errors, possible data corruption, etc. This setting<\/a> helps to avoid running with outdated binaries.<\/p>\n\n\n\nDebugGame Editor<\/code> as my daily driver configuration, but there\u2019s nothing wrong with Development Editor<\/code> either. It runs somewhat faster, helps keep your binaries up-to-date for .uproject launches while you unlearn to do that, but it\u2019s less reliable for debugging.<\/p>\n\n\n\nHot Reload<\/h2>\n\n\n\n
Live Coding (Live++)<\/h2>\n\n\n\n
Unity<\/h2>\n\n\n\n
bUseUnity = false;<\/code> to your Build.cs, and your compiler\/linker errors will often make more sense and directly correspond to the real issue at hand.<\/p>\n\n\n\nbUseUnityBuild<\/code> setting available for Target.cs files that affects EVERYTHING<\/strong>, including forcing a rebuild of the entire engine if you\u2019re on a source build. Only use this if you really mean it.<\/p>\n\n\n\nUnreal type system<\/h1>\n\n\n\n
UCLASS<\/code> and USTRUCT<\/code> correspond to the C# concept of a class<\/code> and a struct<\/code> instead of C++\u2019s. UCLASSes are only passed around by pointer (at least in UFUNCTIONs) and are heap only. USTRUCTs are semantically passed by value even if they\u2019re references, Blueprints will happily object slice them.<\/p>\n\n\n\nUENUM<\/code>, UFUNCTION<\/code>, DECLARE_DYNAMIC_..._DELEGATE...<\/code>, etc.) are #defined to nothing in C++ but parsed by UHT as part of the build process and get an additional .h\/.cpp pair generated per affected file.<\/p>\n\n\n\n.generated.h<\/code> as the last item and use GENERATED_BODY()<\/code> within these types to inject extra members that the engine needs. If you ever see a similar three-word macro, such as GENERATED_UCLASS_BODY<\/code>, those are all obsolete and have been replaced by GENERATED_BODY<\/code> in all cases.<\/p>\n\n\n\nUObject<\/h2>\n\n\n\n
System.Object<\/code> equivalent. They exclusively live on the heap with a garbage collector taking care of them and are usually passed around by pointers or references to pointers (think ref object<\/code>). You mostly create them with NewObject<T><\/code> or CreateDefaultSubobject<T><\/code>.<\/p>\n\n\n\nUWorld::SpawnActor<\/code>.<\/p>\n\n\n\nUPROPERTY<\/code>; anything not reachable through them is considered unreachable and may be deleted. USTRUCTs can be held by value as a UPROPERTY and in turn hold UObject* UPROPERTYs which would then be considered reachable, etc. This is not reference counting; circular references are perfectly fine.<\/p>\n\n\n\nObject pointers<\/h3>\n\n\n\n
UPROPERTY<\/code>s. These all have Object<\/code> in their names, such as TStrongObjectPtr<T><\/code>, TWeakObjectPtr<T><\/code>, but NOT<\/strong> TObjectPtr<T><\/code>. TObjectPtr has no runtime effect in shipped projects, where it is equivalent to a T*<\/code> raw pointer. It is optional (and cumbersome) to use and its existence can be ignored. It supposedly has some nebulous benefits in the editor only.<\/p>\n\n\n\nPtr<\/code> such as TSharedPtr<\/code> or TUniquePtr<\/code> are reinventions of their STL counterparts (with varying levels of quality\u2026) and work with common C++ objects. Ref<\/code>s are the same but disallow being nullptr.<\/p>\n\n\n\nTSharedPtr<UObject><\/code> and TWeakObjectPtr<FVector><\/code> are both invalid.<\/p>\n\n\n\nCasts<\/h3>\n\n\n\n
Cast<T><\/code> is its replacement for UObjects, with CastChecked<T><\/code> behaving like static_cast but with additional debug checks that are not compiled in shipping. With these, you only write T<\/code> instead of T*<\/code> as the template parameter.<\/p>\n\n\n\nClass Default Objects (CDO)<\/h3>\n\n\n\n
const FObjectInitializer&<\/code>) every reflected type to query its defaults and keep it in memory, accessible via UClass::GetDefaultObject<\/code>. This will explain most of the \u201cunexpected\u201d constructor calls you might see.<\/p>\n\n\n\nTemplate<\/code> parameter to NewObject, and there\u2019s no direct replacement for parameterized constructors. Common workarounds include an Init method, a static Create method, or SpawnActorDeferred for actors.<\/p>\n\n\n\nDefault subobjects, components<\/h4>\n\n\n\n
CreateDefaultSubobject<UComponentClass>(\"PropertyName\")<\/code> instead of NewObject, and store the result in a Visible<\/strong> UPROPERTY. Do not use spaces in these FName parameters, doing so triggers bugs.<\/p>\n\n\n\n->SetupAttachment()<\/code> to build component hierarchies.<\/p>\n\n\n\nYourNewComponent->CreationMethod = EComponentCreationMethod::UserConstructionScript;<\/code><\/p>\n\n\n\nUClass<\/h2>\n\n\n\n
UCLASS<\/code>) is the closest equivalent of .NET\u2019s System.Type<\/code>. UClass itself is used the most often, but there are multiple related classes that represent types, such as UStruct, UBlueprintGeneratedClass, etc.<\/p>\n\n\n\nT::StaticClass()<\/code> and Obj->GetClass()<\/code> (cf. typeof and GetType() in .NET). Many engine functions that take a UClass* parameter come with template overloads that let you retain some amount of type safety, e.g., Foo<UExample>()<\/code> replaces Cast<UExample>(Foo(UExample::StaticClass()))<\/code>.<\/p>\n\n\n\nTSubclassOf<\/h3>\n\n\n\n
TSubclassOf<UObject> Example1; \/\/ Defaults to no class\nTSubclassOf<UObject> Example2 = UObject::StaticClass(); \/\/ Straightforward\nTSubclassOf<AActor> Example3 = UObject::StaticClass(); \/\/ Still OK to do\ncheck(Example1 == nullptr);\ncheck(Example2 != nullptr);\ncheck(Example3 == nullptr); \/\/ UObject is not a child of AActor\n<\/code><\/pre>\n\n\n\nDelegates<\/h2>\n\n\n\n
this<\/code>) also come in Unreal flavor. This<\/a> is a good overview.<\/p>\n\n\n\nDECLARE_DYNAMIC_..._DELEGATE_...<\/code> macros and can be stored in UPROPERTYs, passed into UFUNCTIONs, etc.<\/p>\n\n\n\nDECLARE_DELEGATE_...<\/code> macros (without DYNAMIC), but these are practically obsolete as all of them resolve to something like using FYourDelegate = TDelegate<void(int)>;<\/code> (or TMulticastDelegate, etc.) that you can write directly in a cleaner syntax or not define an alias at all. The macros remain required for dynamic delegates as they involve generated code.<\/p>\n\n\n\nDECLARE_EVENT<\/code>). They used to provide extra encapsulation compared to a delegate field but are obsolete and have been replaced by delegates according to a comment in the engine\u2019s source code. The implementation of these macros has changed from how it used to work and the additional encapsulation is no longer provided.<\/p>\n\n\n\nDelegates and CDOs<\/h3>\n\n\n\n
Blueprint interop<\/h1>\n\n\n\n
K2_Something()<\/code>, K2 standing for Kismet 2.0. Some other, less common ones include BP_Something()<\/code>, ReceiveSomething<\/code>, and NotifySomething<\/code>. These are often paired with a DisplayName specifier in their UFUNCTIONs to get sanitized for BP.<\/p>\n\n\n\nProperties<\/h2>\n\n\n\n
private<\/code> but adding the AllowPrivateAccess<\/code> meta-specifier, which will expose them anyway. This will prevent direct access to the field from C++, enforcing the use of your accessors, and can be treated as something like \u201cprotected for BP only\u201d.<\/p>\n\n\n\nTypes<\/h2>\n\n\n\n
Asset references<\/h3>\n\n\n\n
UBlueprint<\/h4>\n\n\n\n
BP_ExampleActor<\/code>, that would be the UBlueprint asset that contains the class BP_ExampleActor_C<\/code> actually inheriting from AActor.<\/p>\n\n\n\nFunctions<\/h2>\n\n\n\n
UFUNCTION(BlueprintNativeEvent) void Example();<\/code>, implement void ClassName::Example_Implementation(){}<\/code>. This naming convention is enforced.<\/p>\n\n\n\nExample()<\/code> instead of its _Implementation, or you\u2019ll bypass BP. An exception to this is calling Super::Example_Implementation()<\/code> in overrides.<\/p>\n\n\n\nconst<\/code> functions default to being pure, but can be marked impure with UFUNCTION(BlueprintPure=false). Otherwise purity is opt-in.<\/p>\n\n\n\nUFUNCTION(BlueprintImplementableEvent, BlueprintCallable)<\/code> is valid.<\/p>\n\n\n\nInterfaces<\/h2>\n\n\n\n
#if CPP<\/code> hacks aside), but the way you use or call them is inconsistent depending on whether they\u2019re meant to be used in BP or not.<\/p>\n\n\n\nMeta=(CannotImplementInterfaceInBlueprint)<\/code>) work with Cast<T><\/code> and regular ->Function()<\/code> calls as you would expect.<\/p>\n\n\n\n->Function()<\/code>s will assert, Cast will not work, and you\u2019ll need generated static helpers. Note the usage of both the U and I halves of the interface:<\/p>\n\n\n\n\/\/ Instead of Thing->Example(1, 2, 3)\nif (Thing->Implements<UMyInterface>())\n IMyInterface::Execute_Example(Thing, 1, 2, 3);\n<\/code><\/pre>\n\n\n\nThreading<\/h1>\n\n\n\n
enum class<\/code> was added to C++.<\/p>\n\n\n\nFRunnableThread::Create<\/code>. This is usually recommended for long-running tasks (a second or more).<\/p>\n\n\n\nGame thread and UObjects<\/h2>\n\n\n\n
Miscellaneous extras<\/h1>\n\n\n\n
Assertions<\/h2>\n\n\n\n
assert<\/code> in their names. Here<\/a> is the official documentation.<\/p>\n\n\n\nif (Configuration <= UnrealTargetConfiguration.DebugGame)\n ProjectDefinitions.Add(\"DO_CHECK_SLOW=1\");\n<\/code><\/pre>\n\n\n\nif (Target.Configuration <= UnrealTargetConfiguration.DebugGame)\n PublicDefinitions.Add(\"DO_GUARD_SLOW=1\");\n<\/code><\/pre>\n\n\n\nSubsystems<\/h2>\n\n\n\n
USubsystem<\/code>, and you, in turn, inherit from one of the specialized subclasses, such as UWorldSubsystem<\/code> or UGameInstanceSubsystem<\/code>. These get created and destroyed on demand together with the thing they\u2019re a subsystem of, with convenient getters (GetSubsystem<T><\/code> that you can wrap in a static getter if you wish).<\/p>\n\n\n\nGameplay Ability System (GAS)<\/h2>\n\n\n\n