CS 142 - Labs

Lab 8

Add functionality to the program begun in Lab 7 to allow the user to create matches between two gladiators given their indices in the list.
If the match was created successfully, the first gladiator specified should be placed in a queue of gladiators awaiting battle. This list of gladiators awaiting battle must function as a queue. You can think of it as a line of people awaiting their turns.
A match may not be created if either of the gladiators is already awaiting battle.
The number of gladiators waiting for battle must be correct at all times.
See Range Checking below.

Add functionality to allow the program to simulate battles. The gladiator at the front of the queue should battle his selected opponent and should be removed from the queue.
The winner should gain a victory and is now available to battle again.
The loser is kicked out of the Colosseum to live a life of shame.
The names of any gladiators who will battle next should be displayed at all times.
The names of the gladiators in the most recent battle should be displayed along with the results.
See Range Checking below.

Add functionality to allow the the gladiator who is last in the queue (most recently added) to run away, removing him from the queue and canceling the match. Therefore neither gladiator should have an opponent.
After this requirement is completed, your queue is really acting as an input restricted deque. This is not a problem because that is what this requirement is asking you to do. However, we do not want to cause any confusion about the difference between these two abstract data types. Please feel free to ask a TA about the difference between a queue and an input restricted deque if you are unsure about the difference.
See Range Checking below.

Recommended choices for the data structures are a pre-defined ArrayList for the list of gladiators, and a queue written by you for list of gladiators awaiting battle. You don't have to follow these recommendations, but if you don't, that could significantly complicate your work.
Having trouble understanding linked lists? This powerpoint presentation might help.

Making your GUI look nice is not something you should concern yourself with on this lab. As long as it functions as it should, we will accept almost any GUI you design. If you want to make your GUI look pretty, get the lab finished first, and then go back and work on the GUI more if you have time.
Click here to view an example GUI. Areas of interest in the different pictures are circled in blue. Your GUI does not need to look like this. These pictures are here only to give you some ideas.

Your program should not cause exceptions (these are printed on the console) when the user performs an action that is not possible with the number of gladiators who are in the Colosseum or queue. For example, if the user tries to view gladiator number 12, but there are only 7 gladiators in the arena, no exception should be thrown. Your program can notify the user or silently do nothing. Another example is if the user tries to simulate a battle when there is no one in the queue. Again, no exceptions should be thrown.

The battle simulation does not need to be very complex. Each gladiator gets one "attack" and the gladiator with the highest attack wins. The attack is the sum of the gladiator’s skill times a random number between 0 and 9 plus the gladiator’s number of victories times a random number between 0 and 9.
This attack could be calculated using the following code:

skill * rand.nextInt(10) + victories * rand.nextInt(10);

As your projects become more complex, testing becomes an important task. Before you try to pass off with a TA, you should spend some time testing your progam to ensure it works properly.
There are a few things that the TAs will not check for. These things are
- Entering non-numerical values in text fields were numerical values are expected
- Setting a gladiator up to fight himself