See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/305244786

Online Game Hub

Technical Report · April 2015

DOI: 10.13140/RG.2.1.1303.4484

CITATIONS READS
0 13,294

5 authors, including:

Arjun R.

30 PUBLICATIONS 136 CITATIONS

SEE PROFILE

All content following this page was uploaded by Arjun R. on 13 July 2016.

The user has requested enhancement of the downloaded file.

ONLINE GAME HUB

CS09-608(P) B.Tech Mini Project 2015

Done By

Arshad Sidhique - ETAMECS013

Jithin V - ETAMECS026

Jose Thomas - ETAMECS027

Muhammed Aslam - ETAMECS036

Guided By

Arjun R
Assistant Professor,CSE

Dept of Computer Science and Engineering

Government Engineering College
Thrissur - 680009
CS09-608(P) Mini Project, 2015

Abstract

This project is aimed at developing a website for online gaming. The Online
Game Hub provides an easy interface that would let the users to the pool of gaming.
It provides the users more pleasure and gladdening his mind by playing these tradi-
tional games such as ludo,bingo,puzzle,dots,vanish and memory game.It also provides
users to interact with other players who are login to the website, even while gaming.
Multiplayer option is also provided in Bingo, so that users can play this game in
different computer systems. A registered user can directly enter to the website by
login using username and password. Basically the website consist of 6 games and a
chat box to interact with other users while gaming.

Department of CSE, GEC Thrissur i

CS09-608(P) Mini Project, 2015

Acknowledgement

First and foremost we wish to express our wholehearted indebtedness to God

Almighty for his gracious constant care and blessings showered over us for the suc-
cessful completion of the project. We are also grateful to Asst. Professor Arjun R
for guiding and correcting various documents with attention and care. He has taken
pain to go through the project and make necessary correction as and when needed.He
gave us moral support and guided us in different matters regarding the topic. He
had been very kind and patient while suggesting us the outlines of this project and
correcting our doubts. We thank her for her overall support. We do extend our
sincere thanks to Asst. Professor Anish Abraham, Asst. Professor Savitha K.K and
Asst. Professor Reshmi Joseph, our project coordinators for their valuable support
and guidance. We also thanks to the head of our department Associate Professor
Helen K.J for her hard support.

We are also thankful to all developers of various softwares that we came into use
during the course of our project. We would also like to thank the stackoverflow.com
team for answering our doubts in the limited amount of time. A big thanks to google
search engine for endless matching answers for our questions and also sharelatex.com
for their online latex editor. We also thank our friends who has supported and helped
us to complete this project successfully.

Department of CSE, GEC Thrissur ii

CS09-608(P) Mini Project, 2015

Contents

List of Figures vi

List of Tables vii

List of Abbreviations viii

1 Introduction 1
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Current system . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Proposed system . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Scope of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Technical Feasibility . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1.1 Hardware Feasibility . . . . . . . . . . . . . . . . . . 2
1.2.1.2 Software Feasibility . . . . . . . . . . . . . . . . . . . 2
1.2.2 Financial Feasibility . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2.1 Development Cost . . . . . . . . . . . . . . . . . . . 2
1.2.2.2 Installation Cost . . . . . . . . . . . . . . . . . . . . 2
1.2.2.3 Operational Cost . . . . . . . . . . . . . . . . . . . . 2
1.2.2.4 Maintenance Cost . . . . . . . . . . . . . . . . . . . 2
1.2.3 Operational Feasibility . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Agile Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1.1 The Basic Working Model . . . . . . . . . . . . . . . 4
1.3.1.2 Future Increments . . . . . . . . . . . . . . . . . . . 5

2 Requirement Analysis 6
2.1 Method of requirement elicitation . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 User Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Project Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Requirement validation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Requirement Review . . . . . . . . . . . . . . . . . . . . . . . 7

Department of CSE, GEC Thrissur iii

CONTENTS CS09-608(P) Mini Project, 2015

3 Software Requirements 8
3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.2 Product Functionality . . . . . . . . . . . . . . . . . . . . . . 8
3.3.3 Users and Characteristics . . . . . . . . . . . . . . . . . . . . 9
3.3.4 Operating Environment . . . . . . . . . . . . . . . . . . . . . 9
3.3.5 Design and Implementation Constraints . . . . . . . . . . . . 9
3.3.6 User Documentation . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1 External Interface Requirements . . . . . . . . . . . . . . . . . 10
3.4.1.1 Hardware Interfaces . . . . . . . . . . . . . . . . . . 10
3.4.1.2 Software Interfaces . . . . . . . . . . . . . . . . . . . 10
3.4.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . 10
3.4.3 Behavioral Requirements . . . . . . . . . . . . . . . . . . . . . 10
3.4.3.1 Use Case View . . . . . . . . . . . . . . . . . . . . . 10
3.5 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . 11
3.5.2 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.3 Software Quality Attributes . . . . . . . . . . . . . . . . . . . 12
3.5.3.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.3.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.3.3 Availability . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.3.4 Maintainability . . . . . . . . . . . . . . . . . . . . . 12
3.5.3.5 Adaptability . . . . . . . . . . . . . . . . . . . . . . 12
3.5.3.6 Testability . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Design 13
4.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 User Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.2 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Coding 18
5.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Functional Template . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Testing 23
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Testing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Types of testing done . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Department of CSE, GEC Thrissur iv

CONTENTS CS09-608(P) Mini Project, 2015

6.3.1 Whitebox testing . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.3.2 Blackbox testing . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4 Advantages and Limitations . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.1 White Box Testing . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . 27
6.5 Future Extensions if possible . . . . . . . . . . . . . . . . . . . . . . . 27

