🎨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)