Skip to content

Iteration 4: System Design Document (SDD)

bsrnrbhdr edited this page May 12, 2019 · 4 revisions

System Design Document (SDD)

1 Introduction

1.1 Purpose of the system

CubeX is a Single Player Game in which a single player competes against the game system. Everyone can play CubeX for having fun.

Figure : Sample CubeX level

  • Figure : Sample CubeX level

In the game player tries to pick up game resources for receiving more points and reach to finish point of the level while not captured by enemies or obstacles.

1.2 Design goals

application be able to:

  • Allows user to select previous levels until where player came to play.
  • Note that there is no ability to save a game in progress; the players must either complete the game or exit it.
  • Allows user to turn off/on the game music.
  • Provide an alternative keyboard-only mechanism for playing tiles and moving them on the board.
  • Allow user to see his/her received points of each level.

1.3 Definitions, Acronyms, and Abbreviations

Important terms and concepts are listed here. More will be added by the project teams. Model A schematic description of a system that accounts for its known or inferred properties

View A visual representation of a model which might also enable a user to manipulate properties of the model

  • Game A game is an instance of CubeX

  • Board A two-dimensional structured game area.

  • Player Any user that interacts with the system.

  • System Any interactions performed by the application are performed by the system.

  • Score The number of points earned by player in the level.

  • Timer The system process keeping track of the amount of time a player has left to complete the level.

  • Log A record of all of the level in the game’s major interactions.

  • GUI Graphical user interface

1.4 References

https://en.wikipedia.org/wiki/SDD

1.5 Overview

The "Introduction" section of this report has a general definition and informations about CubeX. In this report, project requirements come in two headings: non-functional requirements and functional requirements. System models of the game will be defined in detail. The System Model section includes domain analysis, state and activity diagrams. Figure : Component Diagram

  • Figure : Component Diagram

2 Current System

Current System is still developing state.

3 Proposed System

3.1 Overview

This section provides a functional overview of the system. This will again be properly be divided into two parts

3.1.1 Functional Requirements

  • The game is for a single player.
  • Players must be able to start a new game when the program is loaded.
  • Players must be able to start a new game during the progress of a game with confirmation that they want to cancel the old game.
  • The score must always be displayed on a score board.
  • Players must be able to select previous level to play.
  • Players must be able to save the log of the game.

3.1.2 Nonfunctional Requirements

  • 1. Usability
    • Game must be playable on android.
    • “About” and “Help” information about the game must be able to be retrieved at any point during the game or the run of application.
    • SYSTEM will provide status messages to the player to inform the player of the state of the game.
    • SYSTEM must play a sound when player has 10 seconds or less during their turn. (Single beep)
    • SYSTEM must play a sound when player runs out of time. (Alarm clock)
    • SYSTEM must play a sound when player finish the level.
    • SYSTEM must play a sound during the game.
  • 2. Reliability
    • Components of the project code will be tested alongside the implementation phase to ensure that they are functional.
    • Final, integrated project Code will be tested with to ensure that greater than or equal to 80% of the integrated code is covered at run-time and is functioning properly. The remaining 20% will be inspected through manual testing to ensure the highest chance of being quality code.
  • 3. Performance
    • Game must be smooth without graphical lagging.
  • 4. Supportability
    • The application must be run on Android.
  • 5. Implementation
    • Project will be implemented in C#. Using Unity Game Engine.

3.2 Subsystem Decomposition

We divided the game project subsystem into two packages, Game Logic and GUI. The GUI classes are responsible for providing a well-designed and easy-to-understand interaction between the user and the game logic. The game logic class is a major game component independent of the GUI.

Figure : Main Package Relations

  • Figure : Main Package Relations

3.3 Hardware / Software Mapping

For implementing the core design of our game project, we are using C# as the programing language. We are using Unity Game Engine Platform to develop our game. Player will play the CubeX on mobile and our game is single player game not supporting multiplayer. Software can be executed with a single executable file with some other files.

3.4 Persistent Data Management

Some files are saved and maintained in order to provide the game some nonvolatile operations. The game keeps scores of levels and last reached level in text file in order to display to the users or let the user play any level on Option screen. Different colored game objects and music files are also used at different levels of the game in order to provide better enjoyment on gaming. These files are read from the file system with their specified directions as parameters.

3.5 Access control and security

If there is only one player playing a game, the server's operator will never restrict access to a running game. Each different player has the same rights, features. It has a simple structure. It does not include any access control, password and similar applications.

3.6 Global software control

This section will explain the flow of global software control. This means the ordering of transactions in our system. There are three different control flow systems: process driven, thread driven or threaded control flow. Since we have a single system control, one control system can be selected because there are no different components. We use an event-driven flow control that is simple in our system. When an event is available, it is sent to the appropriate object. Information about the event is checked when selecting this submission event. The GameWorld class creates three event sender classes: a public sender that transmits events to all other peers, a simple sender that transmits events to GameWorld and ObjectManager. PeerConnection also uses threaded control flow. The system can create jobs on request or user basis. The PeerConnection class is responsible for fetching outgoing events and for sending them (over a network connection). It is also responsible for sequencing events from the network connection and sending them to the local event sender.  Figure :  Proposed System Game Start and Exit

  • Figure : Proposed System Game Start and Exit

3.7 Boundary conditions

3.7.1 Prerequisites

There is no prerequisite. It does not require a network connection. Because there is no multiple use. No connection is required in Music and Sound.

3.7.2 StartGame and Exit

