CSSE 120 Final Python Project—Fall 2007

Project Requirements

The final project for the Python part of this course is to implement the game Quixo. Rules for the game are given below.

Your project must satisfy these core requirements:

1. You must design and implement a fully functional Quixo game including:
   1. allowing all legal moves
   2. allowing only legal moves
   3. detecting who won the game
2. Your project must use a GUI for game play.
3. There must be at least one user-defined class, Block, to describe an individual block in the game. (We encourage you to use a fully object-oriented design.)
4. All team members must contribute to and understand their project.

Most of the work on your project will be translating the rules provided into a functional design and implementation. There are not many requirements on how specifically you do this. This can be a double edged sword. On the one hand you have a great deal of freedom in design; on the other hand we're giving very little specific guidance. If you are having trouble planning or getting started, get help. It is much better (and easier) to get help early and start off with a good plan than to try to hack a poor design into a semi-functional program in the final days before it is due.

Milestones

To make sure that you are on-track to complete your project, you must meet the following milestones. Each milestone will contribute to your overall project grade. Each milestone must be done before the specified class session.

• Session 18 — UML Class Diagram Sketch: A neatly drawn UML class diagram showing the user-defined classes for your program including instance variables and methods. This does not have to be your final design, just your initial plan. The diagram can be hand-drawn or you may use a program to draw it. We strongly suggest that you draw your initial design on a whiteboard. Regardless of the way you choose to draw the diagram, you must turn in a single plain white 8½ × 11 inch sheet of paper showing your final design. This format is non-negotiable as we will be scanning the designs to share with other teams.

• Session 20 — Program Shows Game State: To support testing and encourage separate development of your model and view, your game must include a pair of top-level functions (i.e., not inside a class), printBoard(board) and createBoard(listOfRows). The printBoard(board) function must print the state of the given board to the console. The createBoard(listOfRows) function takes a list of strings representing the board state. It must return a board initialized to the given state. For example, to create a board with the game state below, we could call the function like this:

  b = createBoard(['----O', 'XX--X', 'XO---', 'OO---', 'X----'])
  

  

  After creating that board, a call to printBoard(b) would output:

  ----O
  XX--X
  XO---
  OO---
  X----
  

  Note that you have to design and implement some data structure, like a custom object, to track the board state. It is not sufficient to merely store and print the list of strings. If you are using an object-oriented design as recommended, your createBoard() function will probably call a constructor and your printBoard() function will probably call a method.

• Session 21 — Program Allows Player to Make Any Single Move: Again to support testing, your game must include a top-level function to allow console-based move input. Create a function:

  makeMove(board, chooseRow, chooseColumn, placeRow, placeColumn)
  

  This function must mutate the game state of the given board to reflect a player picking up a block from position (chooseRow, chooseColumn), where the top row is 0 and the left column is 0, and putting the block back at position (placeRow, placeColumn), sliding the blocks as necessary.

• Session 22 — Game Finished
• Wednesday October 24 (11:45 AM to 1:30 PM)— Final Presentation: You'll present a poster and demo of your game at a final project presentation fair in the Robert Kahn Room in Hulman Student Union. Your poster should include
  1. a title
  2. your names
  3. a description of your design, with UML diagrams
  4. a screen shot of a game in progress, and
  5. anything else that showcases what you have done to develop the your game.

  We will show you a sample poster of a past CSSE 120 team project during session 22.

  You can purchase a cardboard display board at the campus bookstore for about $9.00 per team. (If they are out of display boards you can get two pieces of foam board that you can hinge together with tape for roughly the same price.)

  In addition to presenting your poster, you also need to demo your game on your laptop.  This means you need to bring both your poster and your laptop with its power cord, to the final presentation.

  We will provide power strips for your laptop's power cord.

  We will invite the rest of the campus community to come to the poster session, so you'll want to dress well and do your best to show off your great work.

Grading

Project grades will be based on both individual and group results. We will grade each project milestone, plus the final project program and presentation. Grading will include both the proper functioning of your program and an evaluation of your design, coding style, and documentation.

Each team member will be required to complete an evaluation survey about his or her own performance and that of each of his or her teammates. We will use these surveys and our own observations to assign individual project grades.

About Quixo

Overview

Quixo is a two player board game that is much like tic-tac toe, but with a twist. The board consists of a 5 by 5 array of blocks. Each block is either neutral or belongs to one of the two players. Neutral blocks show a blank face on top. Player blocks show the player's symbol, typically an X or an O. The players alternate turns. On each turn, the player picks up a perimeter block, slides a line of blocks to fill the space, and places the original block in the newly opened space. The moved block now shows the player's symbol. The first player to get 5 in a row wins!

Rules

Initial Game Setup

• The board is a 5 by 5 grid that consists of 25 blocks.
• All of the blocks start showing a blank (neutral) face. That is, neither player owns any blocks initially.
• The two players choose who will play which symbol. The symbols are typically X and O.
• Player X always goes first.

Game Play

Players alternate turns until one player wins. Each turn follows the same progression:

1. The player chooses a block from the perimeter of the board. The block chosen may be neutral or may be owned by the player. If a neutral block is chosen, it now is owned by the player.
2. Removing a block in step 1 creates two incomplete lines of blocks: one horizontal and one vertical. The player chooses one end of one of these lines and slides the blocks to close the original space, opening a new space at the chosen end.
3. The player places the block chosen in step 1 into the space created in step 2, turning the block so that the player's symbol is showing.

The examples below may be helpful. You may also stop by F217 and play the actual game there.

Example: Opening Move

This example shows an opening move by player X. Player X chooses a non-corner block, which means he has three options for which blocks to slide.

Example: Corner Move by O

This example shows a move by player O. Player O chooses a corner block, which means he or she has two options for which blocks to slide.

Winning the Game

The first player to get 5 symbols in a row—horizontally, vertically, or diagonally—is the winner. Because the blocks slide, it is possible for both players to get 5 symbols in a row simultaneously. If this occurs, then the player who made the last move is the loser. The other player wins.

Suggestions

• You may find this online description of the official rules helpful.
• Plan first! Use top-down design and object-oriented design. Get help early if you need it!
• You may want to follow the model-view approach that Zelle uses in section 12.3
• Players usually gain a piece each turn, but if they choose one of their own blocks they won't. Thus, there doesn't always have to be an equal number of pieces on the board for each player.
• When designing your GUI, think about how your users will perceive your game. Try to make it as easy as possible for them to understand the rules. For example, you may wish to highlight the legal moves.

Stretch Goals

If your project is going well and you would like to try some more challenging extensions, here are some ideas:

• Replace Xs and Os with some other clearly distinguishable symbols.
• Animate the moving of blocks.
• Implement the four-player version of the game as detailed here.
• Add sound effects using the winsound Python library.
• Implement a computer player.