1.1. Purpose – The purpose of this document is to initialize and structure fundamental thoughts about the programming part for the modules. It is meant to give a high-level overview and technical description of the system and its overall architecture. This document will also help us implement each piece of the project.

1.2. Scope – This document consists of details which explain deeply the infrastructure of the game. It will cover the individual modules, classes, and the flow between them, showing how each one is connected to the others.

1.3. Definitions/Abbreviations

• HTML - stands for HyperText Markup Language; It is for creating web pages and web applications. It is static.
  
• JavaScript - It is a high-level, dynamic, weakly typed, prototype-based, multi-paradigm, and interpreted programming language. An Object-Oriented script language.
  
• CSS - Cascading Style Sheets is a language used for describing the presentation of HTML web pages and documents. It allows the changing of colors, fonts, layout, etc.
  
• MongoDB - MongoDB is a free open-source document-oriented database software.
  
• Node.js - An open-source JavaScript run-time environment meant for executing JavaScript code server-side.
  

1.4. References – List any outside references used in the creation of the document

• https://www.smartdraw.com/uml-diagram/
• https://creately.com/diagram/example/ile9ybe13/Mario%20Game%20Class%20Diagram

Back to Top

---

2.1. The architectural goal of the system is to successfully implement the four modules so that, in the end, we have a game that is enjoyable to play for the user. It is also a goal to make it a smooth experience.

2.2. Constraints – The constraints of the system are:

• Need to be connected to internet most of the time.
• Short-sightedness. The architecture is bound to change from what the system is in this document because we can't foresee problems that may arise, or changes we will make.

Back to Top

---

3.1. Major Logical Components – Describe the major logical components (including project modules) of the system and include a high-level UML Package Diagram showing their organization and interaction.

Graphical User Interface: The graphical user interface will provide visuals to the user in order for the user to interact with the game. It will guide the user by presenting the appropriate menus and information so that the user will know, for example, how much health their character has left during gameplay. The GUI handles painting to the HTML5 canvas.

Game Engine: The game engine will lay out the rules of the game system and game world. - This includes the relations among the four major components for the game which are, Player, Enemies, Bullets and updates.

Level Editor: The level editor will provide the user with the means to experiment and create their own levels by selecting from an inventory of game objects and entities, and then placing them onto the screen.

Database: Database will help the user to save and retrieve information regarding his score, status, and personal information.

3.2. Classes – Describe the most important classes in the system, their relation to the major logical components, and their organization/interactions. Give UML Class Diagrams for each class discussed.

Game Engine UML Class Diagram:

UI UML Class Diagram:

Back to Top

---

4.1. UML State Diagram

States Description

• Title - Shows the title/initial screen and transits to Login screen when user presses any key/mouse.
• Login - Prompts user to login if registered and transits to Main Menu, otherwise choose to play in Offline/Guest Mode.
• Registration - Registration screen that an unregistered player can sign-up an account.
• Forgot Password - Registered users who forgot password can go to this state and find out.
• Offline/Guest Mode - Unregistered player can play entire game without a registered account and brings the player to the main menu.
• Main Menu - It can transit to 6 states, Profile, Options, New Game, Load Game, Level Editor, and Exit(Final State).
• Profile - Registered players can check their profiles in order to see such as achievements.
• Options - Players can change various options within this state such as Sound, Controls, and Difficulty.
• New Game - Players can play a new game.
• Load Game - Players can load a game saved previously from database.
• Level Editor - Players can go to create/load a customized level
• Create a Level - Players can create a level.
• Load a Level - Players can load a saved level.
• Edit a Level - Players can edit a loaded level.
• Test/Save a Level - Players can test/simulate and save a level.

4.2. Architecturally Significant Use Cases

• Login(Login/Forgot PW)

• Options(Sound/Controls/Difficulty)

• Level Editor Menu(Create/Edit a Level)

Back to Top

---

5.1. Processes / Threads – List all processes and threads which run during normal system operation. This should address issues such as startup and shutdown, concurrently running system components, fault tolerance.

The processes that will be concurrently running during normal system operation are:

1. The game client within a browser window.
2. A web browser to house the operation of the game.
3. The database.
4. The server (single thread).

The game will have an offline mode, which will not require the database, otherwise the database will be running along with the browser, game client, and server. There should be no issues with startup and shutdown, unless the user has a load of browser tabs open along with the game tab, causing the browser to close down.

5.2. Classes

Process Diagram:

Back to Top

---

6.1. Deployment View

Back to Top

---

7.1. Size

The system should be able to handle at least fifty users. This is not something we can anticipate at the moment.

7.2. Memory - For storage of assets, we will require at least ~1mb for sound effects, ~20mb for music, ~2mb for images and sprites, not to mention the main game files. The database will hopefully store ~50 users and their data, and allow for them to create up to 2 levels each, equaling 100 levels.

7.3. Performance - The ideal fps for the game is 30 fps. As for loading times, the goal is to keep them 5 seconds or under.

• Enemy: enemies will disappear as they collide with any bullet shot by the player. In addition, they will be generated randomly.

• Player: player will have [20 as health scores (hp)], and each time the player collides with any of the enemies will reduce it is health score by 1.

• Upgrade: items will be on the space field for the player to collect, and each collected item will be beneficiary for the player as it increases the player’s score, and the health score for the player.

• Bullets: bullets will be shot by the player as well as the enemy. However, the aiming angle for shooting will be different for each of the enemies and the player. The player will be able to shoot bullets by using the mouse direction, whereas,enemies will shoot bullets randomly.

Back to Top

---

8.1. Overview

1. DataBaseName
2. Collections
3. Objects

8.2. Specifics – For each major database item, give specific storage details, and database organization.

Back to Top

---

9.1. Overview

• The files and software will be stored in our github repository during development and maintenance. We will have separate folders for image files, sound files, sprite files, enemy files, level files, and then game client code files, and server files.

9.2. Component Diagram

Back to Top