Lab 1: Silver Dollar Game

Aaron Bauer

January 9, 2021

Lab 1: Silver Dollar Game1

Check-in Post

For this and each subsequent lab in this course, you will be expected to make a check-in post on a Moodle forum by a certain date. These posts are intended to facilitate class-wide collaboration on the labs and incentivize you to start the lab early. Making an on-time check-in post will constitute 5% of the lab grade. Specifically, you should contribute at least one of the following:

You can find the lab 0 check-in forum here: https://moodle.carleton.edu/mod/forum/view.php?id=620454

Overview

In this lab, we will write a program to play the Silver Dollar Game described at the end of Bailey Chapter 3 (page 67). In addition to gaining experience writing, compiling, and running programs from scratch, this lab will help us to think about how we can efficiently represent data and break our logic into reusable methods. Careful planning will help tremendously, so take the time to complete the Preparatory Exercises before beginning your work on the lab.

Preparatory Exercises

Preparatory exercises are never need to be submitted and are not graded—their purpose is to ensure that you think about the lab in advance.

Before you begin writing Java code for this lab, I recommend you (1) read the lab description from the textbook (2) watch the lab intro video below, and (3) read through this lab handout and sketch out a design for your Silver Dollar Game program. You should feel free to use the sample Rock, Paper, Scissors Design Document as a guide. It is OK if the design is very simple to start! It is expected you will start with a rough outline and refine it as you work on the lab. You might also refer to this Rock, Paper, Scissors example that implements a simple Rock, Paper, Scissors game using the TwoPlayerGame interface that you will use for this lab.

Suggested Timeline

Step 1: Getting the Code

Download the starter project (lab1-handout.zip). Unzip it and make sure the files are in their own folder. Open the folder in VS Code (File>Open Folder).

Step 2: Implementing CoinStrip

In this lab you will implement the Silver Dollar Game that is found at the end of Bailey Chapter 3 (Note: page 67 of the text, 83 in the PDF) or in this PDF excerpt.

As you think about the design of your game, you should first decide on a representation of the coin strip. Make sure your representation supports all of the operations necessary such as:

When we say “representation,” our real focus is: what data structures will you use? For instance, you might use a variable boolean[10] board; to represent the game board, where each index of the array represents a space on the strip of paper, and true indicates that a coin is present in that space while false indicates that the space is empty. This is a sensible approach, but let’s think about the implications of this design:

There are other interesting design questions that would come up if we were to implement the Silver Dollar Game this way. Now, it is certainly possible to use this design to successfully create all the game’s required functionality, but it probably isn’t the best solution we can come up with. Let’s explore an alternative design.

The Two-Player Game Interface

The starter project provides a Java interface inside the file TwoPlayerGame.java. This interface describes three methods that you must implement in your CoinStrip class. We’ve replicated the contents of TwoPlayerGame.java below:

public interface TwoPlayerGame {

    /**
    * Returns true if the specification of a move describes a legal move
    * given the rules of the game. Note: this does not check whether the
    * move is a *good* move, only whether the move is legal.
    * The move specified is checked against all game rules.
    *
    * A move is described by:
    *   - a resource (e.g., position, gamepiece, pile of matches, etc.)
    *   - a description of the move (e.g., how many matches to remove, how
    *                                many spaces to move, etc.)
    * @param resource describes the game element
    * @param units describes the move
    * @return true if the move is valid
    */
    public boolean isValidMove(int resource, int units);

    /**
    * At the conclusion of this method, the game state is changed to represent
    * the completion of the described move. If the described move is not valid,
    * the behavior of this method is undefined.
    *
    *
    * A move is described by:
    *   - a resource (e.g., position, gamepiece, pile of matches, etc.)
    *   - a description of the move (e.g., how many matches to remove, how
    *                                many spaces to move, etc.).
    *
    * @param resource describes the game element
    * @param units describes the move
    */
    public void makeMove(int resource, int units);

    /**
    * Returns true if the game is over.
    * @return True if the game is over, false otherwise.
    */
    public boolean isGameOver();
}

Since we require that you use this interface, we’ll talk now about a design that we think lends itself to a nice implementation of the Silver Dollar Game.

Instead of representing the spaces on the game board, we can create a data structure that represents the locations of the coins. Let’s use an array of integers, int coins[], where each index corresponds to a single coin, and the value stored at a given index represents the location of that coin on the board.

Now let’s reexamine the questions we posed for the previous design:

This is a very compact representation of the game, and it makes enforcing many rules fairly efficient!