7 Software Quality Assurance 28

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.3 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.3.1 Background and Context . . . . . . . . . . . . . . . 29
7.1.3.2 Project Objectives . . . . . . . . . . . . . . . . . . . 29
7.2 Quality Assurance Strategy . . . . . . . . . . . . . . . . . . . . . . . 29
7.3 Audits and Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3.1 Work Product Reviews . . . . . . . . . . . . . . . . . . . . . . 31
7.4 Further Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8 Conclusion 32

Appendices 34

A User Document 35
A.1 Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.3 Puzzle Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.4 Vanish Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.5 Ludo Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.6 Bingo Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.7 Dots Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.8 Memory Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Department of CSE, GEC Thrissur v

CS09-608(P) Mini Project, 2015

List of Figures

1.1 Agile Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 Usecase diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Dataflow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Usecase Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

A.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.3 Puzzle gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.4 Vanish gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.5 Ludo gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.6 Bingo gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.7 Dots gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.8 Memory gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Department of CSE, GEC Thrissur vi

CS09-608(P) Mini Project, 2015

List of Tables

4.1 Signup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Login Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Message List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.1 Blackbox Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.1 List of Software Items . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2 Quality Assurance Strategy . . . . . . . . . . . . . . . . . . . . . . . 30
7.3 Work Product Review . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Department of CSE, GEC Thrissur vii

CS09-608(P) Mini Project, 2015

List of Abbreviations

PHP Hypertext Pre-processor

SQL Structured Query Language

HTML Hyper Text Mark-up Language

CSS Cascading Style Sheet

SMTP Simple Mail Transfer Protocol

IEEE Institute of Electrical and Electronics Engineers.

DB Database.

UI/UX User Interface/User Experience.

Department of CSE, GEC Thrissur viii

CS09-608(P) Mini Project, 2015

Chapter 1

Introduction

1.1 Problem Statement

This project is aimed at developing a website for online gaming. The Online
Game Hub provides an easy interface that would let the users to the pool of gaming.It
consist of 6 games such as Bingo,Ludo,Dots,Vanish and Dots and a chat box to
interact with other users while gaming. Multiplayer option is also provided in Bingo,
so that users can play this game in different computer systems. A registered user
can directly enter to the website by login using username and password.

1.1.1 Current system

Presently, there are lots of online gaming websites available. But multiplaying
options are not available for the games.Some of these websites are less interactive to
the user.

1.1.2 Proposed system

The proposed system is meant to give more easiness to the users that they can
easily addicted to the games. we provide multiplayer options for games.A chat box
is also provide to interact with other players while gaming. And the interface for the
users is quite entertaining and engaging.Menus are interactive and easy accessible
throughout the game.Once the game is in playing mode,everything a player needs
will be clearly visible on the screen and easily accessible.

1.2 Scope of Project

Gaming gives relaxation and enjoyment to every user.In this busy world, gaming
is the solution to release the depression and tension.Social networking with gaming is
a nice combo for any user who was addicted to the world of gaming. The requirements
specified in this document will be used for designing all the aspects and components

Department of CSE, GEC Thrissur 1

CHAPTER 1. INTRODUCTION CS09-608(P) Mini Project, 2015

of the game. The document will be updated as the requirements grow and change
over the design and development process.

1.2.1 Technical Feasibility

We have analyzed the technical feasibility of the project based on the following
factors.

1.2.1.1 Hardware Feasibility

The minimum hardware requirements for developing Online Game Hub are given
below:

• A computer system

1.2.1.2 Software Feasibility

• XAMMP Server

• Sublime Text Editor

• Web Browser(Chrome)

1.2.2 Financial Feasibility

1.2.2.1 Development Cost
For developing an application no particular cost is required. But devices are
needed to demonstrate its working. The only cost required is the cost of devices
needed for demonstration of the working Application.

1.2.2.2 Installation Cost

No particular installation cost is needed other than the cost of hardware devices.

1.2.2.3 Operational Cost

Execution of the application does not actually require any operational cost. The
only operational cost required is the cost of power supplies to hardware devices as
well as the connectivity charges.

1.2.2.4 Maintenance Cost

No particular maintenance cost is needed for this software.

Department of CSE, GEC Thrissur 2

CHAPTER 1. INTRODUCTION CS09-608(P) Mini Project, 2015

1.2.3 Operational Feasibility

The operational feasibility of the application is dependent on the following fac-
tors:

• The database must contain all the details.

• Database must be updated regularly

1.3 Process Model

1.3.1 Agile Model
Agile model is selected for the project. We are planning to implement the
system with basic facilities only. So many future enhancements are possible with
this model. Agile model can satisfy this requirement efficiently. Since it follows the
plan-do-check-act for improvement, backtracking can done easily in Agile model.

Figure 1.1: Agile Model

Department of CSE, GEC Thrissur 3

CHAPTER 1. INTRODUCTION CS09-608(P) Mini Project, 2015

1.3.1.1 The Basic Working Model

Agile modelling is a practise based methodology for effective modelling and docu-
mentation of software-based systems. This can be applied on a software development
project in an effective and light-weight manner. With an Agile Model Driven De-
velopment (AMDD) approach enables a high level modelling at the beginning of a
project to understand the scope and potential architecture of the system, and then
during development iterations it requires modelling as part of iteration planning ac-
tivities and then requires just in time (JIT) model storming approach.

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

• Requirements evolve but time scale is fixed

• Testing is integrated throughout the project life cycle

WHY AGILE?

• Customer satisfaction by rapid, continuous delivery of useful software.

• People and interactions are emphasized rather than process and tools.

• Continuous attention to technical excellence and good design.

• Regular adaption to changing circumstances.

• Even late changes in requirements are welcomed.

• Face-to-face conversation is the best form of communication.

• Customers, developers and testers constantly interact with each other.

• Working software is delivered frequently (weeks rather than months).

AGILE SOLVES ISSUES LIKE:

• Resource wastage

• Costly modifications

• Unclear requirements

