A Game of Multitasking

Middle East Technical University

Department of Computer Engineering

Arınç Elhan – 1819291

Halim Görkem Gülmez – 1819382

Muhammet Furkan Yılmaz – 1881630

Yiğit Kardelen – 1819424

January 4, 2014

Adamadama Development

A Game of Multitasking

Software Design Description Document

2

Preface

This is the official document of Software Design Description (SDD) of “ A Game of

Multitasking”. This document is prepared according to the “IEEE Standard for Information

Technology – Systems Design - Software Design Descriptions. IEEE Std 1016 – 2009”. Main

purpose of this document is to give detailed information about the design description of the

project such as design elements, development and design process of the software product.

3

Publishing Dates of Original and Changed

Subjects

Revision Date Changes

0 03.01.2015 Original Copy

1 01.03.2015 Viewpoint diagrams are updated, grammar corrections are made and the plan is added to conclusion part.

4

Table Of Contents

1. Overview .............................................................................................................................................. 6

1.1. Scope ............................................................................................................................................ 6

1.2. Purpose ......................................................................................................................................... 6

1.3. Intended Audience ....................................................................................................................... 6

1.4. References .................................................................................................................................... 6

2. Definitions ........................................................................................................................................... 7

3. Conceptual Model for Software Design Descriptions ......................................................................... 8

3.1. Software Design in Context .......................................................................................................... 8

3.2. Software Design Descriptions within Life Cycle ........................................................................... 8

3.2.1. Influences on SDD Preparation ............................................................................................. 8

3.2.2. Influences on Software Life Cycle Products .......................................................................... 8

3.2.3. Design Verification and Design Role in Validation ................................................................ 9

4. Design .................................................................................................................................................. 9

4.1. Introduction .................................................................................................................................. 9

4.2. SDD Identification ......................................................................................................................... 9

4.3. Design Stakeholders and Their Concerns ................................................................................... 10

4.4. Design Views ............................................................................................................................... 10

4.5. Design Viewpoints ...................................................................................................................... 10

4.6. Design Elements ......................................................................................................................... 10

4.7. Design Overlays .......................................................................................................................... 10

4.8. Design Rationale ......................................................................................................................... 11

4.9. Design Languages ....................................................................................................................... 11

5. Design Viewpoints ............................................................................................................................. 12

5.1. Introduction ................................................................................................................................ 12

5.2. Context Viewpoints .................................................................................................................... 12

5.2.1. Design Concerns .................................................................................................................. 12

5.2.2. Design Elements .................................................................................................................. 14

5.3. Composition Viewpoint .............................................................................................................. 14

5.3.1. Design Concerns .................................................................................................................. 14

5.3.2. Design Elements .................................................................................................................. 15

5.4. Logical Viewpoint ....................................................................................................................... 16

5.4.1. Design Concerns .................................................................................................................. 16

5

5.4.2. Design Elements .................................................................................................................. 17

5.5. Information Viewpoint ............................................................................................................... 19

5.5.1. Design Concerns .................................................................................................................. 19

5.5.2. Design Elements .................................................................................................................. 19

5.6. Interaction Viewpoint ................................................................................................................. 20

5.6.1. Design Concerns .................................................................................................................. 20

5.7. Pattern Viewpoint ...................................................................................................................... 23

5.8. Interface Viewpoint .................................................................................................................... 23

5.9. State Dynamics Viewpoint .......................................................................................................... 27

5.9.1. Design Concerns .................................................................................................................. 27

5.9.2. Design Elements .................................................................................................................. 28

6. Conclusion ......................................................................................................................................... 29

6

1. Overview

1.1. Scope

This document elaborately gives the design description for the project. To specify and

explain in detail, the development and design process of the software product, design elements

and the viewpoints will be given in this document. Each design concern is expressed in the

context of one design view and each design view is given with the corresponding design

elements. To sum up, the document provides a clear understanding of the basic structure of the

project and how the implementation process will be carried out.

1.2. Purpose

The software design document provides the system modeling and architectural design

for the project. The main and most important purpose of this document is to provide an overall

description of design elements, how they are interacting with each other, the content of

system’s components and behavior prior to the code development phase. It can also be said that

software design description is very important and credentials for people who will be involved in

code development. In other words, this document verifies whether the design issues conform to