Once you have worked through the details of your representation, write down the set of operations needed to adjust/check/populate your data structure (including operations you may need that are not in the TwoPlayerGame interface). Since we’re using Java, your representation should be hidden inside a class called CoinStrip. Operations are made possible by providing public methods that implement those operations. Think about what parameters your methods will take, what values they return, and what the methods do.

Required Methods

In addition to the TwoPlayerGame.java interface, we also require two methods to help us test your code. These methods are shown below:

/**
 * Returns the number of coins on the CoinStrip game board.
 * @return the number of coints on the CoinStrip game board.
 */
public int getNumCoins() {
    return 0;
}

/**
 * Returns the 0-indexed location of a specific coin. Coins are
 * also zero-indexed. So, if the CoinStrip had 3 coins, the coins
 * would be indexed 0, 1, or 2.
 * @param coinNum the 0-indexed coin number
 * @return the 0-indexed location of the specified coin on the CoinStrip
 */
public int getCoinPosition(int coinNum) {
    return 0;
}

I will rarely impose any particular implementation strategy on you in this course, and I don’t think these methods do so; the getNumCoins() and getCoinPosition(int coinNum) methods are quite general. In other words, the methods themselves ask you to provide specific behaviors (which we will rely upon to test your programs), but the methods do not impose any restrictions on the way you implement those behaviors. Further, we think the behaviors these methods provide is critical for any CoinStrip implementation that we can imagine, so we hope that you use these methods to simplify your code.

Further Details

The main method of your CoinStrip class should create a CoinStrip object and then prompt each of two players to make their moves. A move will be of the form:

<cn> <ns>

where <cn> (coin number) specifies the coin to be moved and <ns> (number of spaces) specifies the number of spaces that coin should be moved.

The program should prompt the user for another input if the move is illegal.

To read input from a terminal window, you can use Java’s Scanner class or StdIn from algs4. Here are links to the documentation for both:

Step 3: Testing

The lab handout includes some test cases to help you check whether your CoinStrip implementation follows the specification described in this writeup. The code for these test cases is located in CoinStripTest.java. Running this file with VS Code will run the tests, each of which will print out a message to the terminal about whether the test passed or failed. These tests check

Passing these tests is part of your lab grade (see Grading). You are free to add test cases to CoinStripTests.java (this file is not turned in).

Some functionality of your game is most easily tested by playing your game in a methodical way. Make sure to play through a whole game, testing both valid and invalid inputs. You can assume the user will enter numerical inputs for the moves—it’s fine if your game crashes on other types of input.

Step 4: Style

As relatively new programmers, we are all developing our understanding of what it means to have good style. This is made difficult by the fact that the definition of good style is both hard to quantify, and hard to agree upon.

To help us all along our lifelong quests to write better code, we have included a tool inside each of our repositories that checks our code against some industry-standard, agreed-upon best practices. This tool is called checkstyle. The starter project is already configured to use checkstyle, and as part of Lab 0 you should have installed the Checkstyle for Java extension.

checkstyle will detect style problems, and underline them in red (errors) and yellow (warnings) in your code. They will also appear in the PROBLEMS tab in VS Code. You can view the PROBLEMS tab by going to View>Problems or pressing Ctrl-Shift-M (Cmd-Shift-M on Mac).

For this lab we will be fairly lenient on style grading, and become more strict later on in the course. You are expected to submit a CoinStrip.java that contains no checkstyle errors. In particular, you must fill out the header comment at the top of CoinStrip.java with your name, email, and a (brief) description of your code. You must also make sure to declare all fields of CoinStrip either public or private (probably private).

It is ok to have checkstyle warnings in your submitted code, though I encourage you to fix them if you have time. Avoiding these warnings will be part of your grade on future labs.

Grading

This lab will be graded out of 30 points as follows:

Requirement Points
Test cases in CoinStripTests.java (3 points each) 15 points
CoinStrip.java produces no checkstyle errors 4 points
User prompted to reenter move when invalid move is entered 2 points
Game ends when a user has won, and this is communicated to the user 2 points
String representation of game board clearly communicates the state of the game 2 points
Check-in post 1.5 points
Pieces move correctly based on user input 1.5 points
CoinStrip.java compiles without warnings 1 points
Correct submission format (a file named CoinStrip.java) 1 point

  1. Adapted from Bill Lenhart and Bill K. Jannen, https://williams-cs.github.io/cs136-f20-www/labs/coinstrip.html↩︎

  2. What strategy might you use to pick a random number of coins such that there is a 50 percent chance of a game with three coins, a 25 percent chance of a game with four coins, a 12.5 percent chance of a game with five coins, and so on? (You are not required to implement this strategy in your Coinstrip game, but after you’ve concretely described the strategy in text, writing the code to implement it is often the easy part)↩︎