CS 117, Final Projects, Spring 1997

Description due 5/28/97. Code and documentation due 5:00 PM, 6/11/97.

The Project

For your final project, you will write a game program. You can take one of two approaches: make the game fun to play, or make the computer good at playing the game.

Approach #1: Make the game fun to play

You should design your user interface with ease of use in mind, so users can concentrate on strategy instead of being annoyed by the things required to enter their moves. An aesthetically pleasing display of the game board or hand, if appropriate, also adds to the fun of playing a game. Think about computer games you have played, and what makes some of them a pain to play, and others a delight.

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.

Approach #2: Make the computer play well

Some games are asymmetrical, where one player has an easy job. For example, when you play hangman, one person just has to think up a suitably random word and respond to the other player's guesses. This job is very easy for a computer to perform, and as a result, there are hundreds of versions of hangman on the computers of the world. One could argue that games like hangman are really one-person games. Other games like this are Mastermind and its low-cost relative Bagels.

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

Grading criteria

Successful compilation. If your program doesn't compile, I won't grade it.
Correctness. Your program needs to do the job it's intended to do.
Design. I will look for well-considered choices of data structures and functions, their return values, and their parameters. A good rule of thumb for checking yourself on this point is to look at your main program--if you can tell what the program does from a quick read of the main program, then you have probably come up with a good design.
Style. I want to see good indentation, descriptive variable and function/procedure names, well-placed comments, consistent loop structure, and so on. Ideally, your code will be a pleasure to read.
Documentation. Your description of your project and the comments in your source code are important parts of your project. I want to be able to understand your project fairly well before diving into the code.
Deadlines. Meet them.

The Schedule

By May 28, send me e-mail describing your program and which of the two approaches you plan to take. You may also send me any initial questions you have about your project.

By 5:00 PM Wednesday, June 11, send me the following via HSP.

Your fully commented source code
A description of the program (the description from the May 28 part of the assignment would be fine)
A description of the status of your program (what works, what doesn't, and etc.)

A little advice

Don't start late.

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.

Jeff Ondich, Department of Mathematics and Computer Science, Carleton College, Northfield, MN 55057
(507) 646-4364, jondich@carleton.edu