Getting into C++ with Unreal Engine - Part1 - Setting up
NOTE:
A couple of things were pointed out by Ari Arnbjörnsson, and while not strictly for 'beginners' they are important considerations: at 14:46 I put a note on screen which basically implies you can use a TSharedPtr instead of UPROPERTY to keep an object from garbage collection, which is not really what I intended to say (although it says exactly that!), and is plainly WRONG ;-)
The second point is related to memory management, object lifetimes, and garbage collection, and relates to changes since UE5.0.
I have pinned Ari's comment, please check it out if you want to know more. And hopefully I will talk more about these things in a future video.
This video is the first part in a short series aimed at giving people who want to use C++ with the Unreal Engine a helping hand.
In this part, I go over installing the software you will need, setting up your development machine to allow you to work with C++ in unreal, and then I discuss the most common classes and features you may encounter while working on your projects.
I cover some basic things about how C++ projects work, to help people from a Blueprint background.
And I talk about some of the pitfalls that people who already have C++ experience might encounter, so that you can avoid them.
Links
Chat about gamedev on Discord: / discord
Unreal, hardware and software specs: docs.unrealengine.com/5.1/en-...
Install Epic Launcher: www.unrealengine.com/en-US/do...
Download Visual Studio: visualstudio.microsoft.com/vs...
Download Rider (30 day trial): www.jetbrains.com/rider/downl...
Epic - Setting up Visual Studio: docs.unrealengine.com/5.1/en-...
Unreal Build Configs:docs.unrealengine.com/5.1/en-...
Unreal Coding Standards: docs.unrealengine.com/5.1/en-...
Unreal Collection Classes: docs.unrealengine.com/5.1/en-...
Chapters
00:00 - Start
01:01 - Hardware Specs
01:45 - Epic Launcher
02:55 - IDE
04:35 - Rider
05:14 - Shill for the win!
05:45 - Project Structure
07:17 - If you already know C++
09:56 - C++ Standard Libraries
12:53 - C++ Macros
15:49 - Assets
17:58 - Split C++/BP Classes
21:01 - Code Modules
22:30 - Plugins
24:24 - Unreal Classes
26:10 - Common Unreal Classes
27:49 - GameMode
29:36 - GameMode Default Classes
34:23 - Summary
Great tutorial, very comprehensive, clear and full of facts! Good work! There are two things I'd like to correct though, you might want to fix and reupload: 09:35 - BeginPlay should generally be matched with EndPlay. World Partition keeps distant level cells around until garbage collection is triggered, meaning that level cells can be "revived" if the player goes close to them again before GC runs. That means actors can have their BeginPlay/EndPlay called multiple times before Destroy is called. 14:46 - TSharedPtr is only for FStructs, not UObject classes! It it will delete objects when its counter reaches zero. You should never delete UObjects in UE as only the GC should do it. Since it will delete UObjects without Unreal being notified, it will lead to hard-to-debug crashes when Unreal's GC also tries to delete them. Consider instead using Weak or Soft pointers.
Thanks for the feedback - its nice to know someone actually watched it and paid attention! 😀 I appreciate where you are coming from with BeginPlay/EndPlay, but the truth of the matter is that in *many* classes, EndPlay is simply not required, because although they are, kinda...sorta... like a constructor/destructor, due to the nature of managed objects, which as you point out, *generally* don't require manual clean up, an EndPlay just isn't needed (except of course when it is needed!) Likewise it could also be argued that some classes don't or should need a ctor to initialize CDO stuff - if they don't have anything which will be serialized/exposed with UPROPERTY to the editor, and only do work at runtime. But these are kinda nuanced situations, and I worry about confusing or overloading some newcomers with too much/too soon. I personally, don't like 'boilerplate clutter'; when I make a class, I generally want it to override only what it actually needs to. Which is why I dislike that some things automatically stick a Tick() override in the boilerplate, one of the worst methods to be bandying around without a good reason, especially to newcomers. Anyway, my opinion on all of that, is that newcomers really need some example there. To show these things are there for them, and when they want to use them, or not, as the case may be. Which is definately my plan in future videos. As for the TSharedPtr thing, I didn't want to comment on it at all actually, and I certainly didn't want suggest or explain its usage, because this is supposed to be an entry level video (Which is why I think I just put some text in there at the last minute?) For the record though, it's usage isn't limited to Structs, it can be used with basically anything which *isnt* UObject derived. (it's used a lot for slate widgets which certainly are not Structs, but I think I have even seen engine code that created a shared pointer to a bool. (Unless you are using 'FStruct' to refer to *anything including classes* which are not UObjects? If so, I have not seen that term before.) I digress though; the point wasn't to say TSharedPtr was an equivalent to UPROPERTY, that wasn't my intention - It was just to stop someone coming along and saying... 'UPROPERTY isn't the only thing which does reference counting...', which I thought would just confuse beginners further. Looks like I failed with that point! (Actually I totally failed - I just rewatched that bit, and it looks like I'm saying its a direct replacement! Duh!) In fact, I didn't really explain the idea of pointer reference counting at all - which is something that, while handled by unreal, is important for devs to understand. Lots of these things are on an ever growing list, for better explanation/clarification in future videos.
Ah yes I mean any non-uobjects indeed, not only FStructs. Slate does use it very aggressively since Slate objects don't garbage collect. Since we introduced World Partition we turned off `s.ForceGCAfterLevelStreamedOut` for World Partitioned levels, because of that an Actor's lifetime will be Construct -> BeginPlay -> EndPlay -> BeginPlay -> EndPlay -> etc -> Destroy. That's new and not something UE devs are used to coming from UE4, where Actors were destroyed immediately when a level got streamed out. I'd like the UE programming community to start pairing "Construct Destroy" and "BeginPlay EndPlay", since each Actor will only ever be constructed once and destroyed once, but its BeginPlay and EndPlay will get called multiple (but equal) amount of times. Most code that devs put into OnDestroy is usually code that would have been better be suited in EndPlay, it just hasn't been a problem until World Partition was introduced. If devs put event listeners in BeginPlay and only clean them up in OnDestroy, then it will re-register when BeginPlay gets called again and the event will fire twice every time. Then three times after the next time BeginPlay happens, and so on. This would not happen if the event listeners were removed in EndPlay. Things have changed a bit since Unreal 5.0. If only one of EndPlay or OnDestroy would be mentioned in tutorials, I personally would prefer EndPlay be the event people associate with doing cleanup since it's usually cleaning up the things that were set up in BeginPlay.
@@arihunfjord Thank you so much for taking the time to reply with that, not only because it can help me hopefully provide better instruction to people, but more importantly because my main project at the moment relies on world partition, and I had absolutely no idea it would exhibit that lifetime... until of course it ended up biting me on the backside!
@@ggamedev My pleasure! And thank YOU for the video series. Detailed and well edited videos like these help make the community better. I know the documentation from Epic can be lacking on the C++ front so videos like these help a lot, and make my job easier also 😄
As a veteran C++ game dev that's new to Unreal, this video is gold. Thank you!
Thanks for that comment, it really is nice to know that people find it useful 😄
the question then is, where did you create your games?
This video is in the Goldilocks Zone of explanation. Not too advanced, and not too shallow. Having just started learning UE5 and C++ at the same time, it's all so overwhelming, but this helped a lot. The humour is a more-than-welcome addition.
My god this series is pure gold. Thanks a lot for making these videos, they're really helping me out get into unreal
Man, this is an amazing introduction! I've been looking for something a bit more comprehensive (but not so comprehensive that I get overwhelmed with terms I don't even know what means) and this is the perfect middle ground - You have an amazing style to introduce new things! Thank you!
Thank you very much. It means a lot that you took the time to comment.
@@ggamedevI agree as there are many "script kiddies" or rather "blueprint kiddies" trying to explain something with the blueprint without even a slight understanding of what they are doing and that under the hood there is code 😮. I like your style. I like your knowledge
Hi! Your way of teaching is extremely good. The way you talk about how C++ and Blueprint combined work in Unreal Engine is exactly what I was looking for for a long time now. As a NodeJS developer, I was wondering if I could ever find any exhaustive UE5 C++ starting point and here I am. Thank you very much for your big efforts. Thumbs up!
Such a good overview of very complex and abstract concepts related to C++ and Unreal Engine workflow, thanks for doing it so well!
And thank you for taking the time to drop that comment. That kind of feedback helps to keep the incentive going to produce more content.
This is best C++ Introduction, I finally got time to learn. Thanks!! I will keep up with the series
This is such a great resource, you actually simplified all of it so well. Subscribed!
I just want to thank you for all the work you've put into these tutorials. Keep up the good work and all the best for you!
love this series. this is the first thing t0 get me up and running (coming from the unity engine). thanks!
I'm a beginner, so this video made it easier to understand UE's C++, as I learned about naming conventions and the roles each of.
Thanks for taking the time to drop the positive comment :-)
I greatly admire your teaching style in this course. I urge you to continue delivering such impactful lessons. As someone who has dabbled with Unreal Engine over the past few months, I am thrilled to say that I am now acquiring a wealth of knowledge previously unknown to me. It makes me wonder if it's possible to become a skilled developer solely by mastering Unreal Engine and learning C++. My ultimate goal is to delve into game development and create immersive experiences for virtual reality (VR) and augmented reality (AR). Your guidance and expertise are greatly appreciated. Thank you, and I am eagerly looking forward to more of your insightful content.
I'm really happy to hear you found my content useful 😄 You absolutely CAN become a skilled developer while learning to make games. It doesn't matter if you are creating CAD software, writing applications for banks, or making games - while specific areas will tend to focus on particular things, and use common routines for doing stuff, anyone who wants to be a good developer can be, if you have the mindset that you want to learn more. And there is always more to learn, and always someone who is better (and that we can try to learn from.) But for me, that's part of the fun, you see someone who can do something better than you, and you say 'Right...I'm gonna learn to be that good (or even better)'
As someone who is looking to learn more about UE5 and C++'s role this series is gold. Hope Dave likes his pink socks!
Golden video/series! Thanks so much for making this it was exactly what I was looking for very helpful!!
I'm glad you found it useful, thanks for taking the time to leave a comment 😄
lets go!! i love this, more more more C++ devs gotta make guides, thank you so much!!!
Really great stuff! Thank you for taking the time to make this video
I'm glad you liked it. Thank you for taking the time to drop a comment 😄
Excuse me, I like to think of "sentient washing machines" as washynators, thank you very much. Great video!
😁
I'm absolutely blasted by this video, it's exactly what I was looking for, thanks for the help ! I really appreciate it !
Great video and I look forward to watching the rest of the series. As a Pro C# and .NET developer I can only endorse your comments on Rider: it's a superb IDE and it's very handy that I can use my personal Rider licence for UE5 development too.
thank you for this I'm kind of a head on type of guy so I want to get into everything without reading much of the prerequisites, and I've coded before, and I want a boost, and this was great so thank you very much if you're still doing this, please keep em coming.
I appreciate the positive comment, thank you 😄
THIS TOUTORIAL IS BETTER THAN 99.9% OF OTHER UNREAL ENGINE BEGINNER TOUTORIALS
Great video, exactly what an experienced software dev needs to apply their skills to UE5
Confirming Quadri Production's comment: Really great content and exactly what I was looking for... Thank's a lot!
Its always nice to receive positive feedback, but more than anything it helps me focus on what people find most useful. 👍
Amazing class, thank you so much!
This course 😮 is so amazing explain every single thing in details
Really help me understand the core concept of getting into C++
I'm glad you found it helpful. Thanks for taking the time to drop a comment, I appreciate it 😊
Rreally great..Please continue and cover most used classes with examples please.-
Thanks for taking the time to drop the positive comment 🙂
these are the tuts we need . amazing work
I really appreciate the positive comment... and the sub! ;-)
Yo youre a real G, these are some great tutorials you've made. Thank you ;)
Thank you for taking the time to leave that comment. I really do appreciate it 😄
Thanks for this, you are a great teacher!
Super helpful!
5:14 Made me want to subscribe. Appreciate the honesty. 😂😂
😄 I'm all about that, lol
this helped so much thank you!
I'm glad you found it useful, and thanks for the comment. 😄
So helpful thank you
유익한 정보 감사합니다.
Loved the presentation, and the humor delivery was really nice as well. Also, every time I hear "CPP" I still can't help but laugh because it sounds like "see pp" :) I'm not growing up at all lmao
😆 'Can you CPP?' 'No man... But I can smell it!'
Top tier guide
Great overview!
I'm happy you found it useful. (And thanks for taking the time to leave a comment)
Hey there! Great videos so far! I'm an avid Blueprint user starting to get into C++ for UE and this video series is super helpful! Quick question.. Visual Studio seems to be completely broken in UE 5.3. Intellisense keeps giving nonsensical errors during build and it keeps red underlining obvious methods and classes. For example my UCLASS() macros all show up with red squiggly lines, as do my UFUNCTION() macros. Not in all files, it seems to be random ones, and sometimes closing and reopening fixes, sometimes building fixes, but other times they just remain that way. Very difficult to code and debug/troubleshoot when it's doing that. Do you have a solution for it, besides using Rider?
I cant advise Rider... damn (probably gonna anyway though!) 😉 The first advice for using VS with Unreal, is to disable a bunch of the intellisense features, or simply learn to ignore them - as you have discovered they are mostly false positives. This of course can lead to feeling like you are kinda 'flying blind' - its like how us 'old timey' coders used to do things back in the days before intellisense and code underlining even existed. And there are some guides to configuring VS without paid addons to make working with unreal a little nicer. It's crazy huh? You used to have to actually learn what methods you could call, you couldn't just type '.' or '->' and have the IDE give you a helpful list. Ahhh those were such good times... Actually, NO! THEY SUCKED! Intelisense is a massive productivity tool, it saves time and cuts down errors. So, this is my take, from the options I currently know of. You are LEARNING, right? and specifically in those cases, good intellisense really helps you learn, and it helps you 'explore' the unreal classes more easily, because you can, for example, just take an object pointer, and stick -> on the end, and browse through the available things, which might lead you to discover a method or property that is useful for you. Because (and if any one from Epic ever reads this, I'm sorry, I do truly love Unreal), but the current state of the documentation is APPALLING. So, There is an addin for VS (I think it might even be a Microsoft one i don't recall) and its does add some extra features. It *might* help clean up some of those intellisense errors, but I wouldn't count on it. Then there is stuff like 'Visual Assist' for VS - again, its another paid thing, and yeah, that's a pain point for a lot of people, trust me, I'm not sponsored by anyone - anything I use I'm paying for myself. And that is what led me to Rider. I know you have indicated you don't consider it an option, and I respect that, but let me lay out my reasoning: As you are learning Unreal C++ you kinda need all the help you can get. Rider gives you that. (and Probably Visual Assist also) But they really are an 'edge' when you are learning. After doing Unreal C++ for a few years now, I'm kinda comfortable using Vanilla VS for unreal coding (if i really have to), sure I miss all the nice time savers, but a lot of the knowledge I already gained kinda carries me through that. But I do think that using Rider helped me gain that knowledge faster, or possibly easier, than without it. Being able to write my own unreal classes, and easily have a tool which shows me all the functions in the chain of bases classes I can overload - that alone has been a real help. Lots of people have been asking me for advice on 'what are good courses I can pay for etc?' I would have to say, I think if you are in a position to invest some money in your unreal education, getting set up in a manner which maximises your chance of success is arguably a useful investment before splashing out on courses. Both Rider and Visual Assist have free trials so you can test and see for yourself if you think they are actually worthwhile spending money on. I really wish I could offer a totally free, excellent solution to you. (And to myself!) I have seen various comments from a number of 'Pro Unreal Devs' basically taking the 'hard-core-giga-dev-chad' stance and saying 'Yo Bro, you don't need nuffin, you can code with just NOTEPAD like a REAL dev', and often they have already benefitted from several years in the industry using the paid tools, paid for by their employers, without needing to stump up their own cash, and now they have the experience and knowledge, its kinda easy to be arrogant about it towards people who don't. WOW, I can talk eh? IN SUMMARY: The paid tools can help you learn faster - consider that when thinking if you actually do wanna pay. And if you absolutely don't/cant afford them, that should still not stop you! Keep watching videos, following tuts, and try to be active in the various unreal/gamedev communities - Our discord server for example; we generally have a fairly nice bunch of people there who all respect that we are ALL CONTINUALLY LEARNING, whatever our individual current skill levels. I hope that helps at least a little.
@@ggamedev Wow, what a description! I am fairly familiar with C++ and visual studio by itself, it's just a little confusing when trying to learn UEs special way to do things when Intellisense is telling you everything you are doing is wrong. It's even more confusing when you attempt to build and you receive 'build errors' that aren't actually errors. Especially when things aren't consistent. (I could see if UCLASS() was always highlighted, but when it randomly does it only to certain files, it genuinely makes you feel like something is wrong. I have tried Rider on the free trial, and I really like it. However, at this time since I am only a hobbyist developer I can't justify the cost of the license. VS generally works fine for my other non-UE needs, so I haven't been able to justify making the leap to Rider just for unreal engine, which I only do for a hobby. Once I journey further into the UE C++ adventure that may change though. Thank you for your excellent information and your great tutorials!
amazing series, thanks for github
Thank you for taking the time to comment. Appreciated :-)
I will stay with you until you become the best game dev yt channel here ❤️
Now that is the kind of viewer commitment I can work with! 😆 These positive comments really do inspire me to try and make more, and better content. So thanks!
@@ggamedev I am new to Unreal Engine, and this series is a banger trust me ! Glad you found this encouraging :) Keep up the good work Sir !
This video gave me the will to stick to bp and stop trying to begin to learn c++
Can I use eclipse IDE in unreal engine 5?
Thank god I already know c++ specifics, you did the best you can within 30 mins window but wow that was a massive simplification indeed..
Come on, It's the first part of an ongoing series.... this isn't the matrix: "Tank, I need a pilot program for -B212 helicopter- C++ in Unreal. Hurry."
@@ggamedev I know I know, I'm not faulting you. No one can do that, just saying.
@@Manas-co8wlWe were promised 'THE FUTURE'! Where's my flying car dammit?!
@@ggamedev Where indeed
I have a question how do you compile the codes from unreal engine using Visual Studio do you exit first the unreal engine editor ?
that kind of depends exactly what you mean. I generally open the SLN file in my IDE (Rider or VS), I then run the editor from there, which automatically compiled all the code first.
Good tutorial. Warning to anyone else starting out with Visual Studio. There are weird issues with intellisense so if you're getting several errors and thousands of warnings from unreal files you've never touched you have to switch output to just debug. Also making sure you have every single necessary Visual Studio component (which is changing all the time and depends on what you're doing) and the Visual Studio Integration Tool Plugin. Even then there's some questionable stuff going on.
VS + Unreal + Intellisense = Just don't try to rely on that, its never gonna be great. Installing all the VS component things though, I do think that has gotten a lot better. On the rare occasions I load unreal projects into VS now, it is generally pretty good at telling me if there is something I neglected to install, and then taking me to the installer to add it. But really, I think, right now at least, anyone on a windows/linux platform who is even 1/2 serious about unreal cpp development should first try the free trial of Rider, and then just pony up the cash for it. I know its 'more' money, and I'm not exactly rolling in cash myself, but considering what you need to spend for a 1/2 way decent pc, the subscription to rider is pretty reasonable. Plus there is the fallback option, where you still own a copy if you paid for at least 1 year and then stopped. But for me, its the development *experience* it is so much nicer in Rider, and both myself, and a number of friends I have who also switch all agree that the 'learning curve' for cpp with unreal is just way faster when you use Rider.
Yes! I've already found myself switching to rider. It's just so so much nicer for new comers. @@ggamedev
Great video!
Thank you 😄
Gonna Support this channel please tech more of unreal
Thank you for the support, I really do value it. 👍 I have been quite busy lately, but more tutorial videos are in production, coming soon...
Great video
Thank you for taking the time to leave that positive comment 😄
Is this a good starting point if you are a total beginner? I mean, I have zero background with programming and a limited experience with blueprints.
Honestly, if you are a 'total' beginner, neither C++ or Unreal engine are going to be 'easy'. But that doesn't mean it is impossible. There are many people who got into programming through games, and Unreal in particular. I would have to say, the most useful quality you can bring to the learning is PERSEVERANCE. If you arm yourself in advance with the knowledge that coding for Unreal can be tremendously rewarding, but at points is going to more than likely make you wanna tear your own hair out in frustrated handfuls... then you will be fine. 😉 Lean on the community, and in turn you will then be able to help others. And, join our Discord, where, at the very least, you will find others who are learning, and we all try to help each other where we can, and at the very least sympathise when stuff you think should 'just work'.... 'just doesnt' 😄
Do you run any courses on Udemy or elsewhere? Would be happy to pay up to learn more from you. /Michael
I am getting that kind of question more and more. The short answer is 'no' I don't; but mostly because I have not been very impressed by those course platforms, or the quality of a lot of the 'courses' that end up on there. I try to research as much as possible when I make my own KZhead videos, and yes, a few mistakes inevitably manage to slip through sometimes. I feel bad enough when something like that happens, and even worse if I was actually charging for it as a 'course'. When it is eventually finished, the 'Getting into C++ with Unreal' series will be, a course of sorts I suppose. And I intend to continually add new videos to KZhead, and probably samples, or useful plugins to GitHub. The GGameDevs Discord server has people of all experience levels, and interests, who want to make different kinds of games, and for different reasons; some want to be 'pro' game devs, and others just want to learn for their own amusement. So please consider joining. People ask and answer each others questions, and suggest topics for new KZhead content (or share links to other creators) And its somewhere that we can generally get together and moan about a lack of decent documentation, and when features don't work how most of us expect!
@@ggamedev Thanks for the detailed answer, appreciated! It makes sense, and your answer shows that with that mindset your course would be excellent. I'm in your Discord as of today, thanks!
I couldn't get this set up with the preview version 5.2 unfortunately
There shouldn't be anything is this video that wont work with the 5.2 preview? But it should be said, that the preview versions are exactly that, 'previews', and generally speaking bug fixes and other stuff will go into them before they actually move into the final release versions. It is for that reason I never do actual work with them; it's just a way to view upcoming new features... I only work with the stable release versions. Another problem with being an 'early adopter' of unreal versions (yes, even the full release ones) is that if you come to depend on certain plugins, as some people do, you might have to wait until they are released with support for the newest UE release... and sometimes that doesn't happen for a while after the actual UE release happens. Its an IT thing in general... we are always tempted by the latest, new, shiny release... but you must resist.... RESIST! 😉
@@ggamedev So I figured out everything works except building using ctrl + b or play. You have to use live edit mode.
Is extra effort required to setup up UE with VSCode instead of Visual Studio Community worth it?
Really depends if you are a big VSCode fan? It doesn't really provide you with any extra features AFAIK. I think its more for people who prefer that more minimal feeling IDE. If anyone reading this knows of any addons or whatever which make VSCode superior in any way, leave a comment, Id really like to know.
@@ggamedev Thanks. I'm also looking into Rider for an IDE. ...until then, I'm using VS Community 2022.
thx ;)
Awesome video, a lot of the free unreal c++ getting started content is assss😢
One question when I use rider it takes all the RAM that is left on my PC the moment it starts and then every thing else hangs, PC fans are blowing and rider itslef is pretty slow. Any help? I'm using Windows 11 and its 16 gigs of RAM....
Obviously that should NOT be the case. Not with any kind of even remotely modern hardware setup. I myself an currently running a 10+yr old pc which is fast approaching the end of its usefulness, and even then it doesnt do anything like what you are describing. When opening an unreal project in Rider, Rider will index a bunch of files, which will take some processing and a depending on the size of the project nad your hardware, may take a few seconds up to a couple of minutes. But it certainly should not lock up your system. Rider should be reporting what it is actually doing as it is doing it, and it might help to take a look at that and try to see what is going on. They could also potentially be issues with how things are installed, various drivers (for a number of hardware points), and even OS updates/patches which can all make a difference
@@ggamedev ok so I came back to check the mem usage again, here are the results: - On Startup Screen its: 1GB - In Empty Project Creation and later: 2GB - On simple UE Project: upto 7GB all values are approximately. It would be really helpful if you just reassure me that these readings are fine. Thank You very much! :)
@@chainbreaker8909 Like I said, I cant really answer accurately, because mem. usage, etc is somewhat dependant on specific hardware, etc What I can tell you, is that I have a fairly big unreal project loaded into Rider right now, and its using 6Gb However I get no slowdowns or anything like that
@@ggamedev Thank You very much for taking your time, just one last question is it possible that it could be happening 'cause of Windows 11?
That's possible, but I wouldn't think it likely. I know many others using W11 with Rider, and none have reported anything like that
+1 for Rider
what is even the use of that 60gb+ debugger?
I have troubles undersstanding it...
Indeed, my brain is melting at the moment...
Very good 🤌
Thank you very much!
12:34 Teaset 😂
Who can recommend a C++ tutorial for a beginner before diving into unreal engine?
Learn blueprints, they give you a solid understanding of UE5’s API and follows the basic principles of C++
does this mean that every Engine is using its own version of C++?
Absolutely not. And Unreal isn't really using its 'own version'; it uses valid, technically standard C++, its just that unreal also uses a few other things that kind of make things seem like its using its own thing.
@@ggamedev i see thanks for the quick answer
bro i have errors on firstperson template codes now i hate unreal engine c++
You gotta be chill. It IS gonna happen. You gotta resist those urges to rage-quit, and go Hulk-smash everything up. Particularly at the start, with Unreal and C++, it is so easy to make some seemingly small change and then everything breaks and the compiler is giving you like a bazillion errors, and now nothing compiles and you just wanna break stuff. If you really cant figure it right then, tell yourself you will take a break from it for a bit, and do something else, come back later with 'fresh eyes'. Alternatively join our discord server (or there are many others); anywhere that people might be able to give help and advice. Sometimes its really useful, even when you figure it out yourself, just to have like-minded people to complain about it to! Good old fashioned 'venting' 😄
Seems to me that Cpp development in Unreal is the skeleton, and BP is the muscle of Game Play.
Well... that is certainly one way of looking at it - I guess it depends how robust of a skeleton you have vs how muscular you are! 😄 There IS a lot of flexibility in how you divide your load between the two. In my projects C++ is providing a framework, on top of which blueprints sit. I am doing most of the 'heavy lifting' with C++, the blueprints are there for things which need to be configured or manipulated in the unreal editor - such as moving things around. And also for some data driven assets, which need manipulation in the editor. One example would be a programmatic actor for a building in a village... the C++ code could have all the logic to spawn any kind of building you wanted, wooden huts, stone base barns, church halls, etc. But then a level designer could create BP instances with common settings, specific defined meshes and materials, etc., for a specific look or purpose in the game. I don't really like BPs with a lot of visual scripting, because it *can* get messy. But when people worry about BP performance, they are generally worrying needlessly. And if you are developing with C++ anyway, then more logic intensive parts will not be in the BP.
I hate coding, may AI be able to automate the entire coding part soon so I can make my own games
You are not the first person to make that wish, and not just for coding games; basically people are saying it about everything which takes any level of personal investment to master. I know you are saying you hate the 'coding part' specifically, but the more 'parts' we are prepared to throw automation at, the more and more bland the games are likely to become. The point I would make, is that if AI created a game for you, then its AI's game, not yours. That's fine if you are a game PLAYER who just wants to throw out a few prompts and play the results. But if you want to actually be someone who MAKES games, then it really doesn't seem so appealing in the long run. HOWEVER... if you ARE someone who has GREAT IDEAS - that doesn't mean you automatically need to be a programmer to realise them. That is basically what the role of a game designer is. But it still requires certain skills that should be developed and honed to be the best you can. And yes, finding a team to support you in attempting to realise your game idea can be challenging, it is difficult for all of us, but that doesn't mean you shouldn't try to do it. If you have an amazing game idea, document it however you can; describe it, make a GDD, write backstory, world building and character histories if creative writing is a tool you feel comfortable with. Draw concept sketches of proposed levels, or characters, or diagram some game mechanics you want, if you are comfortable with creating things visually. The more you can actually get out into the real world and not just inside your head, the more likely you will be able to attract some programmers (and other team members) to your project, so that you can concentrate on other aspects which you are happier to work on yourself. If you have something you believe in, you gotta go for it... either learn to handle the coding in a way which you find more acceptable to you (for example, Unreal has blueprints, etc.), or, decide that you are a game designer first and foremost, and you don't really do the coding. There is nothing wrong with not being a coder, many great games were arguably great because their 'vision' didn't come from coders, just as many other great games benefitted because they were designed by coders.
@@ggamedev thanks for your sensible and insightful reply. I'm just frustrated in general cuz I'd love to create games but I have no team or means to hire talented people (I'm from South America lol) and nobody to work with (siblings or friends that would be interested in learning and working together on a project) and I really admire programmers but I'm not talented enough and I feel I'm bit too old to learn something as complicated as C++ (2 years to become proficient!? And there are few job opportunities in my country for C++ devs, and mostly involving embedded systems and sometimes, back end and most employeers require a degree in CS, etc.). I love languages but programming languages are tedious since they make litle sense to us and computers are so dumb that a tiny missing character or typo can lead to infinite loops and pure chaos lol Also there's level design, story part, modelling, rigging, animating, soundFX, so many things to tackle as a solo dev that I can't help but wish that AI do most or all of the coding part and other things so I can better focus on putting my vision and ideas into the game. I don't wish AI replace programmers or anything, I just want it to help me tackling so many overwhelming things since I can't pay people to do that for me, sadly
Shame Rider is subscription. I buy software, I don't lease it.
I totally agree with you. And I'm not getting anything to endorse Rider, so I don't have a vested interest in plugging it, BUT... Rider has a subscription, but it INCLUDES the PURCHASE. Basically, you own the version you pay for, even after the subscription runs out if you don't pay for it any more. No more updates or whatever for you - but you are perfectly entitled to keep using what you have. (the last version that was covered by the subscription) I didn't even realise until after I subscribed, and I thought 'Oh! that's actually kinda nice, because subscription only models suck!'
shill for the win!!!! LOLOL
where is the fun part in all this :(
OK, well, yeah, I do happen to know a few people who would consider C++ to be fun. (They don't always get invited to all the best parties though.) I also know a couple guys who wrote their own compiler 'for a laugh' A close friend of mine is collecting the stems of stinging nettles and intends to make his own fabric from them, 'for fun' So, I guess the point is that 'fun' depends on your own personal inclinations to a large degree. That having been said, a lot of this development stuff *can*, *sometimes* be the same sort of 'fun' as watching paint drying. 😆 That unfortunately just comes with the territory. As far as Unreal Engine development goes, you could just dive in with a purely blueprint based approach, and ignore C++ entirely, if it really isn't for you. But sticking with C++ with Unreal (through the admittedly boring, and often also extremely frustrating parts) will eventually give you an awesome amount of power and flexibility to create games (or other projects even) in any way you want. Again, I cant really promise you 'fun' - but I can (*almost) guarantee it WILL be rewarding. And you might make a massively popular game and earn a huge load of money... At which point, you can message me from your new yacht, and tell me how much fun you are having 😉
"dummstudierte"?
I have to say as a Unity guy, getting C++ scripts going with Unreal 5 is one of the biggest pains in the ass I've ever experienced with game dev. I gave up a dozen times and went right back to sticking with the time consuming blueprints. Idk why but it seems like every time I follow a tutorial to get into writing C++ with Unreal it's just nothing but problems. Huge mistake by Epic IMO to not couple UE with an IDE - even just a configuration setup for VS that you can install and set up alongside installing UE would be amazing for people like me who for some reason are too retarded to figure this out.
I want to tell you how completely wrong you are... except, you are NOT completely wrong, unfortunately. 😄 As a long time developer on many platforms and languages (including C++) I had initial experiences moving to Unreal not unlike those you had. TLDR: Unreal Engine is WORTH learning. Resources: Find the best places that can help YOU do that. If you get understanding from one video creator over others, fine, stick with them, go with what works. If you prefer written media, then use that. Ideally make friends with other devs using Unreal - because often a short conversation tailored to your specific needs can be a lot more easy to digest than hours trawling though docs online. ------ RAMBLING COMMENT! There are good reasons why Unreal is the way it is, why it has changed and is obviously continually evolving now, and why (in my opinion) it will continue to change moving forward. I have used Unity myself, I did a lot of work with C# since its first release, and it made sense to me to try and leverage that. But I quit using Unity as my 'main' development framework for a few reasons: (and these are MY reasons, others will disagree - strongly in many cases, whatever, we are all different.) - History: If I am being honest, 'back in the day' when the first Unreal game was released, I was awed like the majority of gamers. I used the editor (written in VB) and made a bunch of stuff with it. I watched mainstream games being produced with Unreal technologies over the subsequent years, and lamented the frankly ridiculous financial bar to entry which companies needed to be able to use it in their project (other commercial engines also, of course.) Call this 'nostalgia' if you like - its not a practical fact, or a decent reason to invest time and effort in a specific engine, but may have been a factor in my choices, so thats my 'full disclosure' - Features: One of the first things I started working on in Unity required a lot of development to be able to do the same large open worlds that I could effectively create with Unreal, 'out-of-the-box', and which by all metrics would out perform anything I had seen from Unity. - Financial: My earlier woes about financial requirements to use Unreal Engine were completely removed when Epic started letting everyone use it for free. Not a 'lite' version, not a feature disabled version, not something that prevents you releasing games, etc, etc. The full whack, including the source code, a tonne of free examples and assets, (and that was even before the acquisition of Quixel and its subsequent inclusion of mega-scans library assets for free) Basically, I can make whatever I want, and i can sell it, and i don't owe Epic a damn thing until my profits go above $1M I'm unable to find any other company with such a compelling product, that is providing anything similar under any kind of similar terms. - Quality: Here I am talking about the 'potential' quality of output. The performance and graphical quality that unreal engine can achieve, and has demonstrated over the years can be considered at least placing it near at the top of any reasonable metric, if not in 1st place. So... I feel that Unity falls short to Unreal in several ways: The licensing. Unity doesn't compare. Totally free to use up to $1M vs. paying whatever for licenses before you even start, or needing to mess around with different licence versions having differing things included. For me, that's a no-brainer, and an obvious win for Unreal. Not just over Unity, but over most other commercial offerings. It leaves you comparing to stuff like Godot if you want a more favourable financial situation. Performance. Unity fans hate if someone points this out, but from everything I have seen and my own tests Unity just is not as performant as Unreal. Clarification (As Unreal *can* be if the code is well written 😉) IMPORTANT: That doesn't make Unreal better - its only going to be important if the things you are making require certain levels of performance to achieve But, its obviously not all good news for Unreal. Harder to get competent with: A lot of people feel that getting set up with an environment where you start to be productive with Unity is easier than with Unreal. There may be valid arguments for that. However, Unreal effectively DOES have an integrated IDE, if you consider blueprints. Entire games can be created quite successfully using only blueprints, which means, all from within the Unreal editor. It has all you need to produce many things. And is certainly a great place to learn the pieces of Unreal before you jump into the more complex C++ coding side of things. And yes, people complain that you are using VS or Rider or some other IDE, rather than something built INTO Unreal. However, I used VS with Unity, so I cant really say there is any great distinction to be made there. Setting up your dev environment can be a pain, especially if you want to target various other platforms, which themselves have certain installation requirements that may well be quite outside the scope of anything which Epic can 'pre install & configure' for you. For example Android. Epic give you some pretty robust guides on how to do it, but its still going to be down to you to get things set up. Many people consider the Unreal documentation to be... well, how can I put this politely? Erm... 'Crap' To be fair to Epic, is has been getting better; they do seem to be working to improve things. But its not quite there yet. Another Unity comparison, I don't see being made often... A lot of what Epic do with how they try to make C++ 'work'; the macros all over the place, property 'specifiers', custom build tools consuming C#, etc. Is arguably modelled on languages and frameworks like C#/.NET (or maybe Java) A lot of the friction for established C++ devs moving to Unreal is that it simply isn't what they are used to, and it can be argued that it doesn't always work in a manner which is intuitive. Arguments can even be made that it is trying to force developers to use the C++ language; which naturally supports multiple inheritance and doesn't have or need concepts such as interfaces built into it - in a way that languages like C# on .NET were created to do from the ground up in the first place. And yes, I'm rambling on and on, and the Unity vs Unreal vs [pick any other engine] debate will rage on as it always does. It is (IMHO) worth you investing the time to get Unreal working for you. Unless of course, you have a lot of very profitable projects, which you are already comfortable producing using Unity. If Unity gives you everything you need, and you are happy with it, then you don't need to consider anything else. But you did consider something else, didn't you? Which implies that perhaps there are reasons you would like to use Unreal over Unity yourself? Ultimately, I say DON'T GIVE UP. Seriously, stick with it. It is (often) painful to learn it, with many facepalm pitfalls where you are screaming 'Why the hell would they set it up like that!!!' But it is worth it. And people like myself, and many others are there to try and help.