University Project: System Architecture of Asteroid Miner Game

This assignment presents a comprehensive analysis of the system architecture for the multiplayer game 'Asteroid Miner'. The document begins with an overview of the game, its objectives, and the core mechanics, including mineral mining and fuel management within a resource-depleted environment. It then delves into the three-tiered architecture of the game, detailing the presentation, logic, and data tiers, explaining their functions and interactions. The assignment further explores the implementation details through class, activity, sequence, and use case diagrams, alongside user interface designs like the welcome screen and game interface. A significant portion of the document is dedicated to evaluating the robustness, fault tolerance, minimal recovery time, scalability, and security aspects of the game's design. The design ensures player progress is not lost during failures, the recovery time is reasonable, and the system is scalable and secure. References to relevant research papers support the analysis.

Running head: SYSTEM ARCHITECTURE - MULTIPLAYER GAME
System architecture: Multiplayer Game “Asteroid Miner”
Student Name:
University Name:

1SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Table of Contents
Section 1.................................................................................................................................................................2
Description of the system...................................................................................................................................2
Tiers of the system.............................................................................................................................................2
Overall structure of the implementation............................................................................................................2
Section 2.................................................................................................................................................................3
Class diagram......................................................................................................................................................3
Activity diagram..................................................................................................................................................4
Sequence diagram..............................................................................................................................................5
Use case diagram................................................................................................................................................6
User interfaces design........................................................................................................................................7
Section 3.................................................................................................................................................................8
Robustness of the design....................................................................................................................................8
Fault tolerance...................................................................................................................................................8
Minimal recovery time.......................................................................................................................................8
Scalability...........................................................................................................................................................8
Security...............................................................................................................................................................8
References..............................................................................................................................................................9

2SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Section 1
Description of the system
Asteroid Miner Game has been chosen as the system for this study, which is a multiplayer game and
has an extra element of interaction through mineral mining as well as fuel management. This game has been
chosen to illustrate on the software architecture that is required for a multiplayer game [5]. The aim of the
game is to explore an asteroid which is rich in minerals so that the players can collect those minerals and gain
points. The main scenario plots a resource depleted Earth so the players have to collect minerals from the
Asteroid and accomplish their goal by travelling through the space. The players have to collect a predefined
amount of minerals in order to achieve their goal. The players have to land on a specific plot in the Asteroid
and collect minerals then bring it back to their base station. The players have to share a total amount of fuel
available in the base station and with progress they will be able to purchase fuel with the minerals being
already collected by the player. The multiplayer scenario is such that the players have to share resources and
information for accomplishing their goals [2]. The resource comprises of expendable items in the game that is
fuel or minerals and information relates to the game states so that the players are kept updated about their
progress.
Tiers of the system
The multiplayer is designed with three main tiers as discussed below:
Presentation Tier: In this tier, user interface is the essential part which provides an option to the users
to communicate with the system [1]. This tier functions for transforming the user input commands into system
recognizable data and vice versa so that users are able to easily operate the system.
Logic Tier: In this tier, various functions are carried out from which making of logical decisions is
essential as it involves evaluating the user input and providing a feedback to the user in the form of results.
This tier is essential as it acts as a platform for transferring data within the adjacent layers that is presentation
and data layer.
Data Tier: In this tier, the operations are carried out on data that is storage, retrieval such that the user
can provide the users with desired results [4]. The data is being accessed from the database or game server
with the help of this layer and it also processes data transfer so that user action is performed and output is
generated from the system.

3SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Overall structure of the implementation
The aim of this game is to provide an enhanced interactive model so that the players find it more
attractive. The implementation of this game has been done in layers so that there is proper communication
between the different elements and users are able to easily perform their operations.
Section 2
Class diagram

4SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Activity diagram

5SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Sequence diagram

6SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Use case diagram

7SYSTEM ARCHITECTURE - MULTIPLAYER GAME
User interfaces design
Welcome Screen
Game Interface

8SYSTEM ARCHITECTURE - MULTIPLAYER GAME
Section 3
Robustness of the design
The game is robust in nature as robustness in context to the game design means it should be resilient
and scalable. The game has been designed to be resilient as the players do not need to have any technical
ability or knowledge to access and play the game [3]. The user interface of the game has been designed to be
simple so that the controls can be easily understood and there is clear view of the game states in the interface
only.
Fault tolerance
The design of the game has been prepared such that it is able to easily handle faults and the players do
not feel uncomfortable or unhappy while playing the game [6]. The design has been done such that in case of
any failure, the players do not lose their progress.
Minimal recovery time
The minimal recovery time for the game is around 20 - 30 minutes during which the causes of failure
can be determined or required maintenance can be done so that there is no hindrance for the players [3].
There may be some cases when player is progressing through a stage and there is fault then the game is rolled
to previous state so that the player does not loses their resources.
Scalability
The design of the game is scalable in nature as the predefined amount of minerals or fuel can be
modified by the hosting player and it is also categorized according to the selected plot or scenario.
Security
The design of the game is secure in nature and every user or player has their unique username and
password for accessing their account [1]. The authentication of the user is checked so that no user can access
the account of other user and misuse it for their own purpose. Hence, proper security mechanisms has been
implemented while designing the game.

9SYSTEM ARCHITECTURE - MULTIPLAYER GAME
References
[1.] D.V. Ranganathan, R. Vishal, V. Krishnamurthy, P. Mahesh and R. Devarajan, “Design patterns for
multiplayer card games”, In Computer, Communication and Signal Processing (ICCCSP), 2017 International
Conference on (pp. 1-3), IEEE, 2017.
[2.] A. Sapienza, H. Peng and E. Ferrara, “Performance Dynamics and Success in Online Games”, arXiv
preprint arXiv:1801.09783, 2018.
[3.] P. Slovak, K. Salen, S. Ta and G. Fitzpatrick, “Mediating Conflicts in Minecraft: Empowering Learning in
Online Multiplayer Games”, In Proceedings of the 2018 CHI Conference on Human Factors in Computing
Systems, p. 595, ACM, 2018.
[4.] C. Spawforth and D.E. Millard, “A Framework for Multi-participant Narratives Based on Multiplayer
Game Interactions”, In International Conference on Interactive Digital Storytelling, pp. 150-162, Springer, Cham,
2017.
[5.] M. Taylor, M. Baskett, D. Reilly and S. Ravindran, “Game Theory for Computer Games Design”, Games
and Culture, p.1555412017740497, 2017.
[6.] K.G. Vamvoudakis, H. Modares, B. Kiumarsi and F.L. Lewis, “Game theory-based control system
algorithms with real-time reinforcement learning: how to solve multiplayer games online”, IEEE Control
Systems, vol. 37, no. 1, pp.33-52, 2017.