the requirements of the project’s SRS Document. SDD serves as the primary reference for the

code development.

1.3. Intended Audience

As stated in section “1.2. Purpose” of the project SRS document, the intended audience are

developers, testers and end users. The design document gives detailed explanation of data,

architecture (design viewpoints) and procedural design for the developers and testers. The end users

can also be guided by system components, boundaries, restrictions and services description in this

document.

1.4. References

The resources listed below are the references that has been used during the preparation of

this document; IEEE Standard Documents:

[1] IEEE (2009). IEEE Standard for Information Technology – Systems Design - Software Design

Descriptions. IEEE Computer Society.

[2] Unity UI. (n.d.). Retrieved December 30, 2014, from http://unity3d.com/

[3] Parse. (n.d.). Retrieved December 28, 2014, from http://www.parse.com/

[4] 2D Game Development Walkthrough. (n.d.). Retrieved December 31, 2014, from

http://unity3d.com/learn/tutorials/modules/beginner/2d/2d-overview

7

[5] How to create an online multiplayer game with Unity. (n.d.). Retrieved January 2, 2015,

from http://www.paladinstudios.com/2013/07/10/how-to-create-an-online-multiplayer-game-with-

unity/

[6] “A Game of Multitasking” Software Specification Requirements (SRS) Document.

Retrieved December 31, 2014.

[7] StarUML 5.0 User Guide. (2005). Retrieved December 30, 2014, from

http://staruml.sourceforge.net/docs/user-guide (en)/toc.html

2. Definitions

Database: A collection of related data about user scores.

DBMS: A software package/system to facilitate the creation and maintenance of a

computerized database.

User: Person who can play single/multiplayer mode of the game.

SRS: Software Requirements Specifications.

SDD: Software Design Descriptions.

Class Diagram: A type of static structure diagram in UML that describes the structure of a

system by showing the system’s classes, their attributes, operations (or methods), and

the relationship among the classes.

Use Case Diagram: A type of diagram in UML that represents the user’s interaction with

the system.

Sequence Diagram: An interaction diagram that shows how processes operate with one

another and in which order.

State Diagram: A type of diagram used for describing the behavior of systems.

System Context Diagram: A type of diagram that defines the boundary between the

system, or part of a system, and its environment, showing the entities that interact with

it.

System Component Diagram: A type of diagram that are used to illustrate the structure

of complex systems.

System Deployment Diagram: A type of diagram that are used to describe the static

deployment view of a system.

Composite Structure Diagram: A type of diagram that shows the internal structure of a

class and the collaborations that this structure makes possible.

ER Diagram: A data model, which defines the information and data aspects of the

database.

Unity 3D: A cross-platform game creation system developed by Unity Technologies,

including a game engine and integrated development environment.

Game Engine: Software framework designed for the creation and development of video

games.

8

IDE: Software application that provides some good and useful facilities to programmers

for software development.

IEEE: The Institute of Electrical and Electronics Engineers.

FPS: Frame per second.

Scene: In unity, every different screen is represented as scene.

Interface: The part that can be shown by users of the game.

UML: Unified Modeling Language.

Parse: A hosted service, providing backend services to end-user.

GCE API: Google Compute Engine Application Interface

3. Conceptual Model for Software Design

Descriptions

This section includes basic project terms, concepts and context of SDD in which the

documentation is prepared. The conceptual model aims to give a better understanding of the

project terminology, software life cycle and modules that the project resides on.

3.1. Software Design in Context

The software product will be designed in an object-oriented and modular fashion. This

project will be implemented with C# using Unity and Monodevelop as IDE. The software product

is planned to be a game where unity is the game engine. The product will be designed for mobile

devices such as smart phones and tablets. Different operating systems such as Android and IOS

will be an issue. Supporting different screen resolutions and screen aspects will also be an issue.

For multiplayer mode Parse will be used as server side for communicating devices. Security is

handled by Parse. Cloud code will be written in Javascript and frontend communicating functions

will be written in C#. Once the devices learn which device to connect, pear to pear (P2P)

connection will be established. This connection will be wrote with C# using Unity server aspects.

3.2. Software Design Descriptions within Life Cycle

3.2.1. Influences on SDD Preparation

As it can be guessed, the main influence on software design description preparation is

the A Game of Multitasking software requirements specification document. The product

