Abstract

Normally games require little bit high space for playing games but this game is light that it
can be install in each and every handheld device with normal space. It does not require any
additional memory or space as it is small enough that any android phone be able to play this
game. Ludo is a board game it will be play by two to four players. At the beginning of the
game, each player's tokens are out of play and staged in one of the large corner areas of the
board in the player's color (called the player's yard). When able to, the players will enter their
tokens one per time on their respective starting squares, and proceed to race them clockwise
around the board along the game track (the path of squares not part of any player's home
column). When reaching the square below his home column, a player continues by racing
tokens up the column to the finishing square. The rolls of a cube die control the swiftness of
the tokens, and entry to the finishing square requires a precise roll from the player. The first
to bring all their tokens to the finish wins the game. The others often continue play to
determine second-, third-, and fourth-place finishers.
 Table of Contents

CHAPTER 1: INTRODUCTION………………………………………….01

1.1 Project Overview………………………………………………………………….04

1.2 Project Scope……………………………………………………………………...04
1.3 Proposed Solution …………………………..
…………………………………….04
1.4 Main feature Of The Proposed Solution…………………..………………………05
1.5 Introduction To Tools & Technology Used……………………………………....06

CHAPTER 2: REQUIREMENT ANALSIS………………………………...07

2.1 Software Requirement Specification (SRS)….…….............…………………..07

2.1.1 Introduction…...………..…………………………………………...07

2.2 Requirement Specification…………………………………………………….07

2.2.1 Functional Requirement……………………………………………...07

2.2.2 External Interface Requirement……………………………………..08

2.2.3 Performance Requirement…………………………………………...09

2.2.4 Response Time……………………………………………………….09

2.3 General Constraints……………………………………………………….........09

2.3.1 Hardware Requirement ……………………………………………..09

2.3.2 Software Requirements…………………………………..………….09

2.3.3 Performance………………………………………………………..09

2.3.4 Scalability…………………………………………………..............09

2.3.5 Reliability…………………………………………………………..09

2.4 Project Objective…………………………………………………..……………. ..09

2.5 Selected Use Cases………………………………………………………………..10

CHAPTER 3: SOFTWARE DESIGN……………………………………..13

3.1 Use Case Diagram………………………………………….………………………13

3.2 Activity Diagrams………………………………………….………………………14

3.2.1 New Game…….…………………………………………...………………...15

3.2.2 Choose Game………………...…………………..……..……………………16

3.2.3 Sound ON/OFF…………………….…………………..……………………17

3.2.4 Exit Game…………………………….…………………..………………….18

3.3 Sequence Diagram……………………………………………….…………………19

3.5 Collaboration Diagram…………………………………………….……………….20

3.6 Deployment Diagram…………………………...………………….………………21

3.7 Class Diagram……………………………………..……………….………………22

CHAPTER 4: Project Management

4.1 Milestones ………………………………………………………………..23

4.2 Project closeout report ………………………………………………..24

4.2.1 Project deliverables ………………………………………………………..24

4.2.2 Operation and Maintenance ………………………………………………..24

4.2.3 Project Resources. ………………………………………………………..25

4.3 Risk Response Summery ………………………………………………..26

 Chapter 1

Introduction
1.1 Project Overview

