• Create Account

Posted 23 December 2012 - 02:06 AM

I would probably write several variants of input for common cases, such as a function that get's input as a string(as you have now), a function that gets input as a number(this function would validate integer data), and an input that take's an input as an integer, and checks that value between a min/max values.

That was going to be my next thing to do if another solution didn't really present itself.

I just want to point out: Plugging in graphics after isn't as easy as you think. You can't take something in the command line and add graphics without almost completely rewriting it. When I got started, that's what I thought, and it's not true.

While this is true, though like stated from the poster directly above me you can write a program that uses the console as a place holder.  While yes somethings will differently need to be changed a lot of the original code design will more than likely be close to the same.  That's more what I am going for.  I'm actually not planning to replace it with graphics just wanted to work on my code design.  I myself have worked with a couple different graphics API's and I have created some simple 2D games.  I actually just wanted to create a game that was complete as in had all the information that games today really have.  Most games these days tend to have difficulties, so I wanted to try to work on a way to change difficulties.  Games also have different modes.  I wanted to try to have the user change what mode they were playing in.  Games today also seem to have a profiles attached to certain users.  So I wanted to create a way for the user create a profile or change which profile is loaded.  Finally a lot of games tend to have a way to view some stats about the game and how they are doing.  So I wanted to create a way for the user to view stats on how they are doing plus just some general game stats.

The actual game?  It's actually just a simple guess the number game.  lol.  Extremely basic.  I just wanted all aspects of what seems to make a game inside of it.  It is entirely over engineered for such a simple game (that I could make in less than 10 minutes).  That's really what I am going for.  Thanks for the words of encouragement though.

I also appreciate the words of encouragement though.  Thanks a lot!

What you're doing here (OP) is actually close to the correct way of going about this because of things like "Difficulty Game::GetDifficulty()". Once you switch to a graphics based program you can replace that function with one that gets the desired input from a GUI widget. However, I'd suggest putting the string-grab and int conversion on the outside of the function here and then passing them in as arguments. This way once you want to get the selection from a GUI widget you can just pass that as an index into the function you already have, yes?

All that being said, the two functions you showed here are using an awful lot of space and not doing much. Maybe something like this:

enum GameMode : unsigned { //enums will automatically define each successive value as the previous value + 1
COMPUTER_PLAYER = 0,
PLAYER_COMPUTER,
GAMEMODE_ENTRY_COUNT //if new entries are added place them prior to this one
};

GameMode Game::GetGameMode() {
while(1) {
//get user input
GameMode gameMode = (GameMode)(ToInt(StringInput()));

//Check for validity
if(gameMode < GAMEMODE_ENTRY_COUNT) {
return gameMode;
}

//validity failed, so show message and reloop
cout << "Please enter a valid choice using the number next to your desired game mode." << endl;
cout << "Press ENTER to try again..." << endl;
cin.get();
DisplayGameMode();
}

return SOME_INVALID_VALUE; //to shut the compiler up
}

That did make it a lot smaller and got rid of the huge switch-case.  That was the next thing. something just seemed weird have that huge switch-case and that also seemed to be repeating it's self a lot.

Couple questions:

1: I can change my enum to start at 1 can't I?  Just saying because that is what my menu choices start from.

2: Instead of returning some invalid value to have the compiler not complain (I assume it'd be from not all paths returning a value, unless I am wrong?) could it be better to just set the choice to a temporary gameMode variable and then return that temp?  I say that only because I've never seen (though I also haven't looked at a lot of peoples code) a function just return some junk value, even though that part of the code would never get executed (unless I am missing something).  Though now that I think about it, since that function should never return the junk value I guess it really wouldn't matter.

Thanks for all the input so far everyone.

Posted 23 December 2012 - 02:05 AM

I would probably write several variants of input for common cases, such as a function that get's input as a string(as you have now), a function that gets input as a number(this function would validate integer data), and an input that take's an input as an integer, and checks that value between a min/max values.

That was going to be my next thing to do if another solution didn't really present itself.

I just want to point out: Plugging in graphics after isn't as easy as you think. You can't take something in the command line and add graphics without almost completely rewriting it. When I got started, that's what I thought, and it's not true.

While this is true, though like stated from the poster directly above me you can write a program that uses the console as a place holder.  While yes somethings will differently need to be changed a lot of the original code design will more than likely be close to the same.  That's more what I am going for.  I'm actually not planning to replace it with graphics just wanted to work on my code design.  I myself have worked with a couple different graphics API's and I have created some simple 2D games.  I actually just wanted to create a game that was complete as in had all the information that games today really have.  Most games these days tend to have difficulties, so I wanted to try to work on a way to change difficulties.  Games also have different modes.  I wanted to try to have the user change what mode they were playing in.  Games today also seem to have a profiles attached to certain users.  So I wanted to create a way for the user create a profile or change which profile is loaded.  Finally a lot of games tend to have a way to view some stats about the game and how they are doing.  So I wanted to create a way for the user to view stats on how they are doing plus just some general game stats.

The actual game?  It's actually just a simple guess the number game.  lol.  Extremely basic.  I just wanted all aspects of what seems to make a game inside of it.  It is entirely over engineered for such a simple game (that I could make in less than 10 minutes).  That's really what I am going for.  Thanks for the words of encouragement though.

What you're doing here (OP) is actually close to the correct way of going about this because of things like "Difficulty Game::GetDifficulty()". Once you switch to a graphics based program you can replace that function with one that gets the desired input from a GUI widget. However, I'd suggest putting the string-grab and int conversion on the outside of the function here and then passing them in as arguments. This way once you want to get the selection from a GUI widget you can just pass that as an index into the function you already have, yes?

All that being said, the two functions you showed here are using an awful lot of space and not doing much. Maybe something like this:

enum GameMode : unsigned { //enums will automatically define each successive value as the previous value + 1
COMPUTER_PLAYER = 0,
PLAYER_COMPUTER,
GAMEMODE_ENTRY_COUNT //if new entries are added place them prior to this one
};

GameMode Game::GetGameMode() {
while(1) {
//get user input
GameMode gameMode = (GameMode)(ToInt(StringInput()));

//Check for validity
if(gameMode < GAMEMODE_ENTRY_COUNT) {
return gameMode;
}

//validity failed, so show message and reloop
cout << "Please enter a valid choice using the number next to your desired game mode." << endl;
cout << "Press ENTER to try again..." << endl;
cin.get();
DisplayGameMode();
}

return SOME_INVALID_VALUE; //to shut the compiler up
}

That did make it a lot smaller and got rid of the huge switch-case.  That was the next thing. something just seemed weird have that huge switch-case and that also seemed to be repeating it's self a lot.

Couple questions:

1: I can change my enum to start at 1 can't I?  Just saying because that is what my menu choices start from.

2: Instead of returning some invalid value to have the compiler not complain (I assume it'd be from not all paths returning a value, unless I am wrong?) could it be better to just set the choice to a temporary gameMode variable and then return that temp?  I say that only because I've never seen (though I also haven't looked at a lot of peoples code) a function just return some junk value, even though that part of the code would never get executed (unless I am missing something).  Though now that I think about it, since that function should never return the junk value I guess it really wouldn't matter.

Thanks for all the input so far everyone.

PARTNERS