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!
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
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 RUclips. 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 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.
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...
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.
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.
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.
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.
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!
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.
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
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?
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***
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
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.
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 🙂
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.
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.
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.
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)
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.
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).
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.
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.
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.
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.
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!
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.
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.
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.
I was following an UE5 course that focused on teaching c++ but I hated two things, maybe I made a mistake or I just don't know enough or how to set it properly, I would really appreciate any help but, everytime I made changes in visual studio and saved before playing, it took UE5 like a whole minute to compile before I could test the game (something called "live coding") ??? so if I changed anything and saved again, 1 more minute? it drove me nuts. 2nd thing I hated is, you made some variables public in VS to change them in the editor (like serialize field in unity), you set the values in the editor, save your project and close UE5, and when you comeback, those changes you made in the editor are now gone? you have to compile again but the values might not be right or I don't know, it felt like working with c++ was a pain in the a$s. Thanks if you read me.
live coding doesn't actually build changes to the engine so if you clsoe and re-open the engine those changes will be gone. that's by design. You need to build from VS to permanently add those changes to be available in your editor. There also is an option in your project settings that will force a rebuild every time you open the project, which can be nice for this kind of things. but do be aware that if you enable that, the project can't open if you have any compile errors in your code, so that can be a pain. Compile times that long are a bit strange. Assuming you dont have a super low end CPU at least. One thing that I can think of that might cause something to compile that long is if you changed a few .h files. changes in .h files take much longer to compile than changes in .cpp files. In general when you're troubleshooting and recompiling very often, that should be mostly changes to .cpp files. so hopefully that's part of the problem but i'm not sure
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.
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?
well, I've always wanted to learn C++, might as well do it now. a few questions though, is the header file like an interface in C#, or totally different? and how does inheritance work in c++, and does it mix well with blueprints in Unreal?
the header file is reasonably close to an interface in c# i believe. the main thing about it is that the class itself lives inside the header file, then you include that header file in your cpp file and you can create the implementations for it there. This helps with compiling since you don't need to recompile the actual class any time you make a change, only the much simpler .cpp file that has the implementations. Inheritance should work pretty much like you're used to. a child will have no access to private members, only to public and protected members on the parent. methods you want to override in a child should be marked as virtual. C++ works great in combination with blueprint. you code your classes in c++ and then make a blueprint class inheriting from that. here you can give all the values you need to whatever variables you created and exposed to the editor and if you wanted to even add some extra blueprint scripts. any member you expose as a UPROPERTY or UFUCTION you can access as long as you're giving it the right permissions (unreal's documentation has a page on this). The only thing that doesn't work as well is going the other way around, making something in blueprint and feeding that back into your c++ code, while possible in many ways, is a little clunky but you probably dont want to do that too much anyway.
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 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.
i have a legit question! its been bugging me since i've tried Unreal in the past. i was willing to learn C++ because Unreal has its own QoL improvements, but every time i wanted to test the game it would take quite a while to load. im not saying Unity is the fastest to test and debug, but Unreal really did feel slow and idk if this is normal? or is it a Blueprints/C++/Unreal issue? i know C++ is the best at game performance, but i value how quickly i can iterate most.
ive heard people do have issues with that. personally i can't say i have experienced that as an issue. First time compiling takes a while but any time I recompile it goes pretty quick! That said, live coding (unreal system to let you compile without restarting the engine) can be a little buggy sometimes and you may have to restart the engine every so often because of that. if loading up your project takes a long time, that quickly becomes an issue. for me, perosonally that's not an issue and the amount of time and headache i save in other ways is way more than what I lose to the slightly slower compiling and restarting. But that is with a high end CPU, I can't be sure how it preforms on more reasonable hardware. for me a change to 2 or 3 classes that need to be re-compiled would take about 10-15 seconds, assuming that scales more or less linearly , on an average CPU i would think that at most it would take 4 times as long, so up to a minute. of course, if you have to wait a minute for every little change you make, that can be a real issue!
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.
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.
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
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.
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
QUESTION: For aspiring junior developers, can they get hired if they only have worked with blueprints, or is being proficient at C++ from the get go an absolute must?
i'm not confident to answer that one way or another. but in general I do believe blueprint should eb able to get you there but most development studios would then also like you to learn c++. at least that is what I would think if I were in the position to hire a junior dev, no idea how mid sized and bigger studios would look at that though.
@@thegamedevcave thank you for the reply. I teach game design and simulation at a college using Unity. This is going to impact my students and the program.
Depends on the job you're going for. There are roles like game design/technical game designer where you won't touch C++ at all and will just work in Blueprint. For a junior programming role in a studio that uses a C++ based engine, knowing how to use C++ would almost generally be expected for a junior programmer. Especially considering that the job market for juniors has always been very competitive.
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."
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.
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.
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
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.
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...."
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!
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.
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 ;)
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!
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.
The architecture is a bigger concern than syntax. Comopletely different architecture. Took me years to come up with architecture that works well in Unity.
question, does Unreal enforce visual coding, im not really into that stuff and prefer written codes, especially when most tutorials on youtube are based on visual coding, I think it could be harder to learn C++
The engine expects you to use both c++ and blueprint but if you are opposed to using blueprint it's very much possible to entirely ignore it. personally the way I work is I program all my systems in c++ and then just use blueprint for the small scripts that arrange the final implementations (level blueprints mostly). You do make a good point on lack of quality tutorials, or tutorials in general on youtube to learn from though (I hope that in the next few months I can at least get a start on helping on that problem at least). but I personally vind that a combination of ChatGPT and reading though epic's documentation on the website works decently well. sometimes i'll look through some blueprint tutorials, in the end any blueprint node is just a function from c++ so there is a little effort you have to put in to get it into your c++ files but in general when I do find blueprint tutorials to watch, it's manageable to implement that with my own code.
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.
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.
the programming side of things, not that long. it's like learning to work with any library or framework. just a list of object and functions to learn about. the biggest part of learning the engine would be in all the shit surrounding it, at least as a solo dev.. if you work with artists and level designers etc and you'd be purely focused on the code, i imagine it'll be a real easy step.
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.
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.
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.
only partly. it's not like the editor will crash at any issue in your code. Only when you try to make use of a pointer with no value (a nullptr) will it crash. Hardly ideal, i will admit but it is easy to write your code to check for nullptr and just log an error line instead of running the code that would use that pointer. that does add a good few lines of code in the whole scale of a large class though, but it's an easy few lines.
C++ is a tough language by itself as the syntax is far less forgiving than C#, JavaScript and Python. However, if you're using a Visual Scripting Language with it (like Unreal Blueprints), then it's VERY straight forward and makes Unity harder (at least without using Bolt/another framework)
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!
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.
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
![VICTOR Denmark Open 2024 | An Se Young (KOR) [1] vs. Gregoria Mariska Tunjung (INA) [5] | SF](http://i.ytimg.com/vi/Y3QEyCih85s/mqdefault.jpg)
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!
subscribing for this! Would love it if it were like a c++ course for c# devs 😅@@thegamedevcave
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?
C++ and Blueprints are like brothers ❤.
it works really well together! i love the combination of them!
What's the best way of using them together? With blueprints I'm always worried about performance since I also target mobile platforms and the switch !
@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!
Gay brothers
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
@michaelpalmer2143 Java wouldn't be taught anymore if only developers around the globe just for some reason stopped using it.
@michaelpalmer2143 It's not about Java, it's the JVM that's interesting.
@@thegamedevcave I enjoy being able to really mess things up, the best way to learn is from correcting a mistake.
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 RUclips. 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.
I'm not a game dev, why not not use c++ instead of a scripting language?
@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 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.
Currently shifting from unity and your introduction to c++ made my day. Looking forward to see other stuff from you ❤
i could feel my job security fall with every passing second of this
it's going to be a rough couple of months at the very least I think. Stay strong :)
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...
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# :)
@@thegamedevcave I’m starting it tonight!
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 switched from Unity to Unreal a while back and I don't find C++ any more difficult to use than C#. In some ways, it's easier.
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.
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.
I have a video all about setting up VSCode and unreal :) ruclips.net/video/8E0ZbBfNF2E/видео.html
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.
this is a very solid point I skipped over, thanks for pointing it out!
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.
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.
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 C++ that scares me, it's the bloated 30GB engine with 30 min to load my project that scares me 😅
yeah those are some solid reasons to prevent staying away from unreal for sure!
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.
good handful of rules to live by!
I’m so excited for this C++ course! I’ve been a Unity user since the Unity 3 days as a kid, but to get more job opportunities, I gotta learn Unreal 5.
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
yeah having to alter your workflow sucks real bad, that's the biggest issue of course. unreal is in many ways very different as an engine to Unity.
@michaelpalmer2143 unfortunately not for mobile right now
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?
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***
Thanks ! :)
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
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.
@@thegamedevcave that would be interesting... But C# is just beautiful.
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 🙂
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.
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'm glad I could help! lots of people seem to not know that unreal does all that stuff :)
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++
100% this!
Except that blueprints are way less efficient from my own testing.
@@saltyman5603 that's why I said that I would recommend 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.
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)
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.
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).
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.
Looking forward to the C++ course for Unreal
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.
Amazing thank you!! Looking forward to the C++ Course!
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.
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.
I saw the title and thought this was a request to the people at Unity to implement C++ source control into the Unity engine.
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!
Thanks great addition to clear things up!
Thanks for making things less painful.
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.
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.
C++ is faster than C#
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.
epic built fornite by using both CPP and BP !@@thegamedevcave
What extension do you use for vscode while you're working on an unreal project?
Unreal engine 4 snippets (also works with unreal 5)
I was following an UE5 course that focused on teaching c++ but I hated two things, maybe I made a mistake or I just don't know enough or how to set it properly, I would really appreciate any help but, everytime I made changes in visual studio and saved before playing, it took UE5 like a whole minute to compile before I could test the game (something called "live coding") ??? so if I changed anything and saved again, 1 more minute? it drove me nuts. 2nd thing I hated is, you made some variables public in VS to change them in the editor (like serialize field in unity), you set the values in the editor, save your project and close UE5, and when you comeback, those changes you made in the editor are now gone? you have to compile again but the values might not be right or I don't know, it felt like working with c++ was a pain in the a$s. Thanks if you read me.
live coding doesn't actually build changes to the engine so if you clsoe and re-open the engine those changes will be gone. that's by design. You need to build from VS to permanently add those changes to be available in your editor. There also is an option in your project settings that will force a rebuild every time you open the project, which can be nice for this kind of things. but do be aware that if you enable that, the project can't open if you have any compile errors in your code, so that can be a pain.
Compile times that long are a bit strange. Assuming you dont have a super low end CPU at least. One thing that I can think of that might cause something to compile that long is if you changed a few .h files. changes in .h files take much longer to compile than changes in .cpp files. In general when you're troubleshooting and recompiling very often, that should be mostly changes to .cpp files. so hopefully that's part of the problem but i'm not sure
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.
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?
pretty much. people in the comments have been comparing it to interafaces in C#
well, I've always wanted to learn C++, might as well do it now. a few questions though, is the header file like an interface in C#, or totally different?
and how does inheritance work in c++, and does it mix well with blueprints in Unreal?
the header file is reasonably close to an interface in c# i believe. the main thing about it is that the class itself lives inside the header file, then you include that header file in your cpp file and you can create the implementations for it there. This helps with compiling since you don't need to recompile the actual class any time you make a change, only the much simpler .cpp file that has the implementations.
Inheritance should work pretty much like you're used to. a child will have no access to private members, only to public and protected members on the parent. methods you want to override in a child should be marked as virtual.
C++ works great in combination with blueprint. you code your classes in c++ and then make a blueprint class inheriting from that. here you can give all the values you need to whatever variables you created and exposed to the editor and if you wanted to even add some extra blueprint scripts. any member you expose as a UPROPERTY or UFUCTION you can access as long as you're giving it the right permissions (unreal's documentation has a page on this).
The only thing that doesn't work as well is going the other way around, making something in blueprint and feeding that back into your c++ code, while possible in many ways, is a little clunky but you probably dont want to do that too much anyway.
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 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.
i have a legit question! its been bugging me since i've tried Unreal in the past. i was willing to learn C++ because Unreal has its own QoL improvements, but every time i wanted to test the game it would take quite a while to load. im not saying Unity is the fastest to test and debug, but Unreal really did feel slow and idk if this is normal? or is it a Blueprints/C++/Unreal issue?
i know C++ is the best at game performance, but i value how quickly i can iterate most.
ive heard people do have issues with that. personally i can't say i have experienced that as an issue. First time compiling takes a while but any time I recompile it goes pretty quick! That said, live coding (unreal system to let you compile without restarting the engine) can be a little buggy sometimes and you may have to restart the engine every so often because of that. if loading up your project takes a long time, that quickly becomes an issue. for me, perosonally that's not an issue and the amount of time and headache i save in other ways is way more than what I lose to the slightly slower compiling and restarting. But that is with a high end CPU, I can't be sure how it preforms on more reasonable hardware. for me a change to 2 or 3 classes that need to be re-compiled would take about 10-15 seconds, assuming that scales more or less linearly , on an average CPU i would think that at most it would take 4 times as long, so up to a minute. of course, if you have to wait a minute for every little change you make, that can be a real issue!
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.
Unreal abstracts away a lot of the "pain" parts of C++, and it's a lot more like C# anyway.
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've been looking into Godot, but Unreal Engine is looking like another very good option. Thanks to this video, I might give it a shot.
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
@@GabrielM01It is owned by epic games so they aren't dependent on income from Unreal alone
@@DhruvRed yeah, but still, a corporation
@@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
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.
Well what do you choose in the end?
@@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.
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
Yeah, I love Unreal's garbage collection feature.
Man I hate being held hostage by company A. Time to move to company B and be held hostage there instead.
Yeah been wanting to learn c++ for a while now. This gives me some motivation now to do it.
QUESTION: For aspiring junior developers, can they get hired if they only have worked with blueprints, or is being proficient at C++ from the get go an absolute must?
i'm not confident to answer that one way or another. but in general I do believe blueprint should eb able to get you there but most development studios would then also like you to learn c++. at least that is what I would think if I were in the position to hire a junior dev, no idea how mid sized and bigger studios would look at that though.
@@thegamedevcave thank you for the reply. I teach game design and simulation at a college using Unity. This is going to impact my students and the program.
@@rogercotton5134 best of luck to all the students. it's an uncertain time right now. hopefully they'll all find a place in the industry :)
Depends on the job you're going for. There are roles like game design/technical game designer where you won't touch C++ at all and will just work in Blueprint.
For a junior programming role in a studio that uses a C++ based engine, knowing how to use C++ would almost generally be expected for a junior programmer. Especially considering that the job market for juniors has always been very competitive.
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.
unreal already deletes your objects. it has its own garbage collector.
its the same as in unity pretty much.
@@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."
It really is straightforward, unless you skip learning the fundamental mechanics.
I suggest to increase the font size for videos like this, since not all guys have a large screen or good eyes.
Yup looking back at this, it’s very small, in my tutorials where I use c++ I have zoomed in more :)
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.
Last time I tried c++ in unreal building after editing a c++ file took a full 20 minutes! That’s the big pain point to me
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.
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
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.
Godot isn't 2d specialized
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...."
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!
more actual tutorial like videos coming soon :)
@@thegamedevcave yaaay, tnx man :D please do make that series for Unity devs to Unreal bro, you'd be just the person to do it.. I'm counting on you! 🤞
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.
I like the lingo of Spicy C++. we need an jalapeno C++.
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 ;)
It's also really fun with how much control you have.
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!
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.
as someone who has used both unity and unreal, which is what this video is about : half the things you bring up are not relevant to using it in unreal
I'm currently using blueprints and I am ready to learn C++ so I am ready for that new series. 🤙
starting next week I'm hoping to get 1 part a week out for c++!!
The architecture is a bigger concern than syntax. Comopletely different architecture. Took me years to come up with architecture that works well in Unity.
question, does Unreal enforce visual coding, im not really into that stuff and prefer written codes, especially when most tutorials on youtube are based on visual coding, I think it could be harder to learn C++
The engine expects you to use both c++ and blueprint but if you are opposed to using blueprint it's very much possible to entirely ignore it. personally the way I work is I program all my systems in c++ and then just use blueprint for the small scripts that arrange the final implementations (level blueprints mostly). You do make a good point on lack of quality tutorials, or tutorials in general on youtube to learn from though (I hope that in the next few months I can at least get a start on helping on that problem at least). but I personally vind that a combination of ChatGPT and reading though epic's documentation on the website works decently well. sometimes i'll look through some blueprint tutorials, in the end any blueprint node is just a function from c++ so there is a little effort you have to put in to get it into your c++ files but in general when I do find blueprint tutorials to watch, it's manageable to implement that with my own code.
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.
As a 20+ year C/C++ dev, anyone who claims “C++ is easy” really doesn’t understand the language - or only uses a tiny subset of it…
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 wonder how long would it typically take to learn Unreal Engine when you already know C++?
the programming side of things, not that long. it's like learning to work with any library or framework. just a list of object and functions to learn about. the biggest part of learning the engine would be in all the shit surrounding it, at least as a solo dev.. if you work with artists and level designers etc and you'd be purely focused on the code, i imagine it'll be a real easy step.
You have no idea how helpful this is
Thank you for sharing this!
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.
SUBSCRIBED! This is perfect. Thank you!
thank you, this will help a lot
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.
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
spaceship operator? objectively best programming language just for that (good to know though, makes sense but I wasn't aware of that one!)
@@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.
Heard a rumor that Unreal's editor will crash if there's an exception in your code. Is this true?
only partly. it's not like the editor will crash at any issue in your code. Only when you try to make use of a pointer with no value (a nullptr) will it crash. Hardly ideal, i will admit but it is easy to write your code to check for nullptr and just log an error line instead of running the code that would use that pointer. that does add a good few lines of code in the whole scale of a large class though, but it's an easy few lines.
Great summary 👍 For the people that already have the fundamentals of C# and beyond, it's not too hard to switch to C++ in general
C++ is a tough language by itself as the syntax is far less forgiving than C#, JavaScript and Python. However, if you're using a Visual Scripting Language with it (like Unreal Blueprints), then it's VERY straight forward and makes Unity harder (at least without using Bolt/another framework)
Can u make a tutorial on how to make a tutorial for mobile game step by step, from create project to package as apk ?
This was so well done, thank you!
I really think that Unreal and godot are good enough for most devs depending on the complexity of the project
Thanks for this video, helps a lot :D
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!
if you are doing your course, zoom in a little into this code, it is quite hard to see without going into full screen.
yeah overlooked that, in the c++ videos i recorded (which will be going up over the next few weeks) as tutorials I made sure to be more zoomed in!
@@thegamedevcaveThank you...
Pointers point to memory addresses of the objects.
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.
God video - could I just recommend make your font larger when showing code. It's hard to read this stuff as is...
I will do in the future! didn't think of that before recording this!
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