Department of CSE, GEC Thrissur 4

CHAPTER 1. INTRODUCTION CS09-608(P) Mini Project, 2015

1.3.1.2 Future Increments

The future enhancements of the proposed system that we have estimated are
given below.

• Including more games to the system.

• Extending multiplayer options for more games.

• Improving the message system.

• Including advanced methods for notification.

• There is always possibility of enhancing UI/UX(User Interface/User Experi-

ence) and Responsive Design.

Department of CSE, GEC Thrissur 5

CS09-608(P) Mini Project, 2015

Chapter 2

Requirement Analysis

2.1 Method of requirement elicitation

The techniques we have used for gathering requirements from users were:

• Interview

2.1.1 Interview
We had an discussion about the various online gaming websites regarding the
various features that has to be incorporated in to the Online Game Hub. In this
interview the following questions were asked.

• What is the need of such a website?

• What are the issues pertaining to the present gaming system?

• What are the necessary functionality required for the planned web application?

• Who are the intended users of the system?

• What are the different views and privileges given to the different class of users?

• What are the expectations from such a website?

2.2 User Requirements

On the basis of requirement survey conducted among the users, we have reached
to a conclusion that more than 5 percent of people in the world are suffered by depres-
sion and tension due to their job complexity.Gaming gives relaxation and enjoyment
to every user. In this busy world, gaming is a solution to relase the depression and
tension. Social networking with gaming is a nice combo for any user who was ad-
dicted to the world of gaming.

Department of CSE, GEC Thrissur 6

CHAPTER 2. REQUIREMENT ANALYSIS CS09-608(P) Mini Project, 2015

2.3 Project Requirements

On the basis of the requirements demanded by the user the following project
requirements are found out:

• There are mainly 6 games are included with different tastes. They are Ludo,Bingo,Dots,Puzzle
and Vanish.

• Simple and attractive interface is provided for user.

• Users will be able to register and login to get their account from which user
can play games.

• Multiplaying option for the game Bingo is provided for more fun.

• Chat box enables the users to interact with other users while gaming.

• Message from various users are notified instantly.

2.4 Requirement validation

The goal of requirement validation is to make sure that problems are addressed
and suitable solutions are arrived at, before resources are committed to implementing
the requirements. It is concerned with examining the requirements to certify that
they meet the Websitess intentions. The key activities in requirement validation are
conducting requirement reviews , demonstrating prototypes,validating the concep-
tual models etc. We are adopting requirement review as mechanism for requirement
validation.

2.4.1 Requirement Review

Initially we have classified the requirements, prioritized them and then negotiated
the lower priority requirements. Next step is reviewing the requirements in order to
make sure that we have collected the right requirements. The system requirements
listed above are complying with the final product.

Department of CSE, GEC Thrissur 7

CS09-608(P) Mini Project, 2015

Chapter 3

Software Requirements

The software requirements specified in this chapter are applicable for the devel-
opment of the website, Online Game Hub.

3.1 Definitions
• Game Hub:-A game hub is most often one specially-designed web page at a
website which brings various games together from different perspective sources
in to a single system.Interfaces for users should be attractive in order to users
to stay with the website.

3.2 Document Conventions

This document follows IEEE standard format and the conventions followed for
fonts, formatting and naming are the standards followed in Computer Science and
Engineering Department of Government Engineering College Thrissur.

3.3 Overall Description

3.3.1 Product Perspective
Presently, there are lots of online gaming websites available. But multiplaying
options are not available for the games.There are lots of people they are stressed with
people have much pleasure and relaxation from these games.Chat system is included
for users interactions.

3.3.2 Product Functionality

The service offered by the Online Game Hub is given below.
• Game Hub is provided with 6 traditional games such as Bingo,Ludo,Puzzle,Dots
and Vanish.

Department of CSE, GEC Thrissur 8

CHAPTER 3. SOFTWARE REQUIREMENTS CS09-608(P) Mini Project, 2015

• Bingo is provided with multiplayer option. examination and notify the user
concerned.

• Users will be able to register and login to get their account from which user
can play games.

• Multiplaying option for the game Bingo is provided for more fun.

• Chat box enables the users to interact with other users while gaming.

• Message from various users are notified instantly.

3.3.3 Users and Characteristics

We are broadly defining the users who need to gain pleasure and relaxation
through gaming.

• The main stream users of the proposed system are the users who play games
for depression removing.

• Another important users of this system are those who play such games just for
fun.

3.3.4 Operating Environment

The Online Game Hub will need the following : Windows/Unix based server
that supports PHP and MySQL:- A server is a system (software and suitable
computer hardware) that responds to requests across a computer network to provide,
or help to provide, a network service. Servers can be run on a dedicated computer,
which is also often referred to as the server, but many networked computers are
capable of hosting servers. In many cases, a computer can provide several services
and have several servers running. Servers often provide essential services across a
network, either to private users inside a large organization or to public users via
the Internet. Typical computing servers are database server, file server, mail server,
print server, web server, gaming server, application server, or some other kind of
server. Numerous systems use this client / server networking model including Web
sites and email services. An alternative model, peer-to-peer networking enables all
computers to act as either a server or client as needed.

3.3.5 Design and Implementation Constraints

The issues that will limit the options available to the developers are :

• Providing multiplayer games.

• The entire process of the project should be completed by April 2015.

Department of CSE, GEC Thrissur 9

CHAPTER 3. SOFTWARE REQUIREMENTS CS09-608(P) Mini Project, 2015

3.3.6 User Documentation

User manuals or online help will be provided for users to correctly login to the
system and getting it work properly. The user manual will describe the steps to be
followed for the proper working of the system .

3.4 Specific Requirements

3.4.1 External Interface Requirements
3.4.1.1 Hardware Interfaces
The hardware interface required for the user to retrieve the data from the server in
which the web portal is hosted mainly involves a server and a personal pc connected
through a network interface.

