Disappointing course section and too much use of custom functions imo

I have really liked all of the content from GameDev.tv until this section, but I really do not like the use of custom functions like PrintLine without even specifying that it is not built in functionality. I think it would be much better to create a game from a blank project than to start off by using this half make code, especially when it is unclear what is built in and what is not. I do not like how we are introduced to FString::Printf then told that we dont need it because it was already build into custom functions we did not write. I would much rather practice with it in so that I remember that it is normally needed. I also still have no idea what the * is doing in the *HiddenWord part you had us type. That was really explained poorly I thought and I will need to look it up myself now.

I really like your content as a whole and was an still am excited to learn more about C++, but this has sadly been a bit of a rough section imo by your normal high standards. This is not to say that I am not learning a lot still, but the process has been a bit worse and it has been harder to understand fully what is happening at times, when normally you do a fantastic job of making it very easy. I also have been working with BPs is UE4 for years, so i have been able to figure out what is going on fairly well, but I am more concerned about people who are brand new and may not realize for example that they cant magically print text to a sign without setting it up in code first and are confused because you never mention what you have already done for setup.

2 Likes

Apparently, they did this with the newer course updates and I was interested to see what was going on here.

There’s two ways people like to teach beginners. One is to use course functions and the other is to use pure code.

I have never been a fan of having users do things that are not official code so I’m with you on that. This newer course version teaches things that people have to unlearn or become confused about.

However, it would seem that they may have done this because the following might be a bit too much to teach at that point in time (or to save course time perhaps)…

FString Input = Line;
FString Left, Right;
while (Input.Split(TEXT("\n"), &Left, &Right))
{
	Buffer.Emplace(Left);
	Input = Right;
} 
Buffer.Emplace(Input);
UpdateText();

…that’s a lot to throw at a beginner though.

But, they might have simplified it to keep interest. Code can quickly become complicated requiring a lot of time to fully understand. They have a game to consider and you can spend hundreds of hours just on learning code.

I’ve seen some teachers do this with one line of code so its at least much better than that.

2 Likes

I think it makes sense to build out the groundwork for a training course like this. I agree with QueueButton that asking new developers to understand a Buffer is probably too much. My recommendation would be that when GameDev is laying groundwork functions like this, prefix them in a consistent way. I.e. “GameDevPrintLine”. Makes all of your exposed method names really wordy, but I think that’s a fair price to pay for drawing a clear distinction between, “this is what we wrote” vs “this is part of Unreal/C++”.

2 Likes

Privacy & Terms