Group PSP034
This final examination project consists in a Java implementation of the board game Santorini. The main pattern used is a distributed MVC (model-view-controller), in order to create an online multiplayer version of the game.
Final score: 30/30 (A).
- Complete Rules
- 2 or 3 players game
- Simple gods (1-10, except Hermes)
- Socket Connection
- CLI
- GUI (JavaFX)
- Advanced gods (5):
- Hera
- Hestia
- Limus
- Triton
- Zeus
Both client.jar
and server.jar
contain all the necessary dependencies (JavaFX) for Windows, Linux and MacOS.
Download server.jar
here.
In order to start server listening to socket connections on the default port (2020
) run:
java -jar server.jar
Otherwise, to start a server listening to socket connections on a specified valid PORT
(otherwise 2020
will be used) run:
java -jar server.jar PORT
Download client.jar
here.
In order to start a Command Line Interface (CLI) client run:
java -jar client.jar cli
If you are experiencing troubles, change the font size until it looks like this:
In order to start a GUI client, you can just double-click client.jar
, or run:
java -jar client.jar
If you would rather create your own JARs, you can use the included Maven profiles:
Server
profile generatesserver.jar
(active by default).Client
profile generatesclient.jar
.
- Open Maven sidebar
- Open Profiles and Santorini → Lifecycle
- Select a profile
- Run Santorini → Lifecycle → Clean
- Run Santorini → Lifecycle → Package
- Repeat for each desired profile
The project documentation includes UML diagrams, JavaDoc and JUnit4 test coverage.
Both high level design and detailed design diagrams were created.
The first one is an updated version of the initial UML, featuring a concise and schematic representation of the model-controller implementation.
Meanwhile, the latter consists in multiple diagrams, each one with a specific scope, collapsing redundant information:
-
Client
- Detailed client application. CLI and GUI packages collapsed.
- Detailed CLI client. Printables and Scenes packages collapsed.
- Expanded CLI hierarchy. Focuses on CLI sub-packages hierarchy.
- Detailed GUI client.
-
Server
- Detailed controller package.
- Detailed model package. Gods package collapsed.
- Detailed server package.
- Model-controller relationships.
- Server-controller relationships.
- Server application classes relationships.
- Gods hierarchy. Gods classes in model package are expanded and clarified.
- Expanded gods-model relationships.
JavaDoc is available for every project package. Almost every class and method features a brief JavaDoc description, except for a few obvious getters and setters.
Model and controller packages have been tested using JUnit4. Code coverage for both packages is over 95%.
Error Code | Description |
---|---|
CXXX | Client Errors |
C001 | IOException while client is sending a message. Usually caused by server unreachable. |
C002 | IOException while client is waiting for a message. Usually caused by server unreachable. |
C003 | Fatal error in client. Game cannot continue. |
C004 | Client could not establish a connection to the server. |
SXXX | Server Errors |
S001 | Another client has disconnected. Game has ended. |
S002 | Server is not responding. Heartbeat timeout expired. |
S003 | Severe server error. A message received by the game server was irreparably corrupted. |
The best way to run the server is via terminal interface (with ANSI colors support), since it features a detailed log, useful for debug reasons (e.g. it contains messages exchanged, along with their content). The implemented colors are:
when a message is sent by the server
when a message is received by the server
or underline when an important state change occurs (e.g. current player changes or server restarts)
Clients are assigned a temporary random numeric ID as soon as they connect to the server. They are identified by their ID until name and color are chosen. Message sender or recipient can be easily recognised by the player color chosen during the registration to the server, possible colors are:
Headless server works continuously in background (not suggested, as it cannot be shut down without killing JVM process and there is no visible log).