You can download the server and client jars. They can run on linux, macos and windows and include all the needed dependecies for all platforms.
Requirements: Tested and developed with the Oracle JDK 14.
Run the jar with the command java -jar santorini-server.jar
Run the client jar with the command java -jar santorini-client.jar for each player you wish to create
- Java SE 14
- Maven
- JavaFX
- JUnit
- mockito
- IntelliJ IDEA
To run the tests and compile the software:
- Install Java SE 14
- Install Maven
- Clone this repo
- In the cloned repo folder, run:
mvn clean compile assembly:single- The compiled artifact will be inside the
targetfolder.
To compile the server you must change the mainClass property of the maven-assembly-plugin in the pom.xml and set it to it.polimi.ingsw.server.Server
-
Complete rules
-
Socket connection
-
Command Line Interface
-
Graphical User Interface using JavaFX
-
Advanced gods
-
Multiple games
-
-
In order to maximize the usability and readability of the UML class diagrams, we decided to create a general synthetic diagram that shows only the most representative relations and attributes. Moreover we created a diagram for each main package with the IntelliJ autogeneration tool.
Here you can find the javadoc documentation.
Here you can find the rules of the game.
The model and the controller have been tested using mockito.
Here you can find the coverage report.
-
The implementation of the chosen MVC pattern is the "hybrid" one in which input controls are also done on the client side to minimize network usage and server load. The controller takes care of managing turns, updating the model and managing events, requests and responses with the Client. On the server there is a Virtual View , on which the Controller calls methods and submits game requests. Virtual View will forward the methods to the client using the output stream.
-
It represent the status of the game. In particular, there is the information of the single Game, the Players, the Board and all the related information regarding workers and buildings.
-
Provides the user with a representation of the model by saving and updating locally a partial copy of the state of the game. In particular a copy of the Board is saved with all the related information.
It has the application logic and makes changes to the model, by using user inputs.
-
-
An observer pattern has been used to implement the notification mechanism. In particular, the model and the view represent the observed and the observer respectively. Each cell in the game is observed, and as soon as there is a change in the state of that cell, clients are notified.
Given the presence of the network, it was necessary to duplicate the observer pattern also on the client. In fact, the client class receives an update from the Network Handler class.
-
We decided to design the communication between server and client in order to make communication independent from the type of graphical interface chosen by the user. Therefore, the server always sends the same messages regardless of whether the client has chosen to play with CLI or GUI. Furthermore, two types of information are shared: those relating to the game and those useful for monitoring and managing the connection status of clients (PING).
Inside the server, there is a class that represents the virtual view associated with each client, on which the controller calls the methods which are then forwarded to the physical clients through the network.
Messages have been divided into: Request (server -> client) and Response (client -> server).
-
A mechanism has been implemented for detecting disconnections of the client due to network errors or application closing.
Disconnections caused by voluntary closure of the client are detected by the server through the management of network exceptions (SocketException).
-
Here are some screenshots from the game
