Multiplayer Card Game Architecture - PDF
Added on 2021-05-31
11 Pages1368 Words272 Views
Running head: THE MULTIPLAYER CARD GAME ARCHITECHTUREThe Multiplayer Card Game ArchitectureName of the student:Name of the University:Author note:
1MULTIPLAYER CARD GAME ARCHITECHTUREUNO: A multiplayer card gameUNO is a popular cards game that is prevalent for a very long time. The game havemultiple players ranging from two to four who will play the game with turns. The winningcriteria 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 cardsof each rank. In addition, there are the special cards that affects the style of game play ordirectly affect the opponent’s game [1].The application that is being designed below would thrive to bring out the bestplaying experience for this real-life game on the mobile device. Up to four players will havethe 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 graphicalrepresentation with their hold of cards. They will communicate over a distributed client-server network model [5].Functional RequirementsThe 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 andpassword. Returning users will be given the freedom to login to the system byproviding their valid credentials.Main Menu: The main menu would provide the users to choose if they wish to play a2-player game or a full deck 4-player game.Start new game: The application’s programming algorithm must have the capabilitiesto search for a newly starting game on the server and redirect the user into that game.
2MULTIPLAYER CARD GAME ARCHITECHTURELogical backend interface: The application program must implement intelligentalgorithms to detect the state of the game at every move of each client, to decide awinning move or other necessities.Messaging: The game should provide a messaging interface where the players cantext to each other over the same client-server model.Remove player: This is a duty of the Server admin, who can remove or temporary bana player from the game for many a reasons.Non-functional RequirementsThe non-functional requirements for the application would be as follows:Security: The user login details should be stored using high rated encryptiontechniques. This would prevent the server from the threat of Man-in-the-middleattacks. The login sessions should also be ended as soon as the user quits theapplication.Robust: This is the most important that needs to be discussed in details in a latersection of the report. As of now, it can be stated that the server and the client must beable to retrieve from crashes or dodge in such situation in the first place [2].The Client-Server ArchitectureThe board can be considered as a common state, where the users will play their cardsand the server will judge on the outcomes according to the logics and algorithms written intoit.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, thehub that is hosting the game would be considered as the server node [6]. The Server nodekeeps on hosting 12 games every second. Therefore, any client who requests for a new game
3MULTIPLAYER CARD GAME ARCHITECHTUREshall be redirected into a game that would be started within the next few seconds. The serverwould 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 packettransfer mechanism. The UDP or User Datagram Protocol is primarily used for the server andthe client while a game is on. As the game requires multiple players to be playing withrespective turns, it not much important to ensure that all the packets are sent in the perfectorder, where the speed of the transmission matters, hence UDP is chosen over TCP(Transmission Control Protocol), where the speed is comparatively lower, but packets gettransferred in an orderly fashion [4]. The server sometimes uses TCP to send unavoidablerequests to the clients. In addition, the client chats with other clients over a TCP-basedframework using Firebase.The server has complete control over the clients and can remove any client from agame if that node is not responding or may have crashed. The server on a time-out sessionand finally the client node is perished for the particular game. This makes the game tocontinue even if a client is on wait or have crashed. This a robust implementation of thegame.Tier ImplementationIn Tier-I, the basic operations of the game are to be designed and developed like theinterface, the class designs, the activity states and so on. The programming parts of theapplication are also to be done in this tier to fulfill every functional requirements along withthe basic implementations of security.In Tier-II, the application must be improved on the grounds of robustness. Therecovery time for the client nodes shall be improved by allowing the system to take sessional
End of preview
Want to access all the pages? Upload your documents or become a member.