I have been thinking about starting a side project at home to exercise my brain a bit. Reversi looks like a simply game, where mobility has a profound effect on game play.
It is at least a step up from tic tac toe. This would be a single player against an AI of some sort.
I am thinking to try this in C++ on a PC.
What issues am I likely to run into?
What graphics library would you recommend?
What questions am I not smart enough to ask myself?
Issues...
Well, just be sure when writing the strategy part of the game, not to simply do the move that gives you the most pieces. You must also give weight to board position. For example, given the opportunity to place a piece in a board corner should take priority over any other move (besides winning the game) as that piece can never be turned back over. And, placing a piece adjacent to a corner spot is just about the worst move you can ever make (if the corner space is open).
Hope this helps!
In overall, issues you will end up running onto will depend on you and your approaches. Friend tends to say that complex is simple from different perspective.
Choice of graphics library depends about what kind of game you are going to write? OpenGL is common choice in this kind of projects, but you could also use some GUI-library or directly just use windows' or xorg's own libraries. If you are going to do fancy, just use OpenGL.
Questions you ought ask:
Is C++ sensible choice for this project? Consider C and/or python as well. My answer to this would be that if you just want to write reversi, go python. But if you want to learn a low level language, do C first. C++ is an extension to C, therefore there's more to learn in there than there's in C. And to my judge, the more you have to learn onto C++ is not worth the effort.
How do you use the graphics library? If you are going to do fancy effects, go to the scene graph. Instead you can just render the reversi grid with buttons on it.
How ought you implement the UI, should you use the common UI concepts? Usual UI concepts (windowing, frames, buttons, menubars, dialogs) aren't so good as people think they are, there's lot of work in implementing them properly. Apply the scene graph for interpreting input and try different clever ways onto controlling the game. Avoid intro menus(they are dumb and useless work), use command line arguments for most configuration.
I yet give you some ideas to get you started:
Othello board is 8x8, 64 cells in overall. You can assign a byte per each cell, that makes it 64 bytes per each board state. It's 8 long ints, not very much at all! You can store the whole progress of the game and the player can't even notice it. Therefore it's advised to implement the othello board as an immutable structure which you copy always when you change a state. It will also help you later with your AI and implementing an 'undo' -feature.
Because one byte can store more information than just three states (EMPTY, BLACK, WHITE), I advice you will also provide two additional states (BLACK_ALLOWED, WHITE_ALLOWED, BOTH_ALLOWED). You can calculate these values while you copy the new state.
Algorithm for checking out where you can put a block, could go the board through one by one, then trace from empty cells to every direction for regex-patterns: B+W => W^, W+B => B^ This way you can encapsulate the game rules inside a simple interface that takes care of it all.
As the guys were suggesting my idea of telling you for thinking first for algorithms and the game logic. next answer for me was the graphics library, it depends on your target platform, programming language, framework etc. But as I suggest is using C# with Cairo 2D graphics library which you can achieve this using Mono framework (which then you can target all three major operating systems for your game to work) -> www.mono-project.org. Meanwhile I found this I think that and this kind of resource will help you: http://home.datacomm.ch/t_wolf/tw/misc/reversi/html/index.html. But if you finish this, you can try implementing Sudoku.
As mentioned by others, I would begin by getting a deep understanding of the gameplay and strategies, and the algorithms involved. This link may be useful to you, it describes basic Othello strategy and algorithms:
http://www.site-constructor.com/othello/Present/Basic_Strategy.html
You will want to look into minimax with alpha-beta pruning if you write an AI to play against. Your favorite search engine will have much to say on the topic.
After you've taken a whack at the game logic yourself, go read chapter 18 of Peter Norvig's outstanding book Paradigms of AI Programming. (Source code here.) It has a rather short and extremely readable program that can kick just about any human's butt; you ought to learn a lot by comparing your solution to it.
There are tons of libraries out there but as far as I can think your game is going to need event and graphics libraries....and a sound library for more fun!
Allegro 5 is a best choice...Its an All in one library.
http://liballeg.org/
though It is written in C language you can create Object Oriented programs.
and A tutorial for this...
http://fixbyproximity.com/2d-game-development-course/
or you can use low level APIs like.. OpenGL for graphics.
OpenAL for sound.
glfw for events.
but OpenGL is a big deal because you have to create your own sprite sheet handler and all that 2d stuff.
Go with allegro...Complete your game and then go for OpenGL!
Reversi should be a very simple game to implement. It is perfect to learn some basic algorithms of games theory (specifically min-max) during the implementation of the AI.
One thing to note on the AI is that it is perfectly possible to make a perfect AI for Reversi (one that always wins no matter the moves of its opponent). So on the strategy side, if your AI loses, you still have work to do :)
I wrote a reversi game many years ago, when I was still at school. Its strategy was very simple, it just went for the maximum number of pieces, but weighted so it preferred the edges and particularly the corners and didn't like squares that risked giving away the corners.
This worked fairly well against people who hadn't yet worked out what it was doing, but once you had it was very easy to use its strategy against it. I'm not proud to say, however, that it beat me the first few times even though I'd written it!
A proper AI with a few moves of lookahead is far more complicated. Should be an interesting problem, but at the time I was more interested in the user interface.
Related
I have been thinking about making a point'n'click adventure game. The problem I have been running into is representing the game logic and state in a generic(and not butt ugly) way.
Game State:
You took an item from a room, it's no longer supposed to be there(could be done easily)
You talked to a character who went to do something that affects another room/screen, how to save in what state the room and character are
Game Logic:
You talk to a character, he does some animation and changes some stuff in the world state, how would you set this without hardcoding it into the game?
I guess the questions are related because figuring out how to represent the state will go a long way to figuring out how to define "actions."
One of the prettier options would be to use a scripting language, like Lua. You hardcode into the game only the properties that a given room or item or character might have, how they might relate to each other (e. g. item is in the room), and all the real stuff will be done by a script. This has an advantage of easier debugging, if you do it right (you won't need to recompile your game, actually, done right, you won't even need to restart it), but disadvantage of adding some complexity.
Also you may want to consider using some of the already available game engines for point and click adventures, like AGS or Wintermute. If you want to make a game, you will want to avoid programming as much as possible to jump straight to game design. I know that may be hard to accept for a programmer :)
Unless your game engine includes a scripting language of some sort, you'll have to hard-code something. Eliminating hard-coding tends to push the responsibility of defining actions to runtime, and the runtime environment will need some way to define those actions. If you don't have one already, look into an embeddable language like Lua or Python, or possibly even Javascript.
I'm a relatively new developer, and I'm looking to learn C++. I've had experience coding in java, javascript, actionscript, and python, but I want something fast enough to do some high performance 2D and 3D games.
When I eventually learn the basics (control structures, classes, etc) I'd like to develop a 2D game. I've explored various libraries for 2D graphics (cairo, sdl, openframeworks, clutter) but clutter seemed to be the most optimised for accelerated graphics and vector drawing.
Would clutter be a good fit for a 2D game? I realise that it maintains its own scenegraph unlike other libraries, but I've developed a flash game in the past, so I should be used to that.
Are there any performance issues I should be aware of? Has anyone else had experience doing heavy graphics with clutter?
I've done a lot of embedded systems work using Clutter, and am now doing a desktop project with it. It would probably be great for a desktop-based 2D game, with certain caveats:
Mainline development on the toolkit is very heavily Linux-oriented. I'm not sure how well the Windows, Mac, or iOS ("fruity") ports are maintained.
Documentation is sparse, and afaik there are no books. (I'm thinking of writing one.)
It's written in C, and natively exposes C-language bindings. While there are Clutter bindings for many languages including C++, you'll still need to understand the C-language bindings.
It doesn't natively use C++ objects. Instead it uses the C-based GObject system for single-inheritance objects, and even if you're writing to it with the C++ bindings, you'll need to understand about GObject some, too.
If you want to use it with threads, you have to use its threading system - not POSIX threads, or Boost threads, or anything else.
It can really beat the tar out of a GPU, so if you're doing something fancy, frame rates can be mediocre on some of the low-end Intel chips used in cheap laptops and netbooks.
That said, you can do amazing things with it. I really enjoy working with it, and once you understand how to do it, mixing-and-matching with C++ is a lot of fun.
Also, there's a really rockin' open-source conference called GUADEC where the Clutter folks hang. If you were to show up there in July 2011 in Berlin with a really fun Clutter-based game, people would buy you lots of drinks.
I must admit I've never heard of Clutter before, probably because it's not a Windows library and the majority of games developers work on Windows platforms. Similarly, most game developers (even indie/hobbyist ones) are not considering Cairo, or Openframeworks either. More common by far would be the use of SDL, although that is not fully hardware accelerated and thus not a good choice for modern games. SFML is an alternative that is growing in popularity, but most game developers these days are probably rolling their own OpenGL rendering on top of something like SDL.
By the looks of it, Clutter might be a good choice, and it certainly seems fully-featured. But sometimes the problem with the larger frameworks is that they become a bit of a walled garden and it's hard to integrate extra bits that you might need - for example, I don't know how well the input might work.
The other problem with using a less well-known engine is that if you go to https://gamedev.stackexchange.com/ or http://www.gamedev.net and ask questions, the community won't be able to help as much since they are not familiar with the technology you're using. You have to balance the cost of that against the potential gains that come from using an unpopular but actually very competent library. (As well as the possibility that these other guys know something you don't...)
Clutter is relatively new and there are not many applications that use it right now. Especially games. So you will have a hard time finding somebody who has experience with it for gaming purposes.
That said, clutter indeed has some interesting features that make it look compelling for the purpose, and I would even claim that for many types of gameplay the internal scene graph can even be an advantage to the game developer.
I would like to propose you another interesting option for 2D game graphics: Qt from Nokia.
While it is primarily a general-purpose GUI toolkit, it has nice proportions not every game developer would be aware of in first place. In fact, it has a fully-fledged OpenGL drawing backend which can be used to draw any widget, and to use any of Qt's canvas drawing operations.
Things go crazy as soon as you start to explicitely using a QGLWidget, which not only enforces GL drawing mode (which is not the default), but also allows you to mix your own GL drawings with Qt's drawing operations in the same context. You gain the possibility to not only use simple-to-use, high level drawing operations paired with a powerful event queue and efficient input handling; furthermore you keep the freedom to build-in more advanced, low level graphics in the future.
See this example. Note that you can mix native GL drawing freely with Qt's Painter functionality (if you take care of the GL matrix stack).
I've tried to develop a 2D game with C++ in the past using mere objects, however, in the design process I don't know how and what parts of the engine I should split into smaller objects, what exactly they should do and how to make them interact with each other properly. I'm looking for books, tutorials, papers, anything that explains the game engine design in detail. Thanks.
Mandatory reading: http://scientificninja.com/advice/write-games-not-engines
Why do you think you need a game engine? Write the code you need in order to implement your game. Modify it along the way as requirements change. And when you have a complete game, take a step back and look at what the result looks like.
You can't, and shouldn't, lay out a complete class diagram at the start. Sketch out a rough idea of what general components you want, and what their responsibilities should be, and then try to code it. Start out with the classes you're sure of. Sooner or later, some of them will get big and unwieldy, so you split it into multiple smaller ones. Sometimes, you may find that several classes are basically doing the same thing, so you merge them back together. Hopefully, sooner or later, you'll end up with a design that works, which is more than you'd get if you tried to design a game engine up front.
If you haven't made a game before, how can you make an engine? There's tons of free engines out there or you will be spending 20 years trying to get something done because you will be rewriting over and over again.
There are two important types of objects in a game. There are objects that contain processes, and there are objects that interact with the environment and the user.
For those objects that run a process like changing the opacity of objects you'll want them to be independant of any class level variables. They should simply take in value(s) and return value(s). If you have a process to calculate gravity, the process should take in the object that it gravity is being calculated on, and return the the amount of gravity that the object is experiencing, and the direction of gravity if the game takes place in space.
The second more important types of objects are those that interact with the user and the environment. These objects should all inheret of the same base class. The base class will require an image, and the x and y position, and can have variables that perform specific processes like changing the speed or direction of the variable.
With this base class in place you can then perform proccesses like the gravity proccess mentioned earlier using every objects "built-in" variables like speed, direction, and x and y position.
You will also want to set up your objects to run peices of code under certain conditions. It may be a good idea to have your base class provide functions that get run when one of these conditions are met. Some useful conditional functions are a conditional function to go of when an object is first created and when it is destroyed. A conditional function to go of after a timer is set. A conditional functional to go of continually where you can place code to draw images on the screen. A conditional function to go off When a keyboard or mouse button is pushed. A conditional function to go off a set amount of times per second to calculate things like gravity on an object.
This framework has worked very well for me when creating games. It works for any type of game, and works horribly for other types of programs. Sorry if my writin is unclear, I'm typing on my iPod and It would be hard for me to go back and edit things on here.
Eberly's 3D Game Engine Architecture and 3D Game Engine Design are rather heavy on the theory, but cover all of the bases quite well.
http://fivedots.coe.psu.ac.th/~ad/jg/
This guy lays out a good oop style and through the book helps you build an engine frame. It's spot on good stuff.
If you want to code a simple 2d game, a good way to get an idea of what you#re actually trying to do is to:
write a simple game loop, that simply displays a frame buffer in the resolution you want
render a simple sprite with a a given direction and velocity bouncing off the screen edges
ensuring that your logic and display code are decoupled
If this sounds like a a lot of work, or if it contains ideas/ terms you're not 100% sure what they mean: Take a look at one or two of the existing game engines.
If you just want to get an idea of how it's done, coding something is a great way to learn.
If you're more interested in developing a game, I strongly recommend something like Unity as a base, so you can actually work on the game. And since it is an engine, you'll learn over time how many different parts there are, and how they interconnect.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a C++ programmer with very extensive server programming experience. I'm however fairly bored at the moment and I decided to tackle a new area: 3D game programming, for learning purposes. Additionally I think this learning project may turn out to be good resume material in the future should I decide to work in this area.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's. If you are curious as to why (feel free to skip this):
It's a real world successful game
All the map textures, models and what not are already done (I'm not interested in learning how to actually draw a texture with photoshop or whatever)
Their file formats have been more or less completely reverse engineered
There is already an identical open source project (wowmapview) that I can look at if I'm in trouble.
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
What's the most used one in the real world?
And, something else that perplexes me: World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Is this something common in games? Why did they do it? I imagine it's a lot of work and from my understanding nobody uses OpenGL anyway (very very few people know about the secret switch at all).
If it's something usually done, do programmers usually create their own 3d engine "wrapper", something like SDL made in house, and based on switches / #defines / whatnot decide which API function to ultimately call (DirectX or OpenGL)? Or is this functionality already built in in sdl (you can switch between DirectX and OpenGL at will)?
And, finally, do you have any books to suggest?
Thanks!
I realize you already accepted an answer, but I think this deserves some more comments. Sorry to quote you out of order, I'm answering by what I think is important.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's.
However I wanted to focus on the actual 3d and rendering engine, not the interface, so I don't think I will be using it [lua] for this project.
From these two snippets, I can tell you that you are not trying to emulate the game engine. Just the 3D rendering backend. It's not the same thing, and the rendering backend part is very small part compared to the full game engine.
This, by the way, can help answer one of your questions:
World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Yep, they implemented both. The amount of work to do that is non-negligeable, but the rendering back-end, in my experience, is at most 10% of the total code, usually less. So it's not that outraging to implement multiple ones.
More to the point, the programming part of a game engine today is not the biggest chunk. It's the asset production that is the bulk (and that includes most game programming. Most lua scripts are considered on that side of things, e.g.)
For WoW, OSX support meant OpenGL. So they did it. They wanted to support older hardware too... So they support DX8-level hardware. That's already 3 backends. I'm not privy to how many they actually implement, but it all boils down to what customer base they wanted to reach.
Multiple back-ends in a game engine is something that is more or less required to scale to all graphics cards/OSs/platforms. I have not seen a single real game engine that did not support multiple backends (even first party titles tend to support an alternate back-end for debugging purposes).
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
Well, this depends strongly on what you want to get out of it. I might add that your option list is not quite complete:
DirectX9
DirectX10
DirectX11
OpenGL < 3.1 (before deprecated API is removed)
OpenGL >= 3.1
OpenGL ES 1.1 (only if you need to. It's not programmable)
OpenGL ES 2.0
Yep, those APIs are different enough that you need to decide which ones you want to handle.
If you want to learn the very basics of 3D rendering, any of those can work. OpenGL < 3.1 tends to hide a lot of things that ultimately has to happen in user code for the other ones (e.g. Matrix manipulation, see this plug).
The DX SDKs do come with a lot of samples that help understand the basic concepts, but they also tend to use the latest and greatest features of DX when it's not necessarily required when starting (e.g. using Geometry shader to render sprites...)
On the other hand, most GL tutorials tend to use features that are essentially non-performant on modern hardware (e.g. glBegin/glEnd, selection/picking, ... see the list of things that got removed from GL 3.1 or this other plug) and tend to seed the wrong concepts for a lot of things.
What's the most used one in the real world?
For games, DirectX9 is the standard today in PC world. By a far margin.
However, I'm expecting DirectX11 to grab more market share as it allows for some more multithreaded work. It's unfortunately significantly more complicated than DX9.
nobody uses OpenGL anyway (very very few people know about the secret switch at all).
Ask the Mac owners what they think.
Side question, do you really think hardware vendors would spend any energy in OpenGL drivers if this was really the case (I realize I generalize your comment, sorry)? there are real world usages of it. Not much in games though. And Apple makes OpenGL more relevant through the iphone (well OpenGL ES, really).
If it's something usually done, do programmers usually create their own 3d engine "wrapper",
It's usually a full part of the engine design. Mind you, it's not abstracting the API at the same level, it's usually more at a "draw this with all its bells and whistles over there". Which rendering algorithm to apply on that draw tends to be back-end specific.
This, however, is very game engine dependent. If you want to understand better, you could look at UE3, it just got released free (beer) for non-commercial use (I have not looked at it yet, so I don't know if they exposed the backends, but it's worth a look).
To get back to my comment that game engine does not just mean 3D, look at this.
I think the primary benefit of using OpenGL over DirectX is the portability. DirectX only runs on windows. However, this is often not a problem (many games only run on Windows).
DirectX also provides other libraries which are useful for games which are unrelated to graphics such as sound and input. I believe there are equivalents which are often used with OpenGL but I don't think they're actually part of OpenGL itself.
If you're going to be locking into windows with DirectX and you are willing to/interested in learning C# and managed code, I have found XNA to be and extremely easy platform to learn. It allows you to learn most of the concepts without dealing with a lot of the really tricky details of DirectX (or OpenGL). You can still use shader code and have the full power of DirectX but in a much friendlier environment. It would be my recomendation but again, you'd have to switch to C# (mind you, you can also put that on you're resume).
You might want to look at some projects that encapsulate the low level 3d api in a higher level interface that is api independent such as Ogre3D. As you are doing this to learn I assume you probably will be more interesting in implementing the low level detail yourself, but you could probably learn a lot from such a project.
if you are really only interested in the rendering part, i can suggest ogre3d. it is clean, c++, tested and cross-platform. i used it in two projects and compared to other experiences (torque3d for example), i liked the good support (tutorials/wiki/forum) and the not so steep learning curve. i think someone can also learn a lot by looking at the sourcecode and the concepts they have used in the design. there is a accompanying book as well, which is a bit outdated, but it is good for the start
the problem with this is, you will be thinking inside this engine and soon you will need gameplay-like (timers, events) elements for simulating and testing your effects or whatever you want to do. so you will end up working around ogre3ds shortcomings (it is not a game engine) and implement in on your own or use another middleware.
so if you really want to touch 3d rendering first, i would take some computer graphics books (gpu gems, shaderx) and see some tutorials and demos on the web and start building my own basic framework. this is for the experience and i think you will learn the most from this approach. at least i did ...
I'm doing some OpenGL work right now (on both Windows and Mac).
Compared to my midnight game programming using the Unity3D engine, usingOpenGL is a bit like having to chop down your own trees to make a house versus buying the materials.
Unity3D runs on everything (Mac, PC and iPhone, Web player, etc) and lets you concentrate on the what makes a game, a game. To top it off, it's faster than anything I could write. You code for it in C#, Java (EDIT: make that JavaScript) or Boo. (EDIT: Boo support has been dropped)
I just used Unity to mock up a demo for a client who wants something made in OpenGL so it has it's real world uses also.
-Chris
PS: The Unity Indie version recently became free.
I'm currently learning C++ and so I thought it would be a good idea trying to (re)program some "common" text-based games. (Thinking of Hunt the Wumpus, Guess a (pseudo) random number generated by the computer,...)
However, I can't find any good sources for such tasks.
Which text-based games could be "educating" for me to program?
Do you remember a special game you have programmed (written in C++ preferably), which taught you a lot?
It would be nice if you could include:
A general concept of the game
What aspects of the C++ language programming this game would require/involve
A self-learning version of "20 questions" might be quite fun (if you are unfamiliar with this, there is quite a fun implementation of this at Guess the Dictator/Sit-Com Character).
An example session (based on questions from this web site):
Are you female?
> N
Are you overweight?
> N
Do you live in an apartment building?
> Y
Do you travel for your job?
> N
Do you have strange schemes to make money?
> N
Do you live in California?
> N
Are you a new doctor?
> N
Is your father gay?
> Y
Are you gay?
> N
Are you an actor?
> N
Are both your parents gay?
> N
Are you black?
> N
I guess you are Chandler from Friends, am I right?
> Y
At this point, if I had answered N, I would have to say who I was thinking of, choose a question which distinguishes my chosen dictator/sit-com character from Chandler from Friends, and then say whether the answer to my question is "yes" or "no". This question is then remembered, and the program becomes slowly more and more knowledgeable about sit-com characters and dictators.
Depending on how you did this, this could help you learn:
Console I/O (to ask the user the questions)
Binary trees (each question is a node in the binary tree, and the child nodes are the questions you ask depending on the yes/no response)
File I/O (if you save the tree to disk)
I'm trying to remember some of the fun stuff I did way back when in my high school CS class. They're not all games but here it goes:
Text based (ASCII) animation - Basically I animated an ASCII dragon coming into the terminal, saying something, and leaving. After "drawing" each frame it was cleared so basically it was a frame-by-frame ASCII animation generator.
Maze - Used Unicode characters in kind of the same concept. I got keyboard input from the arrow keys and redrew your block going through the maze based on your input. Again, clearing the screen after each frame and printing out the text again.
Snake - similar concept as the above but it was a snake game.
Simple chat - this polled a shared text file on a central server in our school (that someone accidentally chmoded 0777) and facilitated basically a really simple chat room.
The beeper - this program became infamous at my school. Up until XP apparently the sound buffer on Windows computers could easily get overloaded by text. Running this caused the computer to beep until you turned it off (and in most instances also caused it to get bogged down so much you had to do a hard reboot). Definitely pissed off the administration of our high school. Plus it's only a 2-liner.
char o = 7;
while(1) cout << o;
Anyway, not sure if this helped you get any ideas but just use your imagination. You can have a lot of fun without having to know a lot about programming. Just be creative.
Zork of course!
Facebook has some cool engineering puzzles that I like, but they may be a bit advanced for just starting out. I'm am a so-so C++ programmer, so I solved the puzzles first in Python, then in C++.
Check out: Facebook Engineering Puzzles
They seem to have everything from easy (Hors d'oeuvre) to quite challenging (Buffet).
I believe these puzzles were set up for recruiting, but they're fun on their own. (Maybe I'm kind of geeky?)
Plus, they have an added benefit: never know when you might need a job.
A good source of classic games is
http://www.atariarchives.org/basicgames/
The games are in old school basic but learning to translate and write these in any language would certainly be useful to gaining skills.
For instance if you wanted to tackle a few cards games this would be good to create headers, functions, classes and put code into libraries that could be re-used between two or more of the games.
It is not so much what you do as long it stretches your skills and moves from the trivial to something less so...
Find a mentor to review your code and make suggestions about what to try or do different.
A number of basic board games you've played during your childhood.
Battleships! (In some countries, known as subs) -> This teaches you to mess around with arrays, passing buffers around. Can also (if you code an AI) get you to play around with that.
Checkers/Chess -> Implementing an AI is beyond the basics learning, but it's rather easy to code a text representation of the game.
Stratego or basic wargames -> Data structures and OOP.
How about Nim? There are two variations, one with multiple piles where you are allowed to take as many tokens in a single pile as you wish, and one with a single pile where you are allowed to take 1-N tokens at once (N typically around 3). The person to take the last token wins or loses.
Way back when, I implemented a version of the second game that let you specify all the parameters of the game, then would quietly choose to go first or not so as to guarantee a win. Ah, good times.
You must go to the coolest text game ever, Elite.
You can get the source code in very readable, and very interesting C code. The source is available at Ian Bell's site.
Elite was famous for its "infinite" universe. It's quite a clever design.
Hunt the Wumpus would be fantastic. It's a relatively simple game, but most examples are old procedural code in BASIC. You could start from scratch and write an OO version in C++.
Conway's Game of Life is another good one, since it doesn't require any user interaction. I wrote a 3D version early in my career, and found it helpful. And it's fascinating to watch :-)
<aside>
I actually miss the old days, when computer magazines had program listings in the back that you could type in yourself. They had games, utilities, whatever. I learned so much just copying what others had written.
</aside>
Back in the day, I made a hot-seat multiplayer roulette that taught me some basics, all text based. Basically, players would take turns to make bets on various numbers at different levels of stakes, there would be a draw (with animation & sounds), double or nothing for the winner. Was a lot of fun.
Legendary NetHack seems to be an excellent choice and originally in ASCII graphical user interface. However, it is implemented in C, not C++, though may be a good education material. Here you will find all details:
http://en.wikipedia.org/wiki/NetHack
http://www.nethack.org/
checkers. I had great fun writing this in a mixture of cobol and fortran a long time ago
there is a real thrill in seeing your creation act smartly
of course you go through many iterations where it acts dumb before you get to that point
Jotto is a great game that is just about the right complexity for someone learning. You have to think hard about a couple of good data structures, but you can easily put together a fun game in less then 1000 lines of C++.
You should check the site for interactive fiction in english:
http://www.intfiction.org/forum/
This is where the new developers of text games gather to discuss about them. However, implementation is not anymore carried on in C++ - a few specialized programming languages called Inform, TADS and Hugo are used instead.
You'll find a lot of text games (including Zork, Hithhiker's guide to the galaxy, Wumpus...) in the ifarchive:
http://ifarchive.org/
You can find an implementation of one of my one games in C++ here:
http://www.caad.es/baltasarq/if/csa/csa-cpp.zip
It could be useful, provided that you can read in spanish. Anyway, I've moved to Inform 6 myself.
Board games like checkers and Othello. Back in the 90s I had an Othello-AI competition with my coworkers. I think I started with tic-tac-toe before that.
Etudes for Programmers has some fun projects, if you can find a copy.
there used to be an adventure (i.e. text based game) writing language called ALPS and I remember coding a version of this, plus tcp and rudimentary multi user handler, as my first C/C++ project (initially the former, eventually the latter). Project was neatly bite-sized "modules" with definitive yardstick and fun end-result: I used it to make a quaint MUD with my mighty 32K BBC Micro. Coding a C/C++ ALPS ended up teaching me the lingos in literally a week - to a decent working standard (far from expert mind you).