CS 101 (Fall 2000)
Lab 3: Object messages -- WASHOPOLY

Authors: Nate Bayless and Sergey Klibanov
Lab Assigned Design Due
(In class)

1 PM
(In Lab)
(In Lab)
Lab Due
(In class)
1 PM
25 Sep None 27-28 Sep 4-5 Oct 6 Oct


Often to correctly mirror real life, an object-oriented program has to have many interacting objects. This interaction is usually expressed by one object calling another object's method, which could in turn call a third method. This messaging (consider a method call to be a message to execute a particular method with particular arguments) scheme is very representative of real-world interaction, and is a fundamental concept in object-oriented programming.


By the end of this lab, you should Before starting:
[[[ Download PC zip ]]]
Zip includes: You are encouraged to reuse your Emote solution from Lab 2. However, if you want to use the class solution, then unzip the following directly into your Lab3 directory.
[[[ Download Emote .class files if you need them]]]

  1. Problem Statement

    Game.com, the renowned internet game producer is at a remarkable high! The Brain-Storm Developers have been assigned to create a board game for students at Washington University. They came up with WASHOPOLY. However, they need our help to put the game into a language runnable on the computer, and JAVA is the perfect tool.

    Your job is to help create the code for Game, Inc.'s WASHOPOLY by articulating and implementing a system of objects that models real-life counterparts (recall that the API of such objects is the interface, which hides internal implementation). The Game, Inc. head honchos have already decided on the API, and it's set in stone. So, you'll have to honor their wishes in your implementation. Their design involves the following:

    More on the play of the game

    Before we start you in on the design, you need to understand how the game is played. This game allows the user to guess whether a Player in the game is an Athlete, a Brain, or a Remy (Renaissance person). That is, there are three kinds of Players:

    The happiness of each player is a weighted function of Each event the Player attends either positively or negatively effects the Player's GPA and SI, consequently affecting his or her happiness. The game proceeds by rolling a 3-sided die and moving around the board. It takes four full rounds of the board to reach Graduation. The user of the game does not know which kind of Player is moving around the board. The object of the game is to guess which Player is present, as soon as possible. More points are received the quicker the correct guess is made. If a wrong guess is made, points are lost and the game is reset! The user will have the opportunity to guess after each roll.

  2. Design

    Major caveat #1: One of the goals of this lab is to get you thinking of how to write internal representations (i.e. choose instance variables). So, you will find the instance variables missing in most of the files for this lab. Feel free to choose your own instance variables; part of your grade for the lab will be how well you choose them and how well they work. Having said that, the choice of instance variables should be fairly straightforward based on our design - if it seems like the right answer, it probably is!

    Major caveat #2: Another goal of this lab is to get you testing your classes thoroughly. We require all of your classes to have a method public String toString( ) that Java uses to convert your object to a String. You are also required to test your classes thoroughly in Startup.java by printing some tests to the Terminal, some of which involve the use of your toString. The test procedures should be located in the indicated spots in Startup.java. Some examples are provided; if you have any questions, please ask.

    Now, on to the design!

    1. First, the Players are the main objects of the game. They attend events and traverse the board by rolling a die. Each Player is represented by an Emote-face (created in Lab2) that smiles, frowns, etc. to show various levels of happiness.
      Each Player has
      • a GPA level
      • a SI level
      • a Happiness level (which is a function of the above)
      • a Face (which is implemented with an Emote from Lab 2)
      • a StatDisplay
      Each kind of Player calculates its HAPPINESS differently:
      • Athlete --- 25% on GPA and 75% on SI
      • Brain --- 75% on GPA and 25% on SI
      • Remy --- 50% on GPA and 50% on SI
      To display the happiness of a Player, a smile/frown is drawn on the face image for that Player. From Lab 2, the arc for the smile is based from 0 - 100. Since our GPA, SI, and Happiness will all be capped from 0 - 4.0, we must remember to SCALE happiness to fit the requirement for the face!
      The StatDisplay contains a StatBar, which is a horizontal bar that expands and shrinks with the Happiness. The StatDisplay will, therefore, have a visual representation of Happiness with the StatBar, as well as a numerical display for the value (0 - 4.0) of Happiness.
    2. Next, we need to look at the squares that make up the board. 12 squares make up the board.
      They are as follows:
      • Year Start/Graduation
      • Food --- Everyone needs to eat sometime!!
      • Classes --- Those fun-filled learning experiences
      • Friend --- Visit, talk to, study with, etc.
      • Extra-Curricular --- You may choose a specific one if desired
      • Parents Visit --- What more can one say?
      • Study --- Necessary at some point in time
      • Party --- !!!
      • Sport --- Competition at its finest
      • Sleep --- The goal of every college student
      • Finals --- The last test of knowledge
      The above should be instances of a main Square Class!

      All the squares have a set positive or negative effect on GPA and SI. The effect of each square is defined in GameBoard when the squares are constructed.
      Square specifics:

      • Year Start/Graduation which will be the bottom right square on the board. This is where play is started and finished. Effects of this square:
        1. The player must START play on this square.
        2. Each player MUST land on this square EACH round before they can continue with the next one!!!
        3. With each landing on this square, the player's year is incremented.
        4. With each landing on this square, the player's GPA and SI are incremented by 1.
        5. If the player reaches Graduation without guessing, no points are gained or lost and play is reset.
      • CATASTROPHE!! This event will be placed in the top left square. It will have the set effect of lowering the Player's GPA and SI by 1.
    3. The progression of the Player is determined by a die that is rolled. It is an imaginary (can you make one?) 3-sided die that will randomly choose a value. The graphic will be an icon called ROLL!
    4. The GameBoard is what the game is played on, and is therefore a very important component of the design. The GameBoard will have squares around a square board (in the same format as Monopoly).
      • Each time a player moves, it must update the graphical displays on the board (StatDisplay, Face of player).
      • A move is carried out when the player clicks on the ROLL! icon. The die icon will be placed in the upper left corner inside the grid of squares.
      • If the user guesses correctly as to which Player they have, a score is given and play is reset with a new, randomly chosen Player. If an incorrect guess is made, the user's score is lowered and play is also reset.


    The JavaDoc for this lab shows a complete and detailed API.

    The following classes you will have to implement yourself. Look at the API to see in greater detail what properties these classes (and all other classes in the game) have.
  3. Implementation

    You must implement the classes described in the design. For this lab, you are constrained to following this design. Specific implementation steps are given at the end of this document; the files you download repeat those suggestions.

What to turn in:

  1. Complete a code cover sheet.
  2. Provide a printout of any files you have modified (see approach below).
  3. Provide a transcript from Startup's textual tests on your classes. Recall that this file is produced automatically by the Transcript and can be found in the file transcript.txt in the same folder as your Lab 3 files.

Suggested order of implementation:

In general, it is always a good idea to design a program top-down but implement it from the bottom up. A good mentality for design is to think "I can worry about the details later" and assume you can implement anything given enough time. A good mentality for actually implementing, though, is to implement the smaller, less-significant classes first, and then build on top of them akin to a pyramid. We took care of the design for you, it now your job to build the program.
With that in mind, start from the simplest classes and move up. The suggested order is:
  1. StatBar
  2. StatDisplay
  3. Face
  4. Square
  5. Player
  6. GameBoard, which uses all of the above, has already been implemented for you so that you do not have to deal with managing buttons and mouse events.
One extra hint: When you are writing your code, be sure to use very meaningful variable names to make your job as a programmer and the TA's job as a grader easier. For example, if the player has a Happiness level that is of type double, name it double happiness and not double mydouble or double x.

Good luck!

Last modified 11:54:31 CDT 26 September 2000 by Ron K. Cytron