3.4.1.2 Software Interfaces

The complete user data is stored in the database and the information is accessed
by the user through a web browser enabled devices.

3.4.2 Functional Requirements

The function of the Online Game Hub is to provide an easy interface for gaming.
It will have the following phases: Manage users

• Users should register with their username and password to create an account

• Registered user can login to their account.

• Users will be notified with new messages from other users.

• Menus are provided gives easy way to access different games.

• User can chat with other players while gaming.

3.4.3 Behavioral Requirements

3.4.3.1 Use Case View
The service provided by the Online Game Hub is : First the request is send
from the user to the server which then process and retrieves the requested data from
the database.

Department of CSE, GEC Thrissur 10

CHAPTER 3. SOFTWARE REQUIREMENTS CS09-608(P) Mini Project, 2015

Figure 3.1: Usecase diagram

3.5 Non-functional Requirements

3.5.1 Performance Requirements
The main performance requirements that the product should satisfy are:
• Speed : Information retrieval from database should be as fast as possible.

• Load balance : The server should be able to handle reasonable number of users
without any issues.

3.5.2 Design Constraints

• GUI is only in English.

• Login and password is used for the identification of users.

• Only registered users have the ablity to play games.

• This system is working for single server.

Department of CSE, GEC Thrissur 11

CHAPTER 3. SOFTWARE REQUIREMENTS CS09-608(P) Mini Project, 2015

3.5.3 Software Quality Attributes

The most important quality requirements that the system should satisfy are :

3.5.3.1 Scalability
The system should have scalability property. That is this system can be modified
further without the hardcoding the PHP backend.

3.5.3.2 Reliability
The system should be reliable. It should perform the data management operation
efficiently.

3.5.3.3 Availability
System will be available around the clock except for the time required for back
up of data.

3.5.3.4 Maintainability
The system should be maintainable. Sometimes there may be bugs, it should be
easy to correct when it is reported.

3.5.3.5 Adaptability
The system should have the ability to adapt to the new release of web browsers
and new operating systems without any modification.

3.5.3.6 Testability
The Game Hub should be properly tested under various circumstances in order
to assure its reliability.

Department of CSE, GEC Thrissur 12

CS09-608(P) Mini Project, 2015

Chapter 4

Design

4.1 System Overview

The main software platform we have used in building this system includes PHP,
MySQL,Ajax,Javascript, Bootstrap Framework. PHP is most popular server side
scripting language used for suitable for building high-availability heavy-duty dy-
namic web sites, and capable of serving tens of thousands of requests simultaneously.
MySQL is a multithreaded, multi-user, SQL database management system that can
easily integrated with PHP. PHP and MySQL together constitute backend for the
Game Hub. User interface is designed using Bootstrap which is a web development
framework for building responsive sites that can be integrated to work easily in all
platforms.

4.1.1 User Perspective

Presently, there are lots of online gaming websites available. But multiplaying
options are not available for the games.Some of these websites are less interactive
to the user.There are lots of people they are stressed with their job complexity have
much pleasure and relaxation from these games.Chat system is included for users
interactions.
• The main stream users of the proposed system are the users who play games
for depression removing.
• Another important users of this system are those who play such games just for
fun

4.2 Data Flow Diagram

DFDs are used to represent the flow of data through different modules of the
system. An integrated Data Flow Diagram is used to represent the overall system.

Department of CSE, GEC Thrissur 13

CHAPTER 4. DESIGN CS09-608(P) Mini Project, 2015

Figure 4.1: Dataflow Diagram

4.3 Detailed Design

4.3.1 Use Case Diagram
A use case diagram at its simplest is a representation of a user’s interaction with
the system that shows the relationship between the user and the different use cases
in which the user is involved.

4.3.2 ER Diagram
A Sequence diagram is an interaction diagram that shows how processes operate
with one another and in what order. It is a construct of a message sequence chart. A
sequence diagram shows object interactions arranged in time sequence. It depicts the
objects and classes involved in the scenario and the sequence of messages exchanged
between the objects needed to carry out the functionality of the scenario. The
ER Diagram consists of mainly 3 entities :

• The USER entity consists of attributes like Id,Usename,Password and OnlineS-

tatus. Here Id is a primary key.This relation stores signup details.

• The DEVICE entity consists of attributes like Id,OS,Browser,MacId. Here Id

is the Primary Key.Stores the details about the person who logged in.

• The MESSAGE entity consists of attributes like MessageId,Sender,Receiver,Message,Date,Time,I

Stores the details about the message.Here MessageId is the Primary Key.

ER diagram for the proposed system is given below :

Department of CSE, GEC Thrissur 14

CHAPTER 4. DESIGN CS09-608(P) Mini Project, 2015

Figure 4.2: Usecase Diagram

4.4 Database Design

Database design is the process of producing a detailed data model of a database.
The design process consists mainly determining the purpose of database, finding and
organizing the information required, dividing the information into tables, turning
information items into columns, specifying primary keys, setting up the table rela-
tionships, refining your design and applying the normalization rules. After following
these steps, the finalized design of our database system is shown below :

Field Type Null Default

id int(10) Yes NULL
username varchar(30) Yes NULL
password varchar(36) Yes NULL

Table 4.1: Signup Table

Department of CSE, GEC Thrissur 15

CHAPTER 4. DESIGN CS09-608(P) Mini Project, 2015

Figure 4.3: ER Diagram

Department of CSE, GEC Thrissur 16

CHAPTER 4. DESIGN CS09-608(P) Mini Project, 2015

Field Type Null Default

id int(10) Yes NULL
OS varchar(20) Yes NULL
browser varchar(20) Yes NULL
macid varchar(20) Yes NULL

Table 4.2: Login Table

Field Type Null Default