perspective, functional and nonfunctional requirements determine the outline of the

architectural design. The additional specifications of the stakeholders related to the frameworks

or data affect the SDD preparation.

3.2.2. Influences on Software Life Cycle Products

The agile method is adopted for the software process model and the software product

will reach to a final stage after a series of iterations. The first part of the software cycle is to

9

construct multiple mini games which are controlled by different controllers. The next part is to

merge mini games. After the first iteration a prototype will be presented to the stakeholders.

The iterations and additional/changing requirements of the stakeholders have influence on

software life cycle products. After the first demo, single player mode will be finished. The next

part will be constructing the server and handling the multiplayer mode which is the main

concern of the project.

3.2.3. Design Verification and Design Role in Validation

The main credentials for verification and validation of whether design of software obeys

the requirement that are specified in A Game of Multitasking SRS Document. The requirements

for each specific intended use of the software product are modeled in the design view parts of

the document. The verification and validation of the design view models are carried out based

on this document. SDD influences test plans and test cases in further stages. The testing process

will be handled after the code development.

4. Design

4.1. Introduction

The Software Design Description of this project is prepared for giving an overall

architectural design of “A Game of Multitasking” mobile game. In the following sections,

information about Identification of the SDD, identified design stakeholders, identified design

concerns, selected design viewpoints, each with type definitions of its allowed design elements,

design views, design overlays, design rationale and design languages can be found in this order.

4.2. SDD Identification

The system model that is specified in this SDD will be used for each production step

during the development and implementation periods. After the initial iterations, the prototype

will be demonstrated on January 19, 2015. The software product will be released by the end of

May 2015. Tentative date for the

Releasing project will be May 22, 2015. Adamadama development team will be responsible for

issuing “A Game of Multitasking” project. All rights of the end product are reserved. Due to the

exclusive right property, only Adamadama development will be free to modify and distribute the

product. Again, due to the privacy and copyright of the user data, user profiles cannot be

distributed. Apart from these and in order to avoid repetition, Glossary and necessary

terminology is available in section “2. Definitions” and also scope, references, context and

summary can be found in section “1. Overview”.

10

4.3. Design Stakeholders and Their Concerns

Stakeholders include Adamadama Developers team, testers and end users. Stakeholder’s

main concerns are performance, reliability and real time interaction without any delay or lag.

The final software product is planned and expected to be smooth, fast and reliable which will

overcome these concerns. “A Game of Multitasking” is a unique mobile game that aims to fuse

multitasking and mobile gaming. Two main modes will be available when the game is released.

Any further requirements are pointed in the Software Requirements Specification document of

the “A Game of Multitasking” project.

4.4. Design Views

This project will be implemented as mobile game application with different control

mechanisms as two different modes namely single player mode and multiplayer mode.

Therefore, stakeholders can download and play the game in a single player mode as long as they

have mobile phone that supports android or iOS. For the multiplayer mode, they need also good

and smooth Internet connection.

In this document; contextual, composition, interface, logical, interaction and state

dynamics view will be explained in next sections. Detailed description and diagrams about these

views will clarify them. Each view is given with its corresponding viewpoint.

4.5. Design Viewpoints

Software design description identifies context, composition, interface, logical, interaction

and state dynamics viewpoints. Context viewpoint specifies the system boundaries and actors

interacting with the system. Composition viewpoint identifies the system modules, components,

frameworks and system repositories. Interface viewpoint explains the interaction between

different software interfaces. Logical viewpoint includes the detailed description of data design

and class diagrams. Interaction viewpoint gives the sequence of events in the system and the

state dynamics viewpoint models the system as a state machine and shows the state transitions

and conditions on these transitions.

4.6. Design Elements

As a general description, a design element is any item that occurs in a design view. All of

the design elements of this SDD are described and explained in the following sections. Design

elements, their main properties, interactions and restrictions on elements are given together

with the viewpoints that are related to. These main design elements are defined inside the

related viewpoints in detail in section “5. Design Viewpoints”.

4.7. Design Overlays

A design overlay is used to indicate extra information with respect to an already defined

design view. The UI Component in this project refers to the interface of the mobile application

11

interface that is shown by user. Its main purpose is to show the current games, main menu or

score to the user. In addition, receiving inputs and displaying results is another main purpose of

this component.

4.8. Design Rationale

