Skip to content
Snippets Groups Projects
README.md 25.44 KiB

Software Engineering Project - Wizard

Welcome to Wizard, a C++ implementation of the classic card game. Compete with your friends in exciting multiplayer gameplay!

Wizard Logo Cards

🚀 Features

  • 🌐 Multiplayer Gameplay: Play with 3 to 6 players.
  • 🔄 Synchronized Game State: Real-time updates for all players.
  • 🖼️ Elegant User Interface: A visually appealing UI powered by wxWidgets.

You can read the game's rules here. The implementation features a client/server architecture for multiplayer scenarios. It uses wxWidgets for the GUI, sockpp for the network interface, rapidjson for object serialization, and googletest for the unit tests.

1 Overview

The game and source files is available on GitLab on the main branch. The game was developed based on the provided LAMA example project game. This project consists of a server and a client, each with their own main.cpp file. Each player can run his client and connect to the server in the same local network.

2 Compile Instructions

3 Run the Game

4 Play the Game

4.1 Connection Panel

The client renders the GUI that is presented to the player, whereas the server is a console application without a user interface. Every action a player performs in the client application (for example playing a card) is sent as a formatted message to the server application, which processes the request.

  • If the player's move was valid, the server will update the game state (e.g. move a card from the player's hand to the discard pile) and broadcast this new game state to all players of the game. Whenever the client application receives a game state update, it will re-render the GUI accordingly and allow new interactions.
  • If the move was invalid, the game state will not be updated and only the requesting player will get a response containing the error message.

Network Interface

Everything that is passed between client and server are objects of type client_request and server_response. Since the underlying network protocol works with TCP, these client_request and server_response objects are transformed into a JSON string, which can then be sent over the network. The receiving end reads the JSON string and constructs an object of type client_request resp. server_response that reflects the exact parameters that are specified in the JSON string. This process is known as serialization (object to string) and deserialization (string to object). If you want to read more about serialization, read me on Wikipedia.

client-server-diagram

Serialization & Deserialization of messages

Both, the client_request and server_response base classes, implement the abstract class serializable with its write_into_json(...) function. It allows to serialize the object instance into a JSON string. Additionally, they have a static function from_json(...), which allows creating an object instance from a JSON string.