you have no idea how relieved I am that i decided to take this gamble XD i'm still sad about the hundreds/ thousands of other games and devs that are getting fucked though
What a fortuitously well-aged video lol. I myself absolutely adored working with Unity (even with all of its half-baked and incomplete features). I much prefer C# over C++ though I'm experienced in both (reflection and runtime code-generation are big tools that I use a A LOT). I definitely prefer the open-ended design of simple GameObjects as containers rather than inheritance trees like Actors n such. And with some experience and discipline you can find a workflow that is just as clean, fast, and powerful using component-only designs. But alas, Unity has finally burned that bridge to the ground and flooded the river it crossed to as to wash away all of the pieces. Unreal here I come. Thanks for the quick recap! It should help get me up to speed with the very basics at least!
I love architectural freedom and modular nature of Unity. With Unreal it's like building on top of someone's code base, that's not always a bad thing, but it means you have to go with the flow, or fight it around every corner to turn it your way.
the wonderful thing about the existing code base in unreal is that it's really not that hard to ignore it and do your own thing anyway but it is there if you want to use it. It gives you so many more tools to use and it's up to you as a developer to choose which ones you want to use and which ones dont quite do what you want them to do and you can rework those to fit your needs or for a lot of them, just ignore them and build your own stuff anyway. Some people call that bloated, which, there is an argument to be made there, I would like to think of it more as a well developed mature engine that knows how games work and what things are needed to create most types of games and offers them up to the user, that's the point of a game engine after all, is to not have to replicate a bunch of basic stuff for every new game you want to make and have a solid base of tools to start with on a fresh project.
So what? It's never from zero anyway, even in Unity. It's just clever hiding complicated things from its users. You always work on top of someone else codebase. Or you might want to build your own game engine from scratch.
might just be my overkill CPU, but compiling my c++ code is a matter of seconds, that by no means makes it slower than blueprint unless i try to compile every other line i write
haha it very well could be :) Oh and also probably live coding is enabled on your project. It makes the process a lot lot faster, only drawback is sometimes it may not compile the code properly@@thegamedevcave
I work with both, each has it's upsides. My fav thing in Unity are many language extensions/libraries I can use, unitask, unirx, they are really helpful. Unreal is very strict, I dont really see that much of a difference between actor and gameobjects, its that pawns and characters offer you so many things out of the box, but you could do them yourself as well. It is still hard for me to decide which I prefer really
I like unreal's split of actor classes and component classes. that works quite differently between actors and gameobjects really. Unity is a lot more open and lets you as the developer do whatever you want where unreal does guide (and in some ways limit ) you. so long as the game you're making is more helped by the premade tools unreal provides than the engine gets in your way, I think unreal for sure has my preference but if you want to build something from the ground up that goes against what unreal expect you to do, Unity for sure seems more appealing.
My bias but I think that Unity for this sort of game would be a better choice. You don't need all the stuff UE has, of course that is your decision as a developer to make, not mine.
the whole point of taking a 3 month break for me was to evluate this and I've personally come to the conclusion that unreal does offer me a lot of things that I dont have any unity. All the super high end stuff like nanite and such indeed won't help me much, my highest poly models are characters, which it doesn't work on anyway. However, unreal comes with so many little tools and a solid premade framework which unity lacks, which makes it easier to create things much faster. especially as a 1 man team, that's insanely valuable.
To me Unity felt a bit more natural and enabled me to get my ideas into the game a bit easier. In the other hand the built in stuff in UE is amazing. That aside, the decision is clear now, Unity's masters showed their true colors and while Sweeney is no saint, he is a bit more in touch with the dev community.
indeed, no company is your friend!! but some can be a bit more evil than other still. You're right though, unity is a lot more open to developers doing things how they want to do them, instead of pushing them into the more strict and tight framework of unreal, where they do expect you to work they way they indeed you to. that said, for the most part if you insist on ignoring all that, you can rebuild a lot of the premade functions that unreal offers you in your own way still, but at that point you do end up fighting the engine a bit which is hardly ideal :(
Yeah, UE is giving way much more out of the box whereas in Unity you have to pay for assets for similar things. Question: how do you find C++ when compared to c#? As for now, this is the only reason I wasn't using UE because C++ seems to be very unfriendly when compared to C# and Blueprits as you mentioned seems very slow in creation not to mention this spaghetti on screen :)
getting into c++ was a bit rough, mostly i was able to learn c# fully on my own, with c++ for unreal i did look for some help in a structured course to help teach me and once I had that, it really wasn't that bad. Comparing unit C# to unreal c++, you have to learn what pointers are, just so you understand what you're coding but the engine does all the heavy lifting on things like memory management and such, all the things that usually make c++ a total pain in the ass are not something you have to concern yourself much 99% of the time, so at that point it's just a slightly different syntax for some things. If you can get into learning c++ for unreal I highly recommend it, I don't think it's as bad as many people think.
@@thegamedevcave You can make a video explaining this tho, I would like to see the comparison for your migration from Unity to Unreal with the system you use (and it's counter part on Unreal), and maybe a short tutorial for it too
@@muhammadyusoffjamaluddin migrating isnt really a simple task that i think i can make a video on. Its just a lot of writing the same code from c# with a handful of small diferences in c++ which takes a lot of time. But i do plan on making a video on unreal c++ and why i think most people overestimate how difficult it reallt is compared to c#. As well as make a tutorial series about getting started with c++ sometime later this year
@@thegamedevcave I would say unreal C++ is better than normal C++ with all its standard templates and inbuilt memory management (GC). In regards to BP I think people overestimate the negative "performance impact" which is mainly only an issue if you are doing a lot in tick, use large loops or working with large arrays. The main performance pitfall people fall into is that when you add Cast's in your BP to other classes it created a "hard reference" which means now when that first class loads so does the class you cast to (and any it that Casts to) along with any mesh / texture / sounds you have defined on that second class (are loaded into memory). You can get around this by casting to a base C++ or "code only" BP class or using Interfaces... also extra points if you define the variables that hold the assets as soft references and use async asset loading nodes to retrieve them so you are not locking the game thread because of disk I/O.
interesting to hear! I've never heard someone compare blueprint to unity and come out with blueprint being the hard one for programming. What is it that made it difficult compared to coding in c#?
Key fact. Unity doesn't make games. Unreal is used by Valve to ship games (including Fornite). Obviously there are many games written in Unity, but there are *many* game centric things that Unreal does out of the box that some unity developers don't understand... Like efficient space-partitioning of mobile objects, or efficient frustrum culling, or streaming terrain, or world partitioning... not to mention the advanced Lumen/Nanite render functionality in UE5. There are also compromises in Unity because it's design goal is to ship on any platform (including the browser). Like the weird (and buggy) Burst jobs compiler and system. Many subsystems in Unity are also buggy and/or unfinished and the source license is very expensive. There are certainly some types of games, with custom shaders and/or custom GPU compute that are easier to write in Unity, and C# is often a more comfortable language for small projects, but I also recommend anyone interested in shipping a 3d game spend some time to build something trivial in Unreal before deciding.
the mining game isn't particularly well made, it's a messy rush job so it would be quite a bad thing to use for learning, I do have lots of video's on here that are much better for learning. most blueprint based but recently also started some c++ content :)
Ok so basically Unreal helps you a bit with the design of your code, by forcing an already made one that is pretty flexible, I'd say that's a good plus.
unreal's base class is actually object, but this has basically nothing, actor has all the networking and and is the minimum base you can use in blueprints
you're 100% right! if you trace all the parents back you end up at UObjectbase. although as you said, all the interesting stuff is on the actor class and especially for those who work with blueprint, correct me if i'm wrong, you can't make a blueprint on anything beyond actor right? Still, you are for sure technically correct, which is the best kind of correct!
@@thegamedevcave not sure what you mean, you can make a blueprint parent of any blueprint or C++ class, blueprint child however can not inherit directly from UObject
@@ThyTrueNightmare yeah so for blueprint purposes the most basic thing you can inheret from would be the actor and actorcomponent classes right? Of course in C++ you can do whatever you want :)
I've been producing a MMO RPG in unreal since early 2022. Passing the concept phase with a few proof of work concepts. We should talk maybe mix a few of our ideas together if you are interested in a colab.
that would be great! that said, unreal's implementation of c++ isn't all that different from unity's c#. people are quickly intimidated by hearing about c++, but unreal does make it very manageable!
So basiclly unreal is better for high end rpg art design stuff. But unity is better for 2d and gameplay creativity. Well i only care whats best for 500 fps shooter. Where should i go? Whats a dev that aint into the mainstream games but only about performance?
in the end, i dont really think it matters a huge amount, whatever you feel most comfortable working in will likely produce the best restults. but as a general rule of thumb I believe you could follow this : simplistic looking games (low poly art styles , simpler lighting, etc) will likely preform every so slightly better in unity because the engine as a whole seems less power-hungry. but as soon as you move into some higher quality asset usage, unreal wins in both terms of looks AND performance. but again, while I think it's an important choice to make, your comfort with the tools you're using as a creator is the first and most important thing, good results will follow from that.
Honestly I would look into unreal. It's basically designed for building multiplayer FPS games. With C++ and a lot of the built in unreal dev tools, you can squeeze out a lot of performance. Love or hate fortnite, it brought a ton of improvements into the engine making it one of the best engines in the industry, especially for FPS games. But at the end of the day, an engine is only a tool and the quality of the game is determined by the quality of the developers.
haha! It happens. I rarely type the word "because" only once; somehow I always get "becasue" out of my fingers. Your insights into game development is very informative and your presentation is charming keep up the good work! @@thegamedevcave
I bet you are really happy with this decision now.
you have no idea how relieved I am that i decided to take this gamble XD i'm still sad about the hundreds/ thousands of other games and devs that are getting fucked though
@@thegamedevcaveI'm glad you dodged the bullet way ahead of time
@@thegamedevcavei stardet unity nearly the same time this hapend
what happened?@@bubi1909
what happened?@@Impaczus43
What a fortuitously well-aged video lol. I myself absolutely adored working with Unity (even with all of its half-baked and incomplete features). I much prefer C# over C++ though I'm experienced in both (reflection and runtime code-generation are big tools that I use a A LOT). I definitely prefer the open-ended design of simple GameObjects as containers rather than inheritance trees like Actors n such. And with some experience and discipline you can find a workflow that is just as clean, fast, and powerful using component-only designs. But alas, Unity has finally burned that bridge to the ground and flooded the river it crossed to as to wash away all of the pieces. Unreal here I come. Thanks for the quick recap! It should help get me up to speed with the very basics at least!
I love architectural freedom and modular nature of Unity. With Unreal it's like building on top of someone's code base, that's not always a bad thing, but it means you have to go with the flow, or fight it around every corner to turn it your way.
the wonderful thing about the existing code base in unreal is that it's really not that hard to ignore it and do your own thing anyway but it is there if you want to use it. It gives you so many more tools to use and it's up to you as a developer to choose which ones you want to use and which ones dont quite do what you want them to do and you can rework those to fit your needs or for a lot of them, just ignore them and build your own stuff anyway.
Some people call that bloated, which, there is an argument to be made there, I would like to think of it more as a well developed mature engine that knows how games work and what things are needed to create most types of games and offers them up to the user, that's the point of a game engine after all, is to not have to replicate a bunch of basic stuff for every new game you want to make and have a solid base of tools to start with on a fresh project.
So what? It's never from zero anyway, even in Unity. It's just clever hiding complicated things from its users. You always work on top of someone else codebase. Or you might want to build your own game engine from scratch.
When you work in the game industry, you will always work on top of someone's else architecture/code. Doesn't matter if it's Unity or Unreal. :V
welcome to Unreal gang
it feels good to be back ! :)
Yeah well in C++ compiling the code and all of that takes a lot of time as well. Blueprints actually makes the process much faster
might just be my overkill CPU, but compiling my c++ code is a matter of seconds, that by no means makes it slower than blueprint unless i try to compile every other line i write
haha it very well could be :) Oh and also probably live coding is enabled on your project. It makes the process a lot lot faster, only drawback is sometimes it may not compile the code properly@@thegamedevcave
I work with both, each has it's upsides. My fav thing in Unity are many language extensions/libraries I can use, unitask, unirx, they are really helpful. Unreal is very strict, I dont really see that much of a difference between actor and gameobjects, its that pawns and characters offer you so many things out of the box, but you could do them yourself as well. It is still hard for me to decide which I prefer really
I like unreal's split of actor classes and component classes. that works quite differently between actors and gameobjects really.
Unity is a lot more open and lets you as the developer do whatever you want where unreal does guide (and in some ways limit ) you. so long as the game you're making is more helped by the premade tools unreal provides than the engine gets in your way, I think unreal for sure has my preference but if you want to build something from the ground up that goes against what unreal expect you to do, Unity for sure seems more appealing.
My bias but I think that Unity for this sort of game would be a better choice. You don't need all the stuff UE has, of course that is your decision as a developer to make, not mine.
the whole point of taking a 3 month break for me was to evluate this and I've personally come to the conclusion that unreal does offer me a lot of things that I dont have any unity. All the super high end stuff like nanite and such indeed won't help me much, my highest poly models are characters, which it doesn't work on anyway.
However, unreal comes with so many little tools and a solid premade framework which unity lacks, which makes it easier to create things much faster. especially as a 1 man team, that's insanely valuable.
To me Unity felt a bit more natural and enabled me to get my ideas into the game a bit easier. In the other hand the built in stuff in UE is amazing.
That aside, the decision is clear now, Unity's masters showed their true colors and while Sweeney is no saint, he is a bit more in touch with the dev community.
indeed, no company is your friend!! but some can be a bit more evil than other still.
You're right though, unity is a lot more open to developers doing things how they want to do them, instead of pushing them into the more strict and tight framework of unreal, where they do expect you to work they way they indeed you to. that said, for the most part if you insist on ignoring all that, you can rebuild a lot of the premade functions that unreal offers you in your own way still, but at that point you do end up fighting the engine a bit which is hardly ideal :(
This made me want to use unreal.
Very cool!
I really do like unreal a lot!
Yeah, UE is giving way much more out of the box whereas in Unity you have to pay for assets for similar things.
Question: how do you find C++ when compared to c#? As for now, this is the only reason I wasn't using UE because C++ seems to be very unfriendly when compared to C# and Blueprits as you mentioned seems very slow in creation not to mention this spaghetti on screen :)
getting into c++ was a bit rough, mostly i was able to learn c# fully on my own, with c++ for unreal i did look for some help in a structured course to help teach me and once I had that, it really wasn't that bad. Comparing unit C# to unreal c++, you have to learn what pointers are, just so you understand what you're coding but the engine does all the heavy lifting on things like memory management and such, all the things that usually make c++ a total pain in the ass are not something you have to concern yourself much 99% of the time, so at that point it's just a slightly different syntax for some things. If you can get into learning c++ for unreal I highly recommend it, I don't think it's as bad as many people think.
@@thegamedevcave You can make a video explaining this tho, I would like to see the comparison for your migration from Unity to Unreal with the system you use (and it's counter part on Unreal), and maybe a short tutorial for it too
@@muhammadyusoffjamaluddin migrating isnt really a simple task that i think i can make a video on. Its just a lot of writing the same code from c# with a handful of small diferences in c++ which takes a lot of time.
But i do plan on making a video on unreal c++ and why i think most people overestimate how difficult it reallt is compared to c#. As well as make a tutorial series about getting started with c++ sometime later this year
@@thegamedevcave I would say unreal C++ is better than normal C++ with all its standard templates and inbuilt memory management (GC). In regards to BP I think people overestimate the negative "performance impact" which is mainly only an issue if you are doing a lot in tick, use large loops or working with large arrays. The main performance pitfall people fall into is that when you add Cast's in your BP to other classes it created a "hard reference" which means now when that first class loads so does the class you cast to (and any it that Casts to) along with any mesh / texture / sounds you have defined on that second class (are loaded into memory). You can get around this by casting to a base C++ or "code only" BP class or using Interfaces... also extra points if you define the variables that hold the assets as soft references and use async asset loading nodes to retrieve them so you are not locking the game thread because of disk I/O.
holy s*** your underated as f***
Thanks! glad you enjoyed :)
I have been using Unity for long time, and I did try Unreal Engine litle bit, but blueprint was hard :D
interesting to hear! I've never heard someone compare blueprint to unity and come out with blueprint being the hard one for programming. What is it that made it difficult compared to coding in c#?
@@thegamedevcave haha no idea, when I saw blueprint I did quit, maybe in the future I test it again :D
Key fact. Unity doesn't make games. Unreal is used by Valve to ship games (including Fornite). Obviously there are many games written in Unity, but there are *many* game centric things that Unreal does out of the box that some unity developers don't understand... Like efficient space-partitioning of mobile objects, or efficient frustrum culling, or streaming terrain, or world partitioning... not to mention the advanced Lumen/Nanite render functionality in UE5.
There are also compromises in Unity because it's design goal is to ship on any platform (including the browser). Like the weird (and buggy) Burst jobs compiler and system. Many subsystems in Unity are also buggy and/or unfinished and the source license is very expensive.
There are certainly some types of games, with custom shaders and/or custom GPU compute that are easier to write in Unity, and C# is often a more comfortable language for small projects, but I also recommend anyone interested in shipping a 3d game spend some time to build something trivial in Unreal before deciding.
the fact that the people making the engine actually use it is indeed a huge upside for unreal's general usability in my opinion!
Great Video. Thank you.
Great video helps me alot. Will you please share your mining demo project for Unreal Engine so I can learn from it.
the mining game isn't particularly well made, it's a messy rush job so it would be quite a bad thing to use for learning, I do have lots of video's on here that are much better for learning. most blueprint based but recently also started some c++ content :)
I have a feeling you could probably build your game in Unity on top of a free asset called "AnyRPG Core".
best 3d game engine: unreal
best 2d game engine: godot
Yup I can agree on that!
Ok so basically Unreal helps you a bit with the design of your code, by forcing an already made one that is pretty flexible, I'd say that's a good plus.
pretty much yeah! It also comes with a lot of ready made features and systems to work off which saves a lot of time.
unreal's base class is actually object, but this has basically nothing, actor has all the networking and and is the minimum base you can use in blueprints
you're 100% right! if you trace all the parents back you end up at UObjectbase. although as you said, all the interesting stuff is on the actor class and especially for those who work with blueprint, correct me if i'm wrong, you can't make a blueprint on anything beyond actor right?
Still, you are for sure technically correct, which is the best kind of correct!
@@thegamedevcave not sure what you mean, you can make a blueprint parent of any blueprint or C++ class, blueprint child however can not inherit directly from UObject
@@ThyTrueNightmare yeah so for blueprint purposes the most basic thing you can inheret from would be the actor and actorcomponent classes right?
Of course in C++ you can do whatever you want :)
Get ready for an influx of views lmao
Omg you got a good point there 🤣
fr
I've been producing a MMO RPG in unreal since early 2022. Passing the concept phase with a few proof of work concepts. We should talk maybe mix a few of our ideas together if you are interested in a colab.
If only Unreal had official C# support.
that would be great! that said, unreal's implementation of c++ isn't all that different from unity's c#. people are quickly intimidated by hearing about c++, but unreal does make it very manageable!
*EA Unity Be Like:*
nice
So basiclly unreal is better for high end rpg art design stuff. But unity is better for 2d and gameplay creativity. Well i only care whats best for 500 fps shooter. Where should i go? Whats a dev that aint into the mainstream games but only about performance?
godot: it's also extremely lightweight. For me it's simply a better more solid unity
in the end, i dont really think it matters a huge amount, whatever you feel most comfortable working in will likely produce the best restults.
but as a general rule of thumb I believe you could follow this : simplistic looking games (low poly art styles , simpler lighting, etc) will likely preform every so slightly better in unity because the engine as a whole seems less power-hungry. but as soon as you move into some higher quality asset usage, unreal wins in both terms of looks AND performance.
but again, while I think it's an important choice to make, your comfort with the tools you're using as a creator is the first and most important thing, good results will follow from that.
AFAIK, both engine can do whatever you want. It's just one "easier" to achieve things than another.
Honestly I would look into unreal. It's basically designed for building multiplayer FPS games. With C++ and a lot of the built in unreal dev tools, you can squeeze out a lot of performance. Love or hate fortnite, it brought a ton of improvements into the engine making it one of the best engines in the industry, especially for FPS games. But at the end of the day, an engine is only a tool and the quality of the game is determined by the quality of the developers.
heh. 'fuction'
you have no idea how often I make that typo and get confused when my code won't compile XD
haha! It happens. I rarely type the word "because" only once; somehow I always get "becasue" out of my fingers. Your insights into game development is very informative and your presentation is charming keep up the good work! @@thegamedevcave