CPTR 124 Fundamentals of Programming Labs

CPTR 124 Fundamentals of Programming

In this lab you will use a multidimensional array to implement a two-player game.

Teams As usual, you are invited to work with a partner. Please submit one lab write up per team.
Preparing your working folder Make a subfolder named Lab11b within your H:\cptr124 folder.
Background. Three-dimensional Tic-Tac-Toe (henceforth 3D3T) is an extension of the standard Tic-Tac-Toe game to three dimensions. The game "board" is constructed of four layers of 4x4 grids making up a cube as shown in Figure 1.

Figure 1

To play the game, player X types in a three integer sequence that specifies the layer, row, and column where an x should be placed. Player O does the same placing an o in a particular position. The play continues with the players alternating turns until one player gets four entries in a straight line (the winner) or all the squares are filled with neither player getting four entries in a line. When the board is filled and neither player has won the game is a draw.
For 3D3T, "four in a line" can be achieved in the following ways:
- Filling a row within a layer with the same mark
- Filling a column within a layer with the same mark
- Filling the same row and column across all four layers with the same mark
- Filling a line from any corner of the cube to any other corner of the cube with the same mark (this is a diagonal win)
Implementation details. Since during the development process (and during our testing process) the task of entering the moves to play the game is tedious, instead of expecting users to enter moves via the keyboard, your program should instead read moves from a textfile. You can use the editor to create the test files. Each line in the file contains one move; for example, a test file might begin with the entries
```
        3 0 3
        2 3 1
	
```
This means player X moves to layer 3, row 0, column 3, and then player O moves to layer 2, row 3, column 1.
Your test files should be properly formed to yield a complete game. A complete games results in a win for one of the players or a draw.
Players should not be allowed to move to a position that is not on the board, neither should they be allowed to move to a position that is already occupied. A warning is issued for any attempt, and the move is ignored.
During play, a mark is either x for player X or o for player O. In the event of a win, the victor's winning line should be highlighted by capitalizing the marks that make up the winning alignment.
You will likely write a win() method that checks the board configuration after a move to see if the last move resulted in a victory for the player that made the move. Your win() method will necessarily be fairly complex. It will surely test your skills in writing conditional and iterative constructs.
Given a 4 x 4 two-dimensional grid, a win can occur in any of 10 ways. Figure 2 shows the possible ways to win.

Figure 2

Think of the playing cube as being sliced into planes as shown in Figure 3. Figure 3 shows the 18 planes that make up the 3D3T cube.

Figure 3

Your code could check each possible winning configuration; in each plane there are 10 ways to win and the board consists of 18 different planes of interest.
The check is completed as soon as a winner is determined; multiple winning configurations (for example, placing an x in a position that makes four in a line two different ways) are irrelevant. Observe that within the 18 planes shown in Figure 3 there is the potential for considerable redundancy in checking a particular line of marks--see Figure 4.

Figure 4

Notice that the red row (row 3 in layer 3) in Figure 4 appears in three different planes; the blue column (row 3, column 0 cutting across all four layers) appears in three different planes also.
You do not need to worry if you make redundant checks (checking the same line more than once); you do need to make sure you do not omit any essential checks.
While it is possible to be clever and reduce the amount of code considerably by exploiting the symmetry of the planes, it probably is not worth your time for this assignment to try to be too tricky. You'll find the straightforward approach to be much easier to debug and get running. Use some "common sense", though; one particularly poor approach would be the extreme brute force method using no loops whatsoever:
```
        if (board[0][0][0] == board[0][0][1] && board[0][0][0] == board[0][0][2]
             && board[0][0][0] == board[0][0][3] && board[0][0][0] != EMPTY) {
            return board[0][0][0];
        } else if (board[0][1][0] ==  . . .  etc  . . .
	
```
This would require many separate if statements. Do not do it this way!
Fortunately, if no winner is found, the check for a draw is easy.

Output. The board should be drawn initially and redrawn after each move. This program is nongraphical, but it uses text in a clever way to give the effect of a three-dimensional cubic playing board. Empty cells are indicated by a '.' as shown in the initial empty board configuration:

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

The first plane is layer 0, the rows are horizontal within each layer, and the columns are "vertical" (actually slanting slightly to the right from bottom to top).

Suppose player X chooses layer 2, row 3, column 0:

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 x   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

If player O then chooses layer 0, row 1, column 1, we would have

    .   .   .   .
   .   o   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 x   .   .   .

    .   .   .   .
   .   .   .   .
  .   .   .   .
 .   .   .   .

As always, use the standard Java coding style conventions.

Your finished program will be evaluated for correctness and compliance. Points will be awarded as follows:

Points Features

1 Can 1) build a 4 x 4 x 4 empty puzzle, 2) print the puzzle in a way shown in the problem description, and 3) can read in the list of moves from a file and print those moves without affecting the puzzle

2 All of the above but Xs and Os are inserted in their proper places according to the moves in the datafile. Some runtime errors (exceptions) may occur.

3 All of the above without exceptions, plus a tie game can be detected.

4 Some winning combinations detected, but not all.

5 3D Tic-Tac-Toe appears to be completely and correctly implemented.

Points	Features
1	Can 1) build a 4 x 4 x 4 empty puzzle, 2) print the puzzle in a way shown in the problem description, and 3) can read in the list of moves from a file and print those moves without affecting the puzzle
2	All of the above but Xs and Os are inserted in their proper places according to the moves in the datafile. Some runtime errors (exceptions) may occur.
3	All of the above without exceptions, plus a tie game can be detected.
4	Some winning combinations detected, but not all.
5	3D Tic-Tac-Toe appears to be completely and correctly implemented.

When approved, you should submit a printout of your code. Be sure your name and your partner(s) names are included on the printout.