messageid int(10) Yes NULL
sender int(10) Yes NULL
receiver int(10) Yes NULL
message varchar(100) Yes NULL
date date Yes NULL
time time Yes NULL
isread boolean No FALSE

Table 4.3: Message List

Department of CSE, GEC Thrissur 17

CS09-608(P) Mini Project, 2015

Chapter 5

Coding

5.1 Purpose
This project is aimed at developing a website for online gaming. The Online
Game Hub provides an easy interface that would let the users to the pool of gaming.It
consist of 6 games such as Bingo,Ludo,Dots,Vanish,Dots and memory game , and
a chat box to interact with other users while gaming. Multiplayer option is also
provided in Bingo, so that users can play this game in different computer systems.

5.2 Functional Template

Our project is mainly a web application composed of Javascript,CSS frontend
and PHP backend

• Registration:
The register process recieves usename and password of a particular user.
Steps:
1. Get the details from the user
2. Validate the user input.
3. Connect to database
4. If no username exist then insert details to database.
5. else registration failed
6. Close database connection .
$sql= SELECT FROM $tbl name WHERE username=$myusername and
passwor $result=mysql query ( $sql );
$count=mysql num rows( $result );
if ( $count==0)
{
if ($mypassword==$myconfirm)
{
$sql1= INSERT INTO signup VALUES ( , $myusername ,
$pass ) ; ;

Department of CSE, GEC Thrissur 18

CHAPTER 5. CODING CS09-608(P) Mini Project, 2015

mysql query ( $sql1 );

header ( location : . . / . . / index . html );
} else echo please confirm password ;
}
else {
echo Already exist ;
}

• Login:
This process contains a md5 based authentication for accessing the system.
The login uses a username and password combination for authentication.Then
user gets directed to the corresponding home page.
Steps:
1. Get the username and password from the user
2. Connect to database.
3. Retrieve username and password form database equal to the input item
4. If matches go to corresponding home page
5. else login failed
6. Close database connection .
$sql1= SELECT id FROM signup WHERE username=$myusername AND
$result1=mysql query ( $sql1 );
while ($row = mysql fetch array ( $result1 )) $id=$row [ id ] ;
$sql= SELECT FROM signup WHERE username=$myusername AND
password= $result=mysql query ( $sql ); $count=mysql num rows(
$result );
if ( $count==1)
{
$sql1= SELECT FROM login WHERE id=$id ; ;
$result1=mysql query ( $sql1 ); $count1=mysql num rows( $result1 );
if ( $count1==0)
{
$sql2= INSERT INTO login VALUES ( $id , $os ,
$browser , $ph [ 1 ] ) mysql query ( $sql2 );
}
$ SESSION[ user id ]= $id ;
header ( location : account .php?id=$id );
} else
{
header ( location : . . / . . / index . html );
}

• Send a Message:
A chat list of online friends are provided in the webpage.
Steps:

Department of CSE, GEC Thrissur 19

CHAPTER 5. CODING CS09-608(P) Mini Project, 2015

1. 1. Get message from the sender.

