Oddly enough, even though we lost an hour due to that silly Daylight Savings hipster trend, looks like the wee one actually went to sleep earlier than normal. Which means it’s time for another exciting episode of Today I Learned: where I basically take notes so I can read them whenever I want later. This should take us to the half-way point of what’s currently available to watch in the Unreal course.
Section: 2 – Bulls & Cows Word Game – Your First C++
-
Lecture 35: Introducing enumerations
Lecture 36: Writing Error Checking Code
Lecture 37: Using switch Statements
Lecture 38: Warm Fuzzy Feelings
Lecture 39: Handling Game Win Condition
Lecture 35: Introducing enumerations
An enum is a list. So you can assign values such that 1 = OK, 2 = Not_Isogram, etc. Instead of explicitly using if statements, you can just fill up the list with your options, and then access them. So instead of using a bool for true or false, you would use integers as a switch. Unreal’s coding guide suggest that you should begin enums with “E” so you would declare something like “enum EWordStatus{}” to create an enum called WordStatus.
We change the “bool FBullCowGame::IsGuessValid(FString) const {}” to be a “EWordStatus FBullCowGame::IsGuessValid(FString) const {}” which means that we need to make appropriate conversions from bool to EWordStatus wherever that exists in our header.
We of course can’t return false either now that we’ve changed it from a bool to an enum. This means we instead “return EWordStatus::OK;”
Enums have a nasty feature that prevents you from reusing words across separate enums. Unreal suggests that you get around this by using separate namespaces … however we can also work around this thanks to C++ 11 being heroic. This allows us to use an enum class rather than simply an enum. This is known as a “strongly typed enum”. It provides our variables with scope that means the compiler will only recognize their meaning inside of the enum.
Lecture 36: Writing Error Checking Code
We want to make sure that our system gives predictable results. It’s good to program to check for errors so that we can easily debug if something goes wrong.
It also allows us to control behaviour rather than flat out crashing.
Remember, that if we’re not happy with a particular variable (ie: EWordStatus) you can hit ctrl r, ctrl r to rename it across the board.
Lecture 37: Using switch Statements
anatomy of a switch looks like:
switch (expression) // expression is what we switch based on
{
case constant 1:
statements(s);
break;
case constant 2:
statements(s);
break;
default:
statement(s);
}
In our case, we place a switch inside of a do while loop so that we can error check, provide feedback to the player, and continue performing a loop until there is no error in the user’s input.
Lecture 38: Warm Fuzzy Feelings
The only idea behind this lecture is that it’s bad to ignore warnings. Always make sure that warnings are understood and dealt with so that the code operates efficiently and correctly. If we need to return a value, ensure that it has been declared in an appropriate place so that we are guaranteed to return it.
Lecture 39: Handling Game Win Condition
The first step is simply converting our for loop to a while loop so that we can not only do the loop when we have valid guesses remaining, but we can stop it when the game has been won.
This looks like:
while(!BCGame.IsGameWon() && BCGame.GetCurrentTry() <= MaxTries){}
UE's coding standards suggest we use "b" as a prefix for bool variables.
I also swapped out the two separate word length tests that *I* entered into the FBullCowCount for loops, in favour of a single variable now that we've built in some tests for word length.