Making the same game in Godot, Unity and Unreal. Cowboys, bottles and ragdolls yay Link to Discord: / discord Links to me: www.fabianvela... / 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
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.
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.)
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.
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.
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.
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
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
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
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).
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.
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.
"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 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.
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 !
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.
@@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 :)
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!)".
Wow, RU-vid 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.
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
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.
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.
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.
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.
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.
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
@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.
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
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!
I think a big part of what gives Unity a bad name in some people's eyes are that they put that splash screen on all the non-paid-for games on it, so they get the Unity "seal of approval"/splash screen shoved up their face when they open the game and just see another cheap asset flip or someone's first project behind it.
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 :)
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
Although funny, I find your jabs at UE for the names of their Blueprints a little unfounded, lol. In Unity and Godot, you are using a scripting language. If you were using C++ in Unreal Engine, you would 100% be using a line trace, and a Slerp. But because Blueprints are made with more specific interactions in mind, they are named accordingly. A Line Trace doesn't just do a raycast, it also has the ability to output the debug information as a Line without having to use an extra node. Setting all of that up in C++ is about the same. As well as the RInterpTo. They also have FInterpTo, and so on, because they are broken down into the variable type (R - rotator, F - float). There actually are separate Lerp node as well, but from what I understand most people assume Lerp is InterpTo, and don't fully understand the use case, lol.
I disagree with this video. The problem is with this video is that it is lacking nuance, that nobody in the comments is addressing either. What about mobile? What about multiplayer? How does Godot (3.0) perform in open world 3d levels? How does Unreal perform for 2d, and also smaller games when you need a trimmed build? We should do better as a community to go beyond a simple 3d example and changing a few lights in the scene to come to the conclusion that "engine doesn't matter".
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.
You can use C# in godot, C# in Unity, and C# in UnrealCLR for - Unreal. UnrealCLR is pretty interesting compared to Unity, cause you can use all the newest good stuff of .NET 6 an C# 10. Unity uses C# out of the box, but lacks a bit behind cause of the runtime hell and fast updates of .NET, and they have a lot of customization, which might not be easy to bump up to net 6.
Agreed, however I will say that it's very rarely necessary to always be up to date with the latest framework for your projects. Unless you are several version behind, it will mostly affect you very minimally. In fact, it's arguably better to choose a version for your release and stay on that version unless you have to update for whatever reason.
Hey! SilokHawk, the person who GMTK responded to, was really done dirty. What they said was in the context of the pacman game collection that recently came out, who used unity to handle the emulation. While I don't trust myself to properly portray their argument (you can watch their video for that), it is more complex and nuanced than what the out of context clip that GMTK shared would make you believe. GMTK even apologized afterwards.
Except you made a very simple game in each engine, that does not show of each individual engines quirks. There's ways certain things works, in certain engines, that makes it very easy to be able to say "oh, this game is made in X engine, that game is made in Y engine". It's not right to say that all engines are identical, and anyone who points out known, common flaws in an engine is just wrong, it's down to the people who made the game... What? You could've made an even more basic "game" and it would've been as valuable as this "game", which is to say not at all. Other than showing of one engine handling lighting a bit differently, and one engine naming things a bit differently, you showed off none of the well known quirks of each of those engines. This video is just moot, it offers no actual evidence, instead it comes to a conclusion based on poor "evidence" that's just way over simplified to the point where it's meaningless. It's like if you found a dead body, with a bullet wound in it, and you go "well, there's blood, and everyone bleeds, so the death must've been natural". If you over simplify too much, you'll always just end up being wrong. You are in this case. What the video does end up seeming like, is you criticising a couple of other engines, because you're angry that Unity got some criticism, you oversimplifying the issue so that you can say "you're all wrong, look here, it's identical!", and having proven nothing in the end because you didn't address the criticism at all, what so ever. Meanwhile, you offer no criticism vs Unity. You point to the other engines and say "Hey! This engine is worse than Unity in this way" and "Hey, this engine doesn't name things the same way that Unity does, because they're trying to be fancy, and greedy, and they're bad and you're bad if you use them and just use Unity because it's the best that other engine is evil andifyouuseityourfriendsandfamilywilldisownyouandyourhousewillblowupandyourdogwillrunawayand.... Well, you get my drift here. You're just ranting about how other engines are bad, not acknowledging Unity's issues, and not addressing the actual criticism. I've never seen a video of yours before, I have no idea if Unity is your favorite engine to use or not, or if you've ever made a single game before or attempted to make a game before. My impression from this video is that you prefer Unity, that you have some sort of jealousy towards other engines perhaps getting more praise, and that seeing Unity being criticised pissed you off. So, you made this video, kind of ignored the original criticism completely, and made a very simplistic game that barely shows any of the individual quirks of each of the engines used in the video, instead keeping it so simple that they're basically nearly identical. All this so you could point your finger and say "Hey! Your criticism vs Unity is unfair! All engines are created equal! Look at this super simple game I made to prove that you're all wrong! The issue isn't Unity, it's the game makers!", completely ignoring that you can see the same issues in many games made in Unity, by a huge amount of different developers. Same thing with Unreal and basically any other publicly available engine. No engine is perfect, Unity or otherwise. Do the same thing again, but actually highlight the quirks of different engines. Show how some engines have weird physics, lighting, shading, etc etc etc. Then you can say "So, this engine is worse in these circumstances, whilst that engine is worse in those circumstances" and you'll have an actual video worth something. Although, that video would have to point out Unitys flaws, as well as others. I suspect that's not what you want to do. A video like that would prove that, indeed, you can look at certain things in a game that's a tell tale sign that "Hey, this game must've been made in Unity, because of this thing" or "Yeah, this game for sure is made in Unreal, just look at how it's handling that thing". That's very much a real thing. Sure, not all games have situations where those flaws are visible. And most of those flaws can be worked around or solved, so not all games made in a specific engine will show those tell-tale signs showing it must've been made in a specific engine. That's not to say that the problem doesn't exist, because you made a super simplified game that does not touch on any of those issues at all, all so you could go "look! These other engines has some issues that Unity doesn't, but other than those, you can't tell what engine this game was made in, because those people that criticised Unity are just wrong".
That's like saying if you can drive to the store in a pickup truck, a ferrari, or a honda civic, then they are the same car which will act the same in every situation, ever. Your rudimentary demo doesn't prove anything. You don't talk about garbage collection, netcode, workflow, overall effort (you cover that but you don't seem to take it into account of its effect on the final product quality). I can tell which game engine a game is built on more than 1/2 the time just by the feel. Unity is by far the worst with it's terribly timed garbage collection. How could you miss that? Have you ever built anything past a 1 hour tutorial from a YT video?
I love that you actually did a simple game in three engines, nevertheless, I'd love to hear your "process analysis" followup video. I get the point you are trying to make, but you've missed basically all of the important distinctions. Hell, you can make the same game with cpp only. The meaningful comparison is how much the engine helps with (or hinders) the realization of your vision. That includes start time, build time, rebuild time/live coding, etc.
I'm not into game development that much yet. But your video kept me watching because you're funny. in a good way. Like world-class comedian😂😂😂😂. But I learnt a lot!, like Unreal is boujee💀💀
But what about RayTracing in UE vs Unity? :-) Godot will have it too! Someday... They get the Global Illumination and Vulkan support recently! It's in Beta tho... :-)
i mean.. if youre going to do something SIMPLE like this which forces unreal to punch down sure theyre all basically the same, but what if you were to attempt a full "AAA" game? do you really think it would all be equal if you were going to do something the scale of assassins creed valhalla (just an example)? i notice the big publishers are still occasionally willing to use unreal when they dont use their proprietary engines, but i never see them use godot or unity.
And now you understand racism. Well no not really, but you thought it made sense for a few seconds. It'd only be accurate if it was exactly the same engine just with different names and people had really strong complex prejudices towards them in the way they irrationally do the current engines... but like with more lynchings and stuff... and maybe like one engine is like owned by the others for a long time... okay it's a bad analogy.
%90 of everything is shit. Because unity is popular amongst indie devs and hobbiests and these groups dont have the production quality of (most) game development studios so the quality tends to be worse in general. This is the first part, the second is that people see that its made with unity then falsely atribute the quality (or lack of) to the engine instead of the people who made the game. It doesnt help that things like Itch and Steam Green Light allow for the distribution of these games, not that this is a bad thing, its overall a good thing, the part thats "bad" is it allows lesser quality games to be spread and found easier thus futher enhancing this effect.
Unity's biggest mistake was making their logo appear before ever single crappy mobile game. (There's no option to turn it off, only if you buy a Unity subscription)
2:40 this is the most unprofessional way I have have ever seen to import a skeleton mesh to Unreal. Kids, this is why you use Autodesk 3dsMax and not Blender. The rest of the video was cool though.
Hi man little tip : For export from Blender to UE5 use epic blender addon it will solve all you problems. Its little trickier, you need to set up git account and follow epic but it is worth.
2:35 That's a common issue with Blender->Unreal skeletal meshes integration. Blender can't work with custom units and applies scale to the Root bone while exporting if not properly set. It's not an issue for other software like Maya or 3ds max. Yet the physics colliders can be generated even on scaled mesh, you just need to update the settings (for capsule generation). 3:22 Why not Physics.Linecast in Unity? LineTrace in Unreal is the same as Linecast in Unity. The difference is that you provide start and end of the line, while Raycast has a start and a direction. 4:47 In unreal it's called FQuat::Slerp. FMath::RInterpTo is made for Euler's interpolation. The lack of Quaternions in Blueprints is frustrating.
This video is not only filled with accurate truths (and an awesome breakdance sequence) but also highlights a huge problems with todays 'devs'. Which is, they're not actually devs... They're just people who follow tutorials to get something almost like the thing they wanted, then use plugins for everything else... Then blame the tools for the shoddy workmanship. It's like saying, I can't draw because my pencils are crap...
Ok, so you are literally cutting out all of the different features those engines offer, and not base the debate based on the actual differences but isntead of the physics simulation? Unreal is way better when it comes to dynamic lightning, realistic textures etc. and performance optimisation but you just disregard it. Indeed if you cut out all of the features UE5 is much better than Unity, then they are of course the same :D
The thing is most indie devs don't need all those features. And outside of some optimization, players aren't going to care if an indie game doesn't have dynamic lighting. For most I'd say UE is overkill especially if your game is 2d. For the record I don't use unity or godot either. But there really is no one better than the other. It's about what your game needs. A feature existing in an engine means nothing if you aren't going to use that feature.
