Making the same game in Godot, Unity and Unreal. Cowboys, bottles and ragdolls yay Link to Discord: / discord Links to me: www.fabianvelander.com/ / fabianvelander
My experience with Unity over 2 years: The feature you want has two official plug-ins, one is deprecated and the other has been in alpha for several years.
There are also third option. Write your own tool for thing what you need. I am working on a space sim game in Unity because writing tools is hard in Unreal and almost non documented and my game requires custom tools to make it so i am stuck with Unity :P.
This is true. That's why you either try and find something 'good enough' on the asset store (to gut and repurpose, usually), or DIY it. Also, can someone explain why the heck Unreal uses block coding??? What is that unholy abomination?!
2:34 For the ragdoll in Unreal Engine you don't have to scale the model. In the physic section you have (min bone size) that you can reduce so It can detect all the bones.
@@Waffle4569 it actually makes sense You have a flesh meat suit container that is 10cm by 5cm your minimum bone size is set to 5cm, at most your flesh suit can have two bones in it, if you try to cram in more bones then the bones will have to either overlap or explode out from the flesh suit. so you make the bones smaller or make the flesh suit bigger. Basically its not a "default behaviour" they just expect you to be making bigger models so the default bone size is THICC Another way to look at it is unity and godot dont have "bone size" as an option so while you dont have to set bone size you also lose any functionality that relies on said bone size (though thats a stretch and a half but still valid)
@@MrTeathymelet's say you have facial bones, those are pretty small compared to the others and your don't want them to ragdoll so that's actually useful to have that option
@@MondyTS That's a great example! But yeah this kind of thing is why I always prefer the overly complicated tool (as long as that complication comes from having more dials to turn) Sure having to do more stuff manually sucks if you just need something simple, but id much rather take some annoyance that I can make relatively painless through practice or even templates/macros, than slam head first into a brick wall when the "automatic bone scaling" wont let me do the thing I want to do and im just wishing I could turn the dial. I think of it like an automatic vs manual gearbox, the automatic is really nice for driving around day to day because you dont have to micromanage the clutch and pay attention to rpms etc. But when you try to climb that steep hill youre gonna be wishing you had some level of manual control so you can keep the rpms high
Really great video! Perfect example of how engines are simply tools, it's all up to the developer to use the tool to the best of their ability. Every engine nowadays can build any game you can think of provided you have the skills to make it.
You could give it a try to Godot it's really good to support some free and open source engine, just one video would be enough then you can carry on with your unity tutorials.
i will not call is simply tools, i will call it a set of tools, and some time the engines have the 2 of the same set of tool for the same use, and it can be confuse which set of tools to use and what the diff of the set of tools, in the end as you had say it all up to the game developer to know what tools is there, why and how to use them.
The default shadow settings in Godot can look pretty bad, but it's actually not hard to make them look good! 4.0 is better too, but with some tweaking I have better defaults I use for my projects in 3.x and it's great
Great video. It always drove me insane when people use "It's made in x Engine so it's bad" argument. As my dad always used to say "A bad carpenter will blame his tools".
@@serendipinator a home owner doesnt use the tools... the carpenter does... hence the game developer... hence the person going on twitter complaining (the game developer)
@@serendipinator the guy on twitter is a developer tho. And you guys really should watch his response videos before taking conclusions. I know this is a "touchy" subject, but exceptions apply. really looks like fabian did this vid only to get clicks, as there were barely any research at all put into the situation
not really best engine depends on whether you have access to a good artist, unity needs no good artist cause its shit, unreal is amazing when you got an artist
nope. moved from construct to godot and its miles better. And I used it for 2 years. It isn't so black and white, and there are some engines unfit for certain tasks. Most important thing is to at the very least be aware of the capabilities and weaknesses of most engines.
@@Chris_t0 Iam not too familiar with unity, but as far as I know only significantly superior aspect of unreal is how it handles lighting and reflections, but physics are pretty much the same, so when you import high poly models from blender there is very little difference between the two. Correct me if Iam wrong but a skilled 3d artist will make your world look better regardless of what engine you are using.
A perfect video that explains how engines don’t actually affect how your game plays out and it’s almost always on the dev’s part. Just like how you could have fixed the shadows by tweaking a few variables from the project settings or used baked lighting :)
There is some impact an engine can have, look at all the mmo's made with UE3. Notorious for having technical issues. Or look at the lumberjack engine, Amazon has 0 good games thanks to it..... ok.. maybe not just the engine here.
@@vadeka that is false. Most of these games have issues due to terrible support from the developers and Lumberyard is not widely used nor supported. Blame the developer; not the tool.
I'm sure Fabian knows this but the units in Unreal are centimeters. In Unity, Godot, and Blender, they at least default to meters. Hence the 100x difference for that ragdoll :)
What background was the person who first decided that standard units should be centimetres? Engineers work in millimetres and physicists work in metres as standard and both limit themselves to multiples of 1000 if they use something other than standard.
@@rossbatten2912 Easy answer, in Unreal Engine 1 and 2, the engine was not using centimeters but Unreal Units. When Epic games developed their first game in the engine, they used scales in Unreal units that were close to inches. A human sized door in Unreal was usually 96 UU tall and a human character was 72UU tall. When Epic games started thinking about the archviz market they decided to use metric units and chose the unit that was closest to how the were using the old Unreal unit; centimeters.
With Godot's shadows having that gap, Im pretty sure you can fix that by tweaking the bias setting in the inspector. And Godot's GIprobe makes the default shadows a lot nicer.
I don't really keep up with development in too much detail, but _IIRC_ this is an issue with the default shadow bias in Godot 3.x, basically in many cases you end up needing to tweak the bias as you say. Godot 4 handles shadow maps completely differently by default, so now light leaks will almost never happen with no tweaking required. (Then yeah, on top of that setting up some global illumination with GIProbe or VoxelGI or SDFGI (for whatever reason Godot doesn't have it on by default) would make the scene look even more similar to the other two engines, with the bounce light and everything.)
Godot users! To fix your shadows, select your light source (directional light, spotlight, whatever), go to the "shadow" section, and enable "Reverse Cull Face". Bam. As long as the normals on your meshes are correct, you now have nice shadows. Love the editing btw :D
This is probably the most entertaining take on the engine debacle. Engines are simply tools, it's how it's used that makes the difference. Also how do you only have 400 subs? That's criminal right there
About the leftmost tweet mentioned on 00:03, the creator of the video has another video where they explain the clip was taken out of context and that GMTK misconstrued them. It was an interesting video
yeah and the gist of it was that emulations of old games made by the original developer used a custom engine when you could tell they cared and unity when you could tell they didn’t care and the emulation they were talking about was in unity
@@morgan0 The video creator was wrong about a few points though, just not in the way GMTK showed them. For example, unity wasn't used for the emulation
I really hope with Godot 4.0 or 5.0 that 3D performance is comparable to Unity and Unreal, because I much prefer using the Godot engine over the other two in terms of the layout and naming conventions. Godot just makes more sense to me intuitively.
having used the 4.0 alphas a bunch, i can't comment on performance compared to Unity or Unreal, but i can say that it looks and runs pretty damn good, and much better than 3.x!
@@randomcatdude That's good. I've made a 2D game in Godot 3.4 and I have been considering making a low-polygon artstyle 3D game but I wasn't sure if I wanted to use Unreal or wait for Godot 4. The benefit of Unreal is that it's available now and works well, but I don't like the interface compared to Godot.
Wow, UA-cam algorithm nailing the recommendations today. What a fantastic experiment- thanks for sharing this with us! Working in unreal at the moment. This was maybe also a great side-by-side of learning the basics of dev in all three engines. Brilliant.
Honestly people complaining about how ‘if they had only used Unreal instead of Unity their game wouldn’t be sh**’ are the same kind of people that are also working on a 2D platformer with 3 levels and 5 different sprites but somehow manage to crash their game on the starting menu
Listen bro it’s not so easy to crash a game with 3 levels and 5 sprites, it took me 5+ years of hardcore gamedev experience to accomplish that. Tutorial engine crash gang for life!
Actually, my shitty, unfinished game is good because it's in unreal. When I port it to unreal engine 5 it breaks everywhere but it becomes better because it's in unreal engine 5 (which is a good engine). Hope this helps!
Remember to drag and drop some arbitrary Quixel® Megascans™ to your shitty, unfinished game. After that, spend some time picking a nice island in the Pacific that you'll buy with all the incoming profit.
Okay, I just discovered your channel with this video (and wandered around on other videos like the Ball game remake and a few of your devlogs)... And I don't know what happened between these videos and this one, but you seem to have understood how to make good videos in a WEEK or two, with a nice rhythm/flow, good quality video and audio, the video is fun to watch, the background music is cool, fitting and perfectly integrated... It's just all really nice ! I hope you'll keep on doing these, you got my subscription ;) Have a nice day !
props for going through all that effort to prove something that every game designer could tell you, but most gamers or aspiring game devs won't believe with just words alone.
I'm litterally a game dev and I can tell you the players are right on this one, he just doesn't have that much experience in Unreal and thus confirmation biased his own findings by fine-tuning it in Unity. Unity is extremely poor when it comes to base optimization and you have to put in a lot more time into solving that AND making the game look good when it comes to that. You can tell a game's engine just by playing on it for a few hours, even amazing ones like the Forest still shine that Unity *grime* once and a while- and the devs worked extra hard fixing that when they could've had it not be a problem to begin with if they used a better engine like Unreal.
I knew this stuff before, but players talking about engines dont come out of nowhere, theres usually (and sometimes misunderstood) experience behind it. So the question is, why do different games in the same engines often have similar patterns? Like, you know, how most Unreal Engine 3 games had really shitty shader effects, depth of fields and desaturation effects. I think certain UE games als had very strange dimensions to players and environments. Some also had unbelievably bad texture streaming. Its most likely devs being lazy and using stock assets/features/whatevers, and we can still blame them. And sometimes devs just miss the point, ive experienced that as well. Like when they say Total War Games since Empire dont all use the same engine. Or that Bethesda isnt using the Gamebryo engine. Like during FO4 announcement, devs were desperately trying people its not "Gamebryo", when its clearly a development on it, even casual gamers could tell. Like no shit, of course it got upgraded and modified. But we also got the same problems and bugs since 10+ fucking years Mr Specialist, so dont tell me there isnt a problem. Thats imo a way more interesting part of that discussion. Sure devs arent limited by engines, but why are they limiting themselves, and why are they sometimes just not fixing problems? Why can I then tell what engine a game uses, when its not that relevant?
Game engines have differences. Neither Godot nor Unity can achieve the graphical fidelity of the UE5. Especially not the Nanite (fluid LOD) part. Only the Cryengine can visually compete, especially in the lighting department, one of the Cryengines biggest boons. But again, no Nanite. Godot is also graphically inferior to Unity. The code is simply yet not writen to compete. If we would want to go 1000% visuals here. Not every project need RTX to the Max though etc. I hope you get my point. The main problem and with gamers is Engine Repuation. And Unity has a very bad repuation, mostly because of the billions of asset flips released in recent years. And practically all Unity games i know of, have performance issues. But since Epic released the UE4 for free, or as i call it, the Blur Engine. All the Unity known issues now also apply to the Blur Engine 4. Too many developers haphazardly just used that eninge without knowing what they were doing or simply didn't give AF. And the games do not look good, and run really poor. In combination with tons of bugs. Look at Ark Survival Evolved. What a mess of a game. It took years before the devs gave AF that 200MB small Game Patches don't need a full game download anymore... Im at the point where i believe most bugs, come directly from the Engine itself. I say, the Unreal Engine 4 is buggy. And until someone proves me wrong, i have no reason to believe otherwise. Because with every new UE game released, the same crap can be seen. There is simply no way every dev outhere does the same mistakes. This has to be Engine related. Not to mention Epic fixed a glaring issue in the UE3 at the end of its life cycle. That was Object Shimmering/Fresnel like Effect in dark environments. They statet this explictly in their UE 3 Patchlogs. And as soon as the first UE4 games came out, this Object Shimmering was back, full F. force! And they never fixed it again. What i have seen and experienced so far with the UE4 is, while it can deliver greats graphics. It has massive issues the UE3 simply did not have. The UE4 is bloated... Editor and Engine instabilities is one of it. And as it seems, most developers don't even understand half of the Engines settings. Thats why all UE4 games look the same and are blurry AF. You can see at first glance when a game is made in UE4. Till 5 years ago, Frostbite, UE, Cryengine, Untiy etc. Every game looked so different, people could tell by looking at the game or even game trailer which Engine they were made with. It was rather easy to spot. Frostbite was the most obvious.
Loved this, I have tried doing some engine comparisons like this myself, in the end the main take-away is that different engines have different workflows. They can produce the same result so pick the workflow that suits you best!
"Slerp" is shorthand for spherical linear interpolation, a well known term in computer science. Unreal: "RInterp To". I feel you man, the naming convention in Unreal is unreal. And the material editor has a different convention from the Blueprints, just to irritate people a little more.
lol I was gonna mention the material nodes before I read the last line, I really hate how the nodes visually say something different to what theyre actually called, for example Masks are shown as "Mask (R G B)" but the node is called Component Mask, not the best example but basically
@@DJL3G3ND You may spend hours searching for "node" because the nodes in the material editor are called "expressions", and the "nodes" are what others would call the material's outputs. 🤦♂ One of the UV texture nodes, the one that clips the sides of a texture, forgot the name. It works so bad to the point of being useless. Instead of being normalized 0~1, where you input 0.5 to get half the texture, it scales the texture coordinates, so to get half the texture you input 2. It's not too hard to make the calculations manually, but then what's the point of having a node? And the name (it's killing me that I can't remember) didn't allude to this at all.
I've seen another video on this topic. In that video they said that the only difference between engines are the default values. So yeah.... If you see some game and immediately can tell "it's made in X engine", that means that the developer didn't bother to tweak the values to make something of quality.
Although idk how, I can just tell if it's an Unreal game even if lightning is tweaked. Recent example is I saw gameplay video of new game Stray, I instantly got a feeling it was made in Unreal. Do they have something weird with lightning? In star wars, Bioshock Infinite, Borderlands all have very different lightning yet they're so unreal like. For unity, No need to explain further. You know.
Really enjoyed this video! 🙂 It's never about "which engine is better", but rather "what engine best suits your needs". It's too bad that people have to associate the quality of a game with the engine it was made in, rather than it being about the person who made the game.
I have worked with Unreal Engine professionally, and have used Unity extensively in my personal projects. Both engines are very good. There ARE some differences between the two engines, especially with workflow, however, these are tools used to create games are their limitations are based upon the skillsets of those who are using them. This argument regarding these two game engines (I have never used Godot) would be akin to arguing whether 3DS Max, Maya, or Blender create the best 3D models. I would equate Unreal engine to 3DS Max and Unity to Blender. Unreal has its way of doing things and has been an industry standard for many years, just like 3DS Max. Blender has a different workflow and is very open to user plugins for different systems, the same as Unity.
Would you say, that one of the engines is faster to create good games with for indie developers? I know Unity is faster to prototype but surely to make a good, modular game unity isn't necessarily the fastest to produce games with.
@@SanityRblx Unity is well known for its ease of use for indie development. The main reason is how quickly you can prototype a game and get it going. Unreal's biggest fault is its learning curve. It has a very specific way of doing things. Unity, on the other hand, is quite simple to learn. I would say this, if you are wanting an engine to support cutting edge graphics, or photo-realism, then it would be easier to learn Unreal and go that route. However, if you want to build a game faster and are a programmer, then go with Unity.
@@G33kFr33k Thank you, I'm a C++ developer and the learning curve is not an issue for me as I've studied systems more complex than game engines. As I do not wish to break into the gamedev industry, I do not care for whatever framework is used by industry giants. Just wanna do my own thing, so unity seems great. But I must say I find the unreal engine workflow incredible, it really is, the mixing of both blueprints and c++ and all the macros and events and whatnot. If I wanted a real job out of gamedev, I'd definitely take unreal.
@@SanityRblx I absolutely agree. I was a C++ developer for many years. I love C++. C# seemed very limiting to me, but I eventually grew to appreciate it and love the workflow. I really enjoy compile times in C# as compared to C++ ;P The main reason I use Unity is the licensing cost, the modularity, and the ease of creating engine tools and systems.
I was thinking about starting a game jam called `engine hopper`, the developers would make any game of their choosing on as many engines as they can, in one month, and share their experience alongside their games. But me being lazy, I've abandoned the idea halfway because I couldn't be bothered to set up the page. You should host such a jam.
Everytime I show a gamer or 3D artist friends my game prototype: Friend: "What engine did you make that prototype in?" Me: "Unity" Friend: >:O "Why not Unreal?" Me: -_- Don't get me wrong. Unreal looks great, Unity is just my preference right now.
"because I value my sanity" Unreal is great when you know Unreal. Unity is great when you are interested in just making a game. I've been working with Unreal for 8 years. I am still fighting Unreal every single fucking day
I'm a hobbyist developer. I've never actually published anything I've made, but I have tried many different engines and I always go back to Unity. Things are just generally easier to implement and there's not quite as many quirks that hinder your development (there still are some, but way less in my experience).
@@MrERJ1992 Well yes of course, do what's best for you and your project! I'm just referring to people that make that comment after I say we're using Unity. Most of them are not mean, just curious I guess, so I was exaggerating a bit in my previous comment (for fun) but it becomes a bit annoying to be questioned with engine choice after a while!
@@LoneWolf6063 I'm not here to continue any engine war haha, use whatever you like more. Some things are better in one engine and other things are better in another engine, all have their pros & cons. The whole purpose of the video was that you cannot say "one is better/easier then the other", it’s not really about the engine but much more what you do with it :)
As an avid Unreal user and fanboy, this seems pretty dead on to me. I think Unity is pretty darn good but not for me. I am a bit of a power user, doing C++ changes to the engine and have other personal reasons to prefer Unreal but that skeleton thing cracked meup. I work at a game dev studio and have seen issues with the skeleton physics.
You bring up a good point in your comment too about the scripting language. One of the biggest reasons that I prefer Unity is that I am way more fluent in C# than C++ so it takes me way less time to implement something. Not that I couldn't learn, but I'm just so comfortable with C# and prefer it.
@@prateekpanwar646 Unreal's "flavour" of C++ handles memory management for you. You declare your properties as UPROPERTY and then it's automatically reference counted.
@@prateekpanwar646 Unreal comes with a garbage collector and reflection system. So any UObject (basically the most basic Object Type in Unreal Engine) is garbage collected, and if a pointer is marked with the UPROPERTY macro it will automatically null itself when the object it is referencing is destroyed. So the only thing to get used to is the syntax of C++ and some best practices. In general the modern C++ isn't as scary as people make it be and Unreal makes it even easier because it gives you enough abstraction to not have to deal with the difficult part. For more basic types you also have various smart pointers, but usually you only need such things when you do stuff outside of gameplay programming.
Honestly, most games apart from super indie games are going to use custom shaders too, so they'd look the same across all three engines as well. It's really not until you get into super resource taxing games like open world games where Unity and Unreal really start to show their differences.
Yes! Yes! I'm making an open world games using HDRP in Unity and Unreal 5 has this new tools and stability that confuse me! Do not know to migrate or not. " really start to show their differences." Do you know this "differences"? can you expand on this?
@@Domarius64 Unreal is pretty openly supportive of open-world style games. Their proximity loading techniques require very little programmer interference and simply... look and perform better than any competition. Having a game where models don't clip in and out of view really helps for open-world games, and its "free" in unreal.
This is a super well made video, thank you. The engine wars have left many gamedevs with thousand yard stares as people yell at them about things they think they know better edit: greatest outro ever no competition
I feel like knowledge a d experience of the engine, just any other tool, is more important than the engine itself. Like, I know that to fix the rag doll problem in unreal you just change the min bone size and it'll detect all the bones instead of just two, but I probably would have a much harder time doing the same thing in unity.
It's not often that I comment on a video, but I just want to say keep it up! I love the way you present, very entertaining and informative at the same time.
@Evi1 M4chine Almost no material system seems to have a "standard" that can be imported into a game engine, there are certain similarities in 3D software to make shaders using a node system BUT the closest to the regular thing I have seen is UE4. Unity has its own fricking way of handling nodes to make shaders, the ones that come with default projects may seem enough but have some limitations or quirks, for example, in Unity standard shader there is only one "slot" for roughness + metallic which requires you to mess around with color channels in your image editor to get something of use.
For the record .... when exporting to Unreal Engine from another software, you need to set the scale to METERS and the value needs to be 0.01. Unreal Engine is in METERS. You CANNOT just set it to Centimeters and export. It MUST STAY IN METERS. That will fix the pivot points on your bones 100% of the time and you will not have to increase it to 100% then reduce it 100%. Just keep it in METERS and 0.01 before exporting.
@@palmzmetal9131 It's true for anything being exported to Unreal. Rather it be Blender, Maya, Houdini....they will all need to be in meters and set to 0.01 if exporting to Unreal and the scale to be fine. Such a small thing that fixes so much. LOL So many people think they can just use centimeters and while that makes logical sense, it just doesn't work that way.
@@mattmurphy7030 That is news to me. Do you "have to" or have you not tried "meters and set to 0.01"? I've exported from solidworks with the "meter" option and variable and it worked fine. Albeit 4 years ago. LOL. Something could have changed since then> If you did try the meter and 0.01 setting and that didn't work, then that is good to know.
In unreal, by default the sky is partially colored by the directional light source, which is why you couldn't completely change the color. Hope this helped :)
Awesome video!!! I really liked the comparison you made and tbh, at the end with all the games scaled down side by side, I couldn't tell the difference between them lol. Also that unreal scaling issue got me so bad too.
The bloom and auto-exposure you said you were experiencing is due to the project's default post process settings. You can either edit these in Project Settings -> Rendering -> Default Settings or you can also manually override them by adding a post process volume to your level and enabling the infinite extent property, so that it affects the whole world. You can then disable or tweak the undesired post-processing features. Under the Bloom section you can set the bloom intensity. Under the exposure settings, you can change the metering mode to manual and then set the exposure compensation to whatever you like.
Love the humor. Love the dry serious nature of the humor. This is a very humorous video. It made me laugh. I was also impressed that a human can understand Quaternions, but this was a funny video.
I love using Unity. Lots of good and unique games have come from it. Hearing people say stuff like "Unity sucks cuz it's bad and Unreal is better" is just frustrating. It shouldn't matter if it's free, popular or easy to use. It's a tool that can make decent games.
Gamers are consumers and they dictate the rules. Unity has a bad reputation because of asset flips and trashy horrors. Unity developers pay to remove "made in Unity" splash screen and that's a sad fact
I would preface all three of those with "out of the box." You can get comparable performance on all three of those topics in all three engines. They just cater to some things more than others out of the box.
Whole reason I go with unity is performance, unreal looks nice but it will ruin older computers and often times the size is much larger than unity when exported to final project. But yee if you want the best looking thing go unreal, if you want performance and space efficiency go unity, :p
@@jondro6284 C++ may be faster, but Unreal is a massive engine with a lot of overhead, and fundamentally they aren't targeting low end platforms so they don't put much time in optimizing it for non gaming hardware.
@@Waffle4569 the complexity of the engine doesn't influence the game much, unless a dev is lazy enough to leave crazy out of box postprocess and code in blueprints. And Unity literally doesn't support old AMD GPUs. Many of my friends have weak PCs and we like to play small coop games which are almost all made in Unity. But we can't anymore, games made after ~2017 inevitably crash after a few minutes of play
well, in my opinion (tried both btw), Godot has a better 2D engine than Unity, but in 3D, Unity is definetly better that Godot. Godot works kinda faster in both compiling and you know, Unity loves to check the code every 2 mins and make you wait for about 10 seconds. So use the engine that suits what you want, 2D? Godot will do the job. good 3D? Unity is so good in this, even graphics. some awesome graphics and lighting? Unreal ofc
@@Barnaclebeard The technicals should matter to you way more than the ethics. Are you going to not use a powerful screwdriver perfectly suitable for building your chair, just because it was forged by an asshole?
i'd like to mention that the upcoming godot 4.0 will certainly catch up pretty well with Unity in terms of 3D it's much more performant and capable of good graphics
@@randomcatdude i actually heard about it, and I'm excited for it, but at the end of the day, the hard part about learning gamedev is HOW to make a game, and not WHAT to use to make a game, once you learnt how think like a game developer, switching wouldn't be hard imo
Awesome, love this so much. Also, I've got an idea. We should have a massive game-dev event thing where game-devs represent their engine of choice and they all try to get the same result and make the same game. We only saw 3 engines in this video, but there're so many more engines like Roblox or Game Maker that I'd love to see have the same end result.
This is such a great video. Basically proves the point that all the engines all have their annoying issues along the way but come to the same final destination
The "you can do anything in any engine" take I'm seeing a lot here is pretty uninformed. You can _eventually_ amass a million dollars working any job but it's going to take a lot longer to do so as a McDonald's cashier than as a doctor. Same with engines. Nanite is literally just a checkbox you tick that allows you to immediately start using a virtually unlimited number of models. Unity simply does not have anything close out of the box. So now you have to go and learn ECS/DOTS or whatever which completely changes the way you program your game. Network replication is built in to Unreal. Unity at the moment doesn't have a stable, non-deprecated networking solution so now you have to go hunt around and figure out if you want to use Mirror or something else. And so on. Of course on the other hand, if you want to make a mobile, 2D, or VR game, you'll probably have a quicker and easier time using Unity. So yeah, each engine has its own usages but to say that they're interchangeable is just wrong; you're going to save literally thousands of hours by using the engine that's better suited to the type of game you want to make.
just a (not so) little note about nanite : while the feature is insane, and have incredible potential, it is as of now, far to be a finished one, it has a very high "entry" performance cost, it's run pretty well on High spec GPU, but on medium/low spec GPU it's tank performance. Nanite is also as of now pretty limited, you can only use it on Non-deformable Opaque mesh, which mean, no vertex-deformation not any sort of transparency (not even alpha clipping :( ) Of course, these feature about transparency and vertex deformation are being worked on as of now .Unreal 5.1 will feature vertex deformation and alpha clipping so it'll be usable for some case of foliages, but as of now, 5.1 is a messy and unusable mess (working with it is a torture) another limitation of nanite, is the ammount of "cluster", while it allow to use immensely more polygon than even, it's far to be limit-less, especialy for foliages as each leafe of small isolated groups of polygon is considered as a "cluster" which can quickly fill up the cluster limit of nanite
It's absolutely the correct take. Unreal has some extra artist tools in its corner, absolutely. But Unity has superior development tools for engineers (particularly in its modularity). It really is down to what you prioritize or care most about. If you're a studio and want to tell your engineers "Deal with it, I want the best graphics as painlessly as possible" go with Unreal. So the take "You can do anything in any engine" isn't misinformed simply because certain engines cater to certain aspects of development more. It's as you say, go with the tools that suit your need the best. Like the aspects of Unity you say are a fault (it not having built-in network support) are also what makes it so great ~ There are different network solutions competing to be the best Unity version. Giving you greater choice to what suits your game best. Server-authoritative by default? Mirror. Easy to use but easy to cheat? Photon. Disconnected from Unity? Normcore. Expand that to most aspects of Unity whereas in Unreal it's usually "Alright this is how we're doing things, if you don't like it suck it up (i.e we still kinda use the inheritance model of programming game dev that was deprecated 20 years ago so hope you like memorizing different forced object types!)".
Nice video. I cringe whenever gamers talk shit or praise an engine. Sure, some do things better than others and each of them have their own workflow, but under the hood they are more or less the same.
Unreal gives to much assuming you don’t want to create things from scratch. I tried learning Unreal after knowing Unity for 4+ years. I wanted to create a custom character controller, but every single bit of documentation and all the videos online only show how to use Unreal’s built-in controller and how to modify it to make it “your own”. I’m sure it’s possible to make your own, but Unreal feels more like you’re building a game in a creative-mode setting where the end result isn’t truly yours.
Back in 2014 when UE4 first came out I tried it, and there wasn't much documentation on how to do things in C++ (I already knew C++). I came back a year later and it seemed like they were still pushing everyone to use blueprints. I consider switching now but your comments are making me think it is still a bad idea.
It's because everything is built on top the current controller. If you want to make your own controller you'd have to recreate root motion, animation handling, even parts of the animation blueprint depend on the existing controller.
Pretty sure you can make a blank (empty) project and do it all from scratch, and if you don't like the default character blueprint you can always make a new one, or just create a new C++ class yourself :D
In a big production environment, the designers will only use premade things anyhow. Either build in from the engine or from their programmers. The workflow is very oriented towards splitting up tasks between team members. Hence offering a visual scripting language for the "dumb" level designers instead of them writing code. Unity is more focused on smaller teams, and more flexibility for a single developer.
My experience with Unity over 2 years: The feature you want has two official plug-ins, one is deprecated and the other has been in alpha for several years.
So you're saying that there are options? :P Kidding haha
This is so Unity it hurts
There are also third option. Write your own tool for thing what you need. I am working on a space sim game in Unity because writing tools is hard in Unreal and almost non documented and my game requires custom tools to make it so i am stuck with Unity :P.
@@LukiGames0 Really? That's so cool!
This is true. That's why you either try and find something 'good enough' on the asset store (to gut and repurpose, usually), or DIY it.
Also, can someone explain why the heck Unreal uses block coding??? What is that unholy abomination?!
2:34 For the ragdoll in Unreal Engine you don't have to scale the model. In the physic section you have (min bone size) that you can reduce so It can detect all the bones.
Weird default behavior... imagine if it deleted triangles below a certain size because "oh i didn't think you wanted that"
@@Waffle4569 it actually makes sense
You have a flesh meat suit container that is 10cm by 5cm your minimum bone size is set to 5cm, at most your flesh suit can have two bones in it, if you try to cram in more bones then the bones will have to either overlap or explode out from the flesh suit.
so you make the bones smaller or make the flesh suit bigger.
Basically its not a "default behaviour" they just expect you to be making bigger models so the default bone size is THICC
Another way to look at it is unity and godot dont have "bone size" as an option so while you dont have to set bone size you also lose any functionality that relies on said bone size (though thats a stretch and a half but still valid)
@@MrTeathymelet's say you have facial bones, those are pretty small compared to the others and your don't want them to ragdoll so that's actually useful to have that option
@@MondyTS That's a great example!
But yeah this kind of thing is why I always prefer the overly complicated tool (as long as that complication comes from having more dials to turn)
Sure having to do more stuff manually sucks if you just need something simple, but id much rather take some annoyance that I can make relatively painless through practice or even templates/macros, than slam head first into a brick wall when the "automatic bone scaling" wont let me do the thing I want to do and im just wishing I could turn the dial.
I think of it like an automatic vs manual gearbox, the automatic is really nice for driving around day to day because you dont have to micromanage the clutch and pay attention to rpms etc.
But when you try to climb that steep hill youre gonna be wishing you had some level of manual control so you can keep the rpms high
@@Waffle4569 yeah because randomly deleting polygons from a mesh ist totally the same thing then not adding shapes to all bones.... fml
Really great video!
Perfect example of how engines are simply tools, it's all up to the developer to use the tool to the best of their ability. Every engine nowadays can build any game you can think of provided you have the skills to make it.
You could give it a try to Godot it's really good to support some free and open source engine, just one video would be enough then you can carry on with your unity tutorials.
i will not call is simply tools, i will call it a set of tools, and some time the engines have the 2 of the same set of tool for the same use, and it can be confuse which set of tools to use and what the diff of the set of tools,
in the end as you had say it all up to the game developer to know what tools is there, why and how to use them.
@@foreducation408 Godot is bad, switch to Bevy or something
@@foreducation408 no. Useless engine.
It's not that simple.
With some engines you will have way less problems to implement something.
The default shadow settings in Godot can look pretty bad, but it's actually not hard to make them look good! 4.0 is better too, but with some tweaking I have better defaults I use for my projects in 3.x and it's great
any pointers for how one would go about achieving that?
Share shadow settings please
shadow settings pls
and changing the bias you can resolve this
"Ain't No Rime For That!"
Very entertaining video! Cool way to compare the engines. I completely agree, it’s never really about the engine but much more what you do with it!
Where have you been? I hope all is good! Waiting for your next upload!
Codeer...I always look for your new devlogs. Hope you upload soon.
Every engine has advantages and disadvantages.You have to choose based on your game
unless its visuals, unity is dogs balls
@@simrananand9424 Check his channel
Great video. It always drove me insane when people use "It's made in x Engine so it's bad" argument. As my dad always used to say "A bad carpenter will blame his tools".
Its weird tho, because in this case its like the saying would be changed to "A bad home owner blames the carpenter's tools"
Your father is wise
@@serendipinator a home owner doesnt use the tools... the carpenter does... hence the game developer... hence the person going on twitter complaining (the game developer)
@@serendipinator the guy on twitter is a developer tho. And you guys really should watch his response videos before taking conclusions. I know this is a "touchy" subject, but exceptions apply.
really looks like fabian did this vid only to get clicks, as there were barely any research at all put into the situation
Another is "don't go blaming the toolbox, you need the right tools for the job"
Best engine is the one you are most familiar with.
Underrated comment.
not really best engine depends on whether you have access to a good artist, unity needs no good artist cause its shit, unreal is amazing when you got an artist
nope. moved from construct to godot and its miles better. And I used it for 2 years.
It isn't so black and white, and there are some engines unfit for certain tasks. Most important thing is to at the very least be aware of the capabilities and weaknesses of most engines.
@@Chris_t0 Iam not too familiar with unity, but as far as I know only significantly superior aspect of unreal is how it handles lighting and reflections, but physics are pretty much the same, so when you import high poly models from blender there is very little difference between the two. Correct me if Iam wrong but a skilled 3d artist will make your world look better regardless of what engine you are using.
@@tezwoacz Yep. You're not wrong.
A perfect video that explains how engines don’t actually affect how your game plays out and it’s almost always on the dev’s part.
Just like how you could have fixed the shadows by tweaking a few variables from the project settings or used baked lighting :)
good take
not to mention the skybox in UE4
@@fabianvelander Just delete it. Place a new sphere and material shader on it.
There is some impact an engine can have, look at all the mmo's made with UE3. Notorious for having technical issues.
Or look at the lumberjack engine, Amazon has 0 good games thanks to it..... ok.. maybe not just the engine here.
@@vadeka that is false. Most of these games have issues due to terrible support from the developers and Lumberyard is not widely used nor supported. Blame the developer; not the tool.
@@maxisjoe "blame the devs but not the tools"
yes but I feel like that there is a situation where you can blame the developers of the tool
This was fantastic, and funny as heck. Using primarily Unreal Engine, I laughed HARD at the naming differences!
I'm sure Fabian knows this but the units in Unreal are centimeters. In Unity, Godot, and Blender, they at least default to meters. Hence the 100x difference for that ragdoll :)
What background was the person who first decided that standard units should be centimetres? Engineers work in millimetres and physicists work in metres as standard and both limit themselves to multiples of 1000 if they use something other than standard.
funny enough in blender i set the units to mm and in fushion 360 the model was 100x smaller while also on mm
@@rossbatten2912 the reason it uses cm is because it's easier to specify that, for example, a wall is 40 units thick than 0.4 units thick.
@@rossbatten2912 Easy answer, in Unreal Engine 1 and 2, the engine was not using centimeters but Unreal Units. When Epic games developed their first game in the engine, they used scales in Unreal units that were close to inches. A human sized door in Unreal was usually 96 UU tall and a human character was 72UU tall.
When Epic games started thinking about the archviz market they decided to use metric units and chose the unit that was closest to how the were using the old Unreal unit; centimeters.
@@cedric7751 Goddamn Americans
With Godot's shadows having that gap, Im pretty sure you can fix that by tweaking the bias setting in the inspector. And Godot's GIprobe makes the default shadows a lot nicer.
I don't really keep up with development in too much detail, but _IIRC_ this is an issue with the default shadow bias in Godot 3.x, basically in many cases you end up needing to tweak the bias as you say. Godot 4 handles shadow maps completely differently by default, so now light leaks will almost never happen with no tweaking required.
(Then yeah, on top of that setting up some global illumination with GIProbe or VoxelGI or SDFGI (for whatever reason Godot doesn't have it on by default) would make the scene look even more similar to the other two engines, with the bounce light and everything.)
@@KillahMate yeah, its wierd there is even a thread on it where one of the devs said they look shit on purpose for what ever reason(?)
@@RADkate well, whenever something is shit and a dev says it's on purpose, it's almost certainly for compatibility reasons.
@@KillahMate thats it i guess godots standard settings are pretty low anyways tough a few easy tweaks you can make the shadows look a lot better
@@KillahMate it not by default, because then it would burn integrated graphics cards and make things so laggy.
Godot users! To fix your shadows, select your light source (directional light, spotlight, whatever), go to the "shadow" section, and enable "Reverse Cull Face". Bam. As long as the normals on your meshes are correct, you now have nice shadows.
Love the editing btw :D
This is probably the most entertaining take on the engine debacle. Engines are simply tools, it's how it's used that makes the difference. Also how do you only have 400 subs? That's criminal right there
Up to 800 now! The algorithm pointed this video to me and couldn't be happier
it's 2k already
Welp, I guess the algorithm is doing something good for once, sub count just exploded in a few days.
@@Kennedy00Louis niko
@@RenderingUser yes indeed, very cultured.
About the leftmost tweet mentioned on 00:03, the creator of the video has another video where they explain the clip was taken out of context and that GMTK misconstrued them. It was an interesting video
yeah and the gist of it was that emulations of old games made by the original developer used a custom engine when you could tell they cared and unity when you could tell they didn’t care and the emulation they were talking about was in unity
@@morgan0 The video creator was wrong about a few points though, just not in the way GMTK showed them.
For example, unity wasn't used for the emulation
I really hope with Godot 4.0 or 5.0 that 3D performance is comparable to Unity and Unreal, because I much prefer using the Godot engine over the other two in terms of the layout and naming conventions. Godot just makes more sense to me intuitively.
You could give Stride3d a try. It is closer to unity, but also way stronger in 3d than Godot.
having used the 4.0 alphas a bunch, i can't comment on performance compared to Unity or Unreal, but i can say that it looks and runs pretty damn good, and much better than 3.x!
@@randomcatdude That's good. I've made a 2D game in Godot 3.4 and I have been considering making a low-polygon artstyle 3D game but I wasn't sure if I wanted to use Unreal or wait for Godot 4. The benefit of Unreal is that it's available now and works well, but I don't like the interface compared to Godot.
@@DankMemes-xq2xm Use Godot 4 - it's in Beta now! Somewhat stable for a small project.
Wow, UA-cam algorithm nailing the recommendations today. What a fantastic experiment- thanks for sharing this with us! Working in unreal at the moment. This was maybe also a great side-by-side of learning the basics of dev in all three engines. Brilliant.
Honestly people complaining about how ‘if they had only used Unreal instead of Unity their game wouldn’t be sh**’ are the same kind of people that are also working on a 2D platformer with 3 levels and 5 different sprites but somehow manage to crash their game on the starting menu
😂😂
this hit home hard :c
Listen bro it’s not so easy to crash a game with 3 levels and 5 sprites, it took me 5+ years of hardcore gamedev experience to accomplish that. Tutorial engine crash gang for life!
Watch the video by the person who said that stuff
I think I was never this offended by something I 100% agree with! 😂
Actually, my shitty, unfinished game is good because it's in unreal. When I port it to unreal engine 5 it breaks everywhere but it becomes better because it's in unreal engine 5 (which is a good engine). Hope this helps!
What were you using that upgrading to UE5 broke it "everywhere?" I've got a 40,000 line codebase that didn't break anywhere.
Remember to drag and drop some arbitrary Quixel® Megascans™ to your shitty, unfinished game. After that, spend some time picking a nice island in the Pacific that you'll buy with all the incoming profit.
Okay, I just discovered your channel with this video (and wandered around on other videos like the Ball game remake and a few of your devlogs)... And I don't know what happened between these videos and this one, but you seem to have understood how to make good videos in a WEEK or two, with a nice rhythm/flow, good quality video and audio, the video is fun to watch, the background music is cool, fitting and perfectly integrated... It's just all really nice !
I hope you'll keep on doing these, you got my subscription ;)
Have a nice day !
Godot's defaults for shadows are a bit wonky, but just playing with the settings for them for a few minutes will get rid of that.
so glad i found your channel with this video. your editing style and humor is great!
props for going through all that effort to prove something that every game designer could tell you, but most gamers or aspiring game devs won't believe with just words alone.
Gamers love to hate the developers of the games they love to play. I will never understand it lol.
@@TwistedSisler Yeah, I really just don't get the logic here, honestly.
I'm litterally a game dev and I can tell you the players are right on this one, he just doesn't have that much experience in Unreal and thus confirmation biased his own findings by fine-tuning it in Unity. Unity is extremely poor when it comes to base optimization and you have to put in a lot more time into solving that AND making the game look good when it comes to that. You can tell a game's engine just by playing on it for a few hours, even amazing ones like the Forest still shine that Unity *grime* once and a while- and the devs worked extra hard fixing that when they could've had it not be a problem to begin with if they used a better engine like Unreal.
I knew this stuff before, but players talking about engines dont come out of nowhere, theres usually (and sometimes misunderstood) experience behind it. So the question is, why do different games in the same engines often have similar patterns? Like, you know, how most Unreal Engine 3 games had really shitty shader effects, depth of fields and desaturation effects. I think certain UE games als had very strange dimensions to players and environments. Some also had unbelievably bad texture streaming.
Its most likely devs being lazy and using stock assets/features/whatevers, and we can still blame them.
And sometimes devs just miss the point, ive experienced that as well. Like when they say Total War Games since Empire dont all use the same engine. Or that Bethesda isnt using the Gamebryo engine. Like during FO4 announcement, devs were desperately trying people its not "Gamebryo", when its clearly a development on it, even casual gamers could tell.
Like no shit, of course it got upgraded and modified. But we also got the same problems and bugs since 10+ fucking years Mr Specialist, so dont tell me there isnt a problem.
Thats imo a way more interesting part of that discussion. Sure devs arent limited by engines, but why are they limiting themselves, and why are they sometimes just not fixing problems? Why can I then tell what engine a game uses, when its not that relevant?
Game engines have differences. Neither Godot nor Unity can achieve the graphical fidelity of the UE5. Especially not the Nanite (fluid LOD) part. Only the Cryengine can visually compete, especially in the lighting department, one of the Cryengines biggest boons. But again, no Nanite.
Godot is also graphically inferior to Unity. The code is simply yet not writen to compete. If we would want to go 1000% visuals here. Not every project need RTX to the Max though etc. I hope you get my point.
The main problem and with gamers is Engine Repuation. And Unity has a very bad repuation, mostly because of the billions of asset flips released in recent years. And practically all Unity games i know of, have performance issues.
But since Epic released the UE4 for free, or as i call it, the Blur Engine. All the Unity known issues now also apply to the Blur Engine 4. Too many developers haphazardly just used that eninge without knowing what they were doing or simply didn't give AF. And the games do not look good, and run really poor. In combination with tons of bugs.
Look at Ark Survival Evolved. What a mess of a game. It took years before the devs gave AF that 200MB small Game Patches don't need a full game download anymore...
Im at the point where i believe most bugs, come directly from the Engine itself. I say, the Unreal Engine 4 is buggy. And until someone proves me wrong, i have no reason to believe otherwise. Because with every new UE game released, the same crap can be seen. There is simply no way every dev outhere does the same mistakes. This has to be Engine related.
Not to mention Epic fixed a glaring issue in the UE3 at the end of its life cycle. That was Object Shimmering/Fresnel like Effect in dark environments. They statet this explictly in their UE 3 Patchlogs.
And as soon as the first UE4 games came out, this Object Shimmering was back, full F. force! And they never fixed it again. What i have seen and experienced so far with the UE4 is, while it can deliver greats graphics. It has massive issues the UE3 simply did not have. The UE4 is bloated...
Editor and Engine instabilities is one of it. And as it seems, most developers don't even understand half of the Engines settings. Thats why all UE4 games look the same and are blurry AF. You can see at first glance when a game is made in UE4.
Till 5 years ago, Frostbite, UE, Cryengine, Untiy etc. Every game looked so different, people could tell by looking at the game or even game trailer which Engine they were made with. It was rather easy to spot. Frostbite was the most obvious.
i loved this video, youre like the perfect balance of funny and chill
new active subscriber :)
Loved this, I have tried doing some engine comparisons like this myself, in the end the main take-away is that different engines have different workflows. They can produce the same result so pick the workflow that suits you best!
The distorted "Scary Code" with Quaternions popping up is exactly how I feel whenever I have to work with rotations, PTSD ensues
"Slerp" is shorthand for spherical linear interpolation, a well known term in computer science.
Unreal: "RInterp To".
I feel you man, the naming convention in Unreal is unreal.
And the material editor has a different convention from the Blueprints, just to irritate people a little more.
lol I was gonna mention the material nodes before I read the last line, I really hate how the nodes visually say something different to what theyre actually called, for example Masks are shown as "Mask (R G B)" but the node is called Component Mask, not the best example but basically
Its not that difficult to grasp. For example "spherical linear interpolation, SLERP, is now simplified to "Rotational Interpolation"
@@Austin_Wynters How am I supposed to guess that? And how is making it longer simpler?
@@DJL3G3ND You may spend hours searching for "node" because the nodes in the material editor are called "expressions", and the "nodes" are what others would call the material's outputs. 🤦♂
One of the UV texture nodes, the one that clips the sides of a texture, forgot the name.
It works so bad to the point of being useless.
Instead of being normalized 0~1, where you input 0.5 to get half the texture, it scales the texture coordinates, so to get half the texture you input 2.
It's not too hard to make the calculations manually, but then what's the point of having a node?
And the name (it's killing me that I can't remember) didn't allude to this at all.
@@MaxIzrin yeah, I havent heard of that specifically but it sounds about right lol
I've seen another video on this topic.
In that video they said that the only difference between engines are the default values.
So yeah.... If you see some game and immediately can tell "it's made in X engine", that means that the developer didn't bother to tweak the values to make something of quality.
exept the source engine
And performance. And available tools/ressources.
@@GordonFreakman69 not anymore, new Source looks like any other AAA game
@@GordonFreakman69 Apex legends is made in source
Although idk how, I can just tell if it's an Unreal game even if lightning is tweaked. Recent example is I saw gameplay video of new game Stray, I instantly got a feeling it was made in Unreal. Do they have something weird with lightning? In star wars, Bioshock Infinite, Borderlands all have very different lightning yet they're so unreal like.
For unity, No need to explain further. You know.
really great video and very practical way to go about this comparison. it's ain't about the engine but what you can do with it i guess
Really enjoyed this video! 🙂 It's never about "which engine is better", but rather "what engine best suits your needs". It's too bad that people have to associate the quality of a game with the engine it was made in, rather than it being about the person who made the game.
The NPC turning into a failed skinwalker while testing for ragdolls was the best thing I've ever seen.
BROOO thankyou so much, this really helped and the tutorial was really easy to use as well :)
Love your style of making videos, looking forward to more!
I have worked with Unreal Engine professionally, and have used Unity extensively in my personal projects. Both engines are very good. There ARE some differences between the two engines, especially with workflow, however, these are tools used to create games are their limitations are based upon the skillsets of those who are using them.
This argument regarding these two game engines (I have never used Godot) would be akin to arguing whether 3DS Max, Maya, or Blender create the best 3D models. I would equate Unreal engine to 3DS Max and Unity to Blender. Unreal has its way of doing things and has been an industry standard for many years, just like 3DS Max. Blender has a different workflow and is very open to user plugins for different systems, the same as Unity.
Would you say, that one of the engines is faster to create good games with for indie developers? I know Unity is faster to prototype but surely to make a good, modular game unity isn't necessarily the fastest to produce games with.
@@SanityRblx Unity is well known for its ease of use for indie development. The main reason is how quickly you can prototype a game and get it going. Unreal's biggest fault is its learning curve. It has a very specific way of doing things. Unity, on the other hand, is quite simple to learn.
I would say this, if you are wanting an engine to support cutting edge graphics, or photo-realism, then it would be easier to learn Unreal and go that route. However, if you want to build a game faster and are a programmer, then go with Unity.
@@G33kFr33k Thank you, I'm a C++ developer and the learning curve is not an issue for me as I've studied systems more complex than game engines.
As I do not wish to break into the gamedev industry, I do not care for whatever framework is used by industry giants. Just wanna do my own thing, so unity seems great.
But I must say I find the unreal engine workflow incredible, it really is, the mixing of both blueprints and c++ and all the macros and events and whatnot.
If I wanted a real job out of gamedev, I'd definitely take unreal.
@@SanityRblx I absolutely agree. I was a C++ developer for many years. I love C++. C# seemed very limiting to me, but I eventually grew to appreciate it and love the workflow. I really enjoy compile times in C# as compared to C++ ;P
The main reason I use Unity is the licensing cost, the modularity, and the ease of creating engine tools and systems.
I was thinking about starting a game jam called `engine hopper`, the developers would make any game of their choosing on as many engines as they can, in one month, and share their experience alongside their games. But me being lazy, I've abandoned the idea halfway because I couldn't be bothered to set up the page. You should host such a jam.
I actually love this idea
This was worth watching, earned a sub. That ending was gold man.
I've always wanted to do something like this! Very well executed comparison!
Everytime I show a gamer or 3D artist friends my game prototype:
Friend: "What engine did you make that prototype in?"
Me: "Unity"
Friend: >:O "Why not Unreal?"
Me: -_-
Don't get me wrong. Unreal looks great, Unity is just my preference right now.
"so you trust the engine more than me??? u sure we friends?"
@@MansonMamaril Sounds like a toxic "friend"
"because I value my sanity"
Unreal is great when you know Unreal. Unity is great when you are interested in just making a game.
I've been working with Unreal for 8 years. I am still fighting Unreal every single fucking day
I'm a hobbyist developer. I've never actually published anything I've made, but I have tried many different engines and I always go back to Unity. Things are just generally easier to implement and there's not quite as many quirks that hinder your development (there still are some, but way less in my experience).
Unreal for me is a slug-fest.
Super fun to watch, if anyone asks again " WhY DonT YoU JuSt uSe UnREaal??" then I will link them this video and they'll hopefully learn something ;)
I mean, I'd still use the Unreal engine, even after watching the video.
@@MrERJ1992 Well yes of course, do what's best for you and your project! I'm just referring to people that make that comment after I say we're using Unity. Most of them are not mean, just curious I guess, so I was exaggerating a bit in my previous comment (for fun) but it becomes a bit annoying to be questioned with engine choice after a while!
I mean ue4 is easier than unity by far. And also lighting and lods are handled better
@@LoneWolf6063 I'm not here to continue any engine war haha, use whatever you like more. Some things are better in one engine and other things are better in another engine, all have their pros & cons. The whole purpose of the video was that you cannot say "one is better/easier then the other", it’s not really about the engine but much more what you do with it :)
@@LoneWolf6063 If you could see how wrong you are
Awesome video.
Loved the breakdance at the end!
Going to just send this video from now on instead of explaining it every time this comes up. Excellent work, also really funny video. Subscribing!
As an avid Unreal user and fanboy, this seems pretty dead on to me. I think Unity is pretty darn good but not for me.
I am a bit of a power user, doing C++ changes to the engine and have other personal reasons to prefer Unreal but that skeleton thing cracked meup. I work at a game dev studio and have seen issues with the skeleton physics.
You bring up a good point in your comment too about the scripting language. One of the biggest reasons that I prefer Unity is that I am way more fluent in C# than C++ so it takes me way less time to implement something. Not that I couldn't learn, but I'm just so comfortable with C# and prefer it.
Do you have to deal with memory management in C++? Or you just write code and check memory at profiling time?
Unity user here using C#
@@prateekpanwar646 Unreal's "flavour" of C++ handles memory management for you. You declare your properties as UPROPERTY and then it's automatically reference counted.
@@prateekpanwar646 Unreal comes with a garbage collector and reflection system. So any UObject (basically the most basic Object Type in Unreal Engine) is garbage collected, and if a pointer is marked with the UPROPERTY macro it will automatically null itself when the object it is referencing is destroyed. So the only thing to get used to is the syntax of C++ and some best practices. In general the modern C++ isn't as scary as people make it be and Unreal makes it even easier because it gives you enough abstraction to not have to deal with the difficult part.
For more basic types you also have various smart pointers, but usually you only need such things when you do stuff outside of gameplay programming.
This is some real high effort content
This was suprisingly entertaining and interesting. Great video!
Your comedic tone and delivery is awesome, and your information is helpful and informative.
Honestly, most games apart from super indie games are going to use custom shaders too, so they'd look the same across all three engines as well. It's really not until you get into super resource taxing games like open world games where Unity and Unreal really start to show their differences.
Yes! Yes! I'm making an open world games using HDRP in Unity and Unreal 5 has this new tools and stability that confuse me! Do not know to migrate or not. " really start to show their differences." Do you know this "differences"? can you expand on this?
He doesn't. Open world games, optimising is going to come down to your own ability. Neither engine has direct support for that.
@@Domarius64 unreal engine 5 has a lot of improvmenets and automatic streaming optimizations for open world so in that area it could help a lot
@@Domarius64 Unreal is pretty openly supportive of open-world style games. Their proximity loading techniques require very little programmer interference and simply... look and perform better than any competition. Having a game where models don't clip in and out of view really helps for open-world games, and its "free" in unreal.
@@lucass8119 ah thst might be new since I last looked
Greetings from Lebanon🇱🇧 Huge fan🙌
i enjoyed the video so much XD ! I intended to try this but you did the job for me, thank u
this is GOLD
Thanks for making this kind of content!
I noticed that godot has some pretty bad shadows too. It's completely fixed in godot 4, but right now they suck, at least with the default settings.
You would have to tweak default settings to look good.
Godot 4 have better shadows by default and better overall (compared to 3)
This is a super well made video, thank you. The engine wars have left many gamedevs with thousand yard stares as people yell at them about things they think they know better
edit: greatest outro ever no competition
i was gonna subscribe but that sarcastic little "simple" when you explained how to get more bones in the rig in UE made me smash that sub button XD XD
Awesome video, really enjoyed watching it
Would have loved to see a performance comparison!
I feel like knowledge a d experience of the engine, just any other tool, is more important than the engine itself. Like, I know that to fix the rag doll problem in unreal you just change the min bone size and it'll detect all the bones instead of just two, but I probably would have a much harder time doing the same thing in unity.
Hahah, I love your jokes about Unreal naming!
Great video 😁
It's not often that I comment on a video, but I just want to say keep it up! I love the way you present, very entertaining and informative at the same time.
dang only 1k subs 😯 this type of content gonna push you up 👌
Something I hate from Unity is the pain of making a shader close to what you would be using in Blender for material settings.
@Evi1 M4chine Almost no material system seems to have a "standard" that can be imported into a game engine, there are certain similarities in 3D software to make shaders using a node system BUT the closest to the regular thing I have seen is UE4.
Unity has its own fricking way of handling nodes to make shaders, the ones that come with default projects may seem enough but have some limitations or quirks, for example, in Unity standard shader there is only one "slot" for roughness + metallic which requires you to mess around with color channels in your image editor to get something of use.
The best and honest comparasion video of game engines I have ever seen so far, well explained Mr. Fabian❤
PS. not to mention it was hella funny too 😂
For the record .... when exporting to Unreal Engine from another software, you need to set the scale to METERS and the value needs to be 0.01. Unreal Engine is in METERS. You CANNOT just set it to Centimeters and export. It MUST STAY IN METERS. That will fix the pivot points on your bones 100% of the time and you will not have to increase it to 100% then reduce it 100%. Just keep it in METERS and 0.01 before exporting.
This is true. I have to do this with Blender.
@@palmzmetal9131 It's true for anything being exported to Unreal. Rather it be Blender, Maya, Houdini....they will all need to be in meters and set to 0.01 if exporting to Unreal and the scale to be fine. Such a small thing that fixes so much. LOL So many people think they can just use centimeters and while that makes logical sense, it just doesn't work that way.
That's not always true, I have to use CM in solidworks when exporting via datasmith.
@@mattmurphy7030 That is news to me. Do you "have to" or have you not tried "meters and set to 0.01"? I've exported from solidworks with the "meter" option and variable and it worked fine. Albeit 4 years ago. LOL. Something could have changed since then> If you did try the meter and 0.01 setting and that didn't work, then that is good to know.
@@pen1208 I wouldn’t have tried that because exporting in unreal’s native units of centimeters works perfectly
I just want to vibe and program in whatever works for me and not worry about being judged by the tool used along the way.
Subscribed! Great video man, definitely made some excellent points.
Epic video, especially the ending! 🎉
It would be interesting to know how fast each variant runs.
In unreal, by default the sky is partially colored by the directional light source, which is why you couldn't completely change the color. Hope this helped :)
Thanks for doing this! I hope this can help people understand that engines are just tools and you can pretty much whatever you want with them.
Awesome video!!! I really liked the comparison you made and tbh, at the end with all the games scaled down side by side, I couldn't tell the difference between them lol. Also that unreal scaling issue got me so bad too.
So what we learned is that Unity is a very well documented and developed game engine
How in tarnation did you grab the objects like that in godot? Been trying for ages 😅
got this question before, so a screenshot of my script (very short) is in my Discord (link in description of video) :)
@@fabianvelander oh wow il check it out thanks!
More like this video! Very interesting to see multiple game engines being used for the same thing and seeing the differences.
This video completed my day. Thank you
It would have been interesting how their performance compared. Maybe could have added 100 NPCs and 300 bottles to test it.
Dude settles entire worldwide debate in 9 minutes. Love it.
The bloom and auto-exposure you said you were experiencing is due to the project's default post process settings. You can either edit these in Project Settings -> Rendering -> Default Settings or you can also manually override them by adding a post process volume to your level and enabling the infinite extent property, so that it affects the whole world. You can then disable or tweak the undesired post-processing features. Under the Bloom section you can set the bloom intensity. Under the exposure settings, you can change the metering mode to manual and then set the exposure compensation to whatever you like.
Man, you resolved the UE issue I've had for MONTHS THANK YOU SO MUCH
1:30 without the texture I though he was flipping the bird
You do realize that unreal has a physics handle component that allows you to grab objects without the need to mess with forces, right?
Love the humor. Love the dry serious nature of the humor. This is a very humorous video. It made me laugh. I was also impressed that a human can understand Quaternions, but this was a funny video.
Very entertaining vid man!
This needs a redo with Godot 4, to see how much the default shadows improved.
I love using Unity. Lots of good and unique games have come from it. Hearing people say stuff like "Unity sucks cuz it's bad and Unreal is better" is just frustrating. It shouldn't matter if it's free, popular or easy to use. It's a tool that can make decent games.
Gamers are consumers and they dictate the rules. Unity has a bad reputation because of asset flips and trashy horrors.
Unity developers pay to remove "made in Unity" splash screen and that's a sad fact
If you put the same models and textures side by side they will look the same in both engines.
Loved this!!! Liked and subscribed! MORE!!!
The commentary video pieces are great. Unreal business fancy. Too funny
Unity : best physics
Unreal : best graphics
Godot : best based-animation
I would preface all three of those with "out of the box." You can get comparable performance on all three of those topics in all three engines. They just cater to some things more than others out of the box.
@@TwistedSisler thanks
Whole reason I go with unity is performance, unreal looks nice but it will ruin older computers and often times the size is much larger than unity when exported to final project. But yee if you want the best looking thing go unreal, if you want performance and space efficiency go unity, :p
Also platforms, Unreal is forever chasing highend PC's and consoles, but everything else is left to die
@@Waffle4569 heck yes, I love how easy it is to port to pc, browser, and Android, get to take my projects and games with me to show to peeps, :3
But Unreal's C++ is faster tho, AAA games made in Unreal always run better on my PC. Plus Unity loves to crash and doesn't support old GPUs from 2010s
@@jondro6284 C++ may be faster, but Unreal is a massive engine with a lot of overhead, and fundamentally they aren't targeting low end platforms so they don't put much time in optimizing it for non gaming hardware.
@@Waffle4569 the complexity of the engine doesn't influence the game much, unless a dev is lazy enough to leave crazy out of box postprocess and code in blueprints.
And Unity literally doesn't support old AMD GPUs. Many of my friends have weak PCs and we like to play small coop games which are almost all made in Unity. But we can't anymore, games made after ~2017 inevitably crash after a few minutes of play
This was very entertaining to watch, well done
Fabian, asbra video. vem visste att jämnföra 3 olika spelmotorer kunde va så här roligt =) keep up the good work.
well, in my opinion (tried both btw), Godot has a better 2D engine than Unity, but in 3D, Unity is definetly better that Godot. Godot works kinda faster in both compiling and you know, Unity loves to check the code every 2 mins and make you wait for about 10 seconds. So use the engine that suits what you want, 2D? Godot will do the job. good 3D? Unity is so good in this, even graphics. some awesome graphics and lighting? Unreal ofc
I really think the legal and ethical differences between the three projects completely eclipse any technical differences.
@@Barnaclebeard The technicals should matter to you way more than the ethics. Are you going to not use a powerful screwdriver perfectly suitable for building your chair, just because it was forged by an asshole?
i'd like to mention that the upcoming godot 4.0 will certainly catch up pretty well with Unity in terms of 3D
it's much more performant and capable of good graphics
@@randomcatdude i actually heard about it, and I'm excited for it, but at the end of the day, the hard part about learning gamedev is HOW to make a game, and not WHAT to use to make a game, once you learnt how think like a game developer, switching wouldn't be hard imo
This is interesting !
I would have loved to see your take on the CryEngine too
Practical approach? SUBSCRIBED!
Thank you!
I was waiting for this for so long.
The whole this game is bad because its made in this engine is just simply "The bad artist always blames the tools" for me at least
dont worry, unity's bad thing has arrived 😭
Awesome, love this so much. Also, I've got an idea. We should have a massive game-dev event thing where game-devs represent their engine of choice and they all try to get the same result and make the same game. We only saw 3 engines in this video, but there're so many more engines like Roblox or Game Maker that I'd love to see have the same end result.
This is such a great video. Basically proves the point that all the engines all have their annoying issues along the way but come to the same final destination
The "you can do anything in any engine" take I'm seeing a lot here is pretty uninformed. You can _eventually_ amass a million dollars working any job but it's going to take a lot longer to do so as a McDonald's cashier than as a doctor. Same with engines. Nanite is literally just a checkbox you tick that allows you to immediately start using a virtually unlimited number of models. Unity simply does not have anything close out of the box. So now you have to go and learn ECS/DOTS or whatever which completely changes the way you program your game. Network replication is built in to Unreal. Unity at the moment doesn't have a stable, non-deprecated networking solution so now you have to go hunt around and figure out if you want to use Mirror or something else. And so on. Of course on the other hand, if you want to make a mobile, 2D, or VR game, you'll probably have a quicker and easier time using Unity. So yeah, each engine has its own usages but to say that they're interchangeable is just wrong; you're going to save literally thousands of hours by using the engine that's better suited to the type of game you want to make.
just a (not so) little note about nanite :
while the feature is insane, and have incredible potential, it is as of now, far to be a finished one, it has a very high "entry" performance cost, it's run pretty well on High spec GPU, but on medium/low spec GPU it's tank performance.
Nanite is also as of now pretty limited, you can only use it on Non-deformable Opaque mesh, which mean, no vertex-deformation not any sort of transparency (not even alpha clipping :( )
Of course, these feature about transparency and vertex deformation are being worked on as of now .Unreal 5.1 will feature vertex deformation and alpha clipping so it'll be usable for some case of foliages, but as of now, 5.1 is a messy and unusable mess (working with it is a torture)
another limitation of nanite, is the ammount of "cluster", while it allow to use immensely more polygon than even, it's far to be limit-less, especialy for foliages as each leafe of small isolated groups of polygon is considered as a "cluster" which can quickly fill up the cluster limit of nanite
@@PlexusDuMenton unreal 4 is released nearly 10 years ago. Unreal 5 is definitely also designed to be used for another 10 years
It's absolutely the correct take. Unreal has some extra artist tools in its corner, absolutely. But Unity has superior development tools for engineers (particularly in its modularity). It really is down to what you prioritize or care most about. If you're a studio and want to tell your engineers "Deal with it, I want the best graphics as painlessly as possible" go with Unreal.
So the take "You can do anything in any engine" isn't misinformed simply because certain engines cater to certain aspects of development more. It's as you say, go with the tools that suit your need the best.
Like the aspects of Unity you say are a fault (it not having built-in network support) are also what makes it so great ~ There are different network solutions competing to be the best Unity version. Giving you greater choice to what suits your game best. Server-authoritative by default? Mirror. Easy to use but easy to cheat? Photon. Disconnected from Unity? Normcore. Expand that to most aspects of Unity whereas in Unreal it's usually "Alright this is how we're doing things, if you don't like it suck it up (i.e we still kinda use the inheritance model of programming game dev that was deprecated 20 years ago so hope you like memorizing different forced object types!)".
Nice video. I cringe whenever gamers talk shit or praise an engine. Sure, some do things better than others and each of them have their own workflow, but under the hood they are more or less the same.
Yep most of these engines use pretty much the same open-source libraries under the hood.
Gamers really have no idea how games are actually made. There's lots of people that think 90% of the work is making models and animations.
@@Madmonkeman coding is like DNA for games.
Subbed, that was great!
Amazing video. The humor is on point. And fr as someone using godot it's very accurate
Unreal gives to much assuming you don’t want to create things from scratch. I tried learning Unreal after knowing Unity for 4+ years. I wanted to create a custom character controller, but every single bit of documentation and all the videos online only show how to use Unreal’s built-in controller and how to modify it to make it “your own”. I’m sure it’s possible to make your own, but Unreal feels more like you’re building a game in a creative-mode setting where the end result isn’t truly yours.
Back in 2014 when UE4 first came out I tried it, and there wasn't much documentation on how to do things in C++ (I already knew C++). I came back a year later and it seemed like they were still pushing everyone to use blueprints. I consider switching now but your comments are making me think it is still a bad idea.
It's because everything is built on top the current controller. If you want to make your own controller you'd have to recreate root motion, animation handling, even parts of the animation blueprint depend on the existing controller.
Pretty sure you can make a blank (empty) project and do it all from scratch, and if you don't like the default character blueprint you can always make a new one, or just create a new C++ class yourself :D
In a big production environment, the designers will only use premade things anyhow. Either build in from the engine or from their programmers. The workflow is very oriented towards splitting up tasks between team members. Hence offering a visual scripting language for the "dumb" level designers instead of them writing code.
Unity is more focused on smaller teams, and more flexibility for a single developer.
You use a pawn base class and not a character and then you can customize the movement logic completely