CSCI142: Computer Science 2
Lab 3 - Predator


Dutch and his elite squad of soldiers are holed up in a bunker just outside an enemy base in the Central American jungle. Their mission from the CIA is to rescue as many officials being held hostage in the base. The base is heavily armed and guarded by an insurgent guerilla force. And unbeknownst to everyone, an alien spacecraft has crash landed in the very same jungle. Alive and on land, a sinister creature known only as the "Predator" begins its merciless hunt on our unsuspecting victims. Who, if anyone, will "get to the choppa!"?

Activity 1: Stacks and Queues


Before implementing the predator simulation, you will write a node based implementation for a generic stack and queue.


The javadoc documenation for all the classes in the first activity can be found by selecting the rit.stu.act1 package on the main documentation page.



With this lab, and all future ones, you will need to use a Version Control System (VCS) to maintain your code VCSs are used throughout all computing fields to allow multiple people to collaborate on shared software and to prevent the loss off work if something is accidentally deleted. For this course we will be Using GitHub as our VCS. Please see the installation guide here for instructions on setting it up.

Note: You must use your RIT username for your GitHub account. If you already have one setup that doesn't use that name, you will need to create a new account for use with this course.

IntelliJ/GitHub Setup

  1. Open IntelliJ and go to the splash screen (close your project if it is open). Select "Configure" -> "Settings" -> "Version Control" -> "GitHub". Select "Add account" and enter your GitHub username for "login", and your GitHub password for "password". And select the "Login" button. If all goes well you will be logged in and you can select "OK" to go back to the splash screen. You only need to do this one time per IntelliJ installation.
  2. Copy the GitHub classroom link for your section into a browser. Your repository will be made and you will receive a message that you are ready to go. Before leaving the browser copy the link to your assignment.
  3. From the IntelliJ splash screen go to "Checkout from Version Control" -> "Git". Copy the link into "URL", and select a proper location for your project in your machine for "Directory". Press the "Clone" button when finished. Select "Yes" when asked to open the project.
  4. You should now see the project with the starter code. If the "src" directory is not blue, right click on it and select "Mark Directory as" -> "Sources Root" (near the bottom).
  5. We are now going to walk you through the steps in order to do your first successful commit and push to your GitHub repo. First, make sure your project is configured for Java 11. Select "File" -> "Project Structure" and select your Java 11 SDK and make sure the language level is 11. If "Project compiler output" section is blank you should navigate to your project directory and add the sub-directory "out" to the end of the path. This is where IntelliJ stores your bytecode files when compiling and running.
  6. Go to the "src/rit/stu/act1" folder. Click on the "StackNode" class. If a window comes up and asks to add some ".xml" files from the ".idea" directory, select the "Add" button. Modify the source code and add your name to the second "@author" tag. Take a moment to locate the file in the project. It should be blue. IntelliJ uses this to indicate a file already under version control has been modified. If the file is black, it is also under version control and has not been modified.
  7. We are now going to add a new class to the project. Right click on the "src/rit/stu/act2/" directory, and create a new class, "Bunker". Notice that the file is red. This means a file is not under version control. Click the "Add" button so the file is added to version control. The file should change to green. This means it is a new file under version control.
  8. We are now ready to do our first commit and push. When you commit the files under source control for your project, it is saving them on your local machine. In order to have your changes go to your GitHub repository, you need to push it. Right click on your project directory and select "Git" -> "Commit Directory...". In the commit window you will see the files that are about to be committed. Add a commit message "my first commit and push to GitHub". As you develop you should frequently do this. Part of your grade for each lab and project is based on having a reasonable number of commits, e.g. at least 4 or 5. Be careful, DO NOT select the "Commit" button. That will not push to GitHub. Press down on that button and select "Commit and Push". If a code analysis window comes up, you can ignore it and select "Commit and Push". If it continues to bother you unselect the "Perform code analysis" checkbox the next time you commit and push. If a Git configure window comes up, put your real name and your RIT email address in the window and select "OK". A push window should come up and select the "Push" button.
  9. If everything worked you have committed and pushed your changes, and all the source code should be black. Check with your instructor or SLI to make sure they can see your commit. You are now ready to work on the lab.

Activity 1: Node Based Stack/Queue

A starter project has been provided for you. The GitHub link for it is specific to your section and will be provided by your instructor. Use it along with the GitHub installation guide to clone the starting repository. Once you have the initial project you can proceed with setting up your file structure. Your source directory should be structured as follows:

If you see syntax errors, make sure you are using Java 11 syntax (File -> Project Structure and in the Project window make sure the project language level is set to 11).

First, make sure you can run the supplied main program, StackTester, in the rit.stu.act1 package. Before running, make sure you have your project configured for Java 11 (File -> Project Structure -> The project SDK is set to your JDK). Right click in the source code and run it. You should get a usage message. Go to the run configuration (directly left of the green run button), and have the stack tester used the supplied list based implementation of a stack, StackList, in the rit.cs package. This is done by adding a single program argument, list.

If everything is ok, the program should run and everything should display as OK in the output window, except for a few assertion tests that you will fix/enable in the following section.

Node Based Stack

First, you will implement the node based stack, StackNode, in the rit.stu package. Here is the relevant documentation:

A skeleton StackNode class is provided for you. This class will implement the Stack interface in the rit.cs package, as well as use the Node class, so make sure to import both of them:

        import rit.cs.Stack;
        import rit.cs.Node;

