Unity dev of 10 years currently making the transition. Thanks for breaking it down this way! It feels easier to think of the dot operator as having three different formats in C++. Looking forward to more higher level content! I think a lot of developers like myself are looking for this specific level of content where we are learning how to use Unreal and C++ but not starting from scratch.
with how much love this video is getting, i am going to try starting up more c++ content sooner than I originally planned! lots of it will also cover some basic stuff but I hope it'll still be insightful!
The base C++ is easy and I recommend to study it apart from Unreal at first. Not all the standard library but pure C++. It may take a week. It’s something wrong with it when somebody start to learn “Unreal C++” without understanding pure the C++ language. Besides that even C# programmer knows what is allocated on the stack and what on the heap. So there should be no difficulties to decide where to use pointers and where not to use them.
Is it possible for you to give me some input on this : How did this effect your earnings? Did u had to go from higher level job to intern or junior developer or something?
@F.ELEVEN blueprints != visual scripting, i think thats the biggest misconception with unreal, blueprints are a way for you to template sublcasses. A good way i like to use them is to create a base c++ "gun" class and then create specific guns as blueprints that inherit from the c++ class, allowing me a useful visual editor for changing grip positions/ damage values etc. You can also use them for simpler logic. Cant speak too much on performance but i know they compile to c++ so i wouldnt worry too much about that.
@@monskov I see, so they also work similar to Unity Prefabs! (Still a bit confusing ngl, gotta explore it more) I've seen that blueprints nativization really helps performance, but c++ is usually still 2x faster. For demanding systems that really require that performance I think it should be better. If you have any other helpful tip regarding coding in Unreal would be awesome! Thanks for the advice!
Thanks for the good explanation. Can't wait for your whole c++ course. I'm a full-time Unity dev for 5 years now and the lack of Unreal coding tutorials as well as stack overflow content is really the biggest problem I have with learning Unreal
yeah the community of people to help and find info from is so much larger with unity! (although, I also feel like with how many people are running from unity now, that's going to not be the case for much longer). I already have a pretty good playlist on the channel for general unreal basics, where the coding is done through blueprint but it still shows off a lot of things about the editor and such too :) C++ video's will start up in a week or so!
I have seen unreal tutorials on RU-vid. Not watched them as I don't have 24hrs to spare, but I guess they're little different from online tutorials that all seem to be video based these days. Though I did watch one on bounce physics that was demonstrated using female models. That one was fun.
As a Unity developer for 14 years, and previously a C++ programmer, I can assure you the reason many Unity devs haven't switched to Unreal is more to do with its lack of a scripting language for editor and game. Making the source open for forking is no substitute for a proper scripting language with a comprehensive and extensible API.
@michaelpalmer2143 imo something being 'easier to read' is a terrible reason. I can empathize with how difficult c++ can be to read if using weird modern features, but if you stick to features up to c++ 11 it's really not that bad.
Rather than giving you fancy APIs you can use to make your stuff happen, Unreal simply exposes the entire engine source code for you to use, which is also the reason why the base engine is 15 GB in size. If you want to use UE in Linux, you have to compile UE from source.
That's like saying rather than giving you the keys to your car they give you the blueprints to how your car door locking mechanism works, and a car jacking guide. Access to source does not negate the lack of a fundamentally desirable feature.
I’m about to finish a CS degree and start delving into Unreal Engine because C++ is so far the only language I’ve actually loved, I still have a ton of concepts and things to understand and learn however I found C++ to be a lot easier to pick up over C# and Java. I wouldn’t say C++ is as hard as people try to make it, it gives you every opportunity to absolutely f**k everything up but that also comes with a great level of giving you the developer full control of what you develop which I love.
that's a nice way of thinking about it, it lets you fuck up real bad but that's because it gives you good pretty low level control. the wonderful thing about unreal is that is kind of (as best as it can) protects you from fucking up too bad, but if you want to, it's still c++ so you have all that control at your fingertips if you want to use it
@michaelpalmer2143java should be replaced with kotlin if you ask me Python is good but personally I hate dynamically typed languages and always try to avoid them Because in large projects with no strict type restriction you may see yourself facing type errors a lot
I don't think the issue to switch to UE for the majority of devs on Unity is related to how complicated C++ is. I personally have learned C++ way before I learned C# and have always rated my C++ knowledge higher than C# simply cause I've used it more for way more complex projects. Granted that I with my small team have already switched from Unity to UE about 1 year ago when Unity upped their pro subscription price. But the thing I struggled with most was not getting used to the engine or C++, rather realizing how as a game dev you find yourself having to solve similar/same problems multiple times across different projects. Well, I had put time and effort in order to develop a solution for those common "issues" in a generic way so I can just easily implement them in any project. Those things have added up over time and made my life so much easier to the point where I wasn't even thinking about it anymore, just cause I had my own custom built frameworks and it was neat. The thing is, when you switch to UE you lose anything like that. All the time and effort you've put into creating those frameworks and adapt them to a generic purpose in order to be easily implementable in many different projects, is LOST. I am not exaggerating when I say that the time I lost when switching was in the order of months. To this day (basically 1 year later) I have still not managed to get to the same point I was in Unity when we're talking about those custom made frameworks I had been using. Maybe I could have if I invested twice or triple the amount of time in doing it, but the point is: I couldn't recover years and years of content I have developed in Unity in as little as one year on UE. And that to me, was only reason I struggled with UE projects when I switched (and still do a bit after one full year). So yeah, I would argue that this is the main problem that drives devs to maybe think twice when switching, they simply have put too much time into Unity things that can't be switched to UE. The very very few who don't switch simply cause they think C++ is too hard, are basically noobs. I don't really think they are the majority of people still using Unity.
this is very true, when choosing to switch or not all the little tricks and oddities of an engine you know are the larger issue. but if you're choosing an engine to start with or like in this case, when you're switching anyway and you jsut need to choose to which engine that is, that is where I hear lots of people going out of their way not to use unreal (partly) because c++ is scary. C++ is often in the list of reasons people tend to say unity is easier to learn than unreal. and with lots of people looking for a new engine, I just wanted to make sure I put in my 2 cents on unreal as an option :)
If you take future opportunities into consideration UE has the most potential for building next gen games. Unity is already lagging behind a lot in technology innovations and it will only get worse. Unity is still good for mobile game dev though
@@DhruvRed Unity is fine unless you are building AAA games and there are things you would wish to do for your game but can't cause Unity lacks features. But that might be the case only if you work in a very big software house that releases truly AAA games and *requires* bleeding edge tech. I will strongly argue that's not the case of the vaaaaast majority of game devs. I mean, sure it would be cool to have those new features and all, but if you are working on indie stuff, that's not really necessary and Unity is fine. UE is a superior engine in terms of features, by far the best if you don't have the time and expertise to build your own. No denying that. But how many of the games developed in UE do you think could not be replicated in Unity? I am of the opinion there are very few. Like very few.
@@webrevolution. Yes. When people talk about Unity lacking certain features or cutting-edge graphics, they forget that the AAA graphics you see on engine demos or games are not just because of the engine. It takes a big team consisting of a large number of artists and a big budget to create that kind of eye-pleasing graphics, irrespective of the engine. I personally don't think even a 2-3 member small team, forget a solo developer, could even think of creating and completing a game that looks similar to those AAA titles. A phase all new indie developers go through is that they feel they can replicate their favorite shiny game all by themselves with few tutorials. But once you start developing your own game, you quickly realize you will have to tone down a load of your expectations. Beginners should check all the games developed and released by solo developers and they will quickly figure out what they can build and why the graphics do not matter. IMO, In the past between UE and Unity artists with no coding experience would go with Blueprints, and most developers (c#/java) with a coding background would choose Unity because it was a natural transition and felt most comfortable to use.
So funny how so many videos on my feed are switch to godot, switch to UE. I love how the gameDev community is. I used UE BP in the past, but switched over to Unity because I love C#. Im going to give C++ a shot. I liked BP but I really like scripting over BP
Blueprint is great for implementing final steps of scripting but I personally agree that writing lines of code feels much better for the majority of the time while programming. I can highly recommend giving unreal with c++ another shot if you loved c# :)
I don't like visual programming in general. 1. Takes more time to read what it does and easy to lose the point of whole picture while figuring it 2. More limited as you can't really make any API or something that can be conveniently reused or design the way you would design in code.
I can't really think of anything easier in C++ than C#. At best they are both at the same level of difficulty, but what do you exactly mean when talking about easier stuff in C#? Please elaborate on that in detail. Cause to me that sounds like absolute nonsense, but idk, maybe I'm missing something.
@@webrevolution. In C#, you can also go in greater depths and write "C++" like code. In C#, you can write: IntPtr or int* unsafe stackalloc lock & unlock fixed StructLayout attribute Span struct __makeref __refvalue & __reftype __arglist checked & unchecked sizeof Learning C# with these stuff, can be a bit tricky, then just learning regular C++ code.
@@webrevolution. It really depends on how much of the C# core language you actually know. If you learned just enough to program in Unity then yes C++ would be harder to learn because you probably did not know about some of its advanced features such as pointers. But if you went and learned the entire C# core language (like I did) then you would realize the learning curve is about the same; I actually thought learning (the core language of C#) was harder.
@michaelpalmer2143 I can see why you wouldn't have to think about garbage collection in C# because it handles that for you, but in C++you have to handle garbage collections yourself(well except in Unreal because it has its own garbage collection system.) Or do you mean that you have used garbage collection in C++ so much that you can use it without thinking?
I'm from a java background and seeing for example the c++ source code of tomb raider or mario 64 is just impossible to understand, for me is a really and hard language, thats why i prefer doing engine and small apps in java.
I'm a beginner with no real programming experience. Tried learning both Unity and Unreal over the years. About a year ago I started becoming somewhat confident and competent in Unity and C#. I switched to Unreal using C++ about 6 months ago and with the help of some courses the transition was pretty smooth. The gameplay framework in my opinion is probably one of the biggest things to get a basic understanding of. Worst part about C++ compared to C# from what I remember is that Unity would just yell at you if you had a null reference. Whereas with Unreal if you try to dereference a null pointer you're going to crash the engine. I can confidently say that anyone who is comfortable with Unity and C# is capable of making the switch. If I can fumble my way through as a beginner then anyone can.
I dont make games that make a million in revenue so the unity change does not affect me, but I have used unity for 7 years now and I work as a game developer as my job. I have been thinking of learning Unreal Engine to become more diverse for my career, not as much for personal use. So I will give Unreal a proper shot and try to use it a few hours a week to begin with. Then we will see how it goes
if you aren't affected by these changes and you dont expect to be in the future then there's a good argument to stick with unity. although, i dont expect many studio's will stick with unity so even if personal projects wont reach that kind of money, if you're working a job in the industry, unity skills are going to become less relevant going forward I think.
and even if C++ is too hard almost all games can be made entirely in blueprints which are so much easier than C# but i would still recomend learning C++
@@Eren_Yeager_is_the_GOAT good point. For me, Godot is way more appealing atm since I can use c#. C++ just doesn't have enough documentation or tutorials for me.
Well... Blueprints for ease of access, and then convert portions (or all of it) to C++ (with Unreals inbuilt tools) to make compiling and overall processing easier.
me to , to be honest I just want to cry. I worked in unity for so long. I am a unity certified programmer . I sell my self as a unity dev. sad and painfull...
You’re statement about worrying about memory management and garbage collection is exactly why I’ve been adverse to it. I didn’t realize unreal compensated for that. Thanks for the info.
I avoid using C++ not because it's hard to learn, but because it's painfully slow to compile and get autocompletion, not to mention having to restart the editor frequently when you recompile.
The compile times aren't ideal i'll agree with you on that. But I also feel like , in my experience working with both engines, recompiling in unreal vs reloading scripts in unity when you make a change, unreal is without a doubt slower, but not really by all that much. the only times where compiling takes me a while is when I make changes to a big header file, if you're just working in a cpp file and need to compile changes it's remarkably fast. You also don't need to restart the editor all that often, you used to have to but unreal has had Live Coding for a good while now where you can compile new code without having to restart the engine. Sometimes that does lead to weird errors when trying to read c++ variables from blueprint but that's about it. so whenever that happens and it's about variables that are relevant to your current testing, you still need to rebuild from source and restart the editor but that's all together not that often in practical terms.
Forgot to mention that a pointer without UPROPERTY or TStrongObjectPtr does not prevent the object from getting garbage collected. To prevent an object from getting garbage collected, you have to use UPROPERTY or TStrongObjectPtr. For example, storing a sound in this variable does not prevent it from being garbage collected. A naked pointer is "basically" the same rules as TWeakObjectPtr. USoundBase* ImpactSound; But this would prevent garbage collection. UPROPERTY() USoundBase* ImpactSound; This would work as well, but can't be exposed to blueprints. So the UPROPERTY macro is usually the goto for me. TStrongObjectPtr ImpactSound; Also, great video!
"Looking for a different engine right now?" How did you know?! Not quite now, but seriously considering it sometime after the current project is released.
Ooooh. I look forward to watching your C++ course. I've been programming with JavaScript and python for 20 years. And dipping in and out of C++ for a year or so and it still has not clicked for me. But good to hear someone say it's easy. I have still not seen anything in C++ that was really cool that could not be done in blueprints (for the specific game I am building). So I hope you come up with some useful examples as I need inspiration to get back into C++ and I'm pretty sure I will need it to do networking at some point for online coop as I think blueprints might not be enough.
for the most part blueprint can really do anything you need it to do, i've run into a few niche things that it won't let you do (writing and reading files from disk aside from save objects, nested arrays, a few functions that have more input parameters than their blueprint versions , but nothing major). So for me it comes down to a preference and speed thing, i can type code at roughly the speed I think at, blueprint i can't create as that speed. Dipping your toes into a bit of c++ can be good for those rare cases where it's actually needed but for the most part, if you're comfortable with blueprint that's perfectly fine :) As far as networking goes, I personally haven't really bothered with that (my game is very much a single player thing) but I do believe you can get a good amount of stuff done for that in blueprint too from what I understand
@@thegamedevcave Yes absolutely, I saw a blueprint talk a few years ago by "Sjorn" i think his name is who is a Unreal expert working for the company and he was saying the same things you just did about how blueprints can do virtually anything in the Engine. And that there is a misconception about blueprints being less performant. That talk was a big reason why I chose Unreal over Unity. BP are a little slower but something like 5% compared to C++ so for the most part it really does not matter for a lot of applications and you can convert them to C++ later if really needed. The main thing to avoid is adding lots of things to the tick and there is loads of ways to avoid that. And as for the loading from disk that is also a reason I want to learn C++ for a second smaller project I am working on for Andorid/iOS/Quest which is currently using a GLTF plugin from the UE market place which lets me load in my 3d objects from my web server which is a great workaround but managing those files on disk really needs some C++ skills and really I would rather just do it all in C++ at some point as I think it will give me far more options for downloading the files and login/username/password management for players as well as security. I look forward to seeing what you share, it is most appreciated.
For me it's not so much C++ that discourages me (I have extensive C experience and C# experience, somehow never got into C++, but it won't be hard I reckon), but the different workflow/tools. I mean, I adore C# so it is a factor too, but it's mostly having to learn a whole new editor and it's bits and bobs. I'm still committed to my current project anyway, but this helped me put Unreal on the table for future projects at least. Cheers
I'm hearing that a lot of this extra stuff to deal with is "not that bad," but I'm not hearing any *benefits* to C++, which makes me wonder what the point is in using that language in the first place.
oh i am 100% with you. the benefit in theory is marginal performance improvements *insert lots of overly technical BS about compiling languages* and c++ gives you some more low level control compared to many other languages should you want to use it. for 99% of game devs neither of those things really matter to be honest. and I do think it's kind of BS that unreal doesn't let you use c# instead. At least from an optics standpoint because their implementation of c++ is pretty much just c#, many people dont see that though because they see c++ and stay away, so horrible choice on epic's part. Either way, I agree that there is no REAL good reason epic forces c++ onto it's devs in the first place.
You should note C++ returns values are kinda special because all objects inside a function get destroyed at the end . Not sure how it is in Unreal but in vanilla C++ you get shallow copy back instead of object reference like in ALL other OO languages. There are tricks to by pass this but if you don't know this it can cost you a lot of time.
aaa I woudl not use that ALL in caps, there are other languages that do not have reference return by standard. Also You are mixing things. C++ have explicit differentiation of STACK and heap: MyObj* give_me() { MyObj* obj = new MyObj(); return obj;} for example.. this destroys NOTHING. Memory allocated in stack is released after a scope delimiter is reached. So the POINTER is detroyed, but object lives adn the copy of the pointer is returned and still points to the same object.
All modern C++ compilers support copy elision such as NRVO and RVO. In many scenarios, having an unmanaged, mostly stack-oriented dataflow, which is where C++ shines, will always blow its managed competitors out of the water, if for no other reason than just cache locality. On the other hand, managed languages such as C# are less prone to memory fragmentation if your app moves around huge troves of data with a lot of allocations / deallocations. Pick your poison.
@@StasAnisimov The advantage of C++ side is.. with more skilled developers you can mitigate all C++ issues . More skilled managed memory develoeprs cannot improve their problems.
Thanks just this video alone has given me some understanding of how C++ translates from Unity C*, more direct translation videos like this would be handy.
for many things the whole architecture is so different it's hard to really compare. Unreal uses a whole hierarchy of different classes to build up the framework you'll be working with that unity simply doesn't have. Gameobjects are like actors. but then actors have child classes called pawns that can be possesed by a player controller, which is not just a script that takes palyer input like you may be used to in unity, it's a whole object in itself that gets linked to a pawn, "possesing" it. same thing goes for AI controllers. Good news is, all that engine stuff that's not c++ related, I already have a lot of content for on this channel with a beginner's course taking you through the way unreal works as an engine in broad strokes There's of course a million different little things that dont really have direct comparisons between both engines, which is the much harder thing to learn than c++ if you're switching. the C++ vs C# side of things is just a matter of things having slightly diffrent names than you're used to. Vector2 is called FVector2D. Vector3 is just called FVector. quaternions are FRotators (more or less anyway).
pointers : there a simple criteria (a bit oversimplified but good to start with) * if its (child of) uobject use pointer * everything else use normal variable * for structs you can optimize passing by const ref, or by ref if you want to modify it. also remember to always put a UPROPERY on uobject pointers. it will automatically avoid dangling pointers.
Wow, a very good and simple summary of something I tried to explain to people started with C++ with a lot of struggle. You did it perfectly and now I can just send them to this video 🙂
You were using Unity before switching to Unreal, right? How fortunate that you did so when you did, I can only imagine the setback it'd be to have to switch with how much progress you've made now.
yeah i was in unity before, the news of unity's new pricing made me both really sad but also very relieved I spent the last 4 months rebuilding in unreal instead of making even more content in unity!
It's not about c++, it's about the feedback loop. C++ compilation is slow. Sure you can use some kind of hot reload with c++, but hot reload in c++ is just a duct tape. Sooner or later the hot reload will corrupt and you force to restart the editor. (Which is the annoying process) And by the nature of hot reload, the thing you working on is not deterministic. If something gone wrong, you aren't so sure if it's just the code you write that cause the issue or the hot reload corrupt. You can clean compile again right that moment and problem is magically gone, then you know is a hot reload gone wrong but it defeat the point of using hot reload in the first place. To save you an iterate time. So you either ditch the c++ hot reload stuff and pay for the compile time or deals with hot reload undeterministic nature. These two options is really frustrating to work with.
I just code small games for fun as a hobby. I enjoy solving problems and coding lets me make my own problems. I don't really plan on monetizing anything I make, But I've already looked into switching to unreal multiple times in the past. I guess this was the final push to do it. It really sucks losing years of work in not only just learning C# but also the tons of generic helper scripts I've wrote and use or reference. Great video though subscribing for more unreal content in the future.
yeah losing out on all your backlog of code you've been using is a real pain :/ If you're not expecting to monetize what you make there could honestly be a good argument for not switching. but (and i'm a little bias here) I also think unreal offers so much cool stuff that makes it worth switching over :)
Nothing changes for you. Unity will start charging you if you make over 200k in revenue AND have 200k installs. Since you're making no revenue, you will never achieve both of these. But change to Unreal if it makes sense for you anyway!
@@unclejacksimulations9423 My thinking is that the engine will continue in a downward spiral. If everyone switches engines they're gonna have less money to keep developing new technologys. Asset creators will leave etc. I could be over reacting some, But if this change goes through in 5-10 more years i think unity will be so far behind I'll end up having to change anyway.
@@Horse4lunch Unity has already been neglecting features, Unreal 5's tech demo is still amazing to this day, and Unity has had 3 years to implement these features, yet they've choosing to go down the parasite route of providing live services that no body asked for from a game engine.
If you are just doing things for fun and stuff you can try some other C# engines too (Flax Engine or Stride3d) are options you could look into also Godot does have C# support.
Blueprint is so powerful in unreal, and the fact that many people understimate its ability to make a full actual AA to AAA without C++, soley with Blueprint, baffles me hard 😢
blueprint is brilliant and you can use it to make pretty much whatever you want. If you prefer visual scripting it sure is an option but it also has some downsides, like how it becomes hard to read, it's easy to get your graph looking very messy, it's much slower than being able to type code and so on. Ideally you want to use both together, they both have their place.
It's not so much about C++ for me, it's more about the fact I prefer stylized graphics over realism. I heard the analogy that using unreal for a 2D or LowPoly games is like driving a Ferrari in a school zone. Unity was the perfect midpoint between 2D specialized engines like Godot and 3D specialized engines like unreal. I don't think anything can replace it right now. I hope unity takes a close look at themselves or another company comes to pick up their niche.
that's a decent way to put it. you can very well do stylized graphics in unreal (look at games like Crash bandicoot and spyro remastered triologies). I am working on a pretty stylized project right now but it's not particularly efficient, but for sure the engine is made more to make realism easier.
Started with scripting python back in 2008~, I've since learned Haskell, hacked on JS, did a course in c#/dotnet and did one project in f#, contributed code to projects written in Nix, C++, Rust and C including the *Linux kernel*. Being scared about transitioning from one statically typed imperative OO language, to another statically typed imperative language, always amuses me. The hardest part about coding is learning to code your *first language*, And yet so many have less confidence approaching a new language than they did with their first. You already learned to code, you just need to learn new syntax, a new website for library references, and about the few gotchyas (like manual memory management) and quirks (how for loops work etc, wtf is a goto). ***YOU WILL BE FINE***
im all for going unreal engine, but the problem is a lot of devs starting out dont have the type of pc required to use unreal engine to a dgree where you dont want to pull your hair out. my pc isnt awful and i still get crashes, compiling shaders for an hour after every other little change. you need a beefy pc going to the c++ side of things the documentation was abysmall 3-4 years ago and it is still subpar going into it now. most of everything out there is preaching the gospel of how amazing blueprints are, even tho many devs would like to code and are 10x faster coding it. not hating on unreal, im currently engineless and looking for a new home , but these have been the issues i have personally been facing
unreal isn't a perfect solution, but no single engine is of course. that said, for a company swimming in money, you'd think epic would pay someone to fix up their horrible documentation, especially since unreal 5 was released a while ago, which gave them the perfect chance to go through everything and improve.
UE might eventually add C# scripting support. C++ is very similar to C# in terms of syntax but there are other complicated layers that someone is new to and might feel overwhelming when faced with those
they are developing their own scriptin language that's already in use in unreal editor for fortnite, so most likely once that has matured a bit more it will be added into unreal engine proper instead of c# support.
As someone who knows c#, c++ c and python, yes, yes it is. While they have similar syntax, c# if far easier and safer, it has a garbage collector, you are encouraged to use the limited standard libraries that do only one thing each, it has safe c style casting, it has python style references, it manages memory safely, it doesn't set you pc on fire when you type a for loop wrong, and much more.
I make my own little side-project game from scratch in C++ no engine, C++ certainly has a learning curve and sharp corners, but even from scratch, C++ is nowhere near as bad as people think. When people describe C++ you'd think they're talking about COBOL. It's not because C++ let you write preprocessor macros, raw pointers, manual string manipulation and Turing complete template boilerpasta that you have to riddle your code with that. They're nice to have when you do need them, but in modern C++ you can go very far without those.
It's hard when you can't find tutorials that are easy to understand. Even Unity has many bad Tutorials, but the ease of C# helps a lot with this. It takes a few seconds to script static variables that persist between scenes in Unity, but it takes forever just to find a tutorial on how to even do this with Unreal. Many tutorials are super confusing and seem way too convoluted to get basic things done, when many basic things should be simple and easy to understand.
Unity tutorials are very much easier to find, although i do think over the next months and years that will change. For the most part following blueprint tutorials should also help with c++ coding, nodes are just functions in the end of course, although you might need to go look through epic's documentation to find which header files to include to get access to some of them which can be a pain.
never claimed c++ is easy, i'm saying unity devs who are affraid of moving to unreal with c++ as a reason need to take a step back and actualyl look at what c++ in unreal is like. normal c++ is a nightmare. we're not talking about software engineers here, we're talking about people who solo develop or work in small teams that need to program a game, in which case, using c++ in unreal isn't as bad as people make it out to be.
I learned how to program in C, before I learned C++, although its been some time its not that hard to pick up again. The only concept that didn't make sense to me was when I was learning C++, was dynamically allocated linked node lists, where you have a head and a tail with nodes in between that you subtract and add, and traverse through. It can get worse than that. where each node become the head of another dynamically allocated linked node list that you connect to. Thats the only concept that still eludes me, today. Some people may argue that you dont need to learn C before C++, but I believe you should. Because everything in C can be done in C++, and its easy to adapt C into the language C++. Now, if you want talk about a programming language that is hard to learn, pick any of the assembly languages for a specific CPU type and brand of any age ( new or old ), and you will discover the meaning of "unforgiving" with a new context, when you make a mistake in assembler code.
all this is what makes c++ a pain to work with and why I myself wouldn't really consider myself a c++ dev, because aside from unreal i dont tend to touch c++. because frankly, i dont quite understand half of it. at least within unreal the engine takes all that stuff and takes care of it for you. whenever I code something outside unreal I do in fact use other languages.
I actually thought assembly language was easier to learn than C or C++ on stand-alone microprocessor boards. I never did much assembly language on an actual computer except when I was in college.
@@thegamedevcave Most programmers will settle for learning C, which can be used from a C++ compiler without C++. The hardest part about C or C++ is understanding pointers and their use with arrays. When I was growing up, I was learning Commodore Business Machine's BASIC, which I discovered was a license of Microsoft's BASIC, on the Commodore PET 2001 series, Commodore 64, and the Commodore Amiga. It was terrible - spaghetti code prone and was always interpreted not compiled as its was intended by Kemeny and Kurtz. It took me 3 times, or 3 years to adapt to learning the language C because of this switch. From there on, I started to learn a more organized system of programming in C which allowed me to do things. It was able to do the same job that I needed done in a fraction of the time, that it would have taken in BASIC. I never touched Visual BASIC, that programming language is a Frankenstein of many language concepts put together. However, regarding C++ or C, it takes a dedicated practice of playing around with it in a non-game engine environment to understand it ( e.g. the gcc compiler on Linux ). So while you may argue that C++ is a pain to work with, I will argue that BASIC was a living nightmare before C existed for Commodore Business Machines. It was either BASIC and/or Assembler for developing games on that platform. Game engines did not exist at the time.
@@dougwarner59 On smaller systems or platforms, such as small devices, assembly language is not that hard to learn, but when you deal with the more complicated CPUs with multi-core processors like intel i9 or AMD Ryzen CPUs its totally different. In addition, you have to be aware of the differences in CPUs, RISC and CISC architectures. Also, AMD and Intel are not the only brands of CPUs that exist, they are just the most popular ones used for computer motherboards that you hear of.
Subscribed! I'll finish my Unity game hopefully in a year, meanwhile I'll be watching your c++ and unreal videos. I know it's a tough ask but adding some direct comparisons to unity and c# would be a blessing. Cheers mate
where possible I'll try to use unity as a reference point but for the msot part you'll find things are mostly the same, other than the very basics like how unreal has a inheretence structure for it's actors rather than just purly component based systems, those kinda of thigsn are the most important differences (which I already have a video on) aside from that pretty much anything you got in untiy just has a slightly different name in unreal. (Vector3 being FVector, Vector2 being FVector2D and so on)
And Godot can use C# Switching to another engine, the big difference are the APIs, not the language. You might be able to write a singleton that ""converts" the API calls. On the Level design, I think that exporting to Blender and then importing might be the best way.
the initial compiling takes a good amount of time, which is a real downside on a low or mid range CPU for sure. but once that huge build is done, compiling any new changes from there is much faster. usually for me after I spend a lot of time coding on a new class, it takes about 8-10 seconds to recompile (on a 16 core CPU so it might be a bit longer for many people), when I just make a little change to an existing cpp file, it complies in about a second or 2.
To be fair the UE cpp library is quite a lot easier than standard cpp. UE does most if not all malloc for you, which is the hard part of cpp. Memory allocation. But yes, UEs cpp lib is not that bad at all.
I am also currently looking at godot and unreal. And after looking at different workflows I think unity initially has different workflows for user convenience it feels good at start but sometimes it does more damage than good.
@@ArtiCast Right now I am learning both, plan is to use unreal for high-end 3D games and for simpler 2D and 3D games I will be using Godot. My on going projects are in unity so I will continue using Unity till mid 2024. And as unity as reversed changes I might also use unity after that. But this thing has motivated me to learn both of the new engines.
As an additional note, the unreal blueprint is also something that we need to discuss. The way that it works (if I remember), is that it behaves like a prefab in unity. However, imagine if every single prefab has a "Component", which enables you to code your "prefab" like it is a Lego Mindstorm. So every time you create a "prefab" (you must create it), you could make a flowchart of nodes that makes the "prefab" do something. Oh yes, there is also "void start" and "void update" in unreal. Don't worry about it.
yup! it's something I skipped over here but it's entirely possible to make a full game without ever even touching c++. I believe fortnite is entirely made in blueprint for instance.
Yeah... so some c++ conventions are obsolete. Specifically, defining classes in an hpp file and then defining class behavior in a cpp is not necessary any more. You can just declare everything inside of the class and the parser doesn't care anymore. You can essentially create classes in c++ exactly how you do it in c# Doing this also simplifies compilation. If I have only hpp files, then my compiler command is "g++ -o main.exe main.cpp" but if I used separate CPP files for function definitions instead of just putting it in the hpp file my compile command becomes "g++ -o main.exe main.cpp abc.cpp xyz.cpp qxz.cpp etc.cpp...."
my issue with blueprints is that they are unreliable when using them on large projects. sometimes, a blueprint will get corrupted and you have to completely rebuild the blueprint by hand. it happened about 3 times on a large project. the thing is that there is no indication that the blueprint is corrupted. you will just get a very strange bug and after like a day or two of incredibly frustrating debugging, you find that inexplicably one of the references to an actor on your blueprint is no longer working. and rebuilding the blueprint makes things work again. there’s also the issue of version control with blueprints. since it exists in its own proprietary world it isn’t very compatible with Git. working with multiple people starts getting tricky. and there’s no elegant way of merging changes between two branches. the blueprint corruption was also quite an issue when upgrading engine versions. i loved the hell out of Unreal. but as an indy dev there were some serious show stoppers along the way that no one seems to talk about.
Agreed, in general it's not too much worse than C#. Until you run into a linker error or the first time you forget to add the UPROPERTY() macro to a pointer and your game crashes after a few minutes and you cannot figure out why. There are a few gotchas but it's definitely doable.
literally had this issue yesterday by chance where i forgot to add UPROPERTY() to an array of pointers to a certain actor , then packaged my game and suddenly it started crashing every few minutes... As much as I am happy that unreal does garbage collection for us, it can also really fuck you over when it decides to destroy things you were intending on still using XD Luckily it's an easy fix once you figure out the issue but it's so easy to forget while coding!
Godot also seems like a great option! from my understanding it's a bit less ready for large 3D games, but then again, unreal isn't really great at making 2D games. it's possible, just clearly not meant for it. so I'd say that might be a big part of choosing one over the other.
unreal is great, but at the end of the day, unreal can have the same issues as unity, its proprietary and owned by a company, so they can switch just as fast as unity did, godot even if it gets bought by a evil corporation and made proprietary theres is always forks and a community behind that will simply stop using the proprietary fork and mantain their own open source fork
@@GabrielM01 Also means great support as large number of devs are working on to improve the engine, which won't happen that quickly in opensource engines
Video title's a little misleading, but I appreciate the breakdown. I'm switching to Godot as my new primary game engine, but I'm also eager to learn how to use engines in case I need to use a different tool for some reason or something goes wrong with Godot.
I honestly dont think the move from C# in unity to c++ is unreal is a particularly difficult one. people freak out when they hear c++, i personally made that transition and as I say in the video. of course there is some adjustment but it's really not that bad. All that said, Godot is probably the safest from corporate BS like what Unity did yeah XD although from what I understand it's 3D isn't really up to unity 3D
I have feeling I will coming back to this chnanel as my animation degree is getting us to make a VR game in unreal over the next 10 weeks. I look forward to seeing your courses and learning from you
if c++ isn't a requirement , blueprint is always a good option with somewhat lower barrier to entry (i assume if you're doing an animation degree you wouldn't be forced into writing c++) for that and lots of unreal engine basics I do already have a playlist of the basics on the channel too :)
@@thegamedevcave yeah Blueprints in unreal are a life saver (especially for not complex projects) and if you don't know C++ but saying that I am trying to learn C++ in my own time as we have a capstone project for our final year and my goal is to create a game so I have to learn the joys of coding haha
Honestly, Unreal Engine C++ is really different, I made a lot of vanilla C++ in the past and this one is actually a really simplified version in comparison, if you try to make some complex projects in vanilla C++ I can assure you that it's start to be a little bit harder, in the way that you will discover new things basically everyday, when C# is way easier to learn and be familliar with. UEC++ is closer to C# in the way it works, for example, the usage of macros in UE (UCLASS, UPROPERTY, etc...) is the equivalent of the C# attributes you put on top of a function or variable. Also Garbage Collection is supported directly by UE.
does UE CG collect all objects that are not being used anymore or just objects from the unreal libraries? I mean what if i use some built-in c++ function that returns some built-in type that needs to be deleted later, or say for example I use the malloc function (sorry i don't know anything about C++, i just know C), does UE take care of that or do i still need to free that myself?
@@medo_0x00 What I know is, if you don't specify your variable with "UPROPERTY" UE is considering this variable to be garbage collected automatically ! So that's probably not an issue with other built-in C++ functions.
Hey man, you got no idea how useful this is to me, really nice. Still wouldn't call it a tutorial but it's nice to have someone to give you a comfortable pillow while reading the book, thanks!
Unity did the documentation and integration with Visual Studio REALLY well. That's why programming C# in Unity is a million times better than c++ in Unreal.
unreal's documentation leaves a lot to be desired I agree but you can press F12 (or whatever shortcut you have this set to) on literally any fuction to see the source code, which also includes the full documentation that's found on epic's website. That's pretty nice really.
So header files are like taking abstract class declarations in C# and the top slice of a normal C# class with your variable declarations and moving it out into a separate file?
This video is super helpful! What VSCode extensions do you use for this? I prefer VSCode over VS, but I can't find any up to date tutorials on setting up VSCode to handle Unreal development.
The architecture is a bigger concern than syntax. Comopletely different architecture. Took me years to come up with architecture that works well in Unity.
I've been learning to program my game with c# in Unity for some time now. But always wanted to switch over to Unreal to utilize it's new features. Coming from a tech artist background, c# was very easy as a first language to pick up. But thank you for explaining this. Was planning on staying in c# a bit longer before attempting to port over. This made me confident enough to start now instead !
i ported over after 3 months of work ui unity a while ago, all I can say is, if you're planning to move to unreal eventually anyway, better sooner than later :) it'll be a rough start to switch engine no matter what, but at elast you won't have to redo as much work ;)
Have learnt C++ last semester. Pointers and memory allocation is ass if you don't know what the hell you're doing. I didn't, but after some time i did understand all of that. And i'm still a big fan of C# (or Java) when i was learning Unity on a course a few years ago!
It's not the language that's the issue for me, it's finding the documentation. I can't even find information on making simple scripts in unreal, it's just all BP tutorials
I've been using C and C++ for years and even still now it often twists my brain into knots, or I forget to free something. I've never tried a game engine before but being able to do all the powerful C++ things while having the support structure of Unreal sounds very appealing. I'm excited to try it out!
i am the other way around, i've only ever used c++ in the context of unreal. And frankly, I wouldn't dare call myself a c++ developer because if I had to deal with all that without the premade structure that this engine provides me with I might just blow up my PC XD
Even vanilla (modern) C++ nowadays can be difficult to get memory leaks with if you utilize smart pointers. It's definitely come a long way as a language.
Oh it is a disaster of a language... and this coming from primarily a C++ dev who's been using it for over 20y now. You can stick with a small subset of the language and get by, but every new update the committee goes out of their way to make it more and more of a mess.
in this video I am specifically speaking on using it in unreal engine, I am not much of a c++ developer outside that honestly, i do believe you when you say it's a disaster of a language but within this context it's not really too bad.
For me the experience of "Blueprints" (gets unreadable if complex code) + "C++" (very slow compile time) in Unreal is not as good as with "C#" in unity.
C++ is no big deal. Just ask C++ devs to explain the difference between: Little endian vs big endian __stdcall vs __fastcall vs __cdecl vs __thiscall vs __vectorcall How multiple inheritance works Or the difference between a Dword and an unsigned long? Everything else not really a big deal.
All my current proffessional / hobby projects are in Unity. Everything I've done was in Unity haha. I would pay a lot for a course that teaches advanced UE alongside Unity. Most tutorials will only teach you the basis, whereas most of the people making the transition are experimented devs needing more in depth courses. I have a question for you : I have a lot of options like remote configuration and cloud saves in some Unity projects; is that feasible in Unreal? If yes, how would one approach such a subject?
Modern C++ isn't too bad. If you're using "new" in your code then you have to manage that object's lifetime. For anyone new to C++, std::algorithm is nice and Kate Gregory has a set of courses on pluralsight to fill the gap. C++ also has a spaceship operator
@@thegamedevcave If you're amused by the spaceship operator, ML style languages let you define your own operators, And there are even search engines for these languages designed to help search library references for the operators since google isn't very good at that.
I'm not so sure yet about C++ implementation, but you just need to delete pointer that you have allocated in memory, because they are out of scope variables, normal variables are attached by their scope and get destroyed when their function end, you can also create an object directly on the stack, so there is no need to use pointers in your code unless you are calling Unreal api but because Unreal take care of it you are safe I guess.
@@nand3kudasai Well not really. "In Unreal Engine, the Garbage Collector (GC) primarily manages the memory used by UObject-derived classes, which are a specific type of class used in Unreal Engine for things like actors, components, and other game objects. The Unreal GC does not manage memory for raw pointers allocated with C++ new or malloc directly. f you allocate memory with new or malloc, it is your responsibility to free that memory when you are done with it using delete, delete[], or free in the case of malloc. Unreal's garbage collector won't automatically delete or free memory for raw pointers. However, if you are working with UObject-derived classes, the Unreal GC will automatically manage their memory. When you create and reference UObject-derived objects using methods like NewObject or CreateDefaultSubobject, the garbage collector will keep track of their references and automatically release memory when there are no more references to the object, following Unreal Engine's reference counting system."
I still consider myself a huge beginner in this; but to this day I didn't find anything harder in UE than Unity. I don't get why people say Unity is easier. Faster? maybe. Easier? It depends if you want to do or if you want to understand. In this sense, the stricter "structuration" of C++ is very helpful to me. I know it's not the case for everyone, but I need this clear framework before I can be comfortable with faster languages that (seem to me) take implicit shortcuts
i fully agree with this angle to be honest. i hear people calling unity easier and faster and I personally don't see why. I've used both and the only reason I can see if that unreal overloads you with possibilities and features and forces you more into their framework. which can make things seem more rigid and complex. Depending on what kind of game you might want to make I can see ta scenario where you'd be fightign against the engine, at which point unreal indeed wouldn't be a good pick but for 99% of cases, I honestly think people are intimidated more by both unreal in general and c++ than they should be. The way I tend to explain this is : well unity is a lot more open but it makes you code a lot of tools that unreal has by yourself and the developers at epic games are WAY better programmers than I am so their ready made solution is probably better than what I'd write anyway.
I think it's a historical issue, back when unity was released c# was touted as the next big thing. That reputation is still with us despite how bloated it has become.
like when it takes you 10 secs to write in unity it takes 10 minutes in unreal it takes forever to compile shaders. its much more easy to deal with compute shaders or whatsoever anything render related in unity in unreal its possible but you have to work with a lot of dumb shit like modules stuff and shit literally doing the same thing would take so much less time in untiy than unreal. i mean its a nice engine but takes a lot of time. and since i like to fiddle around with shaders, its so slow that i hate it. why does it take ages to compile a shader that does only return a fixed color? theres not a single time that i dont find myself cursing at the engine. C++ is not hard at all. also, i think its better because in C# you can't copy a Transform right? its always a reference. i struggled with this a lot. in cpp you can just memcopy. and thats it if you know basic cpp. cpp side is always better as you have more control. the stupid side of unreal is the pipeline and the structure and stuff you know. no one actually blames of cpp. everyone knows that its better. and the engine shuts itself down. it has so many bugs. like when you have a window open and you do something about that window without closing it then the editor just crashes with a null pointer exception. even the editor itself is filled with bugs. its so easy to lose your progress when programming in unreal. its good but its like a hell to use. thats why i hate it. but i use it too. so idk. i will never be one of those "i love unreal engine" gang.
My main problem with Unreal, while I think it's a very beatifull engine to work with, it produces executables with huge sizes, and for indy projects may be a drawback.
compared to unity theyre still bigger but in unreal 5 is seems like the exe files producer are a lot smaller than they used to be. For things like gamejams , where upload time can be a total killer, it's a real pain to deal with, if you're just making a game for release though, i personally don't really see much relevance in file size, you're never going to get to the 100+GB that lots of modern AAA games get to which people are getting more and more used to, I can't imagine you'd lose many, if any, customers to the file size of your game.
“Hard” is relative. C++ definitely a bigger learning curve. To say otherwise is disingenuous. Over the course of my career I’ve worked in several different languages: basic, pascal, Fortran, PL/1, C, C++ (for 9 years), C#, etc. without a doubt, C# is the most enjoyable language I’ve ever used. Epic games is less than 5 miles from my house and if they were a C# house I’d be banging down their door for a job. But I have no desire to go backwards and start working in C++ again.
I have been doing C for some time now (1,5 year) and i absolutely hate CMake and header files structure, is header files really that important /usefull in c++? Right now I’m leaning against C# because it’s easier to understand with scripting compared to the structure of C++
this video is specifically talking about unity developers who avoid unreal because "c++ is too hard" and how unreal really fixes all those problems. Outside of that context, yeah c++ is a lot more of a headache than c#. Anyway, header files aren't technically required but i believe they are split between .h and .cpp files mainly for compiling speed. since a cpp file would only contain implementations and not members, recompiling just that is a lot faster.
It is though. C#-based games don't crash as often. But in C/C++ one askew int *ptr and it's SEGFAULT town. Pointer arithmetic is something that no programmer should be forced to partake in.
i will admit that causing crashing due to nullptrs is really annoying. but it's also really easy to write an really return or if statement to check for nullptrs. And looking at it from the other angle, if a varaible has a value you dont expect and weird shit happens because of it, that can be MUCH more troublesome than just seeing a crash and thinking "oh right, nullptr"
@@thegamedevcave I was talking about other stuff that can lead to segfaults, not just nullptr. I've tried once to make a game with Allegro framework. Had crashes in the audio modules (access violations and subsequent segfaults). Turned out it was crashing because of the way I've initialized my BITMAPS. What bitmaps have to do with audio in the Allegro framework, I have no idea to this day. But yeah, null pointers are the easiest thing to protect from, just as null references in C#. It's all the other stuff pointers can cause that leads into the pointer hell. Though my experience with Unreal might be a little bit colored at the moment due to what I went through during my switching stream that will be put on YT as well.
Dear whoever you are: As someone who has used both C++ and C# for over 15 years, C++ is much harder than Unity. It doesn't seem that way because we have training and practice, but C# is vastly different than C++ with a tougher syntax and lots of 'gotchas'. There's no garbage collecting, and the Unity runtime provides a TON of features which are not in C++ without involving engines and libraries. Don't forget there are thousands of very specific and complete tutorial videos for everything you want to do in Unity, and a very scattered pile of C++ tutorials for various custom engines, direct rendering with OGL or DX, and only a handful specific to games that aren't just basic Unreal C++ Getting Started videos. Unity is a great loss to the game dev community. It was THE entry-level dev platform and it was good at it.
from this comment I assume you've never worked in unreal engine or possibly even watched the video? I make it very clear that there's a world of difference betrain base c++ and unreal engine c++. The lack of garabage collection is one of the biggest things that makes c++ a nightmare to deal with, unreal pretty much fully takes care of that for you.
What are your thoughts on using VS Code for Unity coding? I'm using VS Code in my job for web development and I want to try Unreal, but full VS does not convince me and I can not afford Rider.
VSCode works perfectly fine for me, although the intellisense is real slow for me when using it with unreal for some reason which can be really annoying.
