Completely lost - Looking for a GOOD getting started.

[DualOpAmp]

Okay, I am a C++ programmer with quite a lot of experience. I have published 14 games, and have written my own DirectX11 engine from scratch. But, I am having trouble getting started with this engine. I've watched (multiple times) the getting started with programming tutorial, I've read through the programmer quick start guide, etc. I can't get a grasp. What is a module, game mode etc.? All these terms are thrown at me, with not explanation. The programmer quick start guide tells you a tiny bit of information, and then it ends. What gives? It took me forever to find the reference, and it's huge! With little to no guidance. This is the second day trying to get started with this engine, and I feel like I'm nowhere. Where can I get a good getting started guide that will help me understand the ins-and-out of the engine, the structure of the engine, the common classes in the engine, etc?

Thanks.

[endo]

Try to find something useful here: https://forums.unrealengine.com/show...al-News-Weekly

[TS100101]

I think this is what you're looking for : https://docs.unrealengine.com/latest...ing/index.html

Aside from that, most tutorials are for Blueprints, but the API for Blueprints and C++ is basically the same so even if you are not interested in visual scripting at all, the blueprint video tutorials can help you.

[Kory]

Honestly what you need to do is download the shooter code and other sample games from the marketplace and study them. I've been doing C++ for a very long time and I know what you are feeling. Epic/UE4 does C++ in a weird way.

For basic explanations of GameMode, etc. look here: https://docs.unrealengine.com/latest...ork/index.html

[Slayemin]

I am kind of in the same boat. Realistically, you're not going to get up and running in a day or two. It's going to take a few weeks to really get familiar with the engine and its back end architecture. Fortunately for you, you've got lots of experience with making games, programming, and a game engine, so a lot of the concepts won't be lost on you.

I wrote up my game prototype in C# using XNA, and now I'm in the process of porting it over to UE4. It's going to take a while, but fortunately I'm not in the awkward position of trying to figure out what kind of game I want to make and trying to learn a new tech at the same time. What's been really helpful for me is the C++ code tutorial series they posted. It gives you a taste of how the workflow should go between C++ and blueprints and they leave the rest up to you to figure out and implement. It's a great launching point. There's a plethora of documentation out there, so it's mostly a matter of trying to figure out "I'm trying to do X, how do I do that in UE4?". I recommend following the TutorialCode tutorial series. Follow it step by step and try to understand what each line of code is doing and how they interact with the editor and blueprints. (They also use GameMode code to implement some game logic).

As far as backend architecture goes, getting a good grasp of the class inheritance hierarchy is pretty important too. From what I understand, it goes something like this:

UObject -> Pawn -> Actor -> Character

One slightly annoying but necessary thing about coding in UE4 is that they don't let you use the C++ int keyword. Instead, you have to use their keywords like uint8, uint32, int32, etc. But, if you expose some of those variables to the detail editor, they're grayed out (such as int32, but not uint8). I'm still new to the editor as well, but I haven't figured out how to use restrictions on property values either, so if you have 8 players max and you want to create some sort of editor control to set that restriction... I don't know how to do it, yet.

Anyways, there's lots of resources out there in the forms of documentation, youtube videos, content examples, forum posts, etc. Just manage your expectations a bit and you'll be fine. It's going to take some work to get proficient, but it's certainly a lot faster than writing your own engine from scratch again.

[codingteddybear]

DualOpAmp, I've had the same experience in the last several days. The programming section of the documentation is not structured well at all; for instance, if I want to know what types UE4 uses, what the basic classes are, what the macros / decorators such as GENERATED_BODY() and UPROPERTY() are meant to do, I should be able to easily find them in the relevant sections of a tutorial or reference document. Instead, the API is separated into several sections that seemingly make no sense (what does "core API" mean here and how is it different from the "engine API"? Is the "core API" perhaps meant to be used by the engine plus the editor?); the macros' pages are most easily reached from the "programming basics" page and happen to be in the "gameplay classes" page (even though the term "gameplay class" is undefined and, for me at least, completely new), but not the APIs; and it's unclear where the types specific to Unreal Engine 4 are in the documentation. These are just a few examples.

One of the UE4 tech writers has released a series of video tutorials, which are of some use because they point to the existence of these terms.

I have strongly considered making an alternative set of documents consisting of a hopefully well-ordered table of contents and an introductory text that highlights the terms and features specific to UE4. The table of contents would point to the already existent documents in such a way that no section would use terms and concepts that had not been described in previous sections; the introductory text would go over the terms and concepts that require special emphasis or that have not been defined in any of UE4's code architecture documents.

[Pat-Level17]

I am kind of in the same boat.

Pretty much the same here... C++ is like second nature to me after about 25 years of using it, but I was a little stumped when I first jumped into UE programming. Having been at it for a month now, I will say that one good starting point is actually blueprints. If you're familiar with programming, you'll immediately see what's going on under the hood of the blueprints. But the nice thing about blueprints is that they quickly expose you to everything that the engine can actually do. Try running through the blueprint tutorials, then maybe migrate the behavior from one of those tutorials over to code.

[Pat-Level17]

I have strongly considered making an alternative set of documents consisting of a hopefully well-ordered table of contents and an introductory text that highlights the terms and features specific to UE4. The table of contents would point to the already existent documents in such a way that no section would use terms and concepts that had not been described in previous sections; the introductory text would go over the terms and concepts that require special emphasis or that have not been defined in any of UE4's code architecture documents.