For reference, here is the node and node based stack in Python from CS1. Instead of using exceptions, you should instead use assertions. Take a look at the first line of source code in the pop method of the StackList class in the rit.cs package:

       assert !empty();
In Java, assert is a keyword. If the expression that follows evaluates to true, nothing happens and the program continues to the next line of code. However, if the expression is false, program execution will halt on this line of code and it will display an error message.

At this point you should now implement your StackNode and then use the run configuration below for StackTester to test it

By default, assertion statements are ignored when run. In order to have them work properly, you must enable them by setting the VM options to contain the flag -ea (enable assertions). You should do this for your node based stack. Also remember to change the program arguments to use your node based stack to node, so that the tester uses your node based stack, versus the provided list based stack.

You must use assertions to get full credit for this assignment. Notice how this is documented in the Stack interface using a custom tag in the comments for the methods that need them:

        @rit.pre: stack must not be empty
        @throws AssertionError if stack empty
The pre stands for precondition, which is something that must be true before the method runs (for example, to pop the stack, the stack must not be empty). If an assertion is false and assertions are enabled, it will cause an AssertionError to be thrown.


You can verify whether your node based stack is working correctly with the tester by comparing your output with the solution output.

Node Based Queue

Similar to the last activity, you will now implement a node based queue, QueueNode in the rit.stu package. Here is the relevant documentation:

Similar to the stack, a skeleton QueueNode class is provided in the rit.stu.act1 package.

For reference, here is the node based queue in Python from CS1. Again, you should use assertions where the Queue interface indicates there are preconditions.

At this point you should now implement your QueueNode and then use the run configuration for QueueTester that you set up below to test it

The main program to test your node based queue is QueueTester in the rit.stu package. Just like with the stack tester you should add the -ea flag to VM Options and node to Program arguments.


You can verify whether your node based queue is working correctly with the tester by comparing your output with the solution output.

Activity 2: Get To Da Choppa!


Take some time to familiarize yourself with the design of this battle simulation. Make sure you understand the roles and responsibilities of each class and how they interact with each other.


The java documentation of the classes involved in this activity can be found here. Make note that while the documentation references a sol sub-package that you will be doing things in your stu sub-package only.


You will be implementing this activity in rit.stu.act2 package. Follow the same process you did for lab 2. First, you should create stubs for each of the classes and their methods. Your final project structure should look like the following:

It is suggested you implement and test the classes you need to write for this in the following order. Use the javadocs for each class for details on how they need to be implemented.


All of the "actors" in the simulation e.g. Hostage, Guerilla, Predator and Soldier, implement the Player interface. These are used to produce the victory and defeat messages that are called out by the players.


There is only one Predator in the game. The predator has different chances to defeat a soldier and a hostage that escapes from the enemy base.

Use the Constant Value page to get the values for all constants in the simulation.


The Soldier's are attemping to rescuse the hostages from the enemy base and escort them to the chopper. In honor of lead soldier Dutch, who is Austrian, all the sodliers speak German. To enter the "umlaut" character you can cut and paste it from the javadoc, or you can use the unicode string "\u00FC" in your code.

Also note that whenever you encounter a message that contains curly braces, e.g. {soldier}, it means you should invoke the Soldier's toString() method.


The Guerilla's guard the enemy base and engage the soldiers who enter and try to rescuse a hostage. All the hostages speak Spanish.


The Hostage's are held up in the enemy base awaiting rescue from a soldier who defeats a guerilla. They all speak English.


The Bunker is where the soldiers are stationed at. The bunker can be viewed as a queue (first soldier in is first soldier out). If your node based queue from activity 1 passes all tests you may use it, otherwise use the list based queue.


The soldiers enter the EnemyBase from their bunker. The guerillas are waiting in a guard line which is another queue. The hostages are stored in a cave which is a stack. Again, you may use the node based stack from activity 1, if it passes all tests, otherwise use the list based stack.

When the guerilla at the front of the line faces the soldier, they use the Battlefield.nextInt method to roll the dice and determine a victor. If the soldier is victorious they exit the base with the hostage at the head of the cave. Otherwise, the guerilla re-enters the back of the guard line.


The Chopper is how both the hostages and soldiers escape to safety. It has a limited capacity. Each time the chopper is full, it has to fly away to rescuse the current passengers and then return back to take on more passengers.

The storage of passengers in the chopper is a stack. Again use your node based one if it works correctly, otherwise use the list based stack.


Battlefield is the main class. We are giving you the main method and the dice rolling method. The program expects three integers on the command line, e.g.:

    $ java Battlefield #_hostages #_soldiers #_guerillas

This class has the main simulation routine. It is responsible for creating all the other required structures in the constructor.

Note that in this simulation that while the predator may be temporarily defeated by a soldier or hostage, it can never be truly defeated. The predator is around and ready to battle every soldier and hostage that comes out of the enemy base.

If there are no more hostages left in the enemy base, any soldiers left in the bunker may safely board the chopper in order from the bunker.

Sample Runs

Here are some sample outputs for runs of the main simulation class, Battlefield. Use these to verify the correct operation of your program.


The grade breakdown for this lab is as follows:


Navigate in your file browser to your project directory, and then into the src and rit sub-directories. You should zip up the stu folder, which contains all of your implementation. Name the zip file, and submit it to the dropbox on MyCourses by the due date.