CSSE 120 Final Python Project—Fall 2010

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. Your game's window should be no larger than 1024 x 768 pixels, so it can be easily displayed to the class using the projector.  zellegraphics should suffice for developing the GUI, but you are welcome to explore and use a different library like pygame if you wish.
3. We strongly encourage you to use top-down design, define some kind of new objects (using dictionaries or instances of classes you create),  or consult with your instructor on alternative design choices.
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 designing your solution; on the other hand we are 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 the project is due.

You were not assigned the tic-tac-toe project this term, but exploring that project may give you some ideas on how to approach design.  We will commit our solution to the tic-tac-toe project to you individual repository (not your team's repository).

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 17 — Top Level Structure Diagram: A neatly drawn structure diagram showing the top-level functions that you plan to use in your program including a few formal parameters and return values. You should start thinking about the objects (dictionary types or instances of classes) you will need. 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, first. 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, and may share it with other teams.

• Session 18 — Program Shows Game State: To support testing and encourage separate development of your model and view, your game must include the following two top-level functions (i.e., not inside a class, if you chose to use object-oriented design), 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, list, or dictionary) 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, your createBoard() function will probably call a constructor and your printBoard() function will probably call a method. Again, this is not a requirement---just a suggestion.

• Session 19 — 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 21 — Game Finished — Final Presentation

Grading

Project grades will be based on both individual and group results. We may 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. This rubric will be used as a guide to grade your submitted project code. 

Each team will be responsible for presenting and demonstrating their work to the class.  Students will use this peer evaluation form to give the instructor feedback on each group's presentation.  The instructor will also use this form to evaluate each presentation.

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 or she 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 possibly other design strategies (one example is 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.

Enhancements

Once you are done with the basic version, you may want  to add some enhancements for extra credit. You will earn a higher grade for doing more challenging ones, and the more, the better. Be creative. What's cool and challenges you?  Below are some ideas.  You may wish to discuss other ideas with your instructor, if you wish.

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