# Zappy GUI

The GUI component of Zappy provides a visual representation of the game world, allowing users to observe the game's progress in real-time. Here are the key aspects of the GUI:

1. Purpose: The GUI serves as a spectator view, enabling users to watch the Trantorians' activities, resource distribution, and game events without directly interacting with the gameplay.
2. Implementation: Developed in C++, the GUI uses the SFML (Simple and Fast Multimedia Library) for rendering, which provides a robust framework for 2D graphics.
3. Server Connection: The GUI connects to the server as a special client, identifying itself with the reserved team name "GRAPHIC" to receive game state updates.
4. **Visualization Features:**
   * 2D Representation: The GUI displays the game world as a 2D grid, with each tile representing a section of the Trantor planet.
   * Resource Display: Different icons or colors represent various resources on the map.
   * Player Visualization: Trantorians are shown on the map, potentially with indicators for their level and team.
   * Event Representation: The GUI may display animations or effects for events like broadcasts, elevations, or player deaths.
5. Real-time Updates: The GUI continuously receives updates from the server about game state changes, ensuring a current view of the game world.
6. **User Interface Elements:**
   * Zoom and Pan: Users can likely zoom in/out and pan across the map for a better view.
   * Information Panels: Displays for game statistics, team scores, or individual player information.
   * Time Controls: Potentially includes options to adjust the game speed or pause the visualization.
7. Optional 3D Rendering: While the basic requirement is a 2D visualization, the project allows for the possibility of a 3D interface for a more immersive experience.
8. Performance Considerations: The GUI is designed to handle incoming data efficiently, using appropriate buffering techniques to ensure smooth visualization even with frequent updates from the server.

## Architecture:

The GUI component of Zappy is designed with a modular and efficient architecture to handle the complex game state and real-time updates. Here's an overview of the key architectural components:

1. Command Parsing Factory: We utilize a factory pattern for parsing commands received from the server. This approach allows us to automatically handle different types of information sent by the server in a flexible and extensible manner. The factory determines the appropriate parser based on the incoming command type, enabling easy addition of new command types in the future.
2. GameData Class: At the core of our GUI is the GameData class. This central class is responsible for:
   * Storing parsed information received from the server
   * Creating and managing game elements such as players, food, and stones
   * Serving as the primary data model for the entire GUI
3. Game Element Classes: We have dedicated classes for various game elements:
   * Player: Manages player-specific data, rendering, and animations
   * Map: Handles the game world's size, tile management, and overall layout
   * Stone and Food: Represent resources with their specific properties and rendering information These classes handle their respective textures, sizes, and animations, ensuring a clear separation of concerns.
4. Client Class: The Client class (defined in Client.hpp) is responsible for:
   * Maintaining the connection to the server
   * Implementing the main loop that receives and processes server updates
   * Invoking the command parser factory to interpret incoming data This class serves as the bridge between the server communication and the internal game state representation.
5. Rendering System: While not explicitly mentioned, we can infer a rendering system that utilizes SFML to draw the game state based on the information in GameData and the various game element classes.

### Data Flow:

1. The Client receives data from the server
2. The command parsing factory interprets this data
3. Parsed information is used to update the GameData
4. GameData creates or updates game elements as necessary
5. The rendering system draws the current game state based on GameData and game elements

### Server / Graphical Communication Protocol

\
\
As well as any AI player that follows the AI / Server protocol will work with the server, any graphical client that respects the following protocol will do so.

After etablishing the connection to the server, the graphical client must send `GRAPHIC` in order to be identified as a graphical client.

The server will now receive all the events related to the game, and can send the following commands to get information about the game:

| Command | Description                    | Response Format                       |
| ------- | ------------------------------ | ------------------------------------- |
| msz     | Get the map size               | msz X Y                               |
| bct X Y | Get the content of a map tile  | bct X Y q0 q1 q2 q3 q4 q5 q6          |
| mct     | Get the content of all the map | Successive `bct` lines (1 per tile)   |
| tna     | Get team names                 | Successive `tna N` lines (1 per team) |
| ppo n   | Get a player's position        | ppo n X Y O                           |
| plv n   | Get a player's level           | plv n L                               |
| pin n   | Get a player's inventory       | pin n X Y q0 q1 q2 q3 q4 q5 q6        |
| sgt     | Get the server frequency       | sgt T                                 |
| sst T   | Change the server frequency    | sst T                                 |

Additionally to the command responses, the graphical client will receive the following lines:

| Line received                  | Description                   |
| ------------------------------ | ----------------------------- |
| bct X Y q0 q1 q2 q3 q4 q5 q6   | Tile                          |
| pnw n X Y O L N                | Player connection             |
| ppo n X Y O                    | Player's position             |
| plv n L                        | Player's level                |
| pin n X Y q0 q1 q2 q3 q4 q5 q6 | Player's inventory            |
| pex n                          | Ejection                      |
| pbc n M                        | Broadcast                     |
| pic X Y L n                    | Incantation beginning         |
| pie X Y R                      | Incantation ending            |
| pfk n                          | Egg laying                    |
| pdr n i                        | Resource picked up            |
| pgt n i                        | Resource dropped              |
| pdi n                          | Player death                  |
| enw e n X Y                    | Egg laid by a player          |
| ebo e                          | Player connection from an egg |
| edi e                          | Egg destroyed                 |
| sgt T                          | Time unit modification        |
| seg N                          | End of the game               |
| smg eni e X Y                  | First spawn egg               |
| smg pse P                      | Game paused/resumed           |

When an element is updated, it is sent to the player.

> ℹ️ For example, when a player drops an item, the inventory of the player and the tile content are sent to the graphical client after the drop event.

> ⚠️ When the client sends a command that does not exists, the server will respond `suc`, and `sbp` in case of wrong arguments in a valid command.

Here is the legend for the placeholders used:

| Code | Description                                |
| ---- | ------------------------------------------ |
| X    | X coordinate                               |
| Y    | Y coordinate                               |
| O    | Orientation: 1(N), 2(E), 3(S), 4(W)        |
| q0   | Resource 0 (food) quantity                 |
| q1   | Resource 1 (linemate) quantity             |
| q2   | Resource 2 (deraumere) quantity            |
| q3   | Resource 3 (sibur) quantity                |
| q4   | Resource 4 (mendiane) quantity             |
| q5   | Resource 5 (phiras) quantity               |
| q6   | Resource 6 (thystame) quantity             |
| i    | Resource number                            |
| n    | Player identifier                          |
| N    | Team name                                  |
| e    | Egg identifier                             |
| T    | Time unit                                  |
| L    | Level                                      |
| M    | Message                                    |
| R    | Incantation result (0: failed, 1: success) |
| P    | Pause state (0: resumed, 1: paused)        |

\
\\
