Why Use The Unreal Game Engine? 

I really dont know why unity are scared to make a game. Like jeez! even if it is a mobile game.

That's totally true. We had 2 teams working on 2 games in studio I worked before. One team was 5 devs on unity games nad my team were 25 devs working on UE4 game. My team, despite having much people, had much less problems with people going in their ways. Since 4.26 unreal can save each object on level as separate file so many people can edit the same level as long they don't edit same objects. If I rename/move some assets that are in use by other dev on different branch, it will work as unreal will add hidden redirector file that says "That asset is now there". Unity team had problems with breaking references to things cuz someone cleaned up project and moved assets around while another dev on another branch created prefabs that used them.

@@Dzarafata That meets my expectations. I don't feel like you can have more than a few people on the same Unity project before you start clobbering each others work. Nested prefabs were a huge improvement but they don't really solve the problem.

@@Dzarafata I feel like your experience with redirectors is the opposite of what I would consider good. You are providing a use case where the bad handling of files in unreal somehow ends up being positive in your team. Don't you stop to think why redirectors even exist? Why moving a file or renaming it creates another file? Why can't the engine just somehow deal with it? And maybe more importantly why this doesn't happen in Unity? And the funny thing is that the other point that you bring is also a problem in disguise. Why there's this new feature where each object on the level is saved as a separate file? Why doesn't Unity need this? And why can people working in Unity edit the same file but not in Unreal? The fact that you give these examples as positives without mentioning the technical reasons behind leads me to believe that the reason those 5 devs using Unity had so many issues against 25 using Unreal is not because of the engine but the people themselves. Both engines have pros and cons, but I find it particularly interesting when people bring negatives as positives.

But what if you're an indie dev?

@@kebrus I don't agree that Dzarafata qualified the redirect feature as good or bad. As an anecdote, it exemplifies a team making progress on a project using a tool that supported their workflow.

I hate having to recompile unreal engine when using c++

True, Unreal is great but it takes time to learn

@@FormalSnake I agree. While I think unreal engine c++ is similar to unity c#, its integration with vs code is poor. Getting intellisense to work and compilation to work is really messy. The engine is too bloated. If they can fix their C++ VScode issue, I think c++ is not too hard to learn.

@@leeoiou7295 Indeed.

if you use blueprints which are so underrated! i promise it's much easier than unity bro. i was really surprised

Of course for all the flack, I wish the Unity Engine engineers and developers all the best. Software has come and gone over the years, so will Unreal and Unity some day. No need to cling to them

I was going to say the same, Unity has almost nothing out of the box idk what Mike is saying here

Epic does help external studios a lot, as well as external studios tech is adopted by Epic. For example The Coalition, that makes the Gears of War franchise, have contributed and collaborated with Epic on improving the engine many times over the years. A lot of these cases are custom licenses, from larger studios. So probably any AAA studio that uses UE, has received support from Epic.

I spent 1 month on Godot, If you are a C# nerd, stay away from Godot, if you wanna make money for living, stay away from Godot! If you just wanna play around and have some fun, Godot maybe. Godot has a few interesting stuff, like timer, easy tween, etc. but not enough for production. And if you ever feel like Unity or UE5 sucks, try Godot, then you're gonna realize how great they are.🤪

What are those broken promises?

@@gruntaxeman3740 4.x is full of them. Renderer is busted-- PBR is broken, shadows need a 16K shadow map just to look like a 512 map in any other engine, shadows/lighting is full of artifacts and inconsistent, SDFGI is especially full of artifacts; Juan wrote the Vulkan renderer as if it was OpenGL... and ported ALL of Godots rendering problems with it. On top of that, years ago... Victor Blanco wrote a fork of Godot that showed massive speed improvements. Juan said 4.0 would be just as fast if not faster... which we now know isn't even close to true. Godot is the engine that's all about getting funding, unfulfilling promises, and kicking the can down the road. I used Godot for years, one of the few people on a team that tried to use Godot for a larger, high fidelity games... it was just a lack luster and incapable engine. It's just a mess for anything that isn't small, stylized games... or 2D games. Stay away from its 3D like its a plague, because it is-- and you won't know it until you've actually hit the walls... and the engine is so broken under the hood, making those walls higher is neigh impossible. It's just as well to change engines, like we did.

