In PA03 you created a BattleSalvo game where a human player could compete against a CPU. Because you followed SOLID principles and the MVC design pattern, it should be straightforward to substitute modules of your program, such as the players. 

To make sure you have a strong foundation to build from (and in lieu of being able to instantly grade PA03), here is a rough structure for ***one of many*** possible PA03 implementations:

![This is an abbreviated UML class diagram. Focus on how the classes and interfaces relate to each other, not on each individual method necessary.
~~~
`renderOutput()` is acting as shorthand for the many different print methods you would want in the `ViewOutput` interface.](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/4df4b7a7-df0d-475c-b8c0-20cd5c2047e9/PA03_UML.drawio_(3).png)

This is an abbreviated UML class diagram. Focus on how the classes and interfaces relate to each other, not on each individual method necessary.
~~~
`renderOutput()` is acting as shorthand for the many different print methods you would want in the `ViewOutput` interface.

## ✅ **Key Takeaways**

- ******S:****** Separating into Model, View, and Controller responsibilities ensures modules can be easily substituted
- ****O:**** Interfaces uses generalized naming so as to not limit the scope of extension. See `renderOutput()` in `ViewOutput`
- **L:** `ManualPlayer` and `AiPlayer` do not contain methods not in their abstract class and interface. Instead, take advantage of the constructor to introduce getters through a new class (the `BoardImpl`).
- **I**: Take advantage of Interface Segregation to give `Board` and View to other classes without breaking MVC responsibilities. MVC is a tool which helps us ensure we’re following Single-responsibility, not a hard-and-fast rule. 
*This technique was not required for PA03; do not worry if you did not make use of it.*
- **D:** Instantiate classes in the `Driver` and then inject them to many other classes so that multiple classes can reference the same data models (”sources of truth”).
    - Example `main()` method
        
        ```java
        public static void main(string[] args) {
        	Board userBoard = new Board();
        	Board aiBoard = new Board();
        
        	Player user = new Player(userBoard);
        	Player ai = new Player(aiBoard);
        
        	ViewOutput view = new ConsoleView(userBoard, aiBoard);
        
        	Controller controller = new LocalController(
        		user, ai, userBoard, aiBoard, view)
        }
        ```
        

## 🚧 Important Note

**This is a diagram of one of many ideal solutions. If your implementation does not follow this structure, you should still be able to implement PA04.** If the route towards implementing PA04 is incredibly unclear, it may be worth touching up your PA03 foundation before moving forward and extending it to implement PA04.

*Please talk to a TA if you feel you need to make major changes and are unsure how to proceed.*

# 🔀 Remote Interactions Protocol

To support playing multiplayer BattleSalvo, your implementation will need to match the process format the server expects of all BattleSalvo clients. These formats are called **********protocols**********.

Below are some diagrams which show the protocols your program must support to interact with our server. Note how these are similar to the logic in your PA03 controller.

## 🔌 Connecting to Server Protocol

This is the connection protocol:

