Lab 01: Tic-Tac-Toe

Problem overview

Tic-Tac-Toe is a simple game that usually is based on a 3X3 grid (but not always, see below). Although simple, Tic-Tac-Toe is known as a "zero sum game" since its impossible for two informed players to win a game; the ideal strategy always results in a tie.

That said, with two elementary school children who play this game pretty regularly on kids menus, one can win more often that you'd think (esp. against a non-patient player). The goal of this lab is to implement both a more interactive Tic-Tac-Toe program to see for yourself.

Inspiration

Note, this problem is very loosely based on the 202 Checkboard Lab 1 from Dr. Plank here, although the syntax and overall goals are pretty different. By starting with an intuitive game, hopefully it will help with knocking off some more rust before Part 2 of the lab, which is intended to introduce you to the sort of transparent grading we'll use in 202 and 302 (for those continuing on). It is also is intended to be an assignment that reinforces what you should have learned in CS102 (or its equivalent) while adding a new C/C++ wrinkle: 2D arrays.

Input / Output

You will ultimately be given an integer and a series of characters from standard input in the follow format:

N
X X O
...

For example, here is a 3X3 grid where X wins:

3
X X X
O X O
O O -

Your program should output the following:

X wins

For another example, here is a 4X4 grid where no one wins:

4
X X X O
O X O X
O O X O
X O X O

Your program should output the following:

Tie

Part 1

Develop a simple C++ program called "toecheck.cpp" that will read in a sample input file as described above from standard in and report either "X wins," "O wins", or "Tie."

The idea behind toecheck is we want to "freeze" 8 specific boards that could have been populated manually in a more interactive mode without any typing on our end. This will mean all roughly 100 students will need to make sure their "win" detection code works for at least these 8 test cases.

Part 2

Develop a separate simple C++ program called "toe.cpp" that asks a user for the grid size, and then allows two players to interactively play Tic-Tac-Toe. This program must be able to:

  1. Use formatting (printf/cout) to provide an intitutive and well formatted board each turn to the players
  2. Prevent a player from entering an invalid cell
  3. Prevent a player from changing a previously chosen cell
  4. Determine if a player has won or not after each choice
  5. If no cells remain, report there has been a tie.

The prior cohort liked this for what it is intended to be: a good warm up. You are encouraged to use your "win" detection code from Part 1 in this separate .cpp to detect if any interactive player has won.

For purposes of this practice each run of "toe" will allow the players only one potential game. Subsequent games will require running "toe" again. Also, since we are "freezing" 8 specific cases from Part 1, you can assume that the provided input boards are correct/valid input. No need to worry about tricky input other than what is required in the rubric... that will come later in 202/302.

Please talk to us or use Piazza if you still have questions.

Rubric

I realize its a little awkward and ideally you'd just have to write ** either ** toecheck or toe but I wanted you to get more practice coding on simple inputs loosely consistent with the basic C++ (if/then, for loops, arrays/vectors) assessed in prior 102 labs, namely Speeding Ticket, MPG calculator, bowling, selection sort.

Creating a required "toecheck.cpp" also makes grading transparent and consistent across all submissions, which is an approach we'll use throughout 202/302. In software engineering these are often called "unit tests."

We will grade your submission relative to the rubric below. 

+2    Code is well formatted, commented (inc. name, assignment, and overview), with reasonable variable names
+3    Uses formatting (printf/cout) to provide an intitutive and well formatted board each turn
+3    Prevents a player from entering an invalid cell
+3    Prevents a player from changing a previously chosen cell
+3    Works as intended on a 4X4 board (4 in a row wins)
+3    Works as intended on a 5X5 board (5 in a row wins)
+5    Correctly determines if a player has won or not after each choice
+8    Test cases successfully solved (1 point each)

We realize that this is quite a step up from the simple prelab if your coding skills are a bit rusty, so please start early. We also realize that some edge conditions are harder than others, e.g., detecting a verticle win. Our test cases will be somewhat evenly split between horizontal, vertical, diagonal wins as well as ties. So if you are not able to get certain tests to work you still should receive most of the points if other cases work in your submission.

As potential hints, this is what my program does on a high level:

  1. Uses a fixed 2D array of chars, each of which are initialized to ' '
  2. Has a "turn" counter to keep track of how many cells have been chosen. You can use the mod operator (%) on a similar variable to see if its even (e.g., X) or odd (e.g., O).
  3. I honestly made my code a little "smarter" than a typical 202 solution by testing just the "win" conditions that include the latest chosen cell -- using just single for loop -- vs. checking for all horizontal, then vertical, then diagonal. I assume many of you will do each of these separately, which is somewhat helpful for Part 2, but whatever you choose is totally OK as long as it works.
  4. There are a few methods, but I think the simplest is to look for a "run" of size equal to the board. For example, lets consider the first row. For a win to exist the first character (A[0][0]) must be filled ** AND ** the n-1 cells to its right must also be equal to that first character, aka A[0][0]). In my implementation if A[0][0] was filled I initialized a variable "run" to 1, and incremented run if A[0][j] (for j = 1 to < size) was equal to A[0][0]. If run was n in lenth, then the player who placed A[0][0] won. Its also fine to initialize run to 0 and use board_size - 1 to determine a win. Let us know if you have questions/concerns.
  5. Although somewhat counter-intuitive, the left top to right bottom diagonal is the easiest since A[i][i] must equal A[0][0] for all i = 1 < size. So the diagonal check is only a single for loop. Think on your own about how to change this for the top right to bottom left diagnonal.

Testing your code prior to submission

To faciliate testing, you were previously asked to clone the course Github repository as follows: 

git clone https://github.com/semrich/CS202-24.git cs202

For this assignment, update this clone by using the following: 

git pull

To test your solution against ours, type: 

make test

Submission

To submit your solution, you must submit a tar file on Canvas prior to the deadline using this command: 

tar -cvf lab1.tar toe.cpp toecheck.cpp

Note: Although submission will be faciliated by Canvas, we will compile and test on EECS lab machines!

If you develop your solution elsewhere please make sure it works on the lab computers prior to the deadline