Let’s rephrase a fundamental question here. <\/p>\n\n\n\n
I’m considering using Unreal, but many people seem to be using Unity for making indie games. I’m never planning to go into AAA games, I only want to make indie games as a solo developer (maybe in a small team). Is Unreal the right choice for me? Does Unreal have significant disadvantages compared to Unity for an indie dev or a small team? Is it slower\/harder to make prototypes and small indie games in Unreal? Why do so many people use Unity instead?<\/p>\n\n\n\n
This is just a short summary which should give you some basic overview, so you would know better what to look at. It aims to clarify some doubts and myths.<\/p>\n\n\n\n
This is the myth that Unreal Engine is meant for large studios. It’s essential to debunk it here.<\/p>\n\n\n\n
Unreal Engine was designed with indie teams in mind as Epic already filled the “AAA studio niche” as it was possible at a time. That’s why we have blueprints, visual scripting and dozens of tools working with each other out of the box. Especially if somebody is working on a game where gameplay uses characters or heavily-directed content (implementing and scripting small things in every place of the game instead of relying on programmer every day).<\/p>\n\n\n\n
Unreal rendering focuses on physically based rendering<\/a> and perspective camera. Making stylized games is still possible, there are dozens of small stylized games done in Unreal. You can make a racing game or a spacecraft simulation game, the engine doesn’t focus on FPS games (it’s not Unreal Engine 1, 2, or 3).<\/p>\n\n\n\n It comes with a lot of tools out of the box for handling characters, skeletal animations (not limited to humanoids), rendering things such as hair, fur and eye shaders. It’s extremely indie-friendly in this regard.<\/p>\n\n\n\n Furthermore, it’s already a tradition that Epic promotes stunning indie games developed with UE at major showcase events<\/p>\n\n\n\n Check out examples of solo devs and small studios utilizing the engine:<\/p>\n\n\n\n And the engine scales well from relatively small projects to AAA studios heavily modifying the renderer.<\/p>\n\n\n\n Unity is friendly for programmers.<\/p>\n\n\n\n People are often scared of learning C++ in Unreal Engine. It comes from the fact that pure C++ requires a lot of low-level knowledge, assembling your toolchain. The thing is, you don’t use pure C++ with Unreal ENgine, the same way you don’t use pure C# with Unity. Thanks to that, writing C++ code for Unreal ENgine is much, much easier than regular C++. Actually, it’s more similar to Unity’s C#.<\/p>\n\n\n\n Be warned, Unreal C++ environment doesn’t provide a perfect way to compile the project without ever closing the editor.<\/p>\n\n\n\n If someone wants to be a programmer, shouldn’t be much difference for them, C# or C++. Albeit learning curve for Unreal C++ is steep, partially because the official docs don’t explain programming\/C++ concepts – assuming everybody is a programmer already…<\/p>\n\n\n\n It’s very important to begin a journey into the land of Unreal C++ with proper tools. C++ is punishing those who try to approach with bare hands.<\/p>\n\n\n\n In theory, you could live without things below – especially if you’ve got only a single programmer in the team. However, this is essential for efficient work.<\/p>\n\n\n\n Go ahead, check Introduction to Unreal C++<\/a> in the official documentation \ud83d\ude42<\/p>\n\n\n\n PS: Epic purchased the company behind SkookumScript<\/a> for a reason. This is a speculation, but they might come up with a custom scripting language designed to fill a gap between blueprints and C++. And that would serve us much better than just stitching another general-purpose language to the engine.<\/p>\n\n\n\n It seems that recent<\/a> news<\/a> has<\/a> caused another wave of people leaving Unity for Unreal or at least considering a switch and checking things out \u201con the other side\u201d to see if it\u2019s worth losing access to all those assets bought over the years. If you\u2019re reading this, chances are you\u2019re one of these people. \ud83d\ude42<\/p>\n\n\n\n As someone who had to make a similar call a few years ago, I can say that even accounting for the months \u201clost\u201d on porting and having to learn new tools, it was still worth it. (Obviously the project was not near shipping, YMMV.)<\/p>\n\n\n\n As of writing, 5.3 is the latest stable version. There is no TECH\/LTS split in Unreal. Versions with \u201cpreview\u201d in their names are just that, betas, anything else numbered is stable (generally, more stable than a Unity LTS version, and you can apply your own fixes on top of the engine\u2019s source if needed).<\/p>\n\n\n\n The system requirements for UE4 and UE5 are the same, but UE5 defaults to higher fidelity settings out of the box. If you find that a sandbox project is \u201crunning slower\u201d than you\u2019re used to, that\u2019s because of this and not due to an innate disadvantage of 5. You can change your project settings to match how a UE4 project would behave (or open a UE4 project) to get similar performance characteristics.<\/p>\n\n\n\n UE5\u2019s high-end rendering features such as Nanite and Lumen have a relatively large setup or resolution-based cost, but they scale extremely well, so performance on a sandbox scene is not really relevant.<\/p>\n\n\n\n With earlier versions, there were a few situations (mostly mobile and VR) where UE4 was still an obvious winner, but as time goes on, its advantage is eroding.<\/p>\n\n\n\n For mobile specifically, UE4\u2019s API and runtime support has stagnated, and you\u2019ll probably need to use a custom engine build of VR has also been making steady progress; if you\u2019re not shipping right away, chances are all the remaining issues will have been fixed by the time you ship. Shipping for Quest is where one might consider sticking with UE4 for the time being.<\/p>\n\n\n\n Unless you want to commit to the 4.27+ branch for your entire project, I would strongly recommend starting on the latest UE5 version right away to avoid generating extra porting work.<\/p>\n\n\n\n Unity has a very programmer-centric development style compared to Unreal, with Bolt being a relatively recent addition to the engine. Even designers often deal with C# code and everything revolves around Unreal is not just more artist-focused, but the entire architecture is different in a way that I don\u2019t think the official documentation<\/a> explains well enough. Definitely read that page, but then please come back here and let me tell you about the things that took me some time to realize. \ud83d\ude42<\/p>\n\n\n\n In Unity, you write scripts and attach them to In Unreal, your C++ code is on equal footing with the engine, you\u2019re extending the architecture itself with your game-specific classes. Start un<\/strong>learning to make everything a component and organize your code in classes that make sense in your game world. Don\u2019t try and cross-reference components across different actors, that\u2019s rare to do in Unreal. You can directly have logic in your actors unlike in Unity, use them directly.<\/p>\n\n\n\n Because your C++ is going directly into the engine, the way you compile code is also different. Normally you leave Unity running, change some C#, reload the script runtime, and test your changes. Unreal should be treated more like as if you were writing a command-line program: you\u2019re working on the engine itself instead of being limited to a sandbox. The sandbox is BP and it provides a similar rapid iteration workflow.<\/p>\n\n\n\n There are QoL tools that attempt to do some form of hot reloading, one of which is broken<\/a>, and the other one<\/a> is unstable. Feel free to use Live Coding, but you\u2019ll need some time to get used to working with this style of development\u2013you\u2019ll get some number of successful reloads (anywhere from 0 to many) before you need to ultimately close the Unreal Editor, compile your code \u201ccleanly\u201d, and start again. This does not mean a full rebuild, but the only 100% reliable compilation method is building your C++ code with the editor closed<\/strong>, then<\/strong> starting it anew.<\/p>\n\n\n\n If you don\u2019t already know C++, these are good resources for learning it: If you do, I wrote an article<\/a> to bring you up to speed.<\/p>\n\n\n\n This (underwhelmingly-titled) course from Epic will introduce you to the various In your first month or two, I\u2019d also recommend keeping https:\/\/tackytortoise.github.io\/2022\/06\/24\/common-slacker-issues.html<\/a> on speed dial.<\/p>\n\n\n\n Using ReSharper or Rider is also highly recommended, getting autocomplete for the magic macros is very nice as a beginner. Visual Assist used to be another solid choice for Unreal development.<\/p>\n\n\n\n Most people with a Unity mindset think of this as a choice that has to be made, and default to C++ as the obvious<\/em> choice. That\u2019s a mistake, the correct choice is both<\/strong>.<\/p>\n\n\n\n BP is not just the node graph programming language, it\u2019s a collection of systems built on the reflection system that also deals with saving values on your actors (\u201cprefabs\u201d), upgrading components in derived classes, serializing data (\u201cScriptableObjects\u201d), etc.<\/p>\n\n\n\n I found it useful to default to making actor classes in pairs\u2013immediately create a BP subclass for your C++ class and only ever use the BP one. Empty classes are virtually free and you\u2019ll have them ready to go when you need to add something in either language. The situation becomes a little more complicated with subsystems. If you find yourself thinking of using constructor helpers (don\u2019t!) and there\u2019s no obvious BP escape route, look into Other than this, BP is great for anything that involves logic running across multiple frames (their name for async stuff is \u201clatent\u201d, nodes with a ? icon). I\u2019m I won\u2019t attempt to suggest a \u201ccorrect\u201d balance of BP and C++ because it depends on team skills and preferences. Being C++ heavy, BP heavy, or a mix closer to half-and-half all have their individual benefits and drawbacks. 100% of either is a Very Bad Idea\u2122.<\/p>\n\n\n\n Let\u2019s face it, C# is amazing and a serious benefit of Unity compared to Unreal. However, you have to use Unity for that, which is becoming more and more of an issue. This is the part where Unreal shines and makes it worth tolerating C++ and BP.<\/p>\n\n\n\n A lot<\/strong> of things that you would buy Unity assets for or develop yourself are just\u2026 there already. Very often you need but to click a checkbox. Especially when you\u2019re new, it\u2019s worth spending \u224810 minutes trying to find an engine implementation of whatever you\u2019re trying to do, because it will usually be there. (And, you have full source code access as standard!)<\/p>\n\n\n\n There is no messing around with packages and their incompatibilities. There is no SRP fragmentation hell (there is an alternative forward-rendering pipeline which is compatible with the deferred one if you don\u2019t access the GBuffer). A character controller (both manual and AI) comes out of the box. It\u2019s a built-in class, which is great because virtually every marketplace asset will support it. There is multiplayer support. There are obviously the shiny new features such as Nanite and Lumen. There is an entire generic gameplay ability system that comes with skill levels, cooldowns, status effects, etc. The list goes on.<\/p>\n\n\n\n Epic Games actually makes and ships games, and you can\u2019t help but notice all the small QoL things that permeate the engine and are completely missing from Unity.<\/p>\n\n\n\n Unreal is not perfect and there are some things that are worse and require additional discipline or forethought compared to them Just Working\u2122 in Unity.<\/p>\n\n\n\n A lot of what would be YAML files in Unity are binary files that are a nightmare to version control. Things are mainly referenced by paths instead of GUIDs that lead to hacks like \u201credirector\u201d assets or configuration entries to keep references alive when you move or rename something. You\u2019ll need to avoid merges with a locking workflow using something like Git LFS or P4. One File Per Actor provides some relief for .umaps, use it (4.26+)!<\/p>\n\n\n\n Unity uses quaternions throughout with helper functions such as Epic ships a lot of Not-Invented-Here replacements for standard stuff that are incompatible, buggy, or both, for example Speaking of bugs, although this is unfortunately equivalent to Unity, there are some features that are more or less broken. Strings come in three flavors with their separate macros for literals. Constructors make The convention for engine units is 1u=1cm, and the coordinate system uses +X for forward. This means most digital content creation tools need special settings to export assets correctly (and often you\u2019ll see hacks like characters being rotated 90\u00b0 in a blueprint because the meshes were imported from Maya).<\/p>\n\n\n\n Some parts of BP are best to be avoided completely, structs and enums are infamous examples.<\/p>\n\n\n\n\n\n\n\n I’ve been using Unreal for a few years now, and I’m pretty comfortable with it. When I first started, the only other game framework I had experience with was Unity, and the transition from Unity to Unreal was pretty tough.<\/p>\n\n\n\n At the time, I wished there was an article on how to go from Unity to Unreal, not just “hey learn C++” but more about the mindset to take when using Unreal.<\/p>\n\n\n\n This is probably the single most important thing to do when learning Unreal. Unity (at the time of writing) is mostly closed-source, but its documentation is pretty good, so the only way to learn is throuFor more info on trial-and-error.<\/p>\n\n\n\n Conversely, Unreal’s documentation is a little terse<\/em>. You’re far better off looking at the source code for how the engine does things. You’ll learn how to use classes and components, and how to compose your game.<\/p>\n\n\n\n For more info on what resources to consult, check out my tutorial on Help and Resources for Unreal Engine<\/a>.<\/p>\n\n\n\n Unity is a much purer entity-component system than Unreal. Its GameObjects are empty containers to which you add components. If you want custom behaviour, you add a new component.<\/p>\n\n\n\n Unity has very little in the way of existing code that you are expected to extend. It’s far more agnostic than Unreal, whose code base was built on the multiplayer first-person shooters.<\/p>\n\n\n\n What does that mean for you as a developer? Well in Unreal you are expected<\/em> to subclass existing core classes to get the behaviour you want. Unreal uses a core classes like You then configure Unreal to use your subclasses instead of its defaults.<\/p>\n\n\n\n As a corollary to the point above, sometimes it can be really hard to find the perfect<\/em> place for code. Should I put my custom code in There is usually a correct answer to this depending on what you’re doing, but sometimes there isn’t. Don’t spend ages searching the codebase to find the perfect spot, it’s better to just get something working and wrap it in an accessor method so that you can move it later if needs be.<\/p>\n\n\n\n Unreal is pretty strict with naming conventions, and there are a lot of them. Some things are enforced, if you create a subclass of Unreal has a visual scripting system called Blueprints that can be very helpful when prototyping. It autocompletes in a useful way and doesn’t require you to recompile your game every time you want to make a minor change.<\/p>\n\n\n\n It can help you learn what the myriad classes in Unreal are for, and how they should be used.<\/p>\n\n\n\n However, I would warn against using them exclusively. For code that runs every frame they are not as fast as C++, and they can be far more difficult to debug. When you understand the systems that your scripts are using, I would recommend you move your logic from Blueprints to C++.<\/p>\n\n\n\n Unity’s learning curve is definitely more gradual than Unreal; You can start with an empty scene and gradually add objects and scripts as you implement your game. Any existing code is “opt-in”. Unreal is kind of the opposite, the learning curve is much steeper and it feels like there’s a lot of learning to be done before you write your first line of code.<\/p>\n\n\n\n But don’t be put off, Unreal is a fantastic engine and once you’ve got over that first initial hurdle, I’ve found it’s a lot more smooth sailing than Unity’s closed-source ecosystem.<\/p>\n","protected":false},"excerpt":{"rendered":" Let’s rephrase a fundamental question here. IR […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=\/wp\/v2\/posts\/5217"}],"collection":[{"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5217"}],"version-history":[{"count":2,"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=\/wp\/v2\/posts\/5217\/revisions"}],"predecessor-version":[{"id":5220,"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=\/wp\/v2\/posts\/5217\/revisions\/5220"}],"wp:attachment":[{"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5217"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5217"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.coolcoding.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5217"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}How much do the engines cost?<\/h2>\n\n\n\n
Tools & learning curve<\/h2>\n\n\n\n
Programming<\/h2>\n\n\n\n
Stability of technology<\/h2>\n\n\n\n
Unreal editor requires a better hardware<\/h2>\n\n\n\n
UE4 or UE5?<\/h1>\n\n\n\n
4.27-plus<\/code> to get accepted in the two big app stores. On the other hand, UE5 does not support 32-bit targets.<\/p>\n\n\n\nDevelopment<\/h1>\n\n\n\n
MonoBehaviour<\/code>s one way or another.<\/p>\n\n\n\nGame code<\/h2>\n\n\n\n
GameObject<\/code>s that don\u2019t really do anything by themselves, all functionality comes from components. There is also a very clean line drawn between \u201cyour code\u201d and \u201cengine code\u201d.<\/p>\n\n\n\nGetting started<\/h3>\n\n\n\n
https:\/\/stackoverflow.com\/questions\/388242\/the-definitive-c-book-guide-and-list<\/a>
https:\/\/www.learncpp.com<\/a>
<\/p>\n\n\n\nUSOMETHING<\/code> macros that you\u2019re expected to use:
https:\/\/dev.epicgames.com\/community\/learning\/courses\/KJ\/converting-blueprint-to-c\/<\/a><\/p>\n\n\n\nC++ \u201cvs\u201d Blueprints<\/h2>\n\n\n\n
UDeveloperSettings<\/code>.<\/p>\n\n\n\nshamelessly promoting<\/del> developing a plugin that adds coroutines to UE5 (see the top of this page), but BP remains the only officially-supported way that doesn\u2019t involve callback hell. Timeline nodes are very convenient for interpolation and quick one-off animations. You can easily run them by calling a custom BlueprintImplementableEvent<\/code> from C++.<\/p>\n\n\n\nOverall engine \u201cfeel\u201d<\/h1>\n\n\n\n
Drawbacks<\/h2>\n\n\n\n
Euler<\/code> to convert from designer-friendly representations, making it relatively straightforward to avoid gimbal lock. Unreal has FRotator<\/code> as an entirely separate type, and you\u2019ll need to go out of your way to make sure everything uses the FQuat<\/code> overloads. BP doesn\u2019t even have quaternions exposed by default.<\/p>\n\n\n\nTUniquePtr<\/code> instead of std::unique_ptr<\/code>, TFunction<\/code> instead of std::function<\/code>, TVariant<\/code> instead of std::variant<\/code>, etc. There is no universal best pick for these (see here<\/a>), some of them are genuinely better and good to have, and Epic themselves have started abandoning others like TAtomic<\/code>.<\/p>\n\n\n\nUChildActorComponent<\/code>s sound like a nice replacement for prefabs, but don\u2019t use them (at all).<\/p>\n\n\n\nFName<\/code> needs \"\"<\/code> (most often), FString<\/code> needs TEXT(\"\")<\/code>, FText<\/code> needs LOCTEXT<\/code>\/NSLOCTEXT<\/code>\/INVTEXT<\/code>, but some other combinations also work (and waste CPU). Epic code is not consistent when it comes to using these correctly.<\/p>\n\n\n\nUObject<\/code>s differently compared to when they\u2019re made at runtime. This is a small minefield that you have to correctly navigate every time: components need Visible<\/code> UPROPERTY<\/code> specifiers, not Edit<\/code> (even for editing), and when creating them at runtime you need to call both RegisterComponent<\/code> and AddInstanceComponent<\/code>. Why these are not one function call is a mystery, and even engine code randomly forgets calling the latter.<\/p>\n\n\n\nRead the Source Code<\/h2>\n\n\n\n
Subclassing is Important for Core Behaviour<\/h2>\n\n\n\n
AGameMode<\/code><\/a>, AGameState<\/code><\/a>, UGameInstance<\/code><\/a> to name a few. You should<\/em> subclass these to set up your core gameplay loop.<\/p>\n\n\n\nDon’t agonize over finding the perfect place for stuff<\/h2>\n\n\n\n
AGameState<\/code> or AGameMode<\/code>?<\/p>\n\n\n\nLearn and Follow Naming Conventions<\/h2>\n\n\n\n
AActor<\/code> and don’t prefix your class with A<\/code> then it won’t even compile. Some other conventions, like naming Blueprints with the BP_<\/code> prefix, are not enforced. Either way, I think it’s best to learn the coding standard<\/a> and stick to it.<\/p>\n\n\n\nUse Blueprints scripting to learn, move to C++ when you understand<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n