1. Each client will connect to the server using a `Socket`. (Review Lab 06 for a Socket refresher)
    1. `Socket` will take care of following Transmission Control Protocol (TCP) — this is how the connection is actually made.
    2. If you want to learn more, [here’s a Khan Academy article](https://www.khanacademy.org/computing/computers-and-internet/xcae6f4a7ff015e7d:the-internet/xcae6f4a7ff015e7d:transporting-packets/a/transmission-control-protocol--tcp) which provides some explanation. Networks ([CS 3700](https://catalog.northeastern.edu/search/?P=CS%203700)) is also a class your should look into taking if you find this interesting.
2. The server will request the client to join a game
3. The client will respond with the player name and the preferred game type (more on this later)
4. The server will add the player to the join queue and start a game when available

Below is a UML [Sequence Diagram](https://www.lucidchart.com/pages/uml-sequence-diagram) on how the connection protocol works for each client:

```
Server            Client_1        Client_2      ...
  |     tcp          |                |
  |<-----------------+                |
  |                  |                |
  |     join()       |                |
  +----------------->+                |
  |                  |                |
  |  PlayerInfo      |                |
  |<-----------------+                |
  |                  |                |
  | add to Queue     |                |
  +---->+            |                |
  |     |            |                |
  |     |            |      tcp       |
  |<----------------------------------+
  |     |            |                |
  ...

```

## ♻️ Game Loop Protocol

The game loop is comprised of three stages (we also provide UML Sequence Diagrams for each):

1. **The setup phase**
    
    Each player is given the dimensions of the grid and will return a Fleet of Ships with each Ship’s coordinates on the grid.
    
    ```
    Server              ProxyPlayer     \\\\      ProxyController     Player
      |                     |           \\\\           |                |
      | setup(w, h, FS)     |           \\\\           |                |
      +-------------------->|===========\\\\==========>|--------------->|
      |                     |           \\\\           |     Fleet      |
      |<--------------------|<==========\\\\===========|<---------------+
      |                     |           \\\\           |                |
      ...
    
    ```
    
2. **The play phase**
    
    Each client will receive the following three messages at roughly the same time for each round. Note how similar this is to your own controller implementation.
    
    ```
    Server               ProxyPlayer     \\\\      ProxyController    Player
      |                      |           \\\\           |                |
      | takeShots()          |           \\\\           |                |
      +--------------------->|===========\\\\==========>|--------------->|
      |                      |           \\\\           |   List Coord   |
      |<---------------------|<==========\\\\===========|<---------------+
      |                      |           \\\\           |                |
      | reportDamage(coords) |           \\\\           |                |
      +--------------------->|===========\\\\==========>|--------------->|
      |                      |           \\\\           |                |
      |                      |           \\\\           |   List Coord   |
      |<---------------------|<==========\\\\===========|<---------------+
      |                      |           \\\\           |                |
      |successfulHits(coords)|           \\\\           |                |
      +--------------------->|===========\\\\==========>|--------------->|
      |                      |           \\\\           |                |
      |                      |           \\\\           |   void         |
      |<---------------------|<==========\\\\===========|<---------------+
      ...
    
    ```
    
3. **The scoring phase**
    
    When the game is over, each player is notified if they won, lost, or tied the game, along with a rationale.
    
    ```
    Server              ProxyPlayer     \\\\      ProxyController     Player
      |                     |           \\\\           |                |
      |endGame(Result, Reas)|           \\\\           |                |
      +-------------------->|===========\\\\==========>|--------------->|
      |                     |           \\\\           |                |
      |                     |           \\\\           |   void         |
      |<--------------------|<==========\\\\===========|<---------------+
      ...
    
    ```
    

# 🖨️ JSON: Server-Client Communications

Messages between the client and server which follow the above protocols are sent using JSON. We introduced JSON during Lab 06; as a reminder JSON is the format we are using to encode objects. This ensures a standardized and interoperable encoding format between the server and the client so they can interpret each other’s messages. 

- The messages between the server (TA code) and client (your code) will all be based on the structure shown below:
    
    ```json
    {
    	"method-name": "SOME METHOD NAME",
    	"arguments": {
    		...
    	}
    }
    ```
    

<aside>
💡 If your implementation produces a response that the server does not expect (malformed JSON or invalid arguments), then the server controller will handle the error by stopping the game.

</aside>

## ✉️ JSON Message Formats

There are **************six (6)************** different message types based on MessageJson ([given here](https://github.com/CS-3500-OOD/lab06-solution/blob/main/src/main/java/cs3500/lab06/json/MessageJson.java)) that your `ProxyController` needs to be able to handle and delegate to your `AiPlayer`:

### 1. `join`

- server request:
    
    ```json
    {
    	"method-name": "join",
    	"arguments": {}
    }
    ```
    
- client response:
    
    ```json
    {
    	"method-name": "join",
    	"arguments": {
    		"name": "github_username",
    		"game-type": "SINGLE"
    	}
    }
    ```
    
    <aside>
    📌
    
    </aside>