I have completed my first function:
Header File
UCLASS(ClassGroup=(Custom), meta=(BlueprintSpawnableComponent))
class BULLCOWGAME_API UBullCowCartridge : public UCartridge
{
GENERATED_BODY()
public:
virtual void BeginPlay() override;
virtual void OnInput(const FString& Input) override;
void InitGame();
// Your declarations go below!
private:
FString HiddenWord;
int32 Lives;
};
CPP File
{
Super::BeginPlay();
// Welcomeing The Player
PrintLine(TEXT("Welcome to Bull Cow!"));
PrintLine(TEXT("Guess the 4 letter word!")); // Magic number remove
PrintLine(TEXT("Press enter to mooove forward"));
InitGame();// Setting Up Game
// Prompt Player Guess
}
...
void UBullCowCartridge::InitGame()
{
HiddenWord = TEXT("word");
Lives = 6;
}
Interesting note
I can see the use for the “One use per function” rule. In Game terms, lets say you create a “movement” code. Movement, it would seem, is a class of some sorts. This could include individual functions walk, run, crawl, swim, jump, ect. But say you create another program that only utilizes swim or crawl? Copy and paste your functions, declare them as necessary, and you are off to the races.
If all were under one complex function, it would be harder to catch any issues that may crop up between the interplay of these actions. What if various uses of the one function were the problem? The whole function would still not work until properly all uses were dealt with. Whereas one function, one use = one problem. You could ignore which functions to call up to see which is the troublemaker and then work in the fella.