pokemon.java + pokemontester.java

You are a programmer for Nintendo and you come into the office Monday morning and the following email memo is in your inbox, from an Executive VP: Hey! I was playing racquetball at the club this morning and my raquetball partner said that his cousin's sister-in-law's nanny told him that Java is "super awesome" and I think that rewriting the underlying code for our next Pokemon game will allow us to progressively administrate multimedia based human capital(1)!!!!! Never mind that the language it's currently written in is just fine - rewrite it. It's going to be SUPER AWESOME!!!" Cheers, Your Boss' Boss' Boss You know the following: A) Play happens in turns, so you are going to need to write a Game class B) Each game has 2 Pokemon, and each turn they can either attack or defend, resulting in 3 possible scenarios: Attack vs. Attack No one is defending here, so each attacking Pokemon has as percent chance of landing the attack that is equal to it's speed Attack vs. Defend In the event of attack vs. defend: A) 50% of the time, the defending Pokemon is not hurt and the attacking Pokemon is not hurt B) 25% of the time, the attacking Pokemon lands its hit on the defending Pokemon at 25% of power c) 25% of the time, the attacking Pokemon hurts itself at 25% of power Defend vs. Defend Nothing happens C) We'll need a mechanism for human interaction with the player's Pokemon (assume 2 human players) D) We'll need a mechanism for output to the screen and input from the keyboard. After each turn, the TUI should inform the players of exactly what happened during that turn (best accomplished by having the Pokemon classes and the Game class pass strings to the TUI, which then prints them to the screen) E) Each Pokemon's initial stats should be set randomly in the constructor to be within the range specified by the stubbed implementation below. The Pokemon with the higher speed stat attacks first 80% of the time, and the Pokemon with the lower speed stat attacks first 20% of the time. F) Remember that ALL input/output should happen in the TUI!!! You'll be graded on your code, your testing, the presence and validity of your documentation (remember preconditions, postconditions, and invariants?), and whether the program compiles and works properly. Pay careful attention to what is your user interface and what is your "model' - there should be absolutely no input or output in your model! ******************************************************************************************************************************* public class Pokemon { private int health; private int strength; private int speed; public Pokemon(int health, int strength, int speed){ assert health = 1; assert health <= 300; assert strength = 1; assert strength <= 300; assert speed = 1; xxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx