Multiplayer Card Game Architecture: A Client-Server Approach

This project details the architecture of a multiplayer card game, specifically focusing on the design and implementation of a client-server model for an UNO-like card game. The project outlines functional requirements such as sign-up/login, main menu, game starting, and messaging, along with non-functional requirements like security and robustness. It explores the use of UDP and TCP protocols for efficient communication between clients and the server. The architecture is implemented in tiers, with Tier-I covering the basic game operations, Tier-II focusing on robustness through local storage backups, and Tier-III enhancing security and usability. Diagrammatic representations including UML class diagrams, activity diagrams, and use case diagrams are also included. The project aims to create a robust and scalable multiplayer card game application with a focus on user experience and efficient network communication.

Running head: THE MULTIPLAYER CARD GAME ARCHITECHTURE
The Multiplayer Card Game Architecture
Name of the student:
Name of the University:
Author note:

1
MULTIPLAYER CARD GAME ARCHITECHTURE
UNO: A multiplayer card game
UNO is a popular cards game that is prevalent for a very long time. The game have
multiple players ranging from two to four who will play the game with turns. The winning
criteria is to discard all cards on hold while others are still having one or more cards at hand.
The deck of 108 cards contain 25 cards of each color from the primary four, with two cards
of each rank. In addition, there are the special cards that affects the style of game play or
directly affect the opponent’s game [1].
The application that is being designed below would thrive to bring out the best
playing experience for this real-life game on the mobile device. Up to four players will have
the freedom to login into particular game and share the board to fight until the end, digitally.
The interface would have positions for four users with profile pictures and their graphical
representation with their hold of cards. They will communicate over a distributed client-
server network model [5].
Functional Requirements
The functional requirements of this gaming application are as follows:
 Sign up/ Login: New users will be able to sign up with their valid email ID and
password. Returning users will be given the freedom to login to the system by
providing their valid credentials.
 Main Menu: The main menu would provide the users to choose if they wish to play a
2-player game or a full deck 4-player game.
 Start new game: The application’s programming algorithm must have the capabilities
to search for a newly starting game on the server and redirect the user into that game.

2
MULTIPLAYER CARD GAME ARCHITECHTURE
 Logical backend interface: The application program must implement intelligent
algorithms to detect the state of the game at every move of each client, to decide a
winning move or other necessities.
 Messaging: The game should provide a messaging interface where the players can
text to each other over the same client-server model.
 Remove player: This is a duty of the Server admin, who can remove or temporary ban
a player from the game for many a reasons.
Non-functional Requirements
The non-functional requirements for the application would be as follows:
 Security: The user login details should be stored using high rated encryption
techniques. This would prevent the server from the threat of Man-in-the-middle
attacks. The login sessions should also be ended as soon as the user quits the
application.
 Robust: This is the most important that needs to be discussed in details in a later
section of the report. As of now, it can be stated that the server and the client must be
able to retrieve from crashes or dodge in such situation in the first place [2].
The Client-Server Architecture
The board can be considered as a common state, where the users will play their cards
and the server will judge on the outcomes according to the logics and algorithms written into
it.
The understanding of the client-server is the most important phase of the project.
While each player playing in a particular game shall be considered as a feasible client, the
hub that is hosting the game would be considered as the server node [6]. The Server node
keeps on hosting 12 games every second. Therefore, any client who requests for a new game

3
MULTIPLAYER CARD GAME ARCHITECHTURE
shall be redirected into a game that would be started within the next few seconds. The server
would allow another or three other similarly rated players to play the same board.
To make the system more robust, the architecture adapted the TCP and UDP packet
transfer mechanism. The UDP or User Datagram Protocol is primarily used for the server and
the client while a game is on. As the game requires multiple players to be playing with
respective turns, it not much important to ensure that all the packets are sent in the perfect
order, where the speed of the transmission matters, hence UDP is chosen over TCP
(Transmission Control Protocol), where the speed is comparatively lower, but packets get
transferred in an orderly fashion [4]. The server sometimes uses TCP to send unavoidable
requests to the clients. In addition, the client chats with other clients over a TCP-based
framework using Firebase.
The server has complete control over the clients and can remove any client from a
game if that node is not responding or may have crashed. The server on a time-out session
and finally the client node is perished for the particular game. This makes the game to
continue even if a client is on wait or have crashed. This a robust implementation of the
game.
Tier Implementation
In Tier-I, the basic operations of the game are to be designed and developed like the
interface, the class designs, the activity states and so on. The programming parts of the
application are also to be done in this tier to fulfill every functional requirements along with
the basic implementations of security.
In Tier-II, the application must be improved on the grounds of robustness. The
recovery time for the client nodes shall be improved by allowing the system to take sessional

4
MULTIPLAYER CARD GAME ARCHITECHTURE
backups on the local storage of the device. This would allow the users to recover back into
the game from the dropped out stage [2].
In Tier-III, the server should be provided the options to ban players who pertain to
unfair means and improve on the grounds of interface usability for the application. This
enhances security. The local storage should be more efficiently used. The server calls should
be saved in the local storage even if UDP packets are delayed. This would allow the system
to fetch back missed information.
Schedule
1. UML and behavioral Designing: 2 weeks
2. Application interface (Front-end) Designing: 4 weeks
3. Application logic programming: 8 weeks
4. Client-Server integration: 2 weeks
5. Testing: 2 weeks

5
MULTIPLAYER CARD GAME ARCHITECHTURE
Diagrammatic Representations
UML Class Diagram
Activity Diagram

6
MULTIPLAYER CARD GAME ARCHITECHTURE
Sequence Diagram

7
MULTIPLAYER CARD GAME ARCHITECHTURE
Use Case Diagram

8
MULTIPLAYER CARD GAME ARCHITECHTURE
Interface Designs
Login Page
Home Menu Page

9
MULTIPLAYER CARD GAME ARCHITECHTURE
Games Page (4-players)

10
MULTIPLAYER CARD GAME ARCHITECHTURE
References
[1] Demaine, Erik D., Martin L. Demaine, Ryuhei Uehara, Takeaki Uno, and Yushi Uno.
"UNO is hard, even for a single player." In International Conference on Fun with Algorithms,
pp. 133-144. Springer, Berlin, Heidelberg, 2010.
[2] Lewandowski, Scott M. "Frameworks for component-based client/server
computing." ACM Computing Surveys (CSUR)30, no. 1 (1998): 3-27.
[3] Diot, Christophe, and Laurent Gautier. "A distributed architecture for multiplayer
interactive applications on the Internet." IEEE network 13, no. 4 (1999): 6-15.
[4] Chen, Kuan-Ta, Chun-Ying Huang, Polly Huang, and Chin-Laung Lei. "An empirical
evaluation of TCP performance in online games." In Proceedings of the 2006 ACM SIGCHI
international conference on Advances in computer entertainment technology, p. 5. ACM,
2006.
[5] Cronin, Eric, Burton Filstrup, and Anthony Kurc. "A distributed multiplayer game server
system." In University of Michigan. 2001.
[6] Bernier, Yahn W. "Latency compensating methods in client/server in-game protocol
design and optimization." In Game Developers Conference, vol. 98033, no. 425. 2001.