Project #6

CMSC 131

Due: 

Wednesday, April 21, 11:00PM (Part A)

Wednesday, April 28, 11:00PM (Part B)

Object-Oriented Programming I

Type of Project: Closed

Spring 2010


4/25: Mancala examples now available.

4/22: Simplification in Mancala rule on dropping of last stone in empty pit (now this rule can be applied just once per move - see below)

4/22: In order to test your program on your computer with the above rule change, you must do the following:

4/19: See relaxed requirement on unit testing below.

TIC TAC TOE EXAMPLE GAME:

 

MANCALA EXAMPLE GAME:

Objective

This project will give you practice in manipulating one and two-dimensional arrays, will introduce you to thinking about more complex algorithms, and will offer a competitive environment for you to test your skills against your classmates (and TAs!).

 

Overview

The finished project will be an implementation of the gameplay logic of two games: Tic Tac Toe and Mancala. You will write code for your projects as described below and submit as usual to the submit server.  As soon as either game passes all of the release tests, it will be entered in an automated competition where your solution is played against every other student's solution (the tournament will copy submissions and re-run every 10 minutes).  There is a public leaderboard that shows how each person is doing and also shows the complete history of every game.  You are encouraged to submit early so you can compete against other students, analyze why your code wins or loses, and then improve and resubmit your code. The tournament engine runs 24/7, taking the latest successfully submitted projects and running a new tournament every 10 minutes or so.

The main leaderboard shows the results of only the class students, but as an extra motivation, there is an option to include the TA solutions.  So, see how well your program can do.  Compete early and often.  Study how your solution plays in response to other students (and TAs) solutions and see if you can come up with a better algorithm.  You will not be graded on your ranking in the competition, but you will definitely get bragging rights. [ACTUALLY, this isn't implemented yet - at the moment, all solutions including TAs are displayed].

Note that when you define your solution, you also have a mechanism to define the name that your solution will be posted under.  You are free to use your real name, your class account, or an anonymous name of your choosing - so you aren't obligated to share your ranking with others.  However, we will know who is who, so you may not use any name that is offensive or that implies that you are someone else.

Look at the Leaderboard to see current results.

Game Structure

Both games are structured around game state, which is simply the state of the board of the game at any given time.  Tic Tac Toe, for instance, has a game state of 9 cells (organized in a 3x3 grid) which can each contain a space, an 'X' or an 'O'.  The state can be represented as a simple string (which is simply the sequence of 9 characters for Tic Tac Toe), or can be printed in a prettier human readable form as a grid, which is useful for debugging.  To play the game, your code will be able to play a legal move of the game.  You do this by taking an instance of a class representing the game state, and modifying that state to represent your move.  For any game, there are two essential parts to moving:

  1. Deciding what legal move you want to make (e.g., in Tic Tac Toe, you must put down only one piece, it must be your piece, and you can only put it down on a blank spot).
  2. You must modify the game state to represent your move.  For some games, like Tic Tac Toe, this is straight forward.  For other games, this can be more complex.

Your job for this project will be (for each of the two games) to implement a class representing the state of the game, and then to implement the game logic for that game.  Details for each game are below.  You are provided with a driver class for each game which will let you run the game within Eclipse on your own computer for testing before you submit it.  This driver works by creating two instances of your game logic and plays one instance against the other - i.e., it plays your code against itself.

This project is divided into two parts.  The warm up is to implement Tic Tac Toe, and that has its own release tests, submission and deadline.  The game logic here is straight forward, but we want to give you a week to get used to the two-player game action, and to get used to the game server.  Note that even though the grading for this game will close on the first deadline, you can continue to refine your game and compete during the second week of the project.

The second part of the project is just like the first part, but with a new game called Mancala whose game logic is somewhat more complex.

 

Tic Tac Toe (Due April 21st)

The rules of Tic Tac Toe are straight forward.  The board consists of a grid of 3x3 cells, each of which are empty at the start.  There are two players.  The first player always plays 'O' pieces and the second player always plays 'X' pieces.  Players alternate turns until either someone wins, or all 9 cells have been filled. Note that it is possible if played well to never lose, however if both players are good, then the game will always result in a tie.

Legal moves:

Winning game state:

You must write TicTacToeState and TicTacToeSoln classes in the "<studentacct>.tictactoe" package according to the following requirements.

Important notes for all code that you write for this project:

TicTacToeState Class

This class represents that state of the Tic Tac Toe game.  It must meet the following requirements.

TicTacToeSoln Class

This class represents the solution to the Tic Tac Toe game. As described previously, your primary just is to implement the game logic to play a good game of Tic Tac Toe.  It is up to you to figure how how to play well.  If you are not familiar with the game, you should spend some time playing it so you get familiar with it. One of the release tests is to automatically play your solution against a program that plays randomly.  You must beat the random player 60% of the time to pass the release tests, and thus be qualified to move on to the automated class competition.

This class provides a solution to the Tic Tac Toe game.  It must meet the following requirements.

 

Mancala (Due April 28th)

The rules of Mancala are a little more complex than Tic Tac Toe.  You can read about Mancala in general, but you will quickly find that there are many variations of the rules.  We will follow the rules described here.  The board consists of a number of "pits" which hold "stones". There are two players, and the figure above shows which section of the board is owned by which player.   There are regular pits which initially hold four stones each, and each player has a "mancala" where the player tries to move as many stones as possible into. Players alternate turns (sometimes getting to go again) until either the game is over because all of a player's pits are empty.  The player with the most stones in their mancala wins.

Legal moves:

Winning game state:

A number of examples of how Mancala works in specific situations is available here.

You must write MancalaState and MancalaSoln classes in the <studentacct>.mancala package according to the following requirements just as you did with the Tic Tac Toe project. 

Important notes for all code that you write for this project:

MancalaState Class

This class represents that state of the Mancala game.  It must meet the following requirements.

MancalaSoln Class

This class represents the solution to the Mancala game. As described previously, your primary goal is to implement the game logic to play a good game of Mancala.  It is up to you to figure how how to play well.  If you are not familiar with the game, you should spend some time playing it so you get familiar with it. You can make your own game with some pebbles and paper cups, or you can try this online version which will give you a sense of the gameplay, although it uses slightly different rules. One of the release tests is to automatically play your solution against a program that plays randomly.  You must beat the random player 60% of the time to pass the release tests, and thus be qualified to move on to the automated class competition.

This class provides a solution to the Mancala game.  It must meet the following requirements.

 

 

JUnit Tests

Modified 4/19: You are required to write a series of JUnit tests to test all the methods of the the two state classes you are writing (i.e., TicTacToeState and MancalaState). You do not have to write unit tests for your solution classes (i.e., TicTacToeSoln and MancalaSoln).  20% of your grade on this project will be determined by the thoroughness of the tests you write.  Create a class called "StudentTests" in the default package (for each of the two games), and put your tests into that class.   If the tests are not located in this file, your submission will fail.

Each time you write a significant method for your class, you should write a series of JUnit tests (in the StudentTests.java file) that check to ensure that the method is working as it should.  If you come to office hours for help debugging this project, the first thing we are likely to ask you is:  "Show me a JUnit test that demonstrates the problem you are having."

 

Documentation

All code you write must be well documented:

Requirements

As with all programming assignments:

 

Grading

Your grade will be computed as follows (to be split evenly between the two games):