A5 Read Me
Jeff Shaffer 
Matt Conlon

Summary of enhancement: 
We decided to enhance the program by making it possible to observe the game, much like how you can watch a texas hold 'em tournament on TV. The idea was to make a spectator that could see everyone's hole cards and probabilities of winning. We also decided to take away any chat functionality for the spectator so that they couldn't give hints to the actual players. 

This was accomplished mainly by creating a viewer on the server's side that watches games. The viewer reuses the Table class from Client. Some pretty significant changes were required in order to make this possible though. See descriptions below.

To make all of this possible, we created three entirely new classes, Viewer, GameObserver, RotatedGameState, and modified several others. The following is a class by class description of the changes made.

Client: 
We removed the dependency of table on game and make it rely instead on gameState. This way, the sever could use table in order to render the GUI server-side. A method was added that calculated the position of the mouse for clicking on any player's cards to render them in the server viewer. These cards aren't displayed on the server side because the gamestate is censored. But in the viewer, if the mouse is right-clicked on any of the cards of any of the players, you can see the cards of that player. The Server package didn't have the myIndex field which is required by table. Instead, we create a decorated game state, Rotated game state, in which myIndex is now set to zero by collections.rotate. The constructor takes the list of players returned by the gameState and rotates them until the client player is at 0th index. The rotated game state utilizes the decorator design pattern. In doing all of this, it was realized that Game.java was not actually necessary anywhere, so we actually just moved RoomWindow's initialization into Client.java and deleted Room.java entirely. Small other changes were also made to make this possible. See classes for more specifics.

Viewer: 
Viewer is to the server as roomWindow is to the client. It displays a GUI screen for each game that the server contains. The GUI shows the table, players, and cards. It receives messages from the server and double checks updates against the game. 

GameObserver:
Watches the server and keeps a map of viewers to games. This is necessary because each server host multiple games, and each game needs its own viewer. Collects updates from the server and sends the updates to the appropriate viewer.

Game: 
The viewer gets hints from the server about changes to the gameState, and double checks with the game to see if these changes actually occurred before updating the viewer. 

Known flaws with the program at it's current state:
- When a client joins a game, only about half of the time is that client solicited whether or not they want to create a new game. This may have to do with whether or not the client changes his name or not before creating a room. This may also be a problem with the original code submitted to us. We're not too sure...
- The probability computer for the viewer for BEFORE THE FLOP only samples about 1/10 of the communities possible because of space limitations. The total  number of possible combinations is about 200,000,000. We only sample about 200,000 of these. After the flop, the algorithm works gloriously. 





