Mesos / team software engineering project
One online match, different clients, one server.
We turned Mesos into a client-server game in Java. Players can join the same match through a graphical or text interface and connect via Socket or RMI; the server maintains one shared game state.
Politecnico di Milano, academic year 2025/26. Four-person team; final grade: 30/30.
- Result
- 30/30
- Team
- 4 people
- My work
- Server, Controller, Socket and RMI
- Testing
- Unit and integration tests
The game
Players create or join a match in the lobby, take turns under the Mesos rules and see the final result. The server can run multiple matches at once and stores completed-match rankings in a database.
My contribution
I implemented the server side: the Controller that receives actions and coordinates matches, and the two communication paths Socket and RMI. I contributed to the team’s model and server UML diagrams and worked on the player classes in the model.
The game rules, interfaces and leaderboard are products of the team's work.
Two protocols, one set of game rules
Consider a player joining a match: with Socket, the request travels as a message; with RMI, as a remote call. Both reach the same Controller, which updates the match and sends the new state to connected clients.
The shared interfaces VirtualServer and VirtualView keep transport separate from game rules. On the Socket path, each message carries an action to execute (Command pattern). The server can therefore mix Socket and RMI clients in one match.
The model: separate matches and rules
In the model, LobbyManager tracks separate matches. Each match has a GameManager and a state for its current phase: lobby, placement, actions or scoring. The state rejects moves that are not valid in that phase.
Special card effects are separate objects, called through a shared interface instead of checking concrete card types through a long chain of conditions. These are examples of the State and Strategy patterns in the team's model.
How we separated the tests
The structure lets us test one part without starting the entire game each time. The team tested rules, coordination, networking and persistence at different levels.
Game rules
Model and phase-transition tests without a server or user interface.
Controller
Simulated matches and clients verify who receives updates and errors.
Socket and RMI
Integration tests use real network communication and a simulated Controller to isolate the transport layer.
Leaderboard
A swappable repository: in-memory data in tests, H2 for integration, PostgreSQL in the application.
The team worked on feature branches; before merging, someone other than the feature's implementer wrote its tests.
Project materials
The report summarizes features, roles, patterns and test coverage. The repository contains code, tests and deliverables; it is private and the link works for authorized users.