Frequently Asked Questions

Is UE4 good for small teams and solo developers?

Let's rephrase here a fundamental question.

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?

• Unity shines at mobile development, lightweight on phones (small engine footprint, even now possible to embed the Unity app in another app). Unity now supports every mobile monetization method possible (ads, in-app purchase) - they focused for years on it.

• Unity is much better for 2D games. Unreal support is very limited, it has only Paper 2D plugin. Yes, a single plugin and nothing around in the engine is designed with 2D in mind. Even the orthographic camera doesn't fully work with Unreal's lightning. Meanwhile, Unity provides a lot: 2D lightning, animation tools, sprites, tilemaps. Check The evolution of 2D tools in Unity.

• The Unity editor has low hardware requirements, but it won't run much faster on beefy hardware. So it's great to make small games on a laptop, bring it to co-worker space or anywhere. Not so great for projects with a lot of code and assets, Unity won't scale that well.

• Meanwhile, UE4 will fully utilize even 128 thread CPU for things like code compilation, shader compilation, cooking game. Unreal - as engine targeting AAA since the beginning of time - it' optimized for crunching a lot of content. Now they're upgrading engine for open worlds, which will also bring performance and workflow benefits for smaller teams.

• You need to set up some kind of "build system" for UE4 if going serious about C++ with Unreal or having 2 programmers (you need to compile C++ and then open UE4 editor, no magical compilation in the editor like in Unity). It's nothing difficult, and you need that for another sweet thing...

• UE4 source code is available publicly, free of charge. You can make use of that for years, without paying anything. Access to source code it's important, you can easily alter small things in the engine - improve tools, workflows, fix bugs. As every single game engine could have some critical bugs - you can fix in UE4 if it's important releasing, i.e. while releasing a game.

• Unity's easier to start with, partially because of extensive docs. Also, it can be a trap, it's easier engine because of it' much simpler. Fewer systems/features than UE4, usually "simplified" - seems easier to comprehend. The problem arises if you'd like to do something complex/advanced. It's often much harder with Unity. And we're talking about "AAA complex level" - such division doesn't truly exist. Even solo dev can use "AAA things", depends on your needs. You might not need 90% of features, but you might need all complexity and flexibility of Sequencer, so you save a lot of time and effort while working on animating things in your world.

• UE4 is very friendly for artists and designers since you don't programmer to start. And this engine philosophy is to provide all the possible tools. That's why it's so huge piece of software and it can be intimidating for beginners. You don't need to learn everything, just learn what you need for a given game.

• Unity is friendly for programmers or maybe "scripters" would a better world. C# is easier to learn than C++, although... you don't use pure C++ for UE4. "Unreal C++" it's an experience closer to Unity's C# than pure C++. If someone wants to be a programmer, shouldn't be much difference for him. It' only the starting from Unreal C++ is more difficult, partially because official docs don't explain programming/C++ concepts - assuming everybody is programmer already...

• Now, Unity is closing this gap - at least by introducing fundamental tools in the vanilla engine. They didn't include these things until recently: visual shader editor, input management. That's why the Asset Store is so important for Unity, the engine was missing so many things. And still missing some. There's no visual scripting (Unity acquired Bolt as a temporary solution, but their native solution not ready yet. Nobody uses Unity's networking, while UE4 networking is excellent.

• Unity company doesn't create its own games and you can feel it. If you would work on the game, things from mentioned in the point above would be added a decade ago. Meanwhile Epic dog foods every single system. Either with Fortnite (so systems and editor tools tested game played by hundreds of millions of people on every major platform) or a special game developed to prove new systems (i.e. RoboRecall for VR). And this might the most important thing, UE4 tools are proven and often simply work. Meanwhile, Unity does usually create a shiny promotional movie and doesn't even release it as a project. We haven't ever seen a game that looks as good as Unity's internal demo.

• There's no concept of scalability settings in Unity - simply the visual settings available in the engine, so users than adjust it to his/her hardware. It makes a huge difference when working on a game visually awesome 3D game.

• A lot of indie studios switch from Unity to UE4 for the next project because Unity wasn't enough for more ambitious projects: more content, higher visual fidelity, multiplayer. For all the reasons above, Unity is designed for simplicity and small games.

Where to get started?

If you don't know an exact Unreal Engine feature that you need to learn we recommend starting with Learn.Unrealengine.com

Epic Games offers a variety of courses to get you started with most areas of the engine and all fundamentals.

Once you are comfortable with the basics of using the editor and have a basic overview of the engine you can look into more specific areas that interest you.

This wiki offers some help that you can find on the overview pages for articles explaining basic concepts, about creating and importing assets into Unreal Engine or Learning Resources where you can find a curated list of recommendations.

