Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    2
  • comments
    3
  • views
    2284

TicTacToe... Sorta.

Sign in to follow this  
-JetSirus-

428 views

Ok, if you read my previous entry you will note that I am working on a totally stellar adaptation of TicTacToe for the console. After running across a heap of issues I have decided to flex my class making skills. First I need to figure out what classes I need and how they will relate to each other.

What exactly am I going to be doing in its simplest form?
o Displaying a Main Menu.
o Displaying a Game Menu.

What does Main Menu have?
o Some options to choose from.
o Accept some input.
o Do stuff with that input.

Does all of that need to be in one class? Is a class even needed? Good question. Let's lay out some pseudo code.

class MainMenu 
{
void dispMnu();
void getInput();
string parseInput();
}

Ok, semi sexy I suppose. We are defiantly missing something. Aha! Private variables to store junk in.

class MainMenu 
{
public:
void dispMnu();
void getInput();
string parseInput();
private:
string menu;
string input;
}

Sexy! I think we can make 'string menu' a little better though. Let's make that sucker a constant. Which I have been told is way better. Some even say its better than being rich. I like to collectively call those people idiots.

class MainMenu 
{
public:
void dispMnu();
void getInput();
string parseInput();
private:
const string menu = "->TicTacToe<-\n(1)New Game\n(2)Quit\nChoice:";
string input;
}

Now that's what I call one sexy menu. Throw in some particle effects and were rocking. Let's move onward to the easy stuff. Who am I kidding? Oh by the way, I am told that that what I did with 'string menu' was called inline definition. Whatever, let me cut and paste this crap into Visual Studio and listen to it whine and moan.

And we're back! Ok, after about 500 million errors it keeps moaning at me for trying to give 'string menu' a value at declaration. Also I forgot 'std::' for the strings. Here is our new and improved class! OMG, the suspense is killing me! My spell checker tells me 'OMG' is not a word.

class MainMenu 
{
public:
void dispMnu() {};
void getInput() {};
string parseInput() {};
private:
const std::string mnuText;
std::string input;
};

See that semicolon at the last line? Yea, rookie mistake, reminds me to facilitate the sudden death of that darned rookie who keeps wondering around here stealing my socks. Since I obviously am not allowed to both declare and define a variable in a class declaration, let's cook up a constructor that does it.

MainMenu::MainMenu()
{
mnuText = "->TicTacToe\n(1)New Game\n(2)Quit\nChoice:";
}

Titillating as you can see. Probably won't compile because CPP hates me, but it's worth a try at least. Now let's make 'void dispMnu()' shoot some fireballs or some such.

MainMenu::dispMnu()
{
std::cout << mnuText;
getInput();
}

Not the fireball I was looking for, but I guess it will have to do. Since 'dispMnu' is taking advantage of 'getInput' I guess I should define it.

MainMenu::getInput()
{
std::getline(std::cin, input);
parseInput();
}

Could be a lot better, but for now I'm leaving it as is. I'm seeing a pattern here. I keep calling a function from within a function. That could be bad I guess. Perhaps I need to make some of them private.

class MainMenu 
{
public:
MainMenu();
void dispMnu();
private:
void getInput();
string parseInput();
const std::string mnuText;
std::string input;
};

Heck, on second thought, do I even need 'getInput'? Let's rework it and see.

class MainMenu 
{
public:
MainMenu();
void dispMnu();
private:
string parseInput();
const std::string mnuText;
std::string input;
};

MainMenu::dispMnu()
{
std::cout << mnuText;
std::getline(std::cin, input);
parseInput();
}

Looks pretty sexy so far, let's move on to parsing the players input. I'm beginning to weep openly here.

MainMenu::parseInput()
{
if(input == "1")
{
return "NEWGAME";
}
else if(input == "2")
{
return "EXIT";
}
else
{
return "WTF";
}
}

A strange man once told me that using numbers that magically have some other value is bad. I can dig that. So instead I am going to return a string that says something. Some could argue that using an enumeration would be better, but they greatly underestimate how lazy I truly am. I guess that concludes the work on 'MainMenu'. Who am I kidding, my computer is going to vomit urine when I try and compile that. Tune in tomorrow for the exciting conclusion of 'MainMenu'!
Sign in to follow this  


3 Comments


Recommended Comments

Oh come on, you can't just leave us hanging like that!

Damn these syndicated shows. Always squeezing the last drop out of every plot.

Share this comment


Link to comment
Quote:
Original post by Samsonite
It was interesting until I realised that I was reading about a total n00b who tried to make a menu system OOP. [grin].

Hey! I greatly resemble that remark! *insulted* [grin]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!