I’m having a little trouble understanding the premise behind BCGame. I’ve watched the lecture a couple times now I’m am still having some trouble understanding it. I know it’s referred to as “the game” but my understanding is that the game is played through void PlayGame(). Could someone break it down a little simpler for me?
It’s the instance of the FBullCowGame class. Which acts as the interface to the game logic, holdling the hidden word, checking the guess etc.
2 Likes
Hi Joe,
Understanding BCGame is an instance of “class FBullCowGame” inside of of “FBullCowGame.h” was essential to my understanding of this concept. In the lecture, Ben touches on how he could instantiate BCGame2, BCGame3 if he wanted. These would all be different instances that you could call from for information.
I have a question about this as well though, @DanM . Would there be any point in instantiating more instances? Instances by definition are identical so wouldn’t they all return the same information all coming from FBullCowGame?
Cheers.
1 Like
Only because of the way FBullCowGame is setup that instances would be identical on construction though the variables of instances are unique. Say I have BCGame1 and BCGame2 incrementing MyCurrentTry or changing IsGameWon on BCGame1 wouldn’t affect BCGame2.
So to answer your question. Not really no.
1 Like
I have the same trouble understanding this! Loved that reply. Simple but it clarified better the things for me. Thx!
I like to imagine it like this:
FBullCowGame, which is a class, is like a board game. What comes after, the variable name, is like the name of the owner written on the board game with a sharpie.
For example:
FBullCowGame Andy;
FBullCowGame Alex;
Andy and Alex are both an FBullCowGame, so they are both the same “board game” (class), but are unique in that they have different “owners” (variable names). When Andy plays his game he may be winning, losing, have more tries, less, etc than Alex. They are both the same board game, but are unique to one another in that although they contain the same content, the values of each content may differ, thus changing the experience for each player.
Also, the whole PlayGame() function was just used for now, what is inside will most likely be replaced or written inside the FbUllCowGame class.
I hope that helped, I’m still trying to completely understand it myself 
3 Likes
I’m having a hard time understanding it as well but all these replies are helping me understand better. The way I see it(and I don’t know if I’m right) but if fBullCowGame.h is an instance then it is hard to imagine in this game because the game is pretty small and simple compared to others but once we get to bigger games then we’ll have multiple instances where each enemy in the game might have it’s own instances and each object in the world will have it’s own instance as well. Maybe I’m wrong though. The way @Cosme_Tejeda described it it sounds like the instances are like profiles for each character keeping track of their progress in the game. Hope one of these explanations is at least close to what it really is.
An instance is just a specific example of that data type. So, like:
int number = 5;
number is an instance of int. If you need to keep track of multiple integers, you have multiple instances of int. Same thing with an instance of an abstract data type(aka class or struct).
There’s no need for more than once instance of FBullCowGame, but it’s important to know that classes/structs can be instantiated because basically everything in a game will be a part of some type of class or struct, and most games will have tons of instances. Where it really starts getting wacky is when your classes’ classes have subclasses of other classes but the functions you pass them into only accept the parent class.
1 Like