CS 115 Project 2, Spring 2015:
Tic-Tac-Toe

Summary

In this project, you will allow two users to play a variant of Tic-Tac-Toe on their choice of board.

Due dates

Getting Started

Because this program is graphical, you will need to run it using IDLE on your local machine. Download graphics.py into your Python directory.

Checkpoint A (7 points)

Specification

• Ask the user for the size of the graphical window to draw. For example, if the user says 600, you should draw a 600x600 window. Legal values are 100 to 1000 (inclusive).
• Ask the user for the number of squares per side. Legal values are 3 to the window size divided by 10 (rounded down). For example, a 608x608 window could support up to a 60x60 board.
• Ask the user how many squares in a row it takes to win. Legal values are 1 to the number of squares on a side.
• Draw a graphical window for the game board, including lines for the squares. You do not need to draw lines for the top, bottom, right, or left edges of the screen.
• You may assume that the user gives you integers for all 3 inputs. However, if the user gives you an integer that does not meet your specifications, you should print a helpful and specific error message, and exit the program immediately.

Examples

Sample 1

Window side length in pixels: 50
Error: must be a number between 100 and 1000.

Sample 2

Window side length in pixels: 400
Number of squares per side: 50
Error: must be a number between 3 and 40.

In this sample, the upper limit of 40 comes from 400 divided by 10.

Sample 3

Window side length in pixels: 400
Number of squares per side: 4
Squares in a row to win: 4

Here is the blank board your program should draw:

Hints:

To exit a program immediately, import the sys library. Then, you can use sys.exit().

To draw the grid, you will want to use the Line data type from graphics.py. You may want to review Lab 5 to see how this data type is used.

Checkpoint B (8 points)

Specification

• Take turns prompting each player to click a square.
• Draw an X or an O in the square the player clicked, OR color in the square with a different color for each player.
• You should prompt once per square. For example, you will prompt 25 times (13 times for Player 1, 12 times for Player 2) for a 5x5 board. Notice that Player 1 will get an extra turn if the number of squares is odd.
• The two players will alternate until all of the squares have been clicked. For the checkpoint, you can assume that the user will not click the same square multiple times.

Sample 3

Window side length in pixels: 400
Number of squares per side: 4
Squares in a row to win: 4
Player 1: click a square.

Here is the board before Player 1 clicks:

Here is the board after Player 1 clicks:

Player 2: click a square.

Here is the board after Player 2 clicks:

Final Code (55 points)

In your final code, you will extend your checkpoint code in the following ways:

• Print an error message in the console (text window) if a player tries to click a square that has already been clicked. Do not change the marking in that square.
• Print a message in the console (text window) if a player wins. Winning is defined as marking the specified number of squares in a row along any row, column, or diagonal. At this point, you should stop prompting the players to click, and you should wait for the user to click inside the window before closing the graphics window and exiting the program. For example of a winning gameboard (for 5 in a row):
  

  Winner: Player 1. Click the window to exit.

Hint:

One easy way to keep track of what the players have clicked is to use a 2-dimensional list. Initializing a 2D list is a little bit tricky in Python. Here is an example:

size = 5
board = [[0] * size for i in range(size)]

This creates the following 2D list:

[[0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0]]

You can access an individual element by using two index values: one for the row, and one for the column. For example:

board[0][2] = 2

changes the list to:

[[0, 0, 2, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0], [0, 0, 0, 0, 0]]

There is no demo for your final code. See the end of this specification for submission instructions.

Grading

Correctness [55%]

The most important part of your grade is the correctness of your final program. Your program will be tested numerous times, using different inputs, to be sure that it meets the specification. You will not get full credit for this 55% unless your output is grammatically correct, correctly spelled, and professional.

Programming Design and Style [30%]

In addition to being correct, your program should be easy to understand and well documented. A detailed grading sheet for this part of your project is posted at
http://rivoire.cs.sonoma.edu/cs115/proj/cs115_p2_rubric_partial.html

This grade sheet is different from the Project 1 style grading sheet. In particular, you will lose a lot of points if you don't design and use at least one function of your own.

Note that there is an automatic style checker on cwolf that can check some aspects of programming style for you. For details, see the grading sheet link.

Checkpoint [15%]

Your checkpoints are worth a combined 15 points, as described above. The checkpoints cannot be submitted late.

Extra credit [up to 5 points]

There are lots of possibilities to extend this project for extra credit. If you have an idea you'd like to implement, run it by Dr. Rivoire.

Submitting your final code

If your project code is on your computer, you must copy your final code to the CS department server using FileZilla BEFORE following the instructions in the next paragraph. Every lab has instructions on how to do this.

Once your project code is on the cwolf server, you must submit it for grading by logging onto cwolf and running this command:

~srivoire/bin/submit 115

Type P2 when prompted for the assignment, and then type the name of the file you want to submit. Be sure that you confirm your submission by visiting
http://rivoire.cs.sonoma.edu/cs115/submit/proj2.txt
and looking for a file with your name, your cwolf username, and the correct timestamp.

You may resubmit as many times as you like, and only the last submission before the due date will be graded.

Collaboration policy

Programming projects must be your own work, and academic misconduct is taken very seriously. You may discuss ideas and approaches with other students and the course staff, but you should work out all details and write up all solutions on your own. The following actions will be penalized as academic dishonesty:

• Copying part or all of another student's assignment
• Copying old or published solutions
• Looking at another student's code or discussing it in great detail. You will be penalized if your program matches another student's program too closely.
• Showing your code or describing your code in great detail to anyone other than the course staff.

Late policy

There is a 48-hour grace period associated with the final project deadline. This grace period is designed to cover small personal emergencies and other unexpected events. No other consideration will be given for these small emergencies.