Two, three, or four may play. At the beginning of the game, each player's
tokens are out of play and staged in one of the large corner areas of the board in the player's
color (called the player's yard). When able to, the players will enter their tokens one per time
on their respective starting squares, and proceed to race them clockwise around the board
along the game track (the path of squares not part of any player's home column). When
reaching the square below his home column, a player continues by racing tokens up the
column to the finishing square. The rolls of a cube die control the swiftness of the tokens, and
entry to the finishing square requires a precise roll from the player. The first to bring all their
tokens to the finish wins the game. The others often continue play to determine second-,
third-, and fourth-place finisher.

1.2 Project Scope

The scope of our application will be limited to the functional design of the original Ludo,
along with our own selection of additions and modifications to the same. It will support
saving and loading the states of games in progress, and also the ability to save or abandon a
game in progress.

1.3 Proposed Solution

In this project we are intended to make the player

Player shall be able to:

• Be able to set options

• turn game music on or off

• turn game sound effects on or off

 Chapter 1

• Start a game of Ludo select whether it should be a multiplayer or single player game

• select how many human players and computers to play against

• If multiplayer is selected. Select color and name.

• Do a turn. During his/her turn, a player may:

Roll a dice. Move his/her pieces,

◦ depending on the rules do battle with another player, if they have pieces in the same spot of
the playing field. The battle consists of solving a mathematical problem. Whichever player
solves it fastest will be able to push the other player’s piece to another place on the playing
field.

• Load/save a game in progress: if a game is saved, make a copy of the current State of the
game. If a game is loaded, set its State to the target loaded State.

• Exit/forfeit a game in progress if there are no other human players in the game, quit the
application and lose all unsaved state. If there are other human players, the game will not
close for them.

1.4 Main Feature of Proposed Solution

A player shall be able to:

• Be able to set options

• turn game music on or off

• turn game sound effects on or off

• Start a game of Ludo select whether it should be a multiplayer or single player game

• select how many human players and computers to play against (4 in all),

• If multiplayer is selected. Select color and name.

 Chapter 1

• Do a turn. During his/her turn, a player may:

◦ roll a dice. Move his/her pieces,

1.5 Tools and Technology

Tools:

1. Android development tool(ADT)

 Android Studio
 XML
 Java Development tool kit (JDK)
 SDK 7.0
 UML
2. MS Office
3. MS paint
4. 9 Patch resizer

Technologies

i. Touch Screen Control

 Chapter 2

Requirement Analysis
Software Requirement specification

Introduction

Ludo (from Latin ludo, "I play") is a simple board game, for two to four players, in which the
players race their four coins from start to finish according to dice rolls. Ludo is a board game
for two to four players, in which the players race their four tokens from start to finish
according to die rolls. Like other cross and circle games, Ludo is derived from the Indian
game Pachisi, but simpler. The game and its variants are popular in many countries and under
various names.

2.1 Purpose

The purpose of this application is to provide the indoor game service .The user can install
this amazing application on his/her smart phone and can get all feature of this application.
It contain two to four player .this game is played by adults and children’s as well. it is also
known as board game .The benefit of board game for kids? Some are obvious .kids enjoy
them and board games are opportunities for families to play together. In addition social
scientist has argued games teach lesson about getting along with others. Board game can
teach the important social skills.

For example Games may encourage kids to

 Consider the concept of rule

 Practice of rules
 Reason about moral problem

2.2 Requirement Specifications

Purpose of this section: Technical information needed to design the software

2.2.1 Functional Requirements

These are the functional requirements of our application.

Chapter 2

A player shall be able to:

• Be able to set options

• turn game music on or off

• turn game sound effects on or off

• Start a game of Ludo select whether it should be a multiplayer or single player game

• select how many human players and computers to play against (4 in all),

• If multiplayer is selected. Select color and name.

• Do a turn. During his/her turn, a player may:

◦ roll a dice. Move his/her pieces,

◦ depending on the rules do battle with another player, if they have pieces in the same spot of
the playing field. The battle consists of solving a mathematical problem. Whichever player
solves it fastest will be able to push the other player’s piece to another place on the playing
field.

• Load/save a game in progress:

If a game is saved, make a copy of the current State of the game. if a game is loaded, set its
State to the target loaded State.

• Exit/forfeit a game in progress if there are no other human players in the game, quit the
application and lose all unsaved state. If there are other human players, the game will not
close for them.

• Chat with other human players during a network game there will be a separate window
where players can exchange messages.

2.2.2 External Interface Requirements

 System communication
  Internet connection
Chapter 2

 Smart phone
 Bluetooth
 Design

2.2.3 Performance Requirements

Response time
There will not be a delay greater than 3 seconds between a user initiating an action,
and the system performing it.

2.3 General Constraints

Hardware Requirements

The game is lights enough so it can be played on all android platforms.

Software Requirement’s

i. Performance
Game running on mobile should have maximum throughput and maximum utilization.
ii. Scalability
As this game is for android mobiles so it is scalable with android OS platform.
iii. Reliability
As this game is for android mobiles so it is reliable with android OS platform.

2.4 Project Objective

According to our specifications, a successful implementation of Ludo will allow its user to do
all of the following:

• Start a game

• choose between different options

• turn off/on sound

 Chapter 2

• Roll a die

• Battle with a foe (combined with a mathematical problem)

• move a piece, surrender

• show help menu

• Set number of players

• Exit

• show high-score list

• Show time

In summary, our overall criteria are to have a fully functioning Ludo game in terms of core
functionality, extended by our own features.

2.5 selected use cases

Use Case Start Game

Actor: User

Pre-condition:

Use went to main Manu for choosing the game for start

Post condition:

The game will be started.

Description

The user opens the main menu and chooses the number of player then click on the start
button the game will turn on.
 Chapter 2

Use case: Sound On/Of

Actor: User

The User is able to do sound ON/OFF during playing game.

Pre-condition:

Click on the sound button for making ON/OFF.

Post condition

After clicking the button sound ON/OFF sound will be on or off

Description

All players can switch the sound speaker ON or OFF

Use case: Choose Color

Actor User

User will be able to choose color to his/her own decision.

Pre-condition

User will choose color from color list

Post condition

Color will assign to the user which color is chosen by user

Description

When user click on choose color the color will assign to the user.
 Chapter 2

Use case: Exit Game

The player is able to terminate the application

Pre-condition

The player click on exit option

Actor: Player

Post condition

The game will terminate

Description

When the player click on the exit button after clicking the exit button the message is
displayed do you want to save the game click on yes or no then the game will be terminated.
 Chapter 3

Software Design
3.1 Use Case Diagram

System

Start Game

Chose Color

User

Sound ON/OFF

Exit Game

Fig 3.1 Use Case Diagram

 Chapter 3

Activity Diagram

Start game

start game

No

Yes

game will start

Fig 3.2 Start Game

 Chapter 3

Activity Diagram

Choose Color

Select color

No

Yes

continue game

Fig 3.4 Choose Color

 Chapter 3

Activity Diagram

Sound ON/OFF

sound

mute/unmute No

Yes

Fig 3.4 Sound ON/OFF

 Chapter 3

Activity Diagram

Exit Game

Game

Exit No

Yes

Fig 3.4 Exit Game

 Chapter 3

3.3 Sequence Diagram

User

User
Game Manue Choose color Play Game Win/Loss

1 : Option to start new game()

2 : Chose color()

3 : Play game()
4 : Win or Loss()

Fig 3.5 Sequence Diagram

 Chapter 3

3.4 Collaboration Diagram

User

New game Select Color

Game manue Choose Color Play Game

Play game
Home Menu

Win/Loss

Fig 3.6 Collaboration Diagram

 Chapter 3

3.5 Deployment Diagram

user 1

user 4
LAN

User 2 user 3

Fig 3.7 Deployment Diagram

 Chapter 3

3.6 Class Diagram

LUDO MODEL
+Board
+List_Player
View Player
+CanMovePice()
+LudoModel +EndGame() +Color
+Controler +MovePice() +SetPiceStatus()
+NextPlayerTurn() +SetPiceNumber()
+StartGame() +RollDie()
+EndGame() +GetPiceNumber()
+StartGame() +SetColor()
+InilizBoard()
+RollDie()

Board
+Squre<list> Die
Action
+Pices<list>
+DieValue
+Nthing
+SetColor()
+RollDie +RollDie()
+SetWon()
+MovePice
+GetColor()
+EndGame
+GetWon()

Piece Square
+Color +Piece
+GetWon
+AddPiece()
+SetColor() +RemovePece()
+SetWon() +SetColor()
+GetColor() +SetGoal()
+GetWon() +SetHouse()

Fig 3.8 Class diagram

 Chapter #4

Project Management

Milestones

 To explain the main the task under taken by super visor.

 To make sure that project is compiled in time.
 To make sure that the project is within scope or boundaries.

4.1 Milestones

As we have been no mandatory deadlines for deliverable during the master thesis work. We
will present the work conducted at the end of each week to the supervisor. These may come
up with suggestions and directions to guide us in the further work.

Project Milestones
Project start
Project GUI
Project Defender
Documentation of 3rd chapter
50% development and documentation evaluation
Complete working web system
Integration of payment method
Complete documentation and testing
Deploy Solution
Project complete
Table 4.1 Project Milestones

4.2 Project closeout report

4.2.1 Project deliverables:

List all project deliverables and the date each was accepted by the user, identify any
contingencies or condition related to the acceptance.

Deliverable Date Accepted Contingencies or condition

Proposal Defender Should Be On Time
Documentation of 3rd chapter Should Be On Time
Mid Presentation Should Be On Time
Complete documentation Should Be On Time
Complete game Should Be On Time
Table 4.2 Project deliverables

4.2.2 Operation and Maintenance

 Operation and maintenance which are that
 Play game
 Management of user options
 Management of GUI
 All the maintenance will be handled from developer side using Android.

4.2.3 Project Resources.

Person Or
Resources Organization who Turnover Date
Received Resource
Describe or name the resources used
1.1.1.1.1 Project team
K H Sajjad Ahmad AAUR-UIIT
 Muhammad Saad Zahoor AAUR-UIIT
Muhammad Hamza AAUR-UIIT
1.1.1.1.2 Facilities
Internet access
Reversed lab for project
Documentation of previous projects
in Library
1.1.1.1.3 Equipment
Intel(R)Core i3 KH Sajjad Ahmad
Intel(R)Core i5 Muhammad Saad
1.1.1.1.4 Software Tools
ADT
Android Studio
Microsoft office 2007
JDK
Resize
1.1.1.1.5 Other
Support of Supervisor Project Team
Support of Examiners Project Team
Table 4.2.3 Project Resources

4.3 Risk Response Summery

Prioritize and describe the plans for responding to each risk identified and evaluated.

Risk Risk Risk Name Responsible Mitigation Action(s)

Priority Number Person
4 1 GUI Model Sajjad Check out whether the GUI is
working or not
4 2 Sound Module Saad Check out whether all the sound
are working properly or not
3 3 Logical Module Team Check out whether all the logic of
game are working properly or not
3 4 Bugs Team Ensure that game is free from any
kind of bug.
2 5 Human error while Hamza To avoid this risk we will provide
using system then training
2 6 Performance Team Ensure the best performance of
 game
1 7 Technical risk Team To ensure that there would be no
technical risk part of game
Table 4.3 Risk Response Summery