Your choice of game will determine what will be required to make the game fun. For example, if you select a two-person game like Battleship, you will have to program the computer with a strategy, since having two people play Battleship with one screen is a pain. On the other hand, adventure games (you walk from room to room discovering stuff) don't require a smart computer strategy. Similarly, Tic-Tac-Toe is tedious at best, but it's really dumb if the computer is an idiot about choosing its moves.
Be warned that even very simple games can be tricky to implement, so don't try something like Backgammon or Hearts unless you're sure you have plenty of time to devote to the project.
Other games are symmetrical, or very nearly so. Chess, Go, Tic-tac-toe, Dots and Boxes, Battleship, and Cribbage are examples of games in which both players are faced with a nearly identical challenge.
If you choose Approach #2, the heart of your project will be the computer's strategy for playing the game you choose. For example, you could program the computer to play Tic-Tac-Toe by picking a random open square, but you would end up with a program that never wins and almost always loses to an experienced player. On the other hand, if you understand Tic-Tac-Toe, you can program a computer to play it perfectly (always tying when playing a perfect opponent, and winning whenever the opponent makes a mistake).
You can write your program to play against a human player. In this case, you should pay enough attention to the user interface to make sure a new user will be able to figure out how to play. The user will also need to be able to see the current state of the game at any time.
On the other hand, you could write your program so that it plays against itself, and collects statistics on how many games are won by which strategy. For example, it might be interesting to know how many wins, ties, and losses a "play in a random square" Tic-tac-toe strategy would achieve against a "block my opponent if I can, and otherwise play in a random square" strategy. If you take this approach to your program, make sure the program prints out the collected data in an intelligible way, and also make sure to discuss the results of your investigations in the documentation you hand in with your program (see below).
By 5:00 PM Wednesday, June 11, send me the following via HSP.
Have a careful plan of the small steps you will take in travelling from no program to the final program. Design your program modularly, so you can make the modules work one at a time.
Don't go to sleep without a program that compiles and runs without crashing. It doesn't have do anything--just don't try to do so much at once that you can't wrap up the day's work into a running, partially complete, program.
Make copies of your program before making changes.
Don't assume that a text-only game is no fun. An interesting game is interesting whether it's played on paper or in the dust on the ground or on a high-powered graphics workstation.
Feel free to talk to each other and learn from each other, and compare approaches to the problems posed by these programs. If you take a significant idea from another person, please give explicit credit to that person. You may borrow code from my example programs, and from your own homework (which may have been co-written by you and your partner), but if you do, give credit to the author/coauthor. Otherwise, your code should be your own.
Talk to me. I can help. I will hold regular office hours during reading and exam days. I will post my hours on my office door.
Start early, keep in touch, and have fun.