Here we describe what must be done while starting or ending the system.

  • StartGame: When a player enters the game, he starts the game• from the beginning of the level or continues the game.
  • Configure game options is configured by the player to turn •the music sound onor off or to determine the volume level.
  • Exit: The game is closed by the player himself. When player leaves the game, the score and the level at which he stays are held. If the player wants to load level from this section can continue.

3.7.3 Exceptions

Here we describe how our game should react to exceptions that can occur due to problems outside the game itself. Unsaved game data If the player tries to exit in the middle of the level, he loses his status and the last level of that level. In this case, the player wants to exit the system "Are you sure you want to quit?" warning.

4 Subsystem services

4.1 Game Logic Design

4.1.1 Overview

In this section the game will be explained in more detail with class diagrams. Game world is the main part of the game structure. The game has a specific area. If the player leaves this area, player dies. When the walls, traps, flames are in front of the player, the player makes various moves. If the player captured by obstacles players live will decrease. The player should get run away from enemies with his movement abilities in case of encounter with the enemy. The game ends when the player comes to the finish line. Each movement of any dynamic object takes place as discrete grid coordinate movements. If an enemy's current location coincides with the location of the players, the player loses one of his live.

4.1.2 In Game Activities

Game loop updates the map in every frame and saves the movements on it and waits for the player’s next action. Player can move with joystick on the left side of the screen or if player uses PC to play s/he can use arrow keys and space bar. Game loop controls remain lives and decides if game finished or continuing. And checks if the player triggered mesh of any enemies or traps decreases live of player. If the location player arrived has any game resources increases score. All these activities depicted in the following diagram.

Figure : In Game Activity Diagram

  • Figure : In Game Activity Diagram  Figure : Class Diagram
  • Figure : Class Diagram

4.1.3 Detailed Class Design

Player

At the start of a game new player will be declared. After that, we move on to the game world and the game begins. The player is responsible for maintaining actual information and the current score of the level. When a player passes a level, a valid score is added to the base score held by the game manager, and the next level score starts at zero.

  • Properties:
    • “walk” is player’s movement.
    • “jump” is player’s ability to escape the enemy and obstacle.

Game World

The game world is the main administrative class of the project. Provides some algorithms and simplifies operations between classes for the game. The game engine is designed to be unique to any game because it's a singleton class. Requires a player and will not change until exit of the game.

  • Properties:
    • “player” is the person who currently plays the game. It means player object created or read from file as loading procedure after Game World instance is created. Player object is not to be destroyed until game is executed.

    • “Score” keeps the status of that point from the time the player started to the first level.

    • “Game Over” is the end of the game

  • Methods:
    • IsGameOver():is the end of the game
    • GetScore():keeps the status of that point from the time the player started to the first level.
    • Update():records changes in game status.
    • Enterstate():Holds the status of the game.

Menu

Keeps the preferences made at the beginning of the game.

  • Properties: “Options” Game settings. Includes options such as turning the music on, off, and muting.
  • Methods:
    • GetMenuOption()

HighScore

  • “score” Keeps the status of points.

Enemy<>

  • Properties:
    • “move” ability to move around in certain places. If the player touches him during this move, she/he dies.

Door

This class represents the door which lets the go to another room in the level. It is going to be opened when player collect key on the map. Gameworld is responsible from managing the door. This class inherits from Immovable Object class because essentially this door is an immovable object to.

  • Properties:
    • “open” is the state of the door. If this property true door is open. In other words, when player collect key on the map.
  • Methods:
    • “openDoor” method sets the open property as true. Opens the door.
    • “isOpened” used for determining if the door currently opened or not.

GameState <>

  • Properties:
  • “stateId” enumerates the game status by level.
  • Methods:
    • ResetContent():deletes game status. it does not eat the current state when it wants to start a level again

4.2 GUI Design

4.2.2 Overview

In this GUI Design Part, the menu screens and the relationship between them will be explained with the help of class diagrams, activity diagrams and screenshots of these menus which will be almost the same for the implementation progress. We have designed some screenshots for the requirements of a cube game. Then we found out the action flow of the game such that “which screen appears when a certain event happens” or “what needs to be done in the game logic when a button is pressed”, etc.

4.2.3 GUI Components

The Main Menu Panel is the main screen scene in the game as a GUI component. In the panel, there is a label like a header which involves our project’s name “CUBEX”. There are 4 buttons to start the game and for the transition among other menu panels.  Figure : Main Menu Panel

  • Figure : Main Menu Panel In the Options Menu, for the volume adjustments of background music and sound effects.

   Figure : Settings Menu Panel

  • Figure : Settings Menu Panel

4.2.3 GUI Activity Flow

GUI activities start in the main menu which will be displayed at the start of the game. If the user clicks the “play” button, the game starts. If the user clicks to “Load Game” button, the load game menu appears. The user chooses a saved game from the buttons. If there is no game saved to the location for example to “Level 10”, that button will be deactivate and user is not able to click to it. If player does not want to load game, after clicking to the “Back Button” the main menu screen appears. In the main menu, after the user clicks to the “Options”, he/she sees the option menu where there are the settings for the volume. If the user changes them, the changes are applied and the options screen still visible. To exit the game, “Exit Button” must be clicked.    Figure : Main Menu Activity Diagram

  • Figure : Main Menu Activity Diagram

4.3 Sound System Design

There are mainly 2 kinds of sound in the game; “volume” and “music”. Volume is set to the volume level and music off and on button.

4.3.1 Music

There will be a background music that will play in the menu screens.

5 Glossary

  • Hearts: An alternate term for a character's life points or health.
  • Obstacles: A difficulty or problem that prevents you from achieving something.
  • Game resources: Many games involve the management of resources. Examples of game resources include tokens, money, land, natural resources, human resources and game points.