TicTacToe... Sorta.

Published August 04, 2006
Advertisement
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'!
Previous Entry Hmm... OOP?
0 likes 3 comments

Comments

baldurk
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.
August 04, 2006 05:03 AM
Samsonite
It was interesting until I realised that I was reading about a total n00b who tried to make a menu system OOP. [grin].
August 04, 2006 05:43 AM
-JetSirus-
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]

August 04, 2006 03:22 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement

Latest Entries

Hmm... OOP?

693 views
Advertisement