Unreal C++ Course - Update #4 - Project 1 Complete!
Last night I was able to complete the second of five projects in the course!
This project was of middling duration in terms of lecture time. This puts me at about 10 hours completed out of 31 hours, or 32% complete by lecture time. As the work to lecture ratio is likely going to increase, I predict that puts me at no more than 25% complete.
I have mixed feelings about the latest lectures that finished assembling the game. They seem to have been rushed. The instructor made several mistakes, confusing the flow further. However, there were some positives:
- I learned FMath::RandRange() and that "CoreMinimal.h" actually includes a ton of functionality.
- I used continue and break to ensure program flow and readability.
- I predicted and accounted for several of the lecturer's mistakes.
- I learned that IntelliSense can make you think you are going crazy- Don't let it gaslight you and attempt to compile anyway!
However, I found several aspects confusing or vague:
Out Parameters
These are not a type of sorts- just constant references. This was incredibly poorly explained, and worse, poorly demonstrated. We are not "using" Out Parameters- There is nothing about them that adds functionality (as far as I can tell from the lecture). It is just a name for a programming practice.
Structs
The lecturer compares Structs to Classes, says there is no functional difference except they are Public by default, but forgets that they never actually explained what a Class is. Considering I come from C#, I think I broadly understand, but would have appreciated clarification. Also, I am still not exactly sure why the header file is separate to the .cpp. My guess is that it just makes compiling faster.
The bigger issue, though, is why we converted to using a Struct to track two integers. I think I remember at University our lecturers said something along the lines of "It's not just about how to do something, but also about why you are doing it." This was well explained earlier on, but the end of this project seems to have been rushed. My guess is because they have some kind of relationship to one another, even if it isn't a direct relationship. They definitely didn't need to be public.
If they said "These data types aren't really seeing their full potential here, but we will go through the process of using them anyway for future reference", that would have added needed context. As it stands, this is the first time I had to keep watching after they set the task to see what they did and therefore understand what they wanted.
Regardless, it came down to a quick loop and check to increment some values to give the player the clues they needed to guess the HiddenWord.
Extra Credit
This is the lowest-effort lecture of the course so far. We were told to "add a feature" to the game. The trouble is, the game concept was only good because it was simple, a bit like a crossword or other text game. We were given zero suggestions or even things to consider. My comment on the lecture sums up my thought process:
Extra Credit seems pointless, the game loop is complete, I see nothing meaningful that you could add with the knowledge we have so far. There could be a timer, which we don't know how to do yet.There could be a certain amount of Hidden Words before winning the game, which is in my opinion a detriment to the experience of such a simple game. Similarly, decreasing lives (to increase difficulty), awarding bonus lives for minimising incorrect guesses or trying to display the position of the characters does nothing but ruin the elegance of the game, in my opinion.I would have vastly preferred if they offered some suggestions here, instead. As it is, this task seems a bit tacked-on.
The next project appears to be using physics or at least dynamic world entities, so I am excited to get started!
So, just to clear some of those things up:
ReplyDelete-- Out parameters --
Basically these are just secondary return values. They're just extra return values that are kind of written as parameters instead of being the return value for a function. They have more uses in more restricted languages like C and shaders, and you may experience them if you do Windows specific coding, where the return value is an error code and extra detail gets tacked on to out parameters.
-- Structs --
I hesitate to say that these are a holdover from C, but that's what they started with. In C, structs are the only way you can combine multiple types together (Say, group 4 floats for a rectangle's left, top, right and bottom edges) into a single 'thing'. These structs couldn't have methods/functions within themselves, since that idea didn't exist yet, and as a result all their data is public by default - no methods means no way to access private variables, and since inheritance wasn't a thing, protected is pretty pointless too. They're basically just a block of smaller bits of data.
C++ introduced classes, which have inheritance, access modifiers (public, private, protected) and methods. Classes default to private to kind of enforce object orientated programming, but to hold some semblance of support for C, structs remained. Except now you have methods on them, breaking backwards compatibility. Fun.
Not to overcomplicate things, but if you have a struct that is just data, no methods or anything like that, you have a C struct and it works exactly like one. As soon as you add a method, you actually have something completely different and fully incompatibly with a C struct - and there's no way to tell unless you notice that it has a method on it! Interacting with C libraries and add a method to help with calculating something? Bam, C library no longer likes your struct. It's confusing and not at all clear, but you'll eventually 'get' it. The fact that your using a struct to track two integers is just a semi hold-over from C land: Those two integers are related, and it avoids you having to type a 'public:' like with a class. Since you state that they don't have to be public, it sounds like you have methods in that struct that accesses them, in which case there's really no need it couldn't just be a class.
Thanks for clarifying there. Regarding Structs, I think the underlying problem is indeed that the two values were related, but not directly like geometry or anything. One was how many letters match in the same index of the Hidden Word as the Guess, and the other was how many letters matched somewhere in the word (but not an exact index match). There was no proportional calculations to be done on them so a Struct seems a bit like overkill.
DeleteThe key here is that with your example, edges of a rectangle, you really do need them to be related and kept together, ideally. I immediately jumped to thinking there would already be a predefined datatype in Unreal (like in XNA) that that could be a member variable of the class itself, rather than having to define a custom one outside of the class.
If the instructor explained that we might not need to create a struct for a while because there are a lot of data types we can access, but we may need it in the future, I would have understood. They just kind of mixed theory and practice together a bit chaotically.
And finally
ReplyDelete-- Header files --
Oh boy. C and C++ both use this header/body file format and it's not that intuitive. It's all a compiler thing. The way the compiler works it that it compiles each c and cpp file into an 'object' file, then something called the linker tries to combine all these object files into your final file. Header files are a way to say "Hey, this thing exists and it's called SomeClass. It has these methods!", and that way your object files can go "Oh, I take in an instance of SomeClass and call SomeMethod on it. I have no idea what it actually does, just that it exists, has this method and takes these parameters".
It's then the linker's job to go through each object file, see that you want to use 'SomeClass' and call 'SomeMethod' and then find some other object file that actually defines what these do. If it does, then it knows what assembly instructions to jam in to your object file to make it work. If it doesn't, you get an infuriatingly unreadable linker error like 'Unresolved external symbol "__thiscall SomeClass@@@SomeMethod`1l`betthisiseasytounderstand`1i"' and cry in the corner.
You can get actual functional code and stuff in header files, but you have to be very clever about what you do, since #include literally just pastes that file where the #include is (You can actually #include any file, not just header files and some systems use this in tricky ways). This means, sometimes, you could accidentally include the same file twice. For exmaple, you #include "AThing.h" and #include "BThing.h", but Bthing.h also includes 'AThing.h'. Sometimes this isn't an issue, but sometimes you get mystical redefinition errors, since technically you're defining a variable/function/whatever multiple times. This is what '#pragma once' tries to solve, by telling the compiler that 'Yo, you've seen me already, go away'. There are also include guards that do the same thing, they just take three lines, and I think UE4 uses them for compatibility reasons. These are the #if and #define parts at the top of header files, and the #endif at the bottom.
I think the first thing C+++ should do is remove the need for header files and make the compiler a bit smarter.
DeleteThen, remove structs.
You'll be pleased to know that C++ is finally getting a 'modules' system that works more like C#. The C++ team aren't a fan of the preprocessor or #includes, and modules would save like 80% of the effort and compilation issues you currently get. It might be a while for wide adoption though, and I could see Unreal taking some time before it starts using modules. I think the first thing that would be ported over would be the plugin system to be honest.
DeleteStructs ain't going away though. Still needed for C++ to call into C code (The Windows API comes to mind), and C++ might even be getting a third 'object' type soon... Sorry :/