There are also articles, youtube videos or Udemy. (Should you be interested in paying for a course on Udemy please be advised that courses are basically always discounted. Don't be pressured by the design of the website into buying something impulsively. There is no time pressure to purchase. Take your time to make the decision)

Should I use C++ or BP

The engine works by far the best when both are used. C++ works as the programming language, BP works as scripting language. A separation that is used in a lot of large software projects.

It basically means that the foundation is written with a fast runtime, precise memory management, a lot of safeguards, testing and redundancy in C++, which is a bit slower to code but a lot more convenient to make really solid code, especially when you need to change something in a few months. Setting up the C++ environment for use with UE4 takes a while and the language itself is generally recommended for dedicated programmers only as there are a lot of fundamental principles and techniques which need to be understood before the language can be used efficiently.

BP is excellent for quickly combining functionalities and a bit slower than C++ during runtime (aka when the game is running). This difference in speed is mostly irrelevant until you really have performance issues and pretty much all features you commonly see in games can be implemented with BP by itself.

However, it comes with a few downsides. Collaboration is not convenient as BPs are effectively binary files. This means there is no simultaneous editing of the same file as is possible in text-based code. Other tools around BP are also not as effective as the text equivalents simply because text editors have been around much longer and are used by a lot more people. This means debugging large code files will be slower and organization in general is more challenging. Which makes working on larger projects that are primarily BP based inconvenient in the long run, especially during the polishing phase when you need to touch all different kinds of aspects of the code again. The upsides are a much more intuitive way of programming especially for inexperienced programmers and designers and a slightly faster development time when setting up features initially.

An example for how it can work together would be an Inventory system where data storage (e.g. what items exist, how many are inside of the inventory, etc) and fundamental functions (add to inventory, remove from inventory, is in inventory, list all items in inventory) is written in C++. Exposed to BP it becomes very easy and requires but a handful of nodes to implement things such as "Press E to pickup item".

TLDR: If you are alone, in a very small team, inexperienced or only want to test out an idea real quick it is valid to focus on BP only.

It is generally not advisable to focus exclusively on C++ as turnaround times are significantly higher especially if you only need to tweak a few values. The combination of C++ and BP is where the engine shines. So in larger teams, if you are experienced with C++ or an advanced programmer and intend to keep working and maintaining the project for an extended amount of time, it is advisable to use both even if just to manipulate default values in the editor.

Why there's no C#? We need C#

C# support is often requested/asked for the following reasons

• It's a scripting language used in Unity. (although engine itself is written in C++)
• It's easier to learn pure C# than pure C++, syntax seems to be simpler.
• Unity's C# environment is easier for beginners. Engine won't crash on an invalid pointer, and code compiles itself for every user.

You might be surprised then, supporting C# in UE4 is simply... pointless. And it would make development more difficult. How that's possible?

Writing C++ code for UE4 is much, much easier than regular C++. Actually, it's more similar to Unity's C#.

• Generally, you don't use pure C++ while coding games for UE4. Epic build something we often call "Unreal C++", entire layer on top of C++ tailored for game development.
• It provides low-level mechanism like garbage collection or reflection, that you don't need even fully understand, but you gonna take advantage of it every day.
• Unreal C++ provides its own core libraries supporting math, vectors, strings... many of standard things just to make our life easier.
• Writing code is simplified, thanks to dozens of built-in class, function and property specifiers. Also macros and many utilities.
• Basically, Unreal C++ provides a similar experience to Unity's C# in most areas.
• Epic integrated Live++ to all developers since 4.22 - it allows you to quickly recompile changes in .cpp files. Even if the game is running! Super sweet.

That's why requests on adding C# support are simply ignored.

• C# wouldn't add anything really new to the engine. At least nothing giving us more capabilities would be just another way of doing the same things.
• Adding another language would actually make Unreal Engine much more complex: to learn, use and maintain.
  • Tutorials and code samples would come now in one more language. It would be fewer resources for C++ and C# individually.
  • Engine code would still be written in C++, making you a second class UE4 programmer, unable to understand or alter the engine's code. Remember, one of the best things about UE4 is public access to its source code. It's priceless.
  • Supporting another language would make the engine's development slower and prevent from adding some core engine features. And surely a lot of engineers would simply hate it.
• Let's think for a second, why Unity removed additional scripting languages from the engine? It was a huge burden...

You might be skeptical about a few details of C++ environment, but you'd appreciate it if your project's codebase rapidly grows.

• You need to provide compiled binaries to non-programmers, but they work faster thanks to that! There's no compiling code on non-programmer machines. No compilation errors there, also.
• There's no long wait for launching a game in the editor. It's basically instant or very quick. If not, somebody seriously messed up the code or assets.
• Blueprints or C# forgives you if you'd try to call anything on the invalid object. It makes learning a language easier, but it doesn't prevent from writing bad code. It's a really bad thing if you see hundreds of messages about "trying to call null object" in your log, coming from blueprints or C#. This code needs to be fixed, either way.

Go ahead, check Introduction to Unreal C++ in official documentation :)

