Also, there is a option in the Visual Studio installer to have a “Game development with C++” thing installed. Is this necessary, and/or would it help with making a game? Is there anything else that is good for working with C++ in Unreal?
Also I’m new to C++ but have experince with C# so I as wondering about ., ->, and ::. I think that :: is used for accessing static values, and -> is for accessing instance values, but what about .?
Also, why does Unreal name all your classes A[Your Class Name], and why do you have to use a pointer for things like UStaticMeshComponent?
Thanks in advance for helping me with beginner questions.
I don’t know about the Visual Studio stuff as I don’t use VS.
The . operator basically lets you access anything from an object (that’s not a pointer). You use it with structs like FVector. Example: MyVector.Size(), MyVector.X, or MyRotator.Yaw.
The -> operator is a simple way to access anything from the object a pointer is referencing. So, -> first dereferences the pointer, then gives access to the object.
The (*MeshComponent) part dereferences the pointer, so then you could use the . operator.
:: is for accessing something in a namespace. You’ll use it with static functions like with UGameplayStatics.
It’s a naming convention so you know basically what a type is based on. Here’s the rules:
U is for classes based on UObject
A is for classes based on AActor
S is for classes based on SWidget (for Slate UI)
T is for templates classes
F is for structs and classes not based on UObject
I is for interface classes (which is basically a way to use multiple-inheritance in UE)
All UObjects in Unreal Engine use dynamic memory allocation, so they are referenced by pointers. Also, without pointers, every new place a variable is stored is a whole new copy. With pointers, every pointer stored is just a reference (64-bit on 64-bit machines, and 32-bit on 32-bit machines).
And just so you know, all components, actors, assets are based on UObject.
The main reason is garbace collection (GC). UObjects will be destroyed and their memory release when they aren’t used anymore.
Well, first of all, I prefer Linux as opposed Windows. For C++ compilation, I use the clang compiler that’s bundled with UE. For editing the code, I use a very popular and advanced console-based text editor called vim. To execute compilation, I use the Hot-Reload feature in-editor, or use the engine’s cmake configurations to manage builds outside the editor.
Worth noting: This naming convention is not optional. If you don’t stick to the naming convention, your stuff won’t build, or won’t work if it does.
In the .h file for an actor there are two publics::
class [GameName]_API AMyActor : public AActor
{
GENERATED_BODY()
public:
// Sets default values for this actor's properties
AMyActor();
protected:
// Called when the game starts or when spawned
virtual void BeginPlay() override;
public:
// Called every frame
virtual void Tick(float DeltaTime) override;
};
Is there a reason for this? Should only certain things be put under each one?
I personally would advise you put everything below the Tick function. I think the reason it’s in two places is just to keep the order of constructor first, BeginPlay second, and Tick third. But, there is no fundemental two public areas.
Declaring parts of classes as public, protected, and private are ways of hiding data in your object so other parts of code can’t access it. It’s called encapsulation if you want to research it.
If you compile in UE it will still use Visual Studio to compile. The only difference is that compiling in UE will do a “hot-reload”, which is essentially it hot-swapping the new binaries so you can see your changes without restarting the editor. The hot-reload can cause some strange but temporary errors if your code is complicated. So, if you build in VS, you’ll need to restart the editor.
You should always keep your header file and your cpp file in the same order, and you should keep related code next to each other. You can have multiple private/public/protected sections in the header file to keep different bits of related code together (so you can have a bunch of private or protected variables related to a single feature, and then public functions to access that feature, and keep them all next to each other). It’s good code organization, and also if you try to initialize variables in your C++ constructor out of order, you’ll get some nice big fat warnings from the code compiler, because that can mess things up.
In this specific case, it goes constructor, then BeginPlay, then Tick, because that’s basically how the class flows – your first code runs in constructor, then your second code runs in BeginPlay, and then Tick runs continuously after that. If you were to add PostInitialization, I’d put it between constructor and BeginPlay, and if I were to add a OnDestroy or a destructor, i’d put it at the end, and everything else in between Tick and Destructor/OnDestroy
Basically, keep like features together and try to keep flow in mind.
I think your best option there is to get modern hardware. Visual Studio and Rider both have good Intellisense functionality, but you’re crippled if you don’t have a SSD and a large quantity of RAM to hold the caches.
There is exactly nothing in the language, compiler, or runtime that requires this.
Many people may think this is a good idea for organization/navigation purposes, but that doesn’t mean “you should always” do that – just that it’s a good idea if it helps you navigate.
The original question was about whether there’s some underlying language or engine functionality tied to there being multiple public sections. The answer is that, no, there is no reason, other than that’s what the programmer who wrote the code felt like doing. All “public” bits are equally public, and all “private” bits are equally prive, and all “protected” bits are equally protected. Even the order of functions in the header doesn’t really matter, except in very esoteric cases where you want to call code built by one version of the code from code built by another version of the code (having to do with vtable layout/ordering.) This approximately never matters. When it does, “add new things at the bottom, and never delete anything, even if it’s not used” is the simplest way to make it work.
I thought I made it clear that none of that was necessary (except for when you are initializing in your constructor!) but was a good idea / standard practice from an organizational standpoint. And I’d also forgotten about the case where a header change could blow up another binary that depends on your code, even if you change no code at all, simply because that situation does almost never ever come up when you’re dealing with the entire code base, as we usually are here. . . so thanks for also reminding me of a concept i’d completely forgotten about
Yeah, the only time you suddenly need to worry about this is when you need to support user-built mods (or editor variants, or whatever) at the binary-compatibility layer.
And then, it suddenly matters a whole lot, and the bug reports and stack traces will be all kinds of … amazing … when they mis-match, and nobody will understand what’s going on!
… Not that that would ever have happened to me, so I wouldn’t know …
The privacy of variables isn’t related to type. Making variables private is all about making other parts of the program unable to access parts of the object. Generally you’ll want to make internal variables that you don’t ever need accessed outside the object private, and any others be public. However, it’s more complicated than that. I recommend components be private, and then use a public “getter” function to give access to the component. This just makes it so the component pointer won’t ever be pointing to the wrong component.
