Getting into C++ with Unreal Engine - Part1 - Setting up

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hello there this video is the first part in a short series aimed at giving people who want to use C plus plus the Unreal Engine a helping hand if you are a blueprint only unreal developer who wants to get into C plus or someone with prior C plus plus experience who wants to apply it to Unreal then this is for you in this part I'll briefly skip over some of the bits of installing the software you will need and setting up your development machine to allow you to work with C plus in unreal and then I discuss the most common classes and features that you may encounter while working on your projects I'll cover some basic things about how unreal C plus plus projects work to help people from a blueprint background and I talk about some of the pitfalls that people who already have C plus experience might encounter so that hopefully you can avoid them the majority of this video is just to provide you with useful background information you don't need to do anything or follow along with your own project it's all just intended as useful Foundation knowledge that will help you out later practical examples of some of the things covered here are in the next video so yeah you can just kick back and take it easy with this one one of the first things people would probably address is the kind of Hardware specifications you're going to need on your machine but I'm not really going to do that because these things frequently change and any information I give you will quickly be out of date instead I will leave a link to the recommended specifications page of the unreal documentation in the description of this video having a fancy Dan CPU with more cores than your Asian dog years might help you compile your code faster but that's not essential either having lots of RAM is usually a pretty good idea as is having a sizeable amount of hard drive space because just installing various engine features will probably take up over 90 gigabytes and that's even before you start creating your own projects and bloating them out with every free asset you can lay your grubby little hands on I'm going to concentrate on a Windows development setup here because that's what I'm using and the majority of people who are interested in the subject seem to be using it also however you can develop using Mac OS or Linux and you can find details for those platforms on epic's Unreal Engine docs website I'm going to assume that most of you will already have the Unreal Engine installed on your development machine but in case you don't to begin with you're going to need to install the epic games launcher which we'll use to install the engine and to use that you're going to need an epic games account so follow this download link which is also in the video description and click the download launcher button if you don't already have it well the open launcher button if you do when you choose to install the Unreal Engine you will generally be prompted to install the most recent version however if you want to install a previous version this is also an option you might wish to do this if you know that the hardware or operating system specs you wish to work with don't quite meet the criteria for the current version in addition to the core components which are mandatory you can choose to install some other things my recommendations for those with C plus development include the starter content the templates and feature packs which is fairly big the engine source code and editor symbols for debugging which is a nice to have and it's pretty big over 60 gigabytes an integrated development environment or IDE is where you will edit your code and do a bunch of other generally programmery type so you're going to need one Visual Studio is almost the de facto IDE for development on Windows platforms it seems to have been around forever and the good news is that Microsoft are letting you have a very competent version of it completely for free it's certainly got enough features to let you code unreal games Epic have a really good page detailing not only how to download and install Visual Studio but also some configuration options and tips to help get you going so I'm not going to fight that let's work through the page together as usual there's a link in the video description to take you right there just so you know which version you need if you're using the Unreal Engine version 4.25 up to 5.0 you will need Visual Studio 2019. Unreal Engine 5.1 and above can choose to use either Visual Studio 2019 or Visual Studio 2020. when you install Visual Studio you need to bear in mind that you need a few things from the install to be able to work with your Unreal Engine projects those things are called workloads by the vs installer the workloads you will need are the.net development environment which includes c-sharp desktop development with C plus universal windows platform development and game development with C plus in addition to these workloads you also want to include the following tools C plus plus profiling Tools c plus address sanitizer and Windows 10 SDK and the Unreal Engine installer the good news here though is that if you forget to install these things or don't get this setup quite right the chances are although your project won't work properly in Visual Studio Visual Studio will now give you a message telling you that there's a problem and prompting you to download the specific things you're missing which is quite nice if you've watched any of my other videos you might be aware that my IDE of choice for unreal development is Rider produced by a company called jetbrains without any hesitation I can say it's simply light years ahead of anything you can set up with visual studio and even paid plugins like visual assist the downside of course is that it is a paid product but in my opinion well worth the price if you want to check it out I put a link in the description to a 30 day free trial you can open your project in Rider and then go straight back to visual studio it's not going to screw anything up for you so you can just go back to using visual studio after your 30-day trial expires if you want to but I don't think you will want to I think Ryder provides more features which actually help you learn C plus plus for Unreal Engine this is of course all just my own personal opinion I'm not sponsored or anything well obviously not until like thousands of you aspiring game devs have all subscribed to this Channel at which point I can happily abandon all my principles and chill for any old rubbish that comes my way that's right I'll be here wearing their branded merch or poisoning my internal organs with dubious energy drinks telling you all to buy a Scottish Lord title and shell out for some dodgy VPN and if all that goes well I have an amazing nft project I want to get you interested in oh yes my friends you really Gotta Have Dreams if you are already sum up for me familiar with C plus plus you know about header and source files.h and Dot CPP the header files.h are where you define the things that you are going to have for example in a class and the source files.cpp are where you actually have the code that does whatever you want it to do many newcomers to C plus ask why it is that way and the short answer is it's for the compiler the compiler can scan over all the header files first and then it basically knows what's what before it digs into the meat of the actual code in the CPP files yes that is a massive oversimplification there but we don't get too bogged down with that kind of stuff here what we do want to dwell on for a moment is how epic generally structure their source code their standard is to use public and private folders generally speaking all the dot h header files that Define things which should be visible only inside the code module it's written in or in a private folder and anything that should be accessible from outside the module such as things which will be used by other modules should be in the public folder the CPP files generally will go in the private folder regardless because their implementation even if they're dot h header files are public now this might sound a bit confusing but you don't need to do any of this if you're just making a simple game and all your code is going to be in the default module for that game there isn't anything outside of that module which will use that code and so none of this matters to you when it does become more important for you is when you progress to the point that you want to put code into separate modules or create your own code plugins which I will discuss a little further on you may have learned some C plus plus from your school or college or perhaps you use it professionally in an environment where you have used it on your job or have learned it independently as a hobbyist if so that's all great that familiarity will certainly help you get to grips with the Unreal Engine however there are a few things to bear in mind and some false assumptions you might make that could confuse or trip you up so let's briefly go over some of those things generally when you learn C plus plus you are taught principles of object orientation you're introduced to the idea of creating classes which act as a template from which you can create individual object instances you are shown that you can create those instances with the c plus new keyword and you can delete those instances when you don't need them anymore you are taught the concept of Constructors functions which automatically run when instances of the class are created so that that instance can set itself up and destructors which are functions that automatically run when the instance is destroyed so that the class can shut itself down gracefully and clean up any memory and other things it may have been using that's all good standard stuff but because unreal class is are basically managed by the engine it's not exactly how we do things we don't create instances of unreal objects with the familiar C plus new method we have to use engine features such as create new object or spawn actor and we don't delete our objects either generally speaking you don't actually have to do anything to get rid of your object instances once you're done with them once unreal detects there is nothing holding on to a reference to that instance a pointer then it will Mark the object for Destruction and when it decides to perform garbage collection it will get rid of it for you for other reasons Constructors and destructors on your unreal classes may not perform as you expect generally with unreal classes the Constructor is for initializing a default instance of that class this is referred to as a CDO or class default object it is an instance of the class which is used to clone copies from during play and it runs when the code module the class is in is loaded or when the engine starts or maybe with live coding when you change stuff this often can uses those familiar with C plus plus if they expect the Constructor to run when they create each instance but don't worry you just need to get used to some small changes the Constructor is for setting initial property values and creating contained sub-objects that will apply to all the instances you make of that class a function is provided called begin play which you can override to do specific things at the moment each instance has been created and is ready to use similarly you can use begin destroy to do anything you may need when that instance is cleaned up but remember that cleanup generally happens when the Unreal Engine feels like doing it not necessarily at the moment you no longer use the instance another sticking point for people familiar with C plus plus outside unreal is that unreal doesn't use the standard C plus plus libraries in one form or another the Unreal Engine has been around quite a long time beginning in 1995 in fact as far as a C plus plus standard libraries Go epic initially decided to bypass them completely if there was a particular functional feature of the standard Library they felt was required by the engine they simply coded their own version themselves in fact in a post on forums.onrealengine.com from way back in 2015 Tim Sweeney himself said yellow engines avoidance of the C plus plus standard libraries containers is primarily historical C plus plus was standardized in 1998 the same year we shipped the first Unreal Engine game back then the standard libraries were controversial poorly implemented and very inconsistent between platforms they made very aggressive use of new C plus features that hadn't yet been production proven and had some significant problems interoperating with C libraries and you can see why avoiding it might have given epics and benefits they could be sure of exactly what code was being used how optimally it was coded and have quite precise control over exactly which code would be used on the increasing number of platforms that the Unreal Engine supports however in their Unreal Engine coding standard document epic do state the standard libraries may have some things which are both useful and that they don't want to rewrite or wrap themselves and as such there is nothing stopping you from using them however you need to realize that the majority of the Unreal Engine does not rely on them and for many tasks you really need to use equivalent classes provided by the engine I'll link that Doc in the video description read the section use the standard libraries for some guideline do's and don'ts regarding this it's often first encountered with collection classes with many C plus programmers immediately reaching for standard Vector for instance don't worry though the Unreal Engine provides a slew of templated collection classes for pretty much any scenario and you should really be using those instead of what you're used to sorry about that let's take a quick look at some of the most often used ones you might already be familiar with these if you're coming from a blueprint background when you define variables in your blueprints other than single instances you can also choose one of the following three container types tray a one-dimensional array of tea I have made a separate video talking about Tray and how you can easily Implement multi-dimensional arrays based on it see the video description for the link it's basically the 1D array you know and love are implemented for unreal meaning you can mark it with the U property and the contents won't be automatically garbage collected out from under you we'll get back to that in a little bit t-map storage of objects by key and value pair as it's templated both the key and value types are definable to whatever you need T set T set storage of usually unique items which are keyed by the stored objects hash value there are also plenty of other really great templated collection classes provided by unreal that you can use too for a more exhaustive list the unreal documentation is once again your friend and I'll stick another Link in the description in case you want to know more another major difference to C plus plus coding with unreal compared to vanilla C plus plus coding is the heavy use of macros macro leaves in general makes the code appear almost like an enhanced version of C plus plus even though technically it is normal valid C plus plus although if you really want to split hair so it's not totally true because there's all sorts of other magic going on behind the scenes with C sharp and the unreal build tool and the unreal header tool and other stuff but really who cares if you want to think of it as unreal C plus plus I'm not going to knock you and if you want to think of it all as simply elf and Magic you go right ahead many of the reflection macros you will use resemble attribute in managed languages such as C sharp these are macro invocations which are generally placed immediately before specific things like unreal classes have you class structs have you struct individual properties have you property and even functions can have you function some are mandatory for example you can't have an unreal class without a u-class reflection macro immediately forward class declaration and a generated body macro somewhere inside the class body and when you create a new class using the unreal editor or from an IDE Light Rider which understands unreal the macro invocations are automatically inserted where they need to be in the empty class structure which is made for you so you don't need to worry too much about that but properties and functions don't necessarily need those things unless you want to make use of them for some reason marking a field in a class with a U property will ensure that unreal knows not to garbage collect it while your property has a reference to it let me spell that one out because it's quite important if you have an instance of some unreal class and another class has a pointer to it don't expect that pointer to stay valid unless you mark it as a you property because if there are no other pointers to it with you property on them unreal will be perfectly within its rights to go ahead and delete the thing referred to by that pointer because as far as it's concerned no one's using it anymore and because unreal does its garbage collection when it feels the time is right you I actually still be able to carry on using that pointer okay for a little while and then not understand why your game crush is sometime later in a seemingly unrelated piece of code you property can also be used to tell unreal that you want this property exposed to Blueprints and that it is read-only or read writeable in blueprints you can also include tooltip text and have things grouped together in categories and subcategories when they are displayed in property windows in the editor and it's a similar story with functions using u-function you can reveal the function to Blueprints and even have it display a specific name to blueprints that might be different from the name in C plus or indicate that the function is pure that is doesn't change anything in the class and so it won't get an execution pin when the node is used in blueprints if it's a function that will only ever be used by other C plus plus code then many times you don't need to decorate it with you function blueprints won't ever know about it or have direct access to it assets Assets in the Unreal Engine are content which your game uses these things things are not part of the compiled game code they may be imported into unreal after being created in external applications like 3D modeling programs Music Creation software or graphical editing packages things like meshes animations sound effects and textures other assets are created inside the editor such as blueprints which are also assets referencing assets from blueprints is generally pretty simple because blueprints themselves are assets and are created in the editor unreal is free to offer you drop down lists filtered with the specific type of asset you're interested in and you just pick it plus if you decide to move an asset from one place to another in your content structure there are tools which can be used to automatically fix up anything that was using that asset so it knows that it now lives in another location but C plus plus doesn't work that way you can reference assets directly in C plus plus and when you are new to coding C plus plus for unreal that's generally the first thing you try to do with the content browser open in the unreal editor you can select an asset and right click on it to get a context menu from that menu you can get an asset path string written to the clipboard which you can then paste into your C plus code usually somewhere in a Constructor for the specific class that's going to use it epic provide that functionality but they don't really advise you use it firstly it's really brittle get one of these asset paths typed incorrectly or move the asset or rename it in the content browser and you'll see plus plus won't work anymore at best things just won't work properly in your game at worst welcome back to crash City also because of the way the CDO that class default object thing works you may well end up loading that asset into memory before you actually want to use it and keeping it there after you're actually finished with it which probably isn't what you wanted so okay if you're not really supposed to have these hard-coded asset references in C plus plus what are you supposed to do then well one way is to Define classes in C plus plus which have the appropriate type of properties for the assets they will use but which don't actually specify a value for those assets then in the unreal editor you create blueprint classes which inherit from the C plus class and they to specify values for those properties let's take a closer look at that when you make a blueprint class that inherits from a c plus class you can easily then assign assets to specific properties in it using the editor and your C plus plus code can work with those things at runtime without actually ever having needed to know specifically what each asset was set to when the code was compiled after all the C plus plus code only needs to know that something is a texture or a sound effect or a material the contents of the asset at runtime are almost irrelevant as far as the code is concerned if you create your C plus classes which use assets in this way not only does it protect you from broken bad or changed asset paths and the problem with Constructors loading assets which hog memory but it actually makes development much nicer firstly the programmer of C plus plus classes isn't bothered about exactly which sound file or mesh or Texture is going to be used at runtime and so they can just concentrate on writing their code and then when using the editor a level designer for example can easily use a blueprint derived from the class to C plus Coda made and switch between different materials or sound effects without needing to have the code recompiled and yeah sometimes with Indie development that C plus plus coder and the level designer are the same person but these benefits still apply I frequently use this technique opening the editor and easily swapping out placeholder meshes that are used for testing to actual game assets once I have them and I can then easily swap them again if I want something else and I was able to test that things worked with simple meshes like cubes or boxes instead of actual game assets and know that the code worked without needing to stop doing useful work and go build a complicated mesh before I actually needed it the problem is that there is a certain misconception that blueprints are somehow not for real programmers and this is reinforced somewhat by the realization as a blueprinter that you eventually can't do everything you might want to do with them which is why eventually many blueprinters want to get some C plus under their belts the problem though is that that assumption is wrong blueprints are pretty much fundamental to Unreal development and should work hand in hand with C plus plus in general blueprints are concerned with stuff relating to asset it's all layout or configuration visual options or possibly data which can also be considered a type of asset and there are certainly specific assets that wrap data such as data tables and then there is C plus plus for pretty much everything else to do with the logic of your project I wouldn't want to code huge masses of nested branching recursive whatever type of logic with a blueprint they just don't lend themselves to it honestly but they're perfectly valid places to hook up specific assets to Properties or provide a simple response to an event similarly C plus classes ideally shouldn't be overly concerned with the specifics of assets logic is their domain for example you might have a class for a first person character with a camera in blueprints it'll be quite easy to set the camera up to the correct position that you need because you get instant visual feedback and you can keep changing it in C plus you'll be working purely with numbers and if you don't know what the correct height is to type in initially you'll be doing it by trial and error and needing to recompile code constantly it also won't give you the ability to quickly change it should your needs change during development code modules you can think of unreal modules as distinct blocks containing code if well designed those blocks will generally contain code related to specifically one or possibly more areas of functionality that can stand on their own your unreal C plus plus project automatically has its own module called the primary module but you can choose to add other modules so why would you do that well you don't have to of course but deciding to separate your game code into distinct modules has several advantages firstly it makes you think about things in a more well modular way you need to consider what are the specific parts of your game and how they can be implemented as distinct units of work with their own sets of responsibilities another good reason to implement your code within modules is that each module is compiled separately as your project grows larger it often takes longer to compile but if you separate the code into different modules only the modules that have changed need to be recompiled and for larger projects this can save you an awful lot of time if you have modules that you're not actually using they will automatically be excluded from the compilation that sounds a bit silly at first because you're not doubt enough to go to all the troubled have modules in your code that you don't intend to use right but it's actually quite common because you can have modules in your project which contain code that is only used by the unreal editor for example so when you compile your project for a shipping build that code is not needed you can also control which modules are used based on the specific platforms that you're compiling for and you have control over when the modules are loaded and unloaded at runtime plugins plugins are unreal's way of having stuff in a container the plugin which can be added to projects I use the word stuff then because plugins can consist of pretty much everything you use in unreal games they can contain their own asset content such as textures sound effects animations and meshes they can also contain code in the form of one or more modules they don't have to include content and they don't have to include code you can have code only plugins and you can have plugins which only provide assets or a mixture of both it's your choice you get the benefits listed for modules plus you can have Associated assets and all wrapped up in a package designed to be reused distributed and even sold independently of one specific project if you plan to produce multiple games plugins can be a way to develop and test functionality or assets once and then reuse them all over the place for example you could have an assets only plugin where you have your master materials some commonly used material instances and Associated textures then each project that uses it can create specific material instances based on those Master materials and you don't need to worry about migrating a bunch of individual material and texture files around you could build a plugin with all the code required to perform your custom save and load game functions and it could include C plus base classes that Define user widgets for the user interface to manage those saved games with descriptions and thumbnail support further than that you could have actual user widget assets derived from those C plus base classes that give the using project a d default set of actual widgets to use going even further you might design several themes a modern one a Sci-Fi one and an oldie worldly one each including specifically styled widgets derived from your C plus based classes you could then use that plugin with any game that needs save load functions and you have default and theme widgets right out of the box plus the ability to make new themed widgets for each specific project if you choose to do that instead unreal framework classes there are a whole truckload of classes provided by the Unreal Engine some are frequently used and you will get used to them pretty quickly others you might only encounter in unusual or specific situations you object all the unreal classes derive from a class called you object for many of your own classes which will encapsulate specific game data and functionality you will inherit your class directly from you objects bear in mind all classes you make which derive from you object and any of its descendants other than a actor will be named starting with an uppercase U for example U my object you don't have a choice about that various parts of unreal rely on that naming convention so just try to accept it and move on a actor probably the next most frequently counted class is a actor classes which derive from a actor represent anything which can be placed in your game world and have a location this includes things the player can see such as static meshes and even enemies and also things they can't such as Collision triggers just as with you object classes which inherit from my actor or a descendant of it must be named with an initial capital a such as a my actor again don't try to fight it just take a deep breath and accept that that's how the Unreal Engine works so you gotta roll with it this is not a problem if you're coming from a blueprint background with no traditional coding experience but existing programmers have invariably been indoctrinated into certain formatting conventions from whichever languages they've been using these convention zealots battle about such things as whether a particular letter in a name should be upper or lower case and if it's allowable to use underscores and don't even get them started on the go to keyword unreal is how it is and it's more than fair to say it's proven itself epic alert and you use it for free so you know there's that but what about the classes which form an actual framework for your game the first class I'm going to talk about is game mode there are actually two game mode classes you can use when you want to create your own game mode a game mode and a game mode base just to keep things simple a game mode is kept more for historical reasons and these days if you do want to make your own game mode a game mode base is the class you would derive from in the unreal documentation for game mode epic State the main idea behind it is that it contains certain rules that pertain to your game they go on to say that these rules are things like how many players and Spectators are allowed spawn locations and respawn Behavior if the game can be paused and how that pausing works and how level transitions should be handled the problem I have with that description though is that apart from the last one everything else is still basically focused on making multiplayer shooter type games and so it's not immediately clear why you'd want to make your own game mode class if that isn't the kind of game you're making the game mode that you use defines a bunch of things a default Pawn us the pawn in this case being the player's character a HUD class which is used to display widgets on the screen things like the player's health or money or notifications a player controller class which handles the input from the player a game State class responsible for communicating game related information between the various clients and server a player State class which is responsible for communicating individual Player information between the clients and the server and finally a spectator class which you guessed it is yet another multiplayer Unreal Tournament type thing with quite a limited scope for the vast majority of games so having said all of that the first thing I would probably say is don't even bother making your own game mode subclass in C plus plus why not well because it doesn't really do anything useful for you if you create a blueprint from game mode base you can then easily set and change all those things I just talked about however you like right inside the editor but if you do the same thing in C plus plus you can't change those things in the editor meaning you're back to having to edit C plus code and recompile it if you want to make all iterations which honestly kind of sucks now my previous explanation of what the game mode class is for based on the unreal documentation may have left you as it did me quite frankly underwhelmed let me just say though that for the vast majority of games you can create a single blueprint game mode set up those defaults and just use it for the entire game however where it does become useful is games where you might have different environments or even mini games for example when the player in your RPG game is rampaging through the countryside slaying ferocious beasts and looting mysterious treasure chests you could use a game mode where you have defined a character Pawn with armor and a sword and a HUD that automatically displays the character's health and magic and knows how to do notifications of XP and gold after creatures are slain using various combat actions and spells which are initiated from a player controller but then when the player transitions to the inside of a Tavern you've decided that your game will switch to a more social setting the player's Pawn is changed to one that's no longer wearing its armor or brandishing it so or the player controller no longer has combat moves but understands actions for walking around the tavern and talking to people as well as a different Hut which no longer needs to show Health but instead displays things such as the player's social status and the amount of gold they can wage on Tevin games and possibly how drunk they are so even though you might not want to write your own game modes in C plus let's take a look at the classes that you can set with one as those are interesting and useful to create default porn Class A Pawn represents something in the world that can be controlled either by the player or by AI in essence it could be anything a person a robot a car a bouncing ball or a sentient washing machine usually the class will determine what the pawn will look like and how it may behave and move in the world a character is a type of a pawn that has been created to represent roughly humanoid bipedal type characters a character comes with loads of extra stuff to support that role for example it's set up to use a skeletal mesh which the basic Acorn class it derives from is not in addition to the mesh the a character has an upright capsule component used for detecting collisions and a character movement component which simplifies allowing a character to walk run fly fall and swim and allows you to control the speeds at which they can do these things you can set how the character is affected by gravity how well they float in liquids and how they affect physics interactions the HUD class using a HUD classes is somewhat optional because you do not need to use one to display UI widgets on the screen but they are a good way of doing so allowing you to set up various widgets and provide additional logic to display hide and update them as required during play the player controller class a controller is something which controls a pawn sometimes that's a human player and sometimes it's game AI for a player controller it's obviously a player that is doing the controlling a controller possesses the pawn that it's going to control your controller May listen for various input events actions and directly do something with the pawn it is controlling such as making it walk forward begin to jump or fire its fun for simple games some developers prefer to bypass this class specifying the default player controller class in their game mode and listening for these events directly inside their a pawn or a character I understand the appeal of this to new developers it feels like one less class to deal with but honestly it's not so bad and if you use them I think the result is much cleaner more orderly code game State the job of the game State class is to know about General game information and notify each individual client about it in a client server situation it's suited for things like how many players are in a match how much time is remaining in a game the different team scores that kind of thing you can safely ignore this class if you're not interested in making a multiplayer game player State each player state is concerned with the details of a particular player it might have things like their name their current score Etc the player state is responsible for updating all the clients in a similar way that the game state is you can also safely ignore this class if you're not making a multiplayer game spectator class this is once again a multiplayer tournament type thing it's used to specify a class which usually represents a dead player who can fly around the world looking at a match they were in before they were killed and waiting to respawn you can again safely ignore this class if you're not making a multiplayer game you game instance each game has a single instance derived from the U game instance class there is only one instance of a game instance class for your game when it runs this is what some programmers refer to as a Singleton when your game starts that instance is created and it lasts until the game shuts down regardless of if the player changes levels their character dies or if they go back to your main menu screen it's still the same instance so it's a good place to have code and data which you want to exist for the entire execution of your game and that is what unreal programmers generally used to do they created their own class inheriting from you game instance but then epic came up with something better subsystems epic realized there are parts of the engine which operate in a similar way and rather than the programmer needing to make their own game instance class which could quickly become become very bloated and tightly tied to a specific project as more and more bits were added to it they made subsystem-based classes for certain parts of the framework so in a nutshell what you do with subsystems is you make a class inheriting from a specific subsystem class and unreal then automatically sees these and creates the instances for you when it runs neat huh this means that rather than a brittle bloated u-game instance class which will generally be integrated very tightly to one project you can now make several much more elegant you game instance subsystem classes one for each distinct concept you want to encapsulate you want to wrap up code which initializes and manages your save game system that could go in a game instance subsystem want to track achievements in a single player game distinct from which save game or playthrough the player is using that might also be another game instance subsystem each one can be its own independent class which makes them more likely to be reusable in other projects and yes you absolutely can put them in plugins too and the great thing is there's no complicated did configuration needed to use them when a reel fires up it detects you have them and it initializes each one for you and that initialization can even do some logic which you provide to decide if that specific game instance subsystem should even run at all tidy phew well we covered quite a lot there please don't expect you need to remember all of that the main point was just to give you a bit of background you can always come back and replay parts of the video that focus on things you need when you need it and check out some of the links in the video description to the official epic unreal documentation in the next video we'll tackle some practical examples with some actual project code for you to follow along with I hope you can join me for that until then good luck with all your endeavors
Info
Channel: GGameDev
Views: 58,020
Rating: undefined out of 5
Keywords: ue5, unreal engine, c++, getting started
Id: dS5AUaYFcdw
Channel Id: undefined
Length: 34min 48sec (2088 seconds)
Published: Sat Apr 01 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.