2. Connect to database
3. Insert details about the message are stired to the data base.
4. Update the webpage with notification of the message
5. Close database connection.
function sent message ( sender , receiver )
{ message=document . getElementById ( message + receiver ). value ;
if (message!= )
{
var xmlhttp = new XMLHttpRequest (); xmlhttp . onreadystatechange =
function ()
{
if (xmlhttp . readyState == 4 && xmlhttp . status == 200)
{ x = xmlhttp . responseText ;
}
}
xmlhttp . open( GET , ../ php/send .
php?user= +sender+ &rec= +rec xmlhttp . send ();
$( #msg success ). fadeIn (500);
setTimeout ( function ()
{
$( #msg success ). fadeOut (500);
} ,5000); document . getElementById ( message + receiver ).
value= ;
setTimeout ( function ()
{
var xmlhtp = new XMLHttpRequest ();
xmlhtp . onreadystatechange = function ()
{
if (xmlhtp . readyState == 4 && xmlhtp . status == 200)
{
y = xmlhtp . responseText ; document . getElementById ( msg box+
receiver ). innerHTML=
$( #msg box +receiver ). animate({ scrollTop : $(#msg bo
}
}
xmlhtp . open( GET , ../ php/sentmessage
.php?sender=+sender+ &r xmlhtp . send (); } ,1000);
} else
{
$( #msg error ). fadeIn (500);
setTimeout ( function ()
{
$( #msg error ). fadeOut (500);
} ,5000);
}

Department of CSE, GEC Thrissur 20

CHAPTER 5. CODING CS09-608(P) Mini Project, 2015

}
function rec message ( user )
{
var xmlhttp = new XMLHttpRequest ();
xmlhttp . onreadystatechange = function ()
{
if (xmlhttp . readyState == 4 && xmlhttp . status == 200)
{ xx = xmlhttp . responseText ;
if (xx>0)
{
var xmlhtp = new XMLHttpRequest ();
xmlhtp . onreadystatechange = function ()
{
if (xmlhtp . readyState == 4 && xmlhtp . status == 200)
{
yy = xmlhtp . responseText ; document . getElementById ( msg
receive ) . innerHTML=New $( #msg receive ). fadeIn (200);
}
} xmlhtp . open( GET , ../ php/sentmessage .php?sender=+xx+
xmlhtp . send ();
}
}
}
xmlhttp . open( GET , ../ php/ receive .php?user=+user , true
); xmlhttp . send ();
{
} / setTimeout ( function (){ rec message ( user )} ,5000);
} sentmessage . php
<?php mysqlconnect ( localhost , root , ) or die (
cannot connect ); mysql select db ( miniproject ) or die (
cannot select DB ); $i=$ REQUEST[ rec ] ;
$userid=$ REQUEST[ sender ] ; function decrypt ( $encrypted
string , $encryption key )
{
$iv size = mcrypt get iv size (MCRYPT BLOWFISH, MCRYP
$iv = mcrypt create iv ( $iv size , MCRYPTRAND); $decrypted string =
mcrypt decrypt (MCRYPT BLOWFISH, return $decrypted string ;
} define ( ENCRYPTION KEY , monkey );
$res= SELECT username from signup where id=$i ; ;
$us=mysql query ( $res );
while ($row = mysql fetch array ($us ))
$reciever=$row [ username ] ;
$resu = mysql query ( SELECT FROM message list WHERE ( s
while ($row = mysql fetch array ( $resu ))
{
if ($row [ sender ]== $i )
{

Department of CSE, GEC Thrissur 21

CHAPTER 5. CODING CS09-608(P) Mini Project, 2015

echo <div id= r cont ><div class = r msg > ;

$msg=$row [ message ] ; echo $decrypted = decrypt ($msg ,
ENCRYPTION KEY); echo </div>
<div class = r time > ;
echo $row [ time ] ;
echo </div></div > ;
}
if ($row [ sender ]==$userid )
{
echo <div id= s cont ><div class = s msg > ;
$msg1=$row [ message ] ; echo $decrypted = decrypt ($msg1 ,
ENCRYPTION KEY); echo </div>
<div class = s time > ;
echo $row [ time ] ;
echo </div></div > ;
}
}
?>

Department of CSE, GEC Thrissur 22

CS09-608(P) Mini Project, 2015

Chapter 6

Testing

6.1 Introduction
Testing is the process of evaluating a system or its component(s) with the intent
to find that whether it satisfies the specified requirements or not. Testing is executing
a system in order to identify any gaps, errors or missing requirements in contrary to
the actual desire or requirements.

6.2 Testing Methods

There are a number of software testing methods:
1. Unit testing: Unit testing focuses verification effort on the smallest unit of
the software design, the module. This is known as module testing. Since the
proposed system has modules, the testing is individually performed on each
module.
2. Integration testing : Data can be tested across an interface. One module
can have adverse effect on another sub function. When combined it may not
produce the desired function. Integration testing is a systematic technique for
constructing the program structure while at the same time conducting test to
uncover errors associated within the interface.
3. Validation testing: Validation testing can be defined in many ways, but a
simple definition is that validation succeeds when the software functions in
manner that is reasonably expected by the customer. Software validation is
achieved through a series of black box tests that demonstrate conformity with
requirements.
4. Output testing : After performing the validation testing, next step is output
testing of the proposed system, since no system could be useful if it does not
produce the required output in the specific format. The output generated or
displayed by the system under consideration is tested by asking the users about
the format required by them.

Department of CSE, GEC Thrissur 23

CHAPTER 6. TESTING CS09-608(P) Mini Project, 2015

5. Acceptance testing : User acceptance of the system is key factor for the success
of any system. The system under consideration is tested for user acceptance
by constantly keeping in touch with prospective system and user at the time
of developing and making changes whenever required.

6.3 Types of testing done

There are different methods which can be used for Software testing.

6.3.1 Whitebox testing

Whitebox testing (also known as clear box testing, glass box testing, trans- par-
ent box testing, and structural testing) tests internal structures or workings of a
program, as opposed to the functionality exposed to the end user. In whitebox test-
ing an internal perspective of the system, as well as programming skills, are used to
design test cases. The tester chooses inputs to exercise paths through the code and
determine the appropriate outputs. This is analogous to testing nodes in a circuit,
eg. InCircuit Testing (ICT).

While whitebox testing can be applied at the unit. Integration and system
levels of the software testing process, it is usually done at the unit level. It can test
paths within a unit, paths between units during integration, and between subsystems
during a system level test. Though this method of test design can uncover many er-
rors or problems, it might not detect unimplemented parts of the specification or
missing requirements.

Techniques used in whitebox testing include:

1. API testing (application programming interface) testing of the application us-
ing public and private APIs
2. Code coverage creating tests to satisfy some criteria of code coverage (e.g.,the
test designer can create tests to cause all statements in the program to be
executed at least once)
3. Fault injection methods intentionally introducing faults to gauge the efficiency
of testing strategies
4. Mutation testing methods
5. Static testing methods
Code coverage tools can evaluate the completeness of a test suite that was
created with any method, including black box testing. This allows the software
team to examine parts of a system that are rarely tested and ensures that the most
important function points have been tested. Code coverage as a software metric can
be reported as a percentage for:

Department of CSE, GEC Thrissur 24

CHAPTER 6. TESTING CS09-608(P) Mini Project, 2015

1. Function coverage, which reports on functions executed

2. Statement coverage, which reports on the number of lines executed to com-
plete the test 100 percent statement coverage ensures that all code paths, or
branches (in terms of control ow) are executed at least once. This is helpful
in ensuring correct functionality, but not sufficient since the same code may
process different inputs correctly or incorrectly

6.3.2 Blackbox testing

Blackbox testing treats the software as a ”black box”, examining functionality
without any knowledge of internal implementation. The tester is only aware of what
the software is supposed to do, not how it does it. Blackbox testing methods include:
equivalence partitioning, boundary value analysis, all pairs testing, state transition
tables, decision table testing, fuzz testing, model based testing, use case testing, ex-
ploratory testing and specification based testing.

Specification based testing aims to test the functionality of software accord-

ing to the applicable requirements. This level of testing usually requires thorough
test cases to be provided to the tester, who then can simply verify that for a given
input, the output value (or behaviour), either is or is not the same as the expected
value specified in the test case. Test cases are built around specifications and require-
ments, i.e., what the application is supposed to do. It uses external descriptions of
the software, including specifications, requirements, and designs to derive test cases.
These tests can be functional or nonfunctional, though usually functional.

Specification based testing may be necessary to assure correct functionality,

but it is insufficient to guard against complex or highrisk situations.

One advantage of the black box technique is that no programming knowledge

is required. Whatever biases the programmers may have had, the tester likely has a
different set and may emphasise different areas of functionality. On the other hand,
blackbox testing has been said to be like a walk in a dark labyrinth without a ash
light. Because they do not examine the source code, there are situations when a
tester writes many test cases to check something that could have been tested by only
one test case, or leaves some parts of the program untested.

The technique of testing without having any knowledge of the interior work-
ings of the application is Black Box testing. The tester is oblivious to the system
architecture and does not have access to the source code. Typically, when performing
a black box test, a tester will interact with the system’s user interface by providing
inputs and examining outputs without knowing how and where the inputs are worked
upon. After the completion of the implementation, we turned to Black Box testing.
We hosted a demo version of the web application for extensive testing. We seeked
the help of our classmates for the purpose of ensuring data-integrity and security.

Department of CSE, GEC Thrissur 25

CHAPTER 6. TESTING CS09-608(P) Mini Project, 2015

Sl Modules Expected Output Whether

No obtained
the ex-
pected
output or
not
1 User registration Users can successfully register Yes
2 Users login Users can successfully logging into the Yes
system
3 Gaming Users can play games without any bugs Yes
4 Messaging Messages can successfully send and re- Yes
ceive

Table 6.1: Blackbox Testing

6.4 Advantages and Limitations

6.4.1 White Box Testing
6.4.1.1 Advantages
• As the tester has knowledge of the source code, it becomes very easy to find
out which type of data can help in testing the application effectively

• It helps in optimizing the code.

• Extra lines of code can be removed which can bring in hidden defects.

• Due to the tester’s knowledge about the code, maximum coverage is attained
during test scenario writing.

6.4.1.2 Disadvantages
• Due to the fact that a skilled tester is needed to perform white box testing, the
costs are increased.

• Sometimes it is impossible to look into every nook and corner to find out hidden
errors that may create problems as many paths will go untested.

• It is difficult to maintain white box testing as the use of specialized tools like
code analyzers and debugging tools are required.

6.4.2 Black Box Testing

6.4.2.1 Advantages
• Well suited and efficient for large code segments.

Department of CSE, GEC Thrissur 26

CHAPTER 6. TESTING CS09-608(P) Mini Project, 2015

• Code Access not required.

• Clearly separates user’s perspective from the developer’s perspective through

visibly defined roles.

• Large numbers of moderately skilled testers can test the application with no
knowledge of implementation, programming language or operating systems.

6.4.2.2 Disadvantages
• Limited Coverage since only a selected number of test scenarios are actually
performed.

• Inefficient testing, due to the fact that the tester only has limited knowledge
about an application.

• Blind Coverage, since the tester cannot target specific code segments or error
prone areas.

• The test cases are difficult to design.

6.5 Future Extensions if possible

• More games with multiplaying option.

• Group messaging system.

Department of CSE, GEC Thrissur 27

CS09-608(P) Mini Project, 2015

Chapter 7

Software Quality Assurance

7.1 Introduction
Software quality assurance (SQA) consists of a means of monitoring the soft-
ware engineering processes and methods used to ensure quality. SQA en-compasses
the entire software development process, which includes processes such as require-
ments definition, software design, coding, source code control, code reviews, change
management, configuration management, testing, release management and product
integration. SQA is organized into goals, commitments, abilities, activities, measure-
ments, and verifications.

7.1.1 Purpose
The system is meant to give more easiness to the users that they can easily
addicted to the games. We provide multiplayer options for games.A chat box is
also provide to interact with other players while gaming. And the interface for the
users is quite entertaining and engaging.Menus are interactive and easy accessible
throughout the game.Once the game is in playing mode,everything a player needs
will be clearly visible on the screen and easily accessible.

7.1.2 Scope
Every member in our team is responsible for the actions planned in this document
such as documenting the results throughout the development of the project, reviewing
the project progress, and testing the project quality, controlled by this plan. The
following are the portions of the software lifecycle that are covered by the SQAP:
User requirements, Software requirements, Design, Implementation and Testing.
The Software Quality Assurance Plan covers the software items. In addition, the
SQAP is also covered by this quality assurance plan. The list of software items
to be covered in each of the above mentioned life cycle phases are given below:

Department of CSE, GEC Thrissur 28

CHAPTER 7. SOFTWARE QUALITY ASSURANCE
CS09-608(P) Mini Project, 2015

Software Lifecycle Phase Software Item

User requirements User requirement document
Software requirement Software Requirement Specification document
Design Software Design Document
Implementation Document including template of functions
Testing Document showing testing done in project with summary results

Table 7.1: List of Software Items

7.1.3 Project Overview

7.1.3.1 Background and Context
The aim of the project is to create an Online Game Hub for gaming.It is also
provided with a chat box to interact with other users.

7.1.3.2 Project Objectives

Through this project our aim is to provide an interface for gaming.It provides
the users more pleasure and gladdening his mind by playing these traditional games.

7.2 Quality Assurance Strategy

To assure quality of software deliverable in each software development phase, we
will use the test factor/test phase matrix. The matrix has two elements. Those are
the test factor and the test phase. The risks coming from software development and
the process for reducing the risks should be addressed by using this strategy. The
test factor is that the risk or issue which is needed to be tackled, and the test phase is
that the phase of software development which conducts the test. The matrix should
be customized and developed for each project. Thus, we will adapt the strategy to
our project through four steps.
In the first step, we will select the test factors and rank them. The selected test
factors such as reliability, maintainability, portability or etc, will be placed in the
matrix according to their ranks.
The second step is for identifying the phases of the development process. This
phase should be recorded in the matrix. The last step is that deciding the test phase
of addressing the risks. In this step, we will decide that which risks will be placed at
each development phase.
The matrix forms a part of the quality assurance strategy and as mentioned
above this matrix would be used in each of the project lifecycle phases to identify
the risks associated in each of the phases with respect to the testing factors. The
risks would also be accompanied with their mitigation strategies and in case the risk
materialised into a problem, the respective mitigation would be applied. It is for
these reasons, that a mention is made about the matrix here in a separate section of

Department of CSE, GEC Thrissur 29

CHAPTER 7. SOFTWARE QUALITY ASSURANCE
CS09-608(P) Mini Project, 2015

the document and not mixed with other sections of the document to avoid repetition.

Testphase/Test Requirements Design Coding Testing fac-

tors
Correctness Risk: The SRS Risk: Software Risk: For Risk : User may
may not be design document lengthy code not give the cor-
correct as per may not be cor- functions de- rect input
the goals of the rect as per the fined in software
SQAP Strategy SRS Strategy design document
: Formal Tech- : Formal Tech- yearn more for
view of SRS view of SRS code correctness
Performance Risk: User may Risk: Software Risk: Lack Risk : May
have to compro- design document of syntactic have several
mise. may not have structures in se- input cases
the performance lected language which affect the
as per the re- selected. performance.
quirement
Continuity of Risk: Un- Risk: Improper Risk: Possibil- Risk: Possibil-
processing satisfiable way of designing ity of error oc- ity of error oc-
requirements. requirements currences currences

Table 7.2: Quality Assurance Strategy

Department of CSE, GEC Thrissur 30

CHAPTER 7. SOFTWARE QUALITY ASSURANCE
CS09-608(P) Mini Project, 2015

7.3 Audits and Reviews

7.3.1 Work Product Reviews

Work Product When re- How reviewed by Quality Assurance

viewed by
Quality As-
surance
Software requirement After a new re- All the requirements raised by the user are
specification lease achieved.
Software document After modica- Web application developed in PHP and
design tion MySQL.
Coding New release All algorithm and designs coded and imple-
mented perfectly.
Testing New release The product is subjected to both blackbox
testing and white box testing. All user re-
quirements are met.

Table 7.3: Work Product Review

7.4 Further Extension

We have completed our project in all aspects. All functional and non-functional
requirements of all four modules are met. The product is easily usable and user
documentation for all the modules is provided. The system can be extended by
adding more features. The project has gone successfully through all the phases of
software development and has been tested per the requirements.
Further Extensions include :

• More games with multiplayer option.

• Group messaging system.

• Advanced notification system.

Department of CSE, GEC Thrissur 31

CS09-608(P) Mini Project, 2015

Chapter 8

Conclusion

The project has been completed successfully as specified by the requirements.

The implementation and testing has been done in a step-by-step manner. Each
module has been developed and tested individually to obtain the required output
in the desired form. On our way working on this interesting project, we learned
many things.While working on this project, we got valuable experience on the stages
involved while developing any web application that could be useful while working for
a professional company. During the duration of this project we learned the following
things through the implementation and testing of the project:

• PHP server scripting

• MySQL database management.

• Javascript,Jquery, CSS

• Bootstrap for UI/UX.

• Ajax for UI/UX.

The future improvements can be made in certain areas of the project. There is
scope for extending the project to incorporate more features by including more games
with muktiplayer option,Advanced messaging system with notification,etc. The pro-
cess model selected is agile model. So that the new options can be implemented
to the same design in later point of time. The updation of the application is an
important feature of agile process model designs.

Department of CSE, GEC Thrissur 32

CS09-608(P) Mini Project, 2015

Bibliography

[1] Fundamental of Database Systems,Elmasri and Navathe

[2] Ian Sommerville., Software Engineering, 9th Ed, June 2010.

[3] www.w3schools.com/PHP/

[4] www.stackoverflow.com

[5] www.php.net

[6] www.jquery.com/

Department of CSE, GEC Thrissur 33

CS09-608(P) Mini Project, 2015

Appendices

Department of CSE, GEC Thrissur 34

CS09-608(P) Mini Project, 2015

Appendix A

User Document

A.1 Login Page

Figure A.1: Login

This is the login page for the users.New users can register to the system and login
to his account.And Existing users can logging into the system.

Department of CSE, GEC Thrissur 35

APPENDIX A. USER DOCUMENT CS09-608(P) Mini Project, 2015

A.2 Home Page

Figure A.2: Interface

Through this page users can play different games. This page is also provided with
a chat box, through which users can interact with other users.

A.3 Puzzle Gaming

Figure A.3: Puzzle gaming

This is the interface while Puzzle playing.User can interact with other friends
while playing.

Department of CSE, GEC Thrissur 36

APPENDIX A. USER DOCUMENT CS09-608(P) Mini Project, 2015

A.4 Vanish Gaming

Figure A.4: Vanish gaming

This is the interface while Vanish playing.User can interact with other friends
while playing.

A.5 Ludo Gaming

Figure A.5: Ludo gaming

This is the interface while Ludo playing.User can interact with other friends while
playing.

Department of CSE, GEC Thrissur 37

APPENDIX A. USER DOCUMENT CS09-608(P) Mini Project, 2015

A.6 Bingo Gaming

Figure A.6: Bingo gaming

This is the interface while Bingo playing.User can interact with other friends
while playing.

A.7 Dots Gaming

Figure A.7: Dots gaming

This is the interface while Dots playing.User can interact with other friends while
playing.

Department of CSE, GEC Thrissur 38

APPENDIX A. USER DOCUMENT CS09-608(P) Mini Project, 2015

A.8 Memory Gaming

Figure A.8: Memory gaming

This is the interface while Memory game playing.User can interact with other
friends while playing.

Department of CSE, GEC Thrissur 39

View publication stats