Who said it wasn't trivial? I did not say such a thing.
I made the game in, like, 200 lines of code because I made it work with any size of the board.
I don't get what you mean by
>>implementation of player vs. computer
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
I did not say it was trivial. Does trivial mean something else to you? Like something that a newbie can complete is trivial? It is trivial to me, but it might not be trivial to a newbie.
I don't understand what part of the code you are referring to. It's just a simple two-player game, where you control both players.You don't understand what's meant by one player being a human and the other player being the computer?
Although I did implement an AI (min-max with alpha-beta pruning) for tic-tac-toe in C++ IIRC.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
it's not constructive, especially in the context of this thread.
I've seen your posts on many threads now, and I see an alarming amount of adversarial behavior on your part. you don't seem to be interested in learning from others here, but only in being right. furthermore, you clearly haven't read and understood the forum rules, because if you had, you would certainly behave much differently. not every thread needs to turn into an argument, but in every thread in which you post, that's where it ends up. it's obvious that you're not a complete noob to C and C++, but you seem to have a long way to go before you're qualified to give advice and participate in discussion. it's not your knowledge that is a problem, it's your attitude. I suggest you adjust it quickly, and stop being so argumentative. you can disagree, but try to do it with less arrogance. you are not the only one who is allowed to be right.
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
Board game - Wikipedia, the free encyclopedia
> I just need some idea of some games that are simple to program using the Dev C++ 4.9.9.2 prompt!
Nothing worth doing is simple (well you'll never learn anything from doing simple things over and over again).
"complicated" is a matter of perspective as well, you can make things as complicated as you want.
If making TTT using large colour graphics (and not just monochrome single letter 'X' and 'O') would be complicated for you, then that's a good place to start.
Sticking with TTT, you can add
- stupid AI (knows enough to not lose stupidly)
- smart AI (knows enough to win from any mistake you make)
- 2 player mode (on same machine)
- 2 player mode (over the network)
It's all the same game, but the difficulty in implementing it progresses.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Actually, I don't know if this has been mentioned in this topic, but is there a link that'll show me how to program TTT in C++? I think that'd be amazing to learn how to do. I just want to start with user-input the whole time and no AI and maybe light graphics. And by light graphics, I mean that they're not fancy but are pretty much the most simple you can do.
Ah but the challenge is to figure out the logic by yourself ;-)
As far as graphics, the lighest you can go is just using some ASCII art in the console. But really, to get something even remotely pretty you'd have to resort to ncurses or similar.
But proper graphics does not have to be hard in C++, look into SFML for easy to use graphics with a good C++ interface. (Sorry for plugging this library so often, i just think it's vastly underrated.)
The alternative here is to use SDL, although this has a C-style interface which means you'd have to use a wrapper if you want a pretty C++ interface. On the plus side a new version just came out and supposedly it has a bunch of cool features.
TTT is a pretty good challenge because you can keep working on it almost forever when you start to get into the AI part of it.
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
Okay then.
So for TTT, what I want to do is create a 3x3 array of characters initialized to something not equal to either 'x' or 'o'. I will prompt the user to put an 'x' somewhere in the array and then prompt the user again to put a 'o' somewhere in the array in a spot not already equal to 'x' or 'o' (so this way I'm not overwriting a player's previous actions). So let's say I initialize everything to 'a'. Then I can only change the array where the value at an index is equal to 'a'.
We know it's impossible to win with only two entries from each player so we don't even need to scan for winners until turn 5, I do believe. We scan for a winner after each entry from a player, using the most recent entry as a base. We check diagonally, horizontally and vertically. Implementing this might be tricky.
Should the program count 3 'x's or 'o's in a row then we have a winner and the game is over and if there is no winning condition and every element of our array is no longer equal to 'a' then the game is a tie and the program should exit.
This would be the base logic of a PvP TTT game, right? Or is there something obvious that I'm missing in the logic?
I figured using chars is the best bet seeing as each one only eats up 1 byte.
So unless you plan to run this program in a _severely_ memory constrained environment, whether each field on the board is 1 byte or 4 bytes should not concern you in the least. What is more important is how do you represent the board in a manner that makes sense and ensures that the board is always in a valid state. A char is not perfect for this purpose since a char can hold values besides 'x', 'o' and empty.I figured using chars is the best bet seeing as each one only eats up 1 byte.
You could argue that if one of the fields contained the character 'h' then something obviously went wrong somewhere, so why is this relevant? Well if you choose a 2D array of chars to represent your board then you would have to manually take care that only 1 of the 3 valid values ever found it's way onto your boards. With C++ you don't have to depend upon these manually imposed contracts to ensure correctness, use the type system to ensure that no values other than the valid ones can be represented by the board. One way to achieve this is with an enumeration:
Since the board is a fixed size, using a 2D std::vector would be a bad idea. Not because it has a lot of overhead, but because it conveys the idea that the board needs to be able to change in size, which isn't the case. Instead use std::array. This is a fixed size array container which acts identical to old school C-style arrays. The fact that there is no overhead with using std::array is just a bonus, not a main concern, in this case.Code:enum class Tile {X, O, EMPTY};
Instead of using this 2D array directly, i would make a class (call it "TTTBoard" or something along those lines), then you could hide all these implementation details regarding the board representation. Have a check_winner function that could be called in the main game loop that returns one of either X, O, NONE, DRAW or whatever.
That's how i would do it atleast.
As far as the logic itself goes, it's fairly straightforward.
Edit: Of course you _could_ do it the obvious way, with chars and C-style arrays. And you'd probably get away with it due to how simple TTT is. The point is to get into a C++ mindset, so that when you reach the stage where the problems you are dealing with are no longer trivial, you don't end up using oldschool C mechanics when much more powerful tools are at your disposal.
Last edited by Neo1; 08-23-2013 at 05:34 PM.
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
Wait, doesn't C have enumerations too? Wouldn't this be a small example in C?
So enumerations are cool but what happens if the user tries to set the tile value to something not defined in the enumeration? Do I use a throw and exception or something?Code:typedef enum {x, o, empty} tile; tile exampleTile = x;
And not to sound rude but your C++ implementation sounds pretty similar to what I already suggested. "Don't use an array, use std::array."
I'm just having trouble understanding what your global picture of how the game should work.
What you seem to be suggesting is, we need 9 tiles (obviously, the game is played on a 3x3 board). We use enumerations to represent each tile which I like a lot. But this isn't unique to C++ so I don't know what point you were trying to make. Also, if I include the 'class' keyword, it tells me I need the c++11 standard which I'm trying to eschew at this stage of my C++ development. But I can use it if you really want. Yeah, even the use of std::array requires c++11 so I guess I'll get with the times and use it.
Okay, so, we have a tile class with allowed values of x, o or empty as defined by your example,
Note that I prefer undercase, is all.Code:enum class tile {x, o, empty};
Why do I need each tile to be a class? Do I define the behavior of a tile this way?
So, here's what I have so far,
I know the syntax is confusing when using std::array but just trying to conform to your wishes makes it look like that. I'm imagining a simpleCode:#include <iostream> #include <array> using std::array; enum class tile {x, o, empty}; int main(void) { array<array<tile, 3>, 3> gameBoard; return 0; }
would work equally the same.Code:tile gameBoard[3][3];
And then what do I do with this main class you were referring to? Sorry, I'm just terribly confused.
Edit: Ho boy. You can't use cin for enumerated types. Instead, I found something like
which looks super confusing O_oCode:std::istream& operator>>( std::istream& is, object& i ) { int tmp ; if ( is >> tmp ) i = static_cast<object>( tmp ) ; return is ; }
Last edited by MutantJohn; 08-23-2013 at 07:10 PM.
You should always validate user input, regardless if it's C or C++.
As for enumerations, yes, C has them too. But the "enum class" is a type-safe version of enums. Case in point:
enum class foo { a, b, c };
enum class bar { a, b, c }; // Would cause problems in C (remove keyword class)
foo myfoo;
myfoo = foo::a; // OK
myfoo = a; // Not OK: There is no global "a". OK in C. Possibly ambiguous because enum pollute the global namespace.
myfoo = 5; // Not OK: Cannot convert from int to foo. OK in C.
myfoo = bar::a; // Not OK: bar::a is not of type foo (it is of type bar).
std::array is a C++ array, and you know what that meansAnd not to sound rude but your C++ implementation sounds pretty similar to what I already suggested. "Don't use an array, use std::array."
It provides bounds checking support, iterator interface and misc utility functions such as size.
Don't limit yourself to pre-C++11. If there is a better way to do something in C++11 than in previous standards, it's better to learn the C++11 feature rather than the old one, so don't be afraid to use it or experiment with the standard!What you seem to be suggesting is, we need 9 tiles (obviously, the game is played on a 3x3 board). We use enumerations to represent each tile which I like a lot. But this isn't unique to C++ so I don't know what point you were trying to make. Also, if I include the 'class' keyword, it tells me I need the c++11 standard which I'm trying to eschew at this stage of my C++ development. But I can use it if you really want. Yeah, even the use of std::array requires c++11 so I guess I'll get with the times and use it.
That is absolutely fine. C++ enums do not pollute the global namespace.Okay, so, we have a tile class with allowed values of x, o or empty as defined by your example,
Note that I prefer undercase, is all.Code:enum class tile {x, o, empty};
Sure, it would work the same, but it's C, and not C++. Remember that. You lose the advantages of std::array.I know the syntax is confusing when using std::array but just trying to conform to your wishes makes it look like that. I'm imagining a simple
would work equally the same.Code:tile gameBoard[3][3];
Yes, you are defining a type. The compiler does not know how to convert input X to type Y. So you have to overload an operator to do it or do it manually (operator is recommended because it creates "natural" syntax).Edit: Ho boy. You can't use cin for enumerated types. Instead, I found something like
which looks super confusing O_oCode:std::istream& operator>>( std::istream& is, object& i ) { int tmp ; if ( is >> tmp ) i = static_cast<object>( tmp ) ; return is ; }
I know this looks confusing, but it's not really complicated. But instead of me trying to explain it, you should probably take a look at operator overloading, I/O and C++ casts.
Then it should make sense. Perhaps you should put it in a dark corner somewhere and forget it for now? It all depends on how much information you think you can handle.