@@lillybyte "4.x is full of them" Please link where is promised, what and what time schedule. Godot 4.x is just released. It means that there should be no major breaks in code that is develop for Godot 4 but it is still work in progress, and features are still added and optimized. It can be used to developer larger projects that takes years to develop and features should be polished in coming years when game is taking shape. For short projects that takes month or so to develop, it is Godot 3 series what to use. "Renderer is busted-- PBR is broken" How? I've created and imported metallic workflow PBR assets and they work as expected. "shadows need a 16K shadow map just to look like a 512 map in any other engine" Mm.. no. In Godot 3 shadow map implementation seems to be very basic but it works as shadow map should work. However the way it is implemented seems to be inefficient when using direction light. Documentation had mention that calculating shadow map for direction light is more demanding. It should be obvious that developer can optimize shadow map using spotlight. In Godot 4 shadow map implementation is better and it can be possible to backport it or migitate Godot 3 implementation by inspecting how it works on Godot 4 and adjust Godot 3 version using piece of script. Not sure about that what is best way but there are no real showstopper. " Juan wrote the Vulkan renderer as if it was OpenGL... and ported ALL of Godots rendering problems with it." Uh.. of course? Godot 3 version was working. Simplest way to make next version is to port it to Vulkan, optimization can be done later. This is very normal in software development, even very high profile and high budget software. Example in Windows, basic GDI graphic routines were still unoptimized in Windows 98 and had been mostly unoptimized all time. It was Windows 2000 when Microsoft optimized those. " I used Godot for years, one of the few people on a team that tried to use Godot for a larger, high fidelity games... it was just a lack luster and incapable engine." First Godot version that was capable for starting development of larger, high fidelity games was Godot 3. When expecting game development takes time about three years, earliest date to get something larger finished Godot was somewhere 2021. This is same on every engine. Unreal engine 5 was made based on Unreal engine 4, development of features started on 2018 and it was somewhere 2022 when it was released to developers to make games, and they add missing features after that. In fact this very common in everywhere software development. All APIs and frameworks has their own lifecycle, developers should know roadmap and development is often started when platform is unfinished because it technology is not maintained forever. Most important thing what developer want is to get benefit from maintenance that is done someone else or shared together with others. I'm not using Godot 4 as I only do something small so it is too early for my needs. I've have very smooth developing experience in Godot 3.5 and it definitely NOT feel anyway broken. "It's just as well to change engines, like we did." Changing engine is dumb. It is best to postpone engine selection as long as possible and then choose what is suitable for project and schedules to avoid unnecessary migrations. I'm agnostic about tools. I can develop whatever engine I like. I see that Godot can be excellent choice to some projects and some other it is Unreal engine, or Unity. I see Godot mostly fitting on those segments that were used to be before Unity's strong points, having general purpose, lightweight accessible engine. Unity's ecosystem or some features can make Godot wrong choice.

Need to clarify what I mean that Godot 3 was first to write high fidelity game... Well, development need to based on available resources and what features need to implement as Godot is more minimalist engine than example of Unreal. Back in 2018 there would likely almost no ecosystem so it would require lot of development resources. The more the ecosystem expanded, the better Godot fit for projects.

My struggle has been I don't want to write C++ and I don't want to make blueprint spaghetti. It feels like a rock and a hard place.

@@Armadous C++ is not hard, believe me, I have gone to tutorial hell much much worse than C++. You should find a good source on c++ and just start building shit, I have only been using c++ for two months, yet I already built a rest api, with a database, including many libraries in my project. And I'm planning on using this knowledge for game dev later.

@@Armadous C++ is a bit scary at first, but if you already program in C# it's not that bad. I'm still learning it, and it will take a while but it's not as bad as I thought. I didn't think I would like blueprints either, but so far they have been fun, granted I'm not making some crazy large game. I will say so far the UI tools are the hardest for me to grasp and being used to prefabs it's really tough to grasp that concept in Unreal. I guess it really depends on your skills and the game you're making. If you're a solo dev and are making a single-player or minimalist multiplayer game Unity will do just fine. Oh, and one more perk about learning C++, it's used in most other engines, and is kind of an industry standard so you could expand your options that way too.