PS Epic purchased company behind SkookumScript for a reason. This 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.

Can Unreal do X?

With source code access the answer here is simply: Yes. Unreal can theoretically do everything.

The question is whether or not it makes sense to use UE4 for the project and how much effort it is to implement.

Should you be looking for or asking about whether unreal is good for certain things, make sure to be specific and don't look for the entire mechanic but for all the individual systems required for the mechanic instead.

If you only have a vague idea about a mechanic and wonder whether the engine can do it, just assume the answer is yes :)

For example:

• Can Unreal do Portals like in the game Portal / Portal 2?

Yes

• Can Unreal do Portals like in the game Portal / Portal 2 in the way Valve implemented it without going through the entire render pipeline for each portal in view?

No, not without a significant amount of work.

How can I do X?

The best way to figure out how to implement something is by being as specific and elaborate about it as possible.

How to make a portal like in the game Portal? is not a good question to ask yourself. These portals consist of several aspects.

• Teleportation of the player character

• Carrying over velocity between portals

• Rotating towards the ground when the portals aren't aligned

• Removing collision from the area the portal has been placed at so the player character can walk into the portal

• Displaying the area on the other side of the portal

• Seamlessly moving objects through the portal

These are topics you can start to research more and ask about more easily. The more precise you figured out how your mechanic should work the easier this gets.

Vagueness makes it hard to find answers and impossible for others to help you.

Can I open a game as an Unreal Engine project?

No. Games get compiled and packaged. The majority of the work is not accessible anymore under any circumstances.

3D assets, textures, animations and possibly audio can be extracted with more or less effort depending on how the game was packaged. This practice is commonly referred to as "Asset Ripping" and is generally speaking not allowed unless you developed the project.

Is Unreal Engine free?

Yes, with limitations.

The engine is always free to use. You can always start developing your game and don't owe a cent until you sell a product.

If you're making a game or application that's sold to end consumers (aka players) you owe 5% of all money you make from the game (any revenue) after the first $3000 each calendar quarter.

Other uses may be free, may have the same payment structure or require a different or custom license.

Take a look at the FAQ from Epic Games for some more cases explained in simple language.

Please remember that this is meant to give you a quick overview. This is not a legal advice.

Here you can find the EULA which includes the publishing license with all details. Should you have any questions or concerns you should contact Epic directly as well as your lawyer to get accurate answers.

I get an "Error Accessed None" in my Blueprint code

Error Accessed None means that a variable was used for something which contains nothing.

"None" in programming refers to the case that you have referenced nothing.

This is different from the number 0 in that the number 0 describes a value of nothing. Whereas "None" describes the absence of a value.

So, somewhere in your script you did not verify that the values you are using actually exist.

Checking whether a value exists can be done with "IsValid".

You can navigate to the node that caused the error by double-clicking it in the output log within the error message.

Casting doesn't work

Aka: I don't know what to put in the object pin?

The quick explanation is that you misunderstand what a cast is.

Every variable must have a type. This type can store all compatible values which can be more than one type.

Which has to do with how inheritance works in programming. The short explanation is that every class can have a parent and multiple children. For example, a "Character" in UnrealEngine is a child of "Pawn" which itself is a child of "Actor".

A variable of type "Actor" can store pawns and character. But a variable of type "Character" can not store an "Actor". Because every "Character" is "Actor" but not every "Actor" is a "Character".

A cast basically asks a variable whether it belongs to a certain class. So if you know you have a "character" stored in an "actor" variable you can cast it to "Character" and now store it in a "Character" variable. This allows you to use all the functions and variables that "Character" possesses.

Managing references is your responsibility. Only very few references can be obtained just about anywhere and it's a matter of your core systems and data structure about how you maintain and distribute your necessary references.

Take a look at Blueprint Communication which will help you move data from one class to another.

Alternatively, you could reconsider how your system is set up.

Can my computer run Unreal?

Where can I find assets?

Free, high quality and fitting assets are basically impossible to find. You are not alone here ;)

We recommend a look at the Unreal Engine Marketplace as there is a lot of content available for free which you can use as placeholder art.

Mixamo offers a handful of characters and animations that can be very useful during prototyping.

Be careful when downloading assets from some of the free online resources as the license of these assets may not be clear and obvious. Make sure you record and store the license of all assets you use. When using the UE4 Marketplace but especially when you use other sources where you don't know their reputation and reliability so you can always prove that you acted in best faith with due diligence!

And consider using placeholder content to develop your mechanics, modify the textures or models you got for free to be in line with your style or expand the free content with your own work.