Well I certainly wouldn't try to stop you. I doubt anyone else in the community would mind, either!

[oasf]

I have strongly considered making an alternative set of documents consisting of a hopefully well-ordered table of contents and an introductory text that highlights the terms and features specific to UE4. The table of contents would point to the already existent documents in such a way that no section would use terms and concepts that had not been described in previous sections; the introductory text would go over the terms and concepts that require special emphasis or that have not been defined in any of UE4's code architecture documents.

There should be a wiki holding documentation. A mirror of the official documentation + edits and new pages by community. Rama and those guys would probably go nuts

Pretty much the same here... C++ is like second nature to me after about 25 years of using it, but I was a little stumped when I first jumped into UE programming. Having been at it for a month now, I will say that one good starting point is actually blueprints. If you're familiar with programming, you'll immediately see what's going on under the hood of the blueprints. But the nice thing about blueprints is that they quickly expose you to everything that the engine can actually do. Try running through the blueprint tutorials, then maybe migrate the behavior from one of those tutorials over to code.

Yes, this is excellent advise and it should be stickied or something, somewhere.

[praphael]

Honestly I've been kind of winging it, starting from the FPS tutorial and Googling what I need for what I want to accomplish.

Especially weird features like why the macros like GENERATED_UCLASS_BODY() and why you needed the "*.generated.h" were there, what the Blueprints were and how they related to C++ (basically the equivalent of C++ classes) confused me at first If you really can't find the answer to your question, don't hesitate to ask on Ufor E4 Answers

I still don't really understand the architechture all that well and my code is probably going to have be overhauled/refactored at some point, but I prefer to get something done in the "wrong" way rather than be stuck in a rut over the "right" way to do it. For example, right now I'm probably overusing GameMode and Character classes, and for something like saving the game I might have to do either an ugly hack or to move stuff into GameState so it can be easily serielized. I also didn't understand how meshes were created by the Actor, I thought they had to be created in the constructor, which was problematic for my code because I wanted to parameterize the mesh creation in the Actor, and since theres no way of passing info the constructor because its not called directly but called when you call World()->SpawnActor(), all I did was set some variables in my own GameMode class , which the Actor looked up in its own constuctor by calling GetWorld() and GetGameMode(), casting my own GameMode class, then copying the variables to its own internal copy Later I found how you can create instances of meshes at any time by calling NewObject(), but this not how most people do it, since they probably already have a Blueprinted actor of what they want.

But even with those ugly hacks and bad architechture, at least I can say, right now, I got some major features I want to incorporate working, like randomly generated terrain, the ability to load arbitrary meshes when the game starts (eventually they would probably be loaded from a configuration file), and have the user place them in the world.

[WCode]

Alot of good tips here, i like to add this link https://docs.unrealengine.com/latest...ure/index.html .
This explains it read this and when ever you are presented with a link in the text follow it and go back and continue reading.
If you do this everything will be explained.

Also there is no need to actualy know what happens under the hood with macros like GENERATED_UCLASS_BODY() so 4th.
Save this for later when you have a better grasp on the APIs.

Also i second the tip from Pat-Level17m if you are new to UE 4 start with Blueprints. Names and logic are more or less the same for both code and BP.

[DualOpAmp]

Thanks all. Clearly a lot of people feel the same way I do. I'll definitely try starting on the Blueprint tutorials and see if that will help me understand the engine better.

[codingteddybear]

DualOpAmp, the "Getting Started with the Unreal Engine API" page should link you to all the info you need:

https://docs.unrealengine.com/latest...art/index.html

It goes into the basic types and classes (including vectors, matrices, UObjects etc.) used by the engine.

For some odd reason, it's not listed in the main table of contents of the C++ documentation and can only be accessed via a link on the Unreal Engine API webpage.

[Veovis Muad'dib]

As far as backend architecture goes, getting a good grasp of the class inheritance hierarchy is pretty important too. From what I understand, it goes something like this:

UObject -> Pawn -> Actor -> Character

Actors are more general than pawns.

Overview:

UObjects are the base of anything Unreal-specific. The Unreal equivalent to the base Object.

Actors are any UObjects that have a transform. (Exist in world, visible or not) Other engines will call these Entities or GameObjects. Note that Unity's GameObjects have a transform, and so are not equal to UObjects.

• The map
• Scattered barrels and other props
• Bullets
• etc....

Pawns are Actors that the player can possess. (Take control of) Honestly you probably shouldn't use this directly too often, it's probably a better choice to use a Character.

• Security cameras
• Very customized player setups might be better off starting here, but you should know how Characters work before deciding that.
• Same with NPCs.
• etc....

And Characters are Pawns that have been set up as most characters will need to behave.

• The main character should usually be a Character, unless you have some very specific requirements that would make it easier to start with a Pawn.
• NPCs should probably be characters as well, allowing your AI to work similarly to your player controller.

If you wanted you could make your player a Pawn or even an Actor, but you'd have to emulate a lot of what Character does anyway.

[LordNyte]

I was on the same boat, 6 months back. I managed to get up and running with Unreal's C++ after fully understanding blueprints. It's essential IMO. Once you do, everything will fall perfectly in place, and everything will make sense.

Go to Unreal's official YouTube channel, watch ALL blueprint scripting videos, experiment with it until you feel fully comfortable. Next, there is a great playlist "battery collection mini game" which is done in C++. Go through that, and you should get on your feet afterwards.