@@lazyh0rse C++ is verbose and error-prone which wastes time. And the docs for Unreal are bad from what I read.

@@abc33155 it's more verbose, but the verbosity actually make more sense when you use it a lot. It gives you more control, thus more performance, 2-5x while being efficient in power consumption. It's not a lot of work, it just needs a bit more getting used to.

It was for Riviana. They used it in GDC but they haven't released it to us, AFAIK, but 5.2 released today so it is possible we will get it

@@DavidMaclin351 thanks for the info, that suspension looks sexy af

Which renderer code are you talking about? (a) The rendering code you can see when you install the source code, or (b) the rendering code you can see when you link your Epic account to your Github account? Neither requires a special license.

@@lillybyte maybe he's referring to Unity.

@@lillybyte I'd be surprised if it changed but I'll have to check. I'm talking about the code/shaders where the advanced rendering features like foliage and lumen live.

You are not required to only sell on Epic Games store. You just don't need to pay the Unreal engine royalties when selling in the Epic games store, but you can at the same time sell in any other storefront. By default, there is no exclusivity agreement on where you can sell your game.

@@CyberWolf755 THANK YOU!!

Yeah, exactly. I'm very interested on creating some experiences in web browsers but I realized that there is no easy to do this. Some articles mention pixel streaming but looks like web browsers won't be able to run UE projects anymore 🥲

You godot fan boys should spend more time making games and less time evangelising the engine. I am yet to see a proper game made in godot.

​@@leeoiou7295How is gunting evangelising Godot?

I'm here not fanboying anything. Just pointing out how trivial it is to prick open Godot package since all the steps is all there. Which might not sit well with some industries who don't want it.

as someone who uses a heavily modified version of godot 2.1.6 and dislikes all the newer versions as i feel like godot is going in the wrong direction. i'm not sure that's a reason why unless they are using the older version. but the newer versions of godot lets you encrypt gds on export and even the pck instead of just a binary export. however, you are correct since it's open source and there is the gds decomp repo too. it won't be that hard to get your hands on the source. but it will still take a good amount of effort. you kind of answered the question yourself too. the dev could fork it and write their own protection/algorithm system. i do believe the newer encryption features are more than merrier though. it's not really about that, it's just godot 4 is finally starting to render 3d really good now, when wave racer looked better than any of its previous versions. and then there's the "waiting for godot 5, 6, 7" bs as well. there's also a huge influx of bugs and just issues everywhere. the engine is constantly evolving and changing to meet the needs of the "supporters" who "fund the project" cough cough. and it's also becoming bloated af. it's also a function of time, it's going to get worse. game devs spend more time reporting issues on github instead of developing their own game too. i could probably write a book about all the buffoonery i've seen for the past 8 years. there's a ton of reasons, but the lack of encryption isn't it

@@chocolatecoveredgummybears That community fault, they always want feature, even then compared to unity or unreal the file size is nothing. If you only need 2d you can just build it from it with the feature profile, and bugs, it happens with every engine, i remember having ton of bugs with unity and unreal rendering was broken at some point and too laggy.

That's what I'm saying. Unreal is not hard. It just has a poor user experience. The c++ in unreal as well as the other tools in unreal are quite easy to learn. The engine is simply bloated and clunky. IT crashes often too. It requires patience. Unity hides a lot of all the extra stuffs in its package manager. This is the reason unity will always be more widely used than unreal, even though unreal is a more feature packed engine.

Hmmmm.... to be honest I'm not sure. I would assume it's net company revenue earned using Unreal, not per product, but I'm guessing. It's an interesting question, but I doubt many people are going to make multiple 1M+ earning games per year.

It's per-game, AFAIK. So, let's say you have two games made with UE. If Game A is making above $1M and Game B is making below $1M, you "only" have to pay 5% of the gross lifetime revenue (after the first $1M) of Game A. I believe, though, that you also need to include other sources of revenue that are related to that game in the equation. For example, if direct game sales make less than $1M but the added revenue of DLC, in-game advertisements, or even crowdfunding campaigns, takes you above $1M, you still owe Epic the 5%.

@@plotlessplot Thank you -- and I did not think of indirect revenue like DLC and ads.