Software design pattern is a common reusable solution to a commonly occurring

problem within the context in software design. A design pattern is not a completed design that

can be converted directly into source or machine code. It is a definition or template for how to

solve a problem that can be used in many different situations.

This project is aimed and planned to be a mobile platform game. There are some games

on mobile markets that have the theme of multitasking but they are boring, simple and

unsatisfying from the point of view of users. So, in order to create much more entertaining and

unique game, this project has been chosen.

The project is based on creating an entertaining and a unique game with a multitasking

theme, which runs on the mobile platforms. There are several mini games in the project and

each one will be played with a different mechanism of the device such as virtual joystick with

one game or accelerometer with another game. In the single player mode, there are several

different mini games (three or four) that will be played when the game starts. Player will play

those mini games by using different control mechanisms of the device such as accelerometer or

virtual joysticks. In the multiplayer mode, players will connect to the same mini games and play

at the same time in order to compete each other. One of the mini games is about disrupting

other player’s mini game.

Designing four different mini games is a big issue. So, in order to handle it easily and in a

quick manner, Unity3D game engine has been chosen, in other words games will be developed

using Unity3D. Showing and playing four different mini games at the same time with one screen

is another big issue. So, using a game engine for handling this situation is much more easier than

native approach. Finally, adding an online multiplayer mode to game is another hard task to

achieve. Users will see both the opponent’s game and theirs game real-time. The game can be

won if the opponent loses the game. The connection between two devices will be established by

peer-to-peer architecture. There will be an external server, which stores current active

connections. Clients (devices) will be in interaction with the server only for playing multiplayer

mode. So, in order to handle connection issues, unity’s multiplayer API will be used.

4.9. Design Languages

In this document Unified Modeling Language (UML) is used as the modeling language for

the diagrams that is related with the system and architecture of the project. To emphasize the

static structure and dynamic behavior of the system, UML is used. In addition, ER diagram is

used for the design viewpoint specification (Like showing database structure).

12

5. Design Viewpoints

5.1. Introduction

With the help of the architectural models, notations, and languages, design viewpoints

are used to specify the methods for a system. The design descriptions and constraints of “A

Game of Multitasking” are being realized by using these design viewpoints. Different design

viewpoints are given in the following subsections. The design language is UML.

5.2. Context Viewpoints

Actor interactions of “A Game of Multitasking” and boundaries of the system are

represented in this section. The relationship between “A Game of Multitasking” and external

systems is shown within the system environment. UML Use Case diagram is used in order to

provide the roles of actors.

5.2.1. Design Concerns

“A Game of Multitasking” offers only one service to the one actor, which is player.

Players are able to register and then login to the game. The player can play the single player

mode without this login operation. Also while playing this mode, the game does not require any

internet connection: this mode can be played offline. In this mode, the player can pause and

continue the game via graphical user interface of the game. The player can also see about

section, change his/her preferences in offline mode. In online mode, the player can change

his/her nickname, search a multiplayer match, play a multiplayer match, remove advertisements

by paying an amount, share scores, and see leaderboards. These actions require internet

connection to be able to communicate with related systems.

Our project is context dependent because there is no possibility that our game can be

integrated with any other external system.

The following figure represents the configuration of the “A Game of Multitasking” system

among other external systems:

Figure 1: System Context Diagram

The next diagram is Use Case diagram to show actor interactions:

13

Figure 2: Use Case Diagram

System

Player

Play Multiplayer

Play SinglePlayer

About

Pause

Continue

Share

Leader Boards

Login

Change User Name

Cancel Searching

Register

Steer

Tap

Swipe

Remove Ads

Preferences

See Tutorial

14

5.2.2. Design Elements

The group of stakeholders is one of the important design entities. For our project, as the

game is developed by us and any income will be shared between us, only stakeholder is our

team. This may change after the release of the game, if the game is bought by some company.

The other group of design entities is player actors. The player actor is who interacts with the

game. All those interactions are represented in the Use Case diagram. While the player actor

plays the online mode the game will send input to server, and then take the output. In the single

player mode, there will be no communication between the game and the server.

5.3. Composition Viewpoint

In this section, project components and connections between these components are

explained in detail. Explanations are enriched with diagrams and figures.


This viewpoint aims to inform both programmers and stakeholders. Moreover, thanks to

