Thread: Can anyone tell me any simple games related to C++ 4.9.9.2 ? thanks

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

Originally Posted by SirPrattlepod

You said it was trivial:



You don't understand what's meant by one player being a human and the other player being the computer?

FYI: Your comments would be considered ban able on some boards.
Please stop trying to pick a fight.

You were the one that used the word "trivial" no one else did!
The other poster wondered/questioned if it was enough of a challenge.

Tim S.

Originally Posted by SirPrattlepod

You said it was trivial:

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.

You don't understand what's meant by one player being a human and the other player being the computer?

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.
Although I did implement an AI (min-max with alpha-beta pruning) for tic-tac-toe in C++ IIRC.

Originally Posted by SirPrattlepod

Bannable for pointing out flaws in another person's comments/argument? Right. If that's the case then so be it. I'm not trying to pick a fight, I am merely suggesting that tic-tac-toe isn't such a bad challenge at all (refer to my first comment).

You are the person arguing; the other person was wondering if the problem was challenging enough.

Tim S.

Originally Posted by SirPrattlepod

What's wrong with arguing?

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.

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.

Originally Posted by MutantJohn

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.

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.

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:

Code:

enum class Tile {X, O, EMPTY};

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.

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.

Wait, doesn't C have enumerations too? Wouldn't this be a small example in C?

Code:

typedef enum {x, o, empty} tile;
tile exampleTile = x;

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?

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,

Code:

enum class tile {x, o, empty};

Note that I prefer undercase, is all.

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,

Code:

#include <iostream>
#include <array>


using std::array;


enum class tile {x, o, empty};


int main(void) {


   array<array<tile, 3>, 3> gameBoard;


   return 0;
}

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

Code:

tile gameBoard[3][3];

would work equally the same.

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

Code:

std::istream& operator>>( std::istream& is, object& i )
{
    int tmp ;
    if ( is >> tmp )
        i = static_cast<object>( tmp ) ;
    return is ;
}

which looks super confusing O_o

Originally Posted by MutantJohn

Wait, doesn't C have enumerations too? Wouldn't this be a small example in C?

Code:

typedef enum {x, o, empty} tile;
tile exampleTile = x;

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?

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).

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."

std::array is a C++ array, and you know what that means
It provides bounds checking support, iterator interface and misc utility functions such as size.

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.

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!

Okay, so, we have a tile class with allowed values of x, o or empty as defined by your example,

Code:

enum class tile {x, o, empty};

Note that I prefer undercase, is all.

That is absolutely fine. C++ enums do not pollute the global namespace.

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

Code:

tile gameBoard[3][3];

would work equally the same.

Sure, it would work the same, but it's C, and not C++. Remember that. You lose the advantages of std::array.

Edit: Ho boy. You can't use cin for enumerated types. Instead, I found something like

Code:

std::istream& operator>>( std::istream& is, object& i )
{
    int tmp ;
    if ( is >> tmp )
        i = static_cast<object>( tmp ) ;
    return is ;
}

which looks super confusing O_o

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).
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.