The engine is huge, a lot of complex systems. That can be intimidating for beginners, but remember that no team does need to master every single system, even AAA studios.
- Every project uses a different set of features. You might not need 90% of UE4 systems, but you might need all complexity and flexibility of a single system, i.e. Sequencer - saving a lot of time and effort while working on animating things in your world.
- Blueprint visual scripting has been created with indie developers in mind. It's possible to publish a game scripted entirely with blueprints. Traditional C++ programming would help a lot, but it's not mandatory.
- Don't worry that the engine is used by AAA studios. It's also important for them to have easy to use tools. And get as much work done as possible in a limited time.
PS Here's an article on Differences between Unity and UE4 if you're interested in that.
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.
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)
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.
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. How is that possible?
- "Unreal C++" already offers most of the advantages of Unity's C# environment. It's not like raw C++ you would use to build your own engine. Read about the Programming section of the article on differences between Unity and Unreal.
- C# wouldn't add anything new to the engine, really. No new capabilities, it would be just another way of doing the same things.
- C# isn't either a perfect language when it comes to developing video games. Unity puts a lot of effort to make it performant. Writing their own compiler. Currently refactoring the entire engine to DOTS, partially the limitation of projects relying on C# only. This post on Unity forums explains it nicely. Hopefully, it's clear now that adding C# for scripting isn't that obvious thing to do...
- Adding another language would actually make Unreal Engine much more complex: to learn, use and maintain.
- Epic would have to develop and maintain 3 different programming environments! Unreal C++, visual scripting and C# which wasn't designed to "just work" with any of already existing environments.
- Tutorials and code samples would come now in one more language. It would be fewer resources for C++ and C# individually.
- 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.
- Engine code would still be written in C++, making you a second class UE4 programmer, unable to understand or alter the engine's code. Keep in mind, public access to UE4's source is priceless.
- 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 :)
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 :)
- Can Unreal do Portals like in the game Portal / Portal 2?
- 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.
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.
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.
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.
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.
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.
Yes, you can! Check the documentation on sharing Derived Data Cache.