the representation of the system, connecting components and scheduling the progress are much

easier.

In order to show the system components and connections between them, UML Package

diagram is used. The given below figure shows this relationship.

Figure 3: Package Diagram

15

The user/player can run the game under the mobile platforms. Since the project is a

cross-platform application, it perfectly runs with both Android&IOS. After running the

application, main menu is shown. According to the selection of player, the application writes the

game information to the database. In Single Player Mode, in basic, game type, duration and

score information is written to the database using the MySQL API. On the other hand, when the

selection is Multiplayer mode, application connects to the GameServer. After the matchmaking

is completed and opponent is found, application runs in Multiplayer mode and writes the

necessary information to the database. Game Score and information like winner are recorded

into the database when the game ends.

Although currently not need, but in the future, the “Dedicated Game Server” will be used

in order to effectively maintain the application and provide high performance. The above figure

shows the basic deployment over the Google Cloud Platform. “Cloud Platform provides the

building blocks so you can quickly develop everything from simple websites to complex

applications“. Using the magnificent power of Google cloud the performance of the application

will be unquestionable.


Main Application:

o Functional attribute: Players access the whole functionalities with the main

application. According to user selections, the main application operates. Almost

every operation in the single player and multiplayer mode is coordinated by the

main application.

Figure 4: System Deployment Diagram

16

o Subordinates attribute: There is only one main application and it is stand-alone.

Due to this, it does not contain any other application. However, it interacts and

communicates with both database and GameServer.

Database:

o Functional attribute: MySQL database stores data about players, history and

played games.

o Subordinates attribute: MySQL API connect database to the main application.

UI:

o Functional attribute: User interface of the main application displays main menu,

selection scenes, multiplayer mode scenes and control operations/inputs done

by users.

o Subordinates attribute: UI contains view and controller components. View

component displays menus and buttons. Controller checks the selected buttons

or the other actions.

GameServer:

o Functional attribute: According to subscribed players, the appropriate

matchmaking is done. Additionally, the In-Game requests are handled.

o Subordinates attribute: GameServer is a stand-alone component. It does not

contain any other component.

5.4. Logical Viewpoint

In this section, briefly detailed designed types and the practical implementation in a

logical standard are examined. The illustration will be based on classes and diagram will be used.


This section gives detailed information about the organization of the classes. Classes of

the system are designed in the object oriented manner. In addition to that, during the

development, class designs may be changed in order to provide some functionality. However,

the general structure will remain same. Details about the classes will be given 5.4.2.

17

Figure 5: Class Diagram


There are 16 classes in the class diagram. Each class will be detailed below.

GameType: An enumeration which indicates the type of the game. The options

are ‘SinglePlayerMode’ and ‘MultiPlayerMode’.

GameStats: This class represents the overall statistics about the games that have

been played by the user. Each Player must hold a reference to that class.

GameController: This class represents and holds the general functionalities in the

game. GameController is run whenever a game is started. According to the user

activities, it has capability to pause/continue the game. Additionally, the distance

server connection and database connection is mainly controlled under this class.

The key and vital class in the application is the GameController class.

DBConnector: This class has capability to manage all database operation. It uses

the MySQL API and makes appropriate operations. In addition to this, it has

throwing special the exceptions and logging mechanism. The only class that can

control and reference to this class is GameController. This structure is built in

order to make the system single-control.

18

UI: UI class is responsible for user-interaction. Every command or input received

from the player is handled in this class. Each Player must hold a reference to this

class. Although currently stated as eight functional capabilities, in the next phases

of the project, more functionality will be brought to this class.

Player: The Player class represents and holds the generic information about the

player/user. Moreover, it holds references to the many other classes and this

class is used as an instance.

GameServer: This class represents the game server. In addition to indicated

capabilities, this class internally handles the in-game requests in a tremendously

fast manner. The only external package is the Server package and this is the only

class in it. Only communication with GameServer class is done by

GameController.

Game: This class represents the game and its content. Mainly the scene of the

game is held here.

Scene: Scene class holds the entire information about the game scene. In other

words, every details and knowledge is restored here in order to be controlled by

the game controller.

GameObject: Everything in the Unity environment is the game object. Every

component created on the scene will be the GameObject instance. In addition,

this class hold every information about the component on the scene.

Component: Each GameObject will have their own components with carries