Nah it's in there somewhere, just didn't get it's own category. Think it might be under the Marketplace category, either that or under pricing.

Yeah it will run it.

Bruv, I ran UE4 on a GTX 960m from 2015. You can run UE5 no problem. I have the same RTX 3060 GPU at my work laptop. If it gets choppy in the editor or you just want a smooth editing experience, just lower the graphics settings in the editor. Most of the time, you don't need the graphics turned up to max. Lumen would be the most costly setting, so turn it off if you don't actually NEED it or lower it's settings. You don't need to use all the fancy UE5 features, the older UE4 ones are still there and look great. Example of UE4 graphics is that Star Wars Jedi Survivor still runs on UE4.

it surely can it not an igpu.

Let me give my opinion from experience using both Unity and Unreal. Unity Engine is a feature that supports the engine itself, and at some point, it runs into limitations in creating high-quality games. Therefore, R&D is performed to implement the function directly or related functions are found in the asset store. However, since the Unreal Engine already supports a considerable level of advanced functions in the engine itself, it is not necessary to look for related functions from the outside, and the engine's functions can be easily implemented by modifying them with a little R&D. Therefore, beginners who are new to the Unreal Engine have a lot to study about the Unreal Engine and are required to understand the function of the engine at a higher level. That's why beginners find it difficult to learn Unreal compared to Unity. It is also the reason why beginners like Unity, which is easy to learn.

You absolutely cannot get the same results from UnityHDRP. Nanite and Lumen are the obvious headline features that Unity has no equivalent of, but there are so many other rendering features that Unity either lacks, or has a lower quality version of.

@@daveface69 Unity is behind unreal in many areas especially rendering. In terms of AR/VR non-gaming apps, architectural workflow and flexibility, Unity is superior to unreal.

@L DEV Lol. I don't even consider godot a professional engine yet. Maybe in another 4 years time.

And using Godot it runs lower end hardware, it is capable of doing highend graphics(*) and Godot 3 is not buggy, not sure about how buggy Godot 4 is because it is so new but is enough good to start project that is aimed to newer APIs. It is constantly improved. (*) And that highend graphics, everyone should know that engine isn't much limiting graphics quality in any modern engine. It is dependent on artists and workflow. Older engines like IdTech 3 had limitations that are visible in games.

@@leeoiou7295 Why Godot is used AAA game development if it is not professional engine?

Why do you say that? What about unreal would make it more difficult for someone with a small amount of resources/experience compared to something like unity?

@@bmhyakiri every new unity project starts with blank state and you add on package / 3rd party asset as you need. For Unreal, every heavy package is there at the start. You can be overwhelming if you do not have experience. Unreal requires both knowledge of c++ and blueprint to make a game, while Unity only requires C#. In short: Unity gives you the lightweight option, if you want your game to look beautiful you need to add more. Unreal gives you all the best possible abilities that turns your demo beautiful at the start. But you need to work more to make it optimized (this is why the experienced team is required).

@@JumpCatStudio102 makes sense, thanks!

Verse isn't available outside of Fortnite for Creators yet. I think I mentioned C++ but I didn't make it a category

He said at the start of the video he's going to focus on the engine's strengths, not weaknesses. Therefore C++ wasn't mentioned much :D

@@LudvikKoutnyArt C++ is a huge strength for Unreal; It doesn't matter how people feel about the language, it's the industry standard for game development and being relatively illiterate in C++ means the vast majority of libraries, engines, code examples, and literature on game development (especially game engine development) will be mostly opaque, black boxes. Also, performance matters for game development so having a proper systems language is vital to being able to fine-tune performance. So if learning Unreal requires that you learn and become adept at C++, great. You finally know the language that all major, popular game engines are written in.

@@xfva_166 It's a weakness that it's the only programming language available, other than blueprints. I agree that understanding C++ can be very useful when learning about game dev, and it allows you to get closer to the metal than other languages when you need it for performance. The thing is, even when I know C++, I'd prefer to avoid it when possible in Unreal; I'd prefer to avoid stuff like the long build times, and how easy it is to leak memory. I'd especially like to avoid Unreal's half-documented, templaty flavor of C++. The other two engines in this series also allow you to use C++ when you really need it. Plus they have other options for when you need to make every nanosecond count. Unity has Burst with HPC#, and Godot has a wonderful extension system that allows you to use something one may prefer to C++, like Rust. Also, many parts of the code aren't that performance sensitive, and those parts benefit more from friendlier languages. Instead of C++ being something nice and useful when you need it, in Unreal it becomes a bit of a cage. I'm excited about the future possibilities of Verse in Unreal, though.

I totally agree! In fact when developing game, please postpone engine selection as long as possible! Most of the work happens in modelling software, gathering all required assets and planning how it should work. During that time there may be new version of every engine, plans and requirements may change so migrating newer or other engine is just waste of time. There are examples of game projects that are failed because developers have changed their engine two or three times during development without any revenue.

that's a fair point that everyone seems to be missing

There is an option to buy a special license for fixed amount available. So if anyone sure there game will make a biggest hit. Then just buy that license (cd project red did this for their upcoming games)

@@MalayalamTechMaster Not sure how realistic that is for solo devs or small indie teams. They don't have the same negotiating power as CDPR. But if that is true and available for all - and if the price is competitive with Unity Pro - then that is good news!

People don't necessarily have to switch, but everyone should at least learn their way around all 3.

Yep, video is up now. Busy UE day here on GFS... ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-bzm45PcgUJ8.html

Actually... Unity has a Lumen like realtime GI solution coming in the next tech stream and Ziva is basically their equivalent to MetaHuman But to straight up answer your question, you'd have to read the license for UE source access. It almost certainly has limitations for exactly this task. That's a big reason why it is source available instead of open source.

@@gamefromscratch Nice with some upcoming solutions, but as far as I can tell Ziva is more of a: Swizz army knife for hollywood where metahumans have a way more narrow focus for game dev. Also where metahumans is free, Ziva is not.

If the Sim version was affordable, it would be able to make UE a run for its money when it comes to large scale world projects.

Unigine is so underrated. The guys behind that engine are pure wizards

I would make the argument that Unity's Asset Store is as big as it is because it's trying to make up for the myriad of shortcomings in Unity itself. Combine this with the "shovelware" aspect of a lot of the assets in there, and I'd say Unreal and Unity are more in parity than not.

@@ZebulonsPi Not sure I agree with you there. I feel that Unity's editor is far more customisable allowing for far greater flexibility for content creation. There are a huge amount of assets that make use of custom editor interfaces which allow for a tonne of functionality which I have not seen much of in the Unreal engine. The Asset Store also seems to be far more affordable. Even when comparing like for like from the same content creator the Marketplace can be 50% more expensive which is a huge turn-off. Unity, as of the last 12 months (give or take), have also been going crazy with sales. I know Unreal do much the same thing but Unity has been absolutely killing it by comparison in my opinion.

@@odo432 Yeah, I can see that. It’s certainly possible that I just haven’t seen all the customizable aspects (or lack thereof) in each engine, so I’ll go with your view on that. A lot of what I’ve experienced from the Unity side is either a lot of things that you’d think should be a part of the engine sold separately by a third party, or just things that look really amateur. It’s certainly possible I’m missing the good stuff! I haven’t bought anything from the Unreal Store, just collecting the free assets, so price wise I don’t have any input. I WILL say that if you like Synty Studios stuff, but it from their website!! They give you BOTH versions, Unreal and Unity, whereas if you buy it from an engine’s store, you only get the one. That’s burned me on a couple of things!

I would pick Godot for 2D and most likely mobile and web. Unreal is excellent for 3D where you need console exports too.

More like pick Unreal for 3D where you have the funds + experienced devs.

i cry then i use cry thats my religion

2D project

2D, Web, C# preferred, overkill, possibly a bad economic choice, bad fit for certain game genres with it's FPS/TPS first design pattern, etc. There are a plethora of reasons why... and why not.

Those photoreal asses are kind of tool to reduce some costs and most valuable are some generic Quixel assets and Metahuman. Of course game specific assets need to be created and many more to avoid that all games didn't look same. It can be hard fork to make all assets to match in photorealistic fidelity.

why wouldnt you use ue5? i can't think of a proper reason

Why do you say that??