Project 1: A More Object-Oriented Mancala

Introduction

We've spent some time thinking about the mancala game... I gave you a largely-complete chunk of code to play a simple version of the game and asked you to fill in the actual game play. Hopefully, you spent some time thinking about that on your own time, as I strongly suggested. We also discussed the limitations of the approach in my code—in particular, it's not very object-oriented, which created some obvious duplications in code (e.g. two arrays of pits). In this project, I'm providing 98% of the game logic and asking you to implement a better design. This is probably a new kind of assignment for many of you: I'm not asking you to write the right kind of loops and conditionals, but I'm asking you to think about the design and structure of your code.

Primary Task

Here is updated code for mancala: PlayMancala.java; MancalaBoard.java. PlayMancala is essentially unchanged from the version I shared in Exercise 1, but MancalaBoard now has fairly complete game-play logic—though you'll notice that the playMove() method only deals with a move made by player 1. Review the code and the comments to be sure you understand what this class does and doesn't do.

Your primary task is to convert this code to use a Player class, one that represents the data and actions of a single player (obviously, the game will then need two Player objects). PlayMancala does not need to change, but MancalaBoard will be substantially reorganized, and some of the "logic" currently in the MancalaBoard class will move into the new Player class.

Style and Documentation

Part of your task is to produce a fully documented, stylistically acceptable project. When you are writing a Java program (or a program in most any language), your main audience is not the computer but other human beings (actually, your primary audience is often yourself-next-week). Your code must be easy for other programmers to read, digest, and comprehend. This is why variable names, whitespace, and other "fussy" things are so important. Indeed, most software companies have their own "style guides" so that everyone's code follows the same conventions, so everyone knows what they're looking at. For this class, I've made a simplified version of Google's Java style guidelines. There are a few items in the guidelines that don't apply to this project (like enum, exceptions, and a few other small things). But everything through section 5 should be pretty clear. Make sure you adhere to this guide!

In particular, notice that Section 7 of the Simplified Style Guide discusses "Javadoc," which is the special commenting "language" used to document methods and classes in Java. The code I've provided you should be an adequate example—be sure you put an @author tag at the top of each of your source files.

Turning in and Grading

To turn in your program, send me a zipfile containing PlayMancala.java, MancalaBoard.java, Player.java, and the .java files for any other classes you write. The zipfile must be named <Lastname><Firstname>Project1.zip (that is, if I were submitting this, I would send DexterScottProject1.zip. Do not send a file that has been compressed with gzip, RAR, or any other archive/compression format. If you prefer, you may store your zipfile with a cloud service and send me a link. Submissions that don't meet these requirements will not be graded.

Your grade will be based on the following elements:

  20%  Compiles and runs
  10%  Runs correctly (game plays properly, etc)
  30%  Appropriate class design.
  20%  Good/readable style (follows guidelines)
  20%  Appropriate comments

Note: This grading scheme is based on the assumption that you do a substantial amount of the work of the project. If you turn in something that is essentially what I gave you with a tiny Player class, you will receive a very low score. But if you do do the work, note that 60% of this project is pretty easy to get (compiles and runs, good style, appropriate comments). The remaining 40% is the "real challenge" of this project.

Your email to me must be datestamped by 11:59pm, Tuesday, March 12. (This gives you a week afterward to focus on studying for the midterm.) Remember that I don't generally accept late assignments. But I'm happy to receive your work well in advance of the deadline.

Finally, remember that projects are individual work. I strongly discourage you from discussing your work on this, or sharing your code, with teammates or other classmates. In this class, teams are there to support your learning; individual work is where you show me what you've learned.

"Appropriate" class design?