physical properties about the GameObject.

AbstractGameScript: This abstract class is generated for the mini games scripts. In

order to achieve a good object oriented design, a generic script class is designed.

This class is the parent class of the mini game script classes.

FirstGameScript: This class is designed and created for the first game. It extends

the “AbstractGameScript” classes. Moreover, additional functionalities that are

specific for this mini game will be added in the following phases of the project.

SecondGameScript: This class is designed and created for the second game. It

extends the “AbstractGameScript” classes. Moreover, additional functionalities

that are specific for this mini game will be added in the following phases of the

project.

ThirdGameScript: This class is designed and created for the third game. It extends

the “AbstractGameScript” classes. Moreover, additional functionalities that are

specific for this mini game will be added in the following phases of the project.

FourthGameScript: This class is designed and created for the fourth game. It

extends the “AbstractGameScript” classes. Moreover, additional functionalities

that are specific for this mini game will be added in the following phases of the

project.

19

5.5. Information Viewpoint

This section provides detail for designed types and their implementations in a

informative way by using entity relationship structures.


Although data are not the most important part of this project, there are some tables to

keep necessary information about the player. Especially for online functionalities, these data

must be kept.

Related entity relationship diagram is given below:

Figure 6: ER Diagram

There are two tables in database, namely Player, and GameStats. “Player” is keeping

information about players. “GameStats” is keeping statistics of the players. Details will be given

in Section 5.5.2.


ER diagram, which is given in 5.5.1., contains two entities:

“Player” entity contains fields about the player who can play the game. Fields of this

entity are given below:

userID: This attribute is primary key of this entity. This id is unique and used to

retrieve necessary statistics about the player.

userName: This attribute contains the user name of the player.

email: This attribute contains the email of the player.

paidAccount: This attribute is a Boolean attribute which is used while deciding

whether to show advertisements to player or not. If an account is a paid account,

then the player will not see any advertisements.

“GameStats” entity contains fields about the statistics of the players. These statistics will

also be used for matchmaking:

userID: This attribute is a foreign key in this entity. This id is unique and used to

retrieve each player’s own statistics.

20

numberOfPlayedGame: This attribute keeps the number of the games that the

player has played so far.

numberOfWins: This attribute keeps the number of the games that the player has

won so far.

numberOfLoses: This attribute keeps the number of the games that the player

has lost so far.

totalPoints: This attribute keeps the total point that the player has gained so far.

highScore: This attribute keeps the high score of the player.

5.6. Interaction Viewpoint

To describe main functionalities (what use cases do, how user interacts with the system),

some example UML Sequence Diagrams are given in this section.


Purpose of this view is giving details about the process of the application. As there are

lots of sequences in our project, emphasis will be put on the most important ones. Given UML

Sequence Diagrams below will represent the behavior of the system and classes for the

important use cases. These diagrams will be interpreted in detail, too.

First sequence diagram is given below and it will describe the login operation for “Player”

class:

Figure 7: Sequence Diagram for Login Operation

When a player wants to login, he/she gives his/her login information to the game’s initial

screen. Then, the game calls login method. This method sends a query to the database. Database

returns whether this information is true or not. If it is true, the main menu comes up. Otherwise,

21

user will see an error saying that the login information is not correct. Still, the player can pass

this login operation but in this case, he/she cannot use online interactions.

Next sequence diagram will show what happens when the player wants to play

multiplayer mode:

Figure 8: Sequence Diagram for Multiplayer Mode

When the player wants to play the multiplayer mode (assuming he/she is logged on),

there will be a matchmaking process to find an opponent and a room. If both of them are found,

then the match can begin, otherwise there will be an error message.

Following sequence diagram give details about updating an account’s payment detail:

22

Figure 9: Sequence Diagram for advertisement removing

When the player wants to remove, he/she has to make a payment. After this payment is

done, changeAccountDetails method will be called and this method will send a query to

database. In the database, related field will be updated. From then, that user will not see

advertisements any more.

A final example sequence diagram will describe what happens when a player tries to

pause the game:

Figure 10: Sequence Diagram for Puase Game Operation

23

The player has an option to pause the game while playing the single player mode. This

can be done by tapping to the pause button on the screen. Then this button (UI element) call its

pauseGame method. This method will call the game’s pause method. Finally, the game will be

paused.

5.7. Pattern Viewpoint

Pattern viewpoint mainly concerns reuse of patterns and available Framework template.

Composite structure diagram is a type of static structure diagram which indicates the internal

structure of a class and the collaborations that this structure makes possible.

In order to provide a deeper understanding of this viewpoint, a composite structure

diagram is provided below.

Figure 11: Composite Structure Diagram

5.8. Interface Viewpoint

As it can be inferred from the name, Interface view specifies a determined contract

among the designers, customers, programmers, and testers. In this section, the user interfaces

that will be developed will be detailed with screens to indicate how the interface will be like. The

images used in this section are retrieved from the initially developed application. No wonder

that view of scenes and menus might change a little during the development and

implementation phases. Nevertheless, screen will have structure similar to these ones.

The initial screen of the application can be seen below. The player selects one of the

game types using the buttons. According to the selection of the player, application directs player

to another screen. The logo and background is currently chosen as this. More eye-opening and

fascinating logo and background images will be designed in the following phases of the project.

24

After user/player selects the game type, assuming player in single player mode, the game

selection screen will be shown to the user. The player will choose which game(s) he/she wants to

play. Each game is represented with their distinctive object that is used in that game. There is

also a button on the top-right of screen. Using this button, player can go back to the main menu.

The below screens are retrieved from each mini game in order to show the interfaces.

The first mini game screenshot is given below. It is a balancing game and player tries to

hold the ball in balance. According to the accelerometer of the mobile device, the bar moves.

Figure 12: Screenshot of the initial menu

Figure 13: Screenshot of the game selection menu

25

The second mini game screenshot is given below. It is a reflex game in which the player's

purpose is to get away from incoming projectiles. The current images of spaceship and

projectiles are have chance to change according to coming feedbacks from the test players.

The third mini game screenshot is given below. It is a catching game, where the player

controls a bucket to catch the balls falling from the top of that part of the screen. The score is

shown at the middle top of the screen, which is actually a timer.

Figure 14: Screenshot of the first game

Figure 15: Screenshot of the second game

26

And finally the fourth game screenshot is given below. It is a run-and-jump game, in

which the player controls a runner who has to jump over the obstacles that are coming on the

right side of the screen. As in all other mini games, the score is shown at the middle top of the

screen, which is actually a timer.

Whenever the players fails, the game over screen will be shown to the player. The

sample game over screen can be seen below. It shows the score and has two buttons. Using this

buttons, the player can restart the game or go back to the menu.

Figure 16: Screenshot of the third game

Figure 17: Screenshot of the fourth game

27

5.9. State Dynamics Viewpoint

This section gives details about the system behavior and states of “A Game of

Multitasking”. UML State diagram is used in order to achieve this.


The following state diagram represents how the system reacts to operations in various

states. Detailed explanation is given in the next subsection.

Figure 18: Screenshot of game over screen

28

Figure 19: State Diagram


This state diagram basically describes the behavior of the system.

In the initial state, the player has three options: login, register, and go to offline mode. In

login state, the player may stay in that state or go to menu state after a successful login

operation.

The register state has no difference than login state. In the menu page, the player has a

variety of options. After picking one of them the player will go to its state. All states, except final

state, can return back to menu state.

About state will show details of our team etc.

The player can change volume settings in ChangePreferences state.

In PlaySinglePlayer state, the player plays the game with steer, swipe and tap actions.

Also, he/she can pause the game and go into pause state. From that state, he/she can continue

and go back to PlaySinglePlayer state or quit the game with device’s own functionality. In

PlayMultiplayer state, there is not any pause option.

Finally, remaining states act same as the About state but with different functionalities,

such as showing a tutorial or showing a form to change user name.

29

6. Conclusion

A Game of Multitasking Project’s implementation details, system architecture, and

design patterns are represented and explained in this Software Design Description document.

Fundamentals of data design, modules, and viewpoints are also included in this document. UML

diagrams are frequently used in the preparation of this document. Finally, with the help of the

design viewpoints, design issues are described in a detailed manner. Our plan is to complete a

playable version of the single player mode first, by complying with this document. After then, a

multiplayer mode will be developed. When that mode becomes playable, too, we are going to

publish our game in mobile markets. There will be regular updates in order to fix bugs (if any)

and add new modes/minigames.

Date post:	12-Feb-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times