Overview:
Play a complete game of three trios with two players, and code it with room for later modification.
Playing this game should consist of a place phase, battle phase, and combo phase.
The entirety of the game should be displayed using a text based view.

Quick start:
Run the main method entering:
"person person" as the command line arguments

or "corner person" or "flip person" to view strategies able to used by our implementation


Key Components:
Model
-Based on a text file input (which is parsed) allocate the specifications for the
grid and player (size, cards)
-Instantiates the grid and player hands
-Play cards from hand to grid to locations as specified by the input from controller
-Verify game states post move (has the game started, do any cards battle,
is the game over, who won the game)
View
-A Simple text based view that displays the grid, the players hands,
as well as what color player the card belongs to as denoted by "R" or "B"
based on the contents as given by the model (grid, hand)
Controller
-A gui based controller that displays a three trios board
-Events to the board are handled by this controller and update the view and model as necessary
- Displays popup messages as necessary to guide player (does not stop game or write to console)
-Displays a game over pop up once the game is over

Key Sub-Components:
Grid
- is arena where three trios is played
Players (playerOne, playerTwo)
- the players control a hand of cards
- they play these cards onto the grid
- these cards battle adjacent cards of the opposite player
- if they win the battled card now belongs to the player that won
- causing a combo effect if multiple cards lose to their adjacent competitor
Grid Cells (must be an odd number)
- Hole Cell is a cell that cannot contain a card
- Card Cell is a cell that can contain a card and belong to a player
- # of playable cells is the count of Card Cells in the Grid without a card
Player Cards
- Have a color associated with the given player
- Can exist on the grid or in the players hand
- # is equal to the (# Card Cells on the grid + 1) / 2 per player

Source Organization:
MODEL:
  Card (Interface)
    - PlayingCard (Class)
    - CardValue (Enumeration)

  Cell (Interface) <C extends Card>
    - CardCell (Class) <PlayingCard>
    - HoleCell (Class) <PlayingCard>

  Player (Interface) <C extends Card>
     - TTPlayer (Class) <PlayingCard>

  ThreeTriosModel (Interface) <C extends Card>
    - TTModel (Class) <PlayingCard>

  - PlayerColor (Enumeration)
  - CardinalDirection (Enumeration)

VIEW:
  ThreeTriosView (Interface) <C extends Card>
    - TTTextBasedView (Class) <PlayingCard>

Changes for part 2
- Added numFlipped() to count the number of cards flipped with a turn.
- Changed the signatures of playGame and playCard to be in line with
  what was discussed in class.
- made FileHandler as a helper class to extract relevant data from files.
- Added an invariant as that was left out.
- Added GUI view, built with JFrame extensions and JPanels for cards/cells

Changes for part 3
- Added ThreeTriosController, which mediates between the view and the model.
- Model status acts as an observer for new turn events and updates via the controller as necessary
- Updated strategies and view orientation to actually display correct behaviors (strategies work as
  intended, view is always proportioned correctly)
- Multiple views are displayed simultaneously and update synchronously

Changes for part 4
-Fixed typing issues across controller, model, and view classes
    (was using class type rather than interface)
-Added getScore method to model implemented in all relevant classes
-Swapped around private TTController helper method signatures for clarity
-Bug fix in TTBoardPanel mouseClick features.handleClickEvent() takes in y, x instead of x, y
as handleClick event has the signature (row, col)

Provider Changes:
-Due to deadline and lack of responses from provider we changed the following ourselves:
    -Removed unused imports in provider/model/Card
    -Swapped declarations of Point east & Point west in provider/view/DrawHand in renderCard()

Functional Features of Provider View Implementation:
-Highlight card
    - Only given player's hand
    - Deselect card by selecting again or selecting new card
-Hovering over unselected cards in hand applies a white highlight
-No card selected error message displays properly
-Glass pane blocker (while it is not the player's turn)
-Empty card cell needed error message displays properly
-Only placeable on grid
-Battle phase works (and updates both views)
-Combo phase works (and updates both views)
-Synchronous for human players
-When the game is over, moves are not registered

Provider Adapters:
-AttackValueAdapter
    -A class housing static conversion methods that allow for respective
    AttackValue <-> CardValue enumeration conversions
-CardAdapter
    - Two way adapter to mask as both our Card and the provider's Card for the model.
    - Two way because some of their methods took in the provider's Card type and we needed to
      convert from that, and vice versa is also true.
-CoachColorAdapter
    -A class housing two static conversion methods that allow for respective
       CoachColor <-> PlayerColor enumeration conversions
-GridAdapter
    - Two way adapter that switches between a list of cells and the provider's Grid class.
    - Two way because their start game takes in a Grid object so we needed a way to represent that
      and also be able to convert that to ours and initialize their grid in the startGame method,
      then using that to initialize our grid.
-GridCellReadOnlyAdapter
    -Object Adapter used to convert from Cell to the provider's GridCellReadOnly
    used in their Grid's GridCellReadOnly[][] readOnly2dArray();
-ModelAdapter
    - Two way adapter that works for both views, since our view and the provider's view are
      hooked up to the same model.
-GameViewAdapter
    -Class Adapter that implements our view ThreeTriosFrame and extends the interactive provider
    view GUIPlayerInteractive so that it can be directly utilized with our controller and updated
    directly by the player.
    -Class adapter because the GameView interface lacked information regarding all features of the
    view necessary for a complete synchronous implementation.

No necessary features were UNABLE to be implemented from the provider's code using adapters.