Project 3: Monopoly

• Updates
• Overview
• Monopoly Rules
• Details
• Classes
• Game Boards
• Sample Output
• Tips
• Working in Pairs
• What to Turn In

• 7/16: If you're seeing weird formatting in the names of properties that have apostrophes in them, you can downloaded an updated Madison.board file, which should resolve the issue. However, this formatting issue is not related to your implementation.
• 7/14: There was a small bug in MonopolyClasses.jar dealing with auto-play while using the GUI. A new version of the JAR file has been posted. If you already downloaded MonopolyClasses.jar, you'll need to replace it with the new version before you can use auto-play with the GUI.
• 7/14: Reminder: When you create new Java projects, remember to follow the instructions from the Eclipse Tutorial (see step 2). You need to make sure to select the radio button "Use project folder as root for sources and class files."

Start by creating a new Java Project in Eclipse. Download the code that we've provided in this jar file. Add the jar file to your project:

• See the tutorial from Project 0 for a refresher on how to do this, or
• In Eclipse, right click on your Java project, go to Build Path > Configure Build Path, click on the Libraries tab, click on the "Add JARS..." button, and select the MonopolyClasses.jar file from within your current project.

Next, download the Java files you will be updating for this project: monopoly_files.zip. Copy this file to your project directory and unzip it (NOTE: you may need to move the files out of a folder named "monopoly_files" into your project directory). It contains code skeletons for all the classes you will be implementing, Dice.java, a file for the board layout called Madison.board, and images needed for the graphical user interface. You'll see that there are lots of comments already provided (much like Project 2), but don't forget to add your own comments as you implement the methods!

In this project, you will be implementing all the unimplemented methods provided in these files; these are described in the Javadoc and in the next section, Classes. You may not change these method headers in any way. You may also implement your own methods in addition to the provided methods, but they must be declared private. You will also be adding instance variables to some classes. You may not create any new files.

You will need to edit each provided method's body (including main in Monopoly.java) so that it implements the functionality described in the Javadoc and the program. When we grade this project, we will test individual methods to verify that they work as specified. Your program output should match the sample output provided.

The Monopoly class is the main class. This is where the players are created and the game begins.

You will need to write main. Your main method should do the following (see the Javadoc for each of the mentioned classes for information on how to invoke their constructors and other methods):

1. Build an array of Player objects for your game (you may have 2-4 players).
2. Construct a new Game instance using your players and the filename for your game board. See Boards (below) for more information.
3. Construct a new MonopolyUI object (either GUI or Console).
4. Invoke the play method of the Game class using your MonopolyUI.

The Player class represents a player. You will implement lots of methods in this class; you will also likely want to add some instance variables.

The Space class represents a space on the board. You will implement lots of methods in this class; you will also likely want to add some instance variables.

The Property class represents a property on the board. The spaces on the board that are the property type have a Property associated with them. You will implement lots of methods in this class; you will also likely want to add some instance variables.

Classes That We Have Provided

The Game class represents a game setup that is being played. This class handles player turns and determines a final winner.

The Board class implements the game board used to play the game. A board may be initialized with default space names or by passing in the name of a file that contains a board description. You will be using the latter; don't worry about reading a file--we've implemented that part for you! You'll just need to pass in the name of the file.

The MonopolyUI class is an abstract class that represents a user interface for this program. You don't need to worry about what an abstract class means; we'll learn about these later. In this project, you'll be using either the GUI or Console class, defined next.

The GUI class is a graphical user interface for this program. The interface creates a new window with an image of the board, displays messages and prompts to the user, and gets input from the user.

The Console class is a text-based user interface for this program. This interface is very similar to what we've used in other projects and is entirely text-based. If you work in Eclipse, this interface runs in the console. The messages and prompts to the user are the same as the GUI interface, and this interface gets text input from the user and does input validation, etc. as necessary.

The Dice class is the same as for Project 2. As before, you should not modify the contents of this file (except during your own testing, when you may want to change the SEED value--sample outputs specify the SEED value used). We will use the original version of this file during grading.

        String filename = "Madison.board";
        

Game myGame = new Game(...);
...
myGame.enableAutoPlay();
myGame.play(...);

You can see sample output from running Monopoly (with the Console user interface) in sample1.txt and sample2.txt. Each sample output specifies the value of SEED in Dice.java. Change this value, run the game in auto-play, and compare your output with the sample.

This summary of pair principle principles was summarized by Finn Kuusisto from a paper by Williams and Kessler:

• Pair programming involves two people working together at one computer, continuously collaborating on design, coding, and testing. One person types; the other either provides directions ("Now we need to write a new method that does ..., Now we need a loop to do ...") or constantly reviews what the typer is doing, and provides comments.
• Pair programming has proved successful both in classes and in industry. Programmers usually report having more confidence in their solutions and enjoying programming more when working in pairs.
• It is important to switch roles often (slide the keyboard back and forth). Because pair programming can be quite intense, it is also a good idea to take breaks (to check e-mail, go for a walk, have a snack).
• It is important to provide honest but friendly feedback. To be effective, there needs to be some healthy disagreement and debate, but pairs also need to be respectful of each other, and try to avoid becoming defensive when receiving criticism.
• Inevitably, programmers do some independent thinking/working. For best results, that work should be reviewed by both partners (and perhaps revised) when they start working together again.
• To be successful, pair programmers must realize that the benefits of working together outweigh their usual preference for working alone, they must confidently share their work, accepting instruction and suggestions for improvement in order to improve their own skills and the code they are writing, and they must accept ownership of their partner's work and thus be willing to constructively express criticism and suggest improvements.

1. Upload the following to the Project 3 Dropbox folder on Learn@UW:
   • Monopoly.java
   • Player.java
   • Property.java
   • Space.java
2. Do not upload:
   1. Game.java
   2. Board.java
   3. Console.java
   4. Dice.java
   5. GUI.java
   6. MonopolyUI.java
3. If you worked with a partner: only one partner should submit .java files. Both partners must submit a README file that contains the full names of both partners.