CSE - 2020 - 27 - Android Dice Roller App

VISVESVARAYA TECHNOLOGICAL UNIVERSITY
“JNANA SANGAMA”, BELGAUM - 590018
2020-21
MOBILE APPLICATION DEVELOPMENT[18CSMP68]
Mini Project Report
On
ANDROID DICE ROLLER APP

SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENT IN 6TH SEMESTER
MOBILE APPLICATION DEVELOPMENT PROJECT WORK (18CSMP68) OF BACHELOR OF ENGINEERING
IN
By
JAYANTH P B 4VM18CS020
SUGAM BK 4VM18CS039
UNDER THE GUIDANCE OF
Mr. SAGAR B
Assistant Professor
Dept. of CSE, VVIET
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VIDYA VIKAS INSTITUTE OF ENGINEERING & TECHNOLOGY
#127-128, Mysore - Bannur Road, Alanahally, Mysuru, Karnataka 570028
Vidya Vikas Educational Trust ®
VIDYA VIKAS INSTITUTE OF ENGINEERING &
TECHNOLOGY
#127-128, Mysore - Bannur Road, Alanahally, Mysuru, Karnataka 570028
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CERTIFICATE
Certified that the MAD Mini Project Work entitled “ANDROID DICE ROLLER APP ”
carried out by JAYANTH PB [4VM18CS020] and SUGAM BK [4VM18CS039], bonafide
students of VVIET in partial fulfillment for the award of degree Bachelor of Engineering in
COMPUTER SCIENCE and ENGINEERING as prescribed by VISVESVARAYA
TECHNOLOGICAL UNIVERSITY, BELGAUM during the academic year 2020-21. It is
certified that all corrections/suggestions indicated for internal assessment have been
incorporated in the report deposited in the departmental library. The project report has
been approved as it satisfies the academic requirements in respect of mini project work
prescribed for the said degree.
[Mr. SAGAR B] [Dr. MADHU B K]

Assistant Professor Professor & HOD
Dept. of CSE Dept. of CSE
EXTERNAL VIVA
Name of the examiners Signature with date
1.
2.
Android Dice Roller App
ACKNOWLEDGEMENT
We would like to thank and express our heartfelt gratitude to God almighty for the
abundant blessings without which this project would not have been successful.
We would like to express our sincere gratitude to Sri. Vasu, Chairman of VVIET,
Mr. Kaveesh Gowda V, Secretary of VVIET and all management members of VVIET, for their
constant support.
We acknowledge and express our sincere thanks to our beloved Principal
Dr. Ravishankar M, VVIET, Mysuru who is the source of inspiration.
We would like to express our deepest sense of gratitude towards Dr. Madhu B K,
Head of the Department, CSE, VVIET, Mysuru for his valuable suggestions, support and
encouragement.
We would like to extend our heartfelt gratitude to Mr. Theja N, Assistant Professor,
Dept. of CSE, for the valuable guidance and advice. We would also like to thank him for his
guidance and useful suggestions, which helped us in completing the project work on time.
We would also thank all other teaching and non-teaching staffs of the Computer
Science Department who has directly or indirectly helped us in completion of this project.
Our thanks and appreciation also go to our family and friends who have willingly
helped us out with their abilities.
Regards,
Jayanth P B
Sugam B K
ABSTRACT
Dice are used in many games, and often in fairly complex ways that make it
difficult to unambiguously describe the dice-roll mechanism in plain language.
Many role-playing games, such as Dungeons & Dragons, use a formalised notation
for some instances of dice-rolls. This notation, once explained, make dice-roll
descriptions concise and unambiguous. Furthermore, the notation has been used in
automated tools for pseudo-random dice-rolling (typically used when playing over
the Internet). This notation is, however, fairly limited in the types of dice-rolls it
can describe, so most games still use natural language to describe rolls. Even
Dungeons & Dragons use formal notation only for some of the dice-roll methods
used in the game. Hence, a more complete notation is in this paper proposed, and a
tool for pseudo-random rolls and (nearly) exact probability calculations is
described. The notation is called "Troll", combining the initial of the Danish word
for dice ("terninger") with the English word "roll". It is a development of the
language Roll described in an earlier paper. The present paper describes the most
important features of Troll and its implementation.
TABLE OF CONTENTS
Acknowledgement
Abstract
Table of contents
List of Figures
1. Introduction 1-2
1.1 Aim 3
1.2 Problem statement 3
1.3 Motivation 3
1.4 Application 3
1.5 Advantages 3-4
1.6 Tools and Technology 4
2. Literature Survey 5
2.1 Related work 5
3. System Analysis 6-11
3.1 Hardware Requirements 6
3.2 Software Requirements 7
3.3 Existing Systems 7
3.4 Proposed System 8
3.5 Feasibility Study 9
3.6 Functional and non-functional requirements 10
4. Design and Analysis 12-18
4.1 System Design 18
4.1.1 Product Perspective 14
4.1.2 Design Process 15

4.1.3 Design stratergies 15
4.2 System Architecture 16-18
5. Implementation 19-25
5.1 Source codes 21-24
5.1.1 Android Mainfest.XML 21
5.1.2 Main Activity .JAVA 22-24
5.1.2.1 New code to initialize sound playback 23-24
5.1.3 Snapshots 25
6. System Testing 26-30
6.1 What is Verification and Validation? 26
6.2 Key Benefits of Testing 26
6.3 Basics of Testing 26-27
6.4 Types of Testing 27-28
6.5 Manual and Automation Testing 28-29
6.6 Test Cases 29
Conclusion 31
Future Enhancement 32
References 31-33
LIST OF FIGURES
Fig no Fig description Page no
3.4.1 Block diagram 8
4.1.1.1 Flow diagram of system 14
4.2.1 Architectural flow Diagram 16
5 Dice pictures used in games 19

CHAPTER 1
INTRODUCTION
A dice is typically a small, throwable object that has multiple faces (most commonly six)
and possible positions that indicate a number (or something else), used for generating random
numbers and events. They are typically used for tabletop games, which includes a wide variety of
games, as well as for gambling. Examples of tabletop games that involve the use of dice include
games like backgammon, Boggle, and Yahtzee, where dice are a central component of the game.
Some other well-known tabletop games include Monopoly, Risk, Dungeons and Dragons, and
Settlers of Catan. There are however, numerous others.
Dice shapes
The most commonly used dice shapes are listed below.
Tetrahedron: 4 faces – the blue die
Cube: 6 faces – the orange, cubic die
Octahedron: 8 faces – the green die
Pentagonal trapezohedron: 10 faces – the orange, non-cubic die
Dodecahedron: 12 faces – the yellow die
Icosahedron: 20 faces – the purple die
Although the image shows some of the more common die shapes, there are many other
polyhedral dice, or dice of other shapes. There are also non-numeric dice, dice that do not follow
a counting sequence that begins at one, and spherical dice.
Virtual dice, like the one above, are almost always based on pseudo-random number
generating algorithms, which are also not truly random. However, a virtual dice roll is likely
more close to true randomness than most physical dice.
They may be used to produce results other than one through six. Loaded and crooked
dice are designed to favor some results over others for purpose of cheating or amusement a dice
tray ,a tray used to contain thrown dice, is sometimes used for gambling or board games.
Today game industry produces many different kinds of multimedia controllers that allow
player to manage game process and naturally interact with media: joysticks, key-boards, remote
controllers, VR helmets etc. This paper aims to show the new possibilities of using analog
random number generator, so-called gambling die used in non-gambling tabletop games.
Nowadays, all the digital tabletop games use digital random generator to simulate the die. We
DEPT OF CSE,VVIET 2020-21 PAGE 1

suggest to use normal 6-side plastic die equipped with several sensors for state classification and
game control. Using of real model will make the game process more interactive and also can
decrease the eyestrain. It assumed to use different dice with different physical parameters for
every player to provide full compatibility with different dice manufacturers including custom-
made dice. Dice recognition techniques have been researched before by several authors most
solutions are based on using the camera and pattern recognition algorithm sand, according to
author’s knowledge, inertial sensors were not yet considered. From the practical point of view
using the camera imposes restrictions on the minimum size of die, area lighting and requires
additional action from user since the camera vision angle is quite limited and resolution
properties are limited too, so playable area is restricted by camera properties. In authors show
that different colors of dice can also affect on accuracy of detection; during experiments they
found that dice that are less contrast are less amenable to recognition by 2% comparing with
more contrast dice. From recognition point of view, method described in this article is more
beneficial since it guarantees100% recognition rate on flat surface. Our initial idea consist of
taking the attitude measurements using accelerometers and gyroscopes and send the result via
existing transmission media to a game device(mobile phone, TV, etc.). The size of modern
MEMS(Microelectromechanical systems) sensors allows top lace it in the die of any shape and
size. In this paper we propose to use IMU(Inertial Measurement Unit) that includes both types of
sensor and able to communicate with other devices. The most important problem in this case is
presented by bias of the die that will affect on game result during the long-term period. By
default, every die can be considered as loaded die due to its physical imperfection. Only the ideal
physical model of die with equal result probability can be considered to be totally unbiased, in
another case any die has some physical issues that provides higher probability for one of the
sides. Moreover, using of intentionally loaded die, which can be considered as cheating, is also
possible during the game process. To prevent cheating and equalize the results in general we
propose to use the algorithm that allows to generate fair results out of pseudo-randomly
generated sequence of numbers, meaning to turn loaded die into unloaded. Originally, the idea of
turning loaded die into unloaded one belongs to John von Neumann who is famous for research
in statistics and game theory .
But in the current research we used the methods described by Ari Jules et al. in[6] which
is also based on the work of von Neumann. These methods allow to generate a fair result out of
minimum three independent rolls. The only side effect of this method lies in the increasing
number of rolls that takes more time for a player to get the fair result. The method doesn’t take
much computational power and can be implemented in any modern device with CPU and data

memory. Another aspect discussed in the article is an upper surface detection. It can be done in
different ways but we present the method using roll and pitch values of the die. Roll and pitch
values are calculated based on accelerometer and gyroscope measurements. There are several
ways to implement described in. One of the problems was to detect the moment when the die is
finally stopped since there are situations possible when the die is balancing on one of the edges
and flips in a second. During this second accelerometer shows that the die is static but surface
detector cannot detect the face properly. For this purpose we included the countdown timer in our
implementation that waits pre-defined amount of seconds before calculating the upper surface.
1.1 Aim
A Dice Roller Android App that has a Button to roll a dice and updates the text on the screen
with the result of the roll.
1.2 Problem statement
We cannot carry a physical dice where ever we go so we have created an app called virtual dice
roller which we can install in our phones and use it whenever we need.
1.3 Motivation
Android Dice roller app is a simply virtual based app .In this app we have used the random
module for this, since we want to randomize the numbers we get from the dice. We are still
working on implementing some graphical interface
.
1.4 Applications
They are typically used for tabletop games, which includes a wide variety of games, as well as
for gambling. Examples of tabletop games that involve the use of dice include games like
backgammon, Boggle, and Yahtzee, where dice are a central component of the game.
1.5 Advantages
The model has several advantages over real dice.

 Virtual dice roll faster.

 The computer can record the results instantly and accurately from multiple
perspectives simultaneously.
 The model attempts to involve the learner by allowing them to choose a
combination before running the experiment.
 There is no need to carry a physical dice when we have a rolling dice app in our
phone.
1.6 Tools and Technology
Tools:
 Android development tool(ADT)
 Android Studio
 XML
 Java Development tool kit (JDK)
 SDK 7.0
 UML
 MS Office
 MS paint
 9 Patch resizer
Technologies:
 Touch Screen Control

CHAPTER 2
LITERATURE SURVEY
A literature review is a written document that presents a logically argued case founded on
a comprehensive understanding of the current state of knowledge about a topic of study. This
literature review discusses about the work on dice rolling application.
2.1 Related work

 Dice and their forerunners are the oldest gaming implements known to man. Sophocles
reported that dice were invented by the legendary Greek Palamedes during the siege of
Troy, whereas Herodotus maintained that they were invented by the Lydians in the days
of King Atys. Both “inventions” have been discredited by numerous archaeological finds
demonstrating that dice were used in many earlier societies.
 The precursors of dice were magical devices that primitive people used for the casting of
lots to divine the future. The probable immediate forerunners of dice were knucklebones
(astragals: the anklebones of sheep, buffalo, or other animals), sometimes with markings
on the four faces. Such objects are still used in some parts of the world.
 In later Greek and Roman times, most dice were made of bone and ivory; others were of
bronze, agate, rock crystal, onyx, jet, alabaster, marble, amber, porcelain, and other
materials. Cubical dice with markings practically equivalent to those of modern dice have
been found in Chinese excavations from 600 BCE and in Egyptian tombs dating from
2000 BCE. The first written records of dice are found in the ancient Sanskrit epic the
Mahabharata, composed in India more than 2,000 years ago. Pyramidal dice (with four
sides) are as old as cubical ones; such dice were found with the so-called Royal Game of
Ur, one of the oldest complete board games ever discovered, dating back to Sumer in the
3rd millennium BCE. Another variation of dice is teetotums (a type of spinning top).
 It was not until the 16th century that dice games were subjected to mathematical
analysis—by Italians Girolamo Cardano and Galileo, among others—and the concepts of
randomness and probability were conceived (see probability and statistics). Until then the
prevalent attitude had been that dice and similar objects fell the way they did because of
the indirect action of gods or supernatural forces.

CHAPTER 3
SYSTEM ANALYSIS
Analysis involves requirement determination and specification. It is basically establishing the
requirements for all system elements and then mapping these requirements to software forms. It
should address issues such as: -
 Profile of people who are operating on the system.

 Software on which the application is going to function.
 Existing system problems.
Analysis encompasses requirements gathering at the system level with small amount of top-level
design. The data obtained from the requirement determination phase are documented in Software
Requirement Specification (SRS) document. During analysis, a great deal of relatively
unstructured data is collected through procedural manuals and through websites. The traditional
approach is to organize and convert the data through system flowcharts, which support future
developments of the system and simplify communication with users. But the system flowcharts
represent the physical system rather than the logical system. Hence, it makes it difficult to
distinguish between what happens and how it happens in the system. Because of this drawback it
is necessary to have something, which is analogous to the architect's blueprint as a starting point
for the design. It is the way of focus on the functions rather than physical implementation.
3.1 Hardware Requirements
Processor : Intel core i5(6 th Generation) or higher
RAM : 8GB or higher
Memory : Minimum of 10GB
Display : Any display of viewable size

3.2 Software Requirements
Operating System : Microsoft Windows 7 ultimate or higher
Tool : Android Studio
Coding language : Java,python, XML
SDK ver : Android 5.0 Lollipop (API level 21) and higher
3.3 Existing Systems
The current system has no proper solution for monitoring and management of Weather. There
exist separate solutions for separate problems like tracking location of user, geological issues of
user and network related issues. There is no proper solution for network related problems.
Nowadays, weather forecasting provides several benefits like cyclone detection in cities, high
tide formation in marine areas, identification for event planning , construction of effective
weather forecasts, other resource management like temperature humidity etc, better customer
relation. Wind speed detection is also one of the significant areas of research .
Limitations
 In this game dice can be rolled in between minimum and maximum values added in the
dice. There will occour error if user gives unexpected input value.
 Dungeons and Dragons, Yahtzee, and a huge number of other games all rely on throwing
dice--from the 4-sided pyramid shape to the familiar 6-sided cube and the monster 20-
sided variety. The dice are meant to introduce an element of chance to these games; we
expect that the outcomes of the rolls will be truly random.
 We cannot use the application if the network condition in poor.

3.4 Proposed system
Fig3.4.1: Block diagram
The game starts immediately after user shacked the dice.

The IMU continues transmitting data until die finally stops. Even if the die stopped moving fora
moment it sends the event that can be detected as a final stop by an application. A good example
of it is an edge balancing. To prevent this unambiguity, we made the IMU to continue sending
data during the next 3 seconds after stop, the states are shown on Figure 3. After the final stop,
application runs unbiasing algorithm and shows the result depending on the algorithm output One
of the most important parts is to separate different stages of dice game.
The whole game process can be divide onto several parts:
•Player is being ready to roll.

•Player shakes the die in order to start the game. This functionality was implemented to prevent
accidental start of the game.
•Player has thrown the die and the die is falling or rolling over the floor
.•The die has stopped rolling.
In our implementation every part is clearly identified by either IMU itself or an application and
both are behave according to corresponding scenarios.
Next chapters of article describe algorithms that were implemented to provide game
functionality, including: state classifier, upper surface detector, die unbiasing. These algorithms
were combined in one solution but the description is presented in different subsections.
3.5 Feasibility Study

A multi curved sheet metal surface for a skin structure has usually been manufactured using a
conventional die forming process involving the use of both a die and a press machine in
accordance with the product shape. However, such processes are economically inefficient
because additional production costs are incurred for the development and management of
forming tools. To overcome this drawback, many alternative processes have been developed;
however, these still suffer from problems due to defects such as dimples and wrinkles occurring
in the sheet. In this study, a new sheet metal forming process called the flexibly reconfigurable
roll forming (FRRF) process is proposed as an alternative to existing processes. Unlike existing
processes, FRRF can reduce additional production costs resulting from material loss and
significantly reduce forming errors. Furthermore, it involves the use of a smaller apparatus.
The methodology and applicable procedure of the FRRF process
are described. Numerical forming simulations of representative multi curved sheet surfaces are
conducted using FEM. In addition, a simple apparatus is developed for verifying the feasibility of
this process, and a doubly curved metal is formed to verify the applicability of the reconfigurable
roller, a critical component in this forming process.

3.6 Functional and non-functional requirements
 Functional requirements
Digital dice can be used for more than just facilitating games – here a few tips for use in
the class. The custom dice can be used for ELA lessons:
Create dice with vowels and consonants. Have students select which dice shows the
vowels and which shows consonants.
Create dice containing nouns, verbs, and adjectives. Roll the dice and have students create
sentences using the given words.
Create dice containing sight words, CVC words, and other vocabulary building blocks
You can also use these dice in your math lessons, not just for quick mental math, but also
for multiplication. Use two 10-sided dice. Roll the dice and ask students to solve that
multiplication problem. Remember that once you’ve made an account, you can easily
save lessons and activities to your profile so you can reuse them later.
Coordinates can also be practiced using dice. Give students a handout with a coordinate
plane showing 1-6 on the x-axis and a-f on the y-axis. Create dice with 1-6 and a-f and
have students mark the coordinates given by the dice. As a variant, you can mark off
coordinates in the classroom and have students move to that location in the classroom!
Via the settings screen you have the option of standard dice or custom dice (for example,
showing words or letter groupings). Within the ‘standard’ option you are given a variety
of options, namely:
Type of dice (dots, numbers, or colors)

Number of sides (6, 8, 10, 12 or 20)
Number of dice (1 to 5)
Dice colors (light, dark, or alternating between light and dark)
Calculation (show calculate button for 2 or more dice)
For dots and colors you can only select six sided dice. If you want dice with up to 20
sides, select numbers as dice type
 Non-functional requirements

 In systems engineering and requirements engineering, a non-functional requirement

(NFR) is a requirement that specifies criteria that can be used to judge the operation of a
system, rather than specific behaviours. They are contrasted with functional requirements
that define specific behaviour or functions. The plan for implementing functional
requirements is detailed in the system design. The plan for implementing non-functional
requirements is detailed in the system architecture, because they are usually
Architecturally Significant Requirements. Broadly, functional requirements define what a
system is supposed to do and non-functional requirements define how a system is
supposed to be. Non-functional requirements are often called "quality attributes" of a
system. Other terms for non-functional requirements are "qualities", "quality goals",
"quality of service requirements", "constraints" and "non-behavioural requirements”.
The non-functional requirements of our system are:
 Accessibility: The concept of accessible design and practice of accessible development

ensure both "direct access" (i.e. unassisted) and "indirect access" meaning compatibility
with a person's assistive technology.
 Availability – System will be available all time. Whenever one can use it.
 Security – Only registered owner can use the system.
 Maintainability –The system provides a better platform for tracking and monitoring the
cattle.
 Reliability – The system is scalable as it provides the better and faster results.
 Scalability – The system is scalable as it allows the cattle owner to select the particular
symptoms and get the result of it.
 Authentication: Only authorized nodes can communicate with others.

 The proposed system should support the end user requirements.
 The system is capable of processing when the large numbers of images are provided as
input and also it must be interactive and delays involved should be less. So, in every
action-response of the system, there should be no long-term delays.

CHAPTER 4
DESIGN AND ANALYSIS
4.1 System Design
System design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy the specified requirements. Here, the design functions and operations
are described in detail, including screen layouts, business rules, process diagrams and other
documentation. The output of this stage will describe the new system as a collection of modules
or subsystems. Having a design methodology enforces consistency in the work as it helps in
achieving the deadlines timely.
The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced that describe the desired software features in detail. They generally include functional
hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudo code, and a complete entity relationship diagram with a full structure of the database.
Systems design implies a systematic approach to the design of a system. It may take a bottom-up
or top-down approach, but either way the process is systematic wherein it takes into account all
related variables of the system that needs to be created — from the architecture, to the required
hardware and software, right down to the data and how it travels and transforms throughout its
travel through the system. Systems design then overlaps with systems analysis, systems
engineering and systems architecture.
Design begins with requirements model. The team works to transform this model into four level
of design detail and they are,
• The data structure
• The system architecture
• The interface representation
• The component level detail
The data design transforms the information domain model created during analysis into the data
structure that is required for the implementation. The data objects and relationships defined in the
entity relationship diagram and detailed data content depicted provide the basis for the data

design activity. Part of data design may occur in conjunction with the design of software
architecture.
The importance of software design can be stated with a single word - Quality. Design provides
the representations of software that can be assessed for quality. Design is an iterative process
through which requirements are translated into a "blueprint" for constructing the software. The
design represented at a high level of abstraction - a level that can be directly traced to the specific
system objective and more detailed data, functional and behavioural requirements. There are
three characteristics that serve as a guide for the evaluation of a good design. Each of these
characteristics is actually a goal of the design process. They are:
• The design must implement all of the explicit requirements contained in the analysis
model and also accommodate the desired implicit requirements.
• The design must be readable and understandable for coding, testing and subsequently
support the software.
• The design should provide a complete picture for addressing the data, functional and
behavioural domains from an implementation perspective.
The Software design includes different design materials. The designs are Architectural, Work
flow, Use case, Activity, Sequence, Database, Form Design. These designs are used in software
development of a web-application and provides details of how the android - application should be
created.
The Project virtual dice roller will helps us to play any dice games where ever we want,There is
no need to carry a physical dice everywhere we go.

4.1.1. Product perspective:
Fig 4.1.1.1 :Flow diagram of system
This is for a similar game but the player is rolling one dice and not 2. The object of this games is
to roll a 6 on the dice on the first roll. If you do not roll a 6, then to when you must roll the same
number you rolled on the first roll before you roll a 6 to win. Rolling a 6 after the first roll ends
the game
 Step 1: Importing the required modules.
 Step 2: Building a top-level widget to make the main window for our application.
 Step 3: Designing the buttons.
 Step 4: Forming a list of images to be randomly displayed.
 Step 5: Constructing a label for image, adding a button and assigning functionality.
 Step 6: Forming a list of images to be randomly displayed.

4.1.2. Design Process
The design process involves developing several models of the system at different levels of
abstraction. As design is decomposed, errors and omissions in earlier stages are discovered. And
their feedbacks help in earlier design models to be improved. The various design activities are:
 Architectural design: The sub-systems making up the systems and their relationships are
identified and documented.
 Abstract Specification: For each sub-system an abstract specification of the services it
provides and the constraint under which it must be operate is produced.
 Interface Design: For each sub-system, its interfaces with other sub-systems is designed
and documented. This interface specification must be unambiguous as it allows the sub-
system to be used without knowledge of the sub-system operation.
 Component Design: Services are allocated to different components and the interfaces of
these components are designed.
 Algorithm Design: The algorithms are used to provide services that are designed in
detail with corresponding specifications.
4.1.3. Design Strategies

The two design strategies are:
 Functional Design: The system is designed from a functional point of view, starting with
high-level view and progressively refining this into a more detailed design. The system
state is centralized and shared between the functions of operating on that state.
 Module Design: The system is viewed as a collection of modules rather than functions.
The different modules are later integrated together into a single unit.

4.2.System Architecture:
Fig 4.2.1 :Architectural flow diagram
Android application consists of two parts: Unity application as a front-

end and Java Android application for passing the messages to Unity engine and
determining the states of dice as a back-end. Java application is packed to a JAR file and
pushed to Unity. Such architecture was chosen since Unity is not able to call the native
Android functions and handle the threads by itself thus the bridge b etween Unity and
Android is needed.
Initially, Android application opens Bluetooth connection to the
measurement unit and sends a Start measurements message. After getting the message
unit starts analysing accelerometer and gyroscope messages and sends roll, pitch and the
current state of IMU back to the phone(the yaw is not significant for the current research
and more com-plicated to compute). Java application receives and handles the messages,
makes a decision about the current state of an application and waits until the Unity call.
Unity engine calls update functions implemented in a bridge object after every frame
update. Unity is used due to represent the raw data in appropriate and understandable

way. Application allows to track the roll and pitch of die, track final result, analyse it and
generate unloaded result, save it to a file and show on the screen. Current version uses 6-
faced model of die but potentially can be used to represent die with N faces.
Creating the function
For this part of the project, I imported 2 libraries: statistics and rand int (from random).
The statistics library is not needed for this project, but I think it’s neat to use the library
to gather statistics on any rolling you decide to do.
from random import rand int
import statistics
Now we are ready to create our dice rolling function. For this function, there will be 2
required inputs: n and x.
n will be the number of sides for the dice you are rolling.
x will be the number of dice you are rolling.
# Define the dice rolling function using two inputs.
rolls = []
def roll_many(n, x):
for i in range(x):
roll = randint(1,n)
rolls.append(roll)
print(roll)
That’s it! Simple enough. Now you can use this function to obta in dice rolls.
# This cell will simulate rolling 2 six -sided dice.
rolls = []
roll_many(6,2)
This is an example of what should show up when you run it
In the current research authors successfully reused ap -plied

states of motorcyclist on the states of gambling die. The motion model of die is quite
similar with the motor-cycle motion model described . ”Motion”and ”static” states of
vehicle are fully identical with the corresponding states of die in the game. And
”motorcyclecrash event” is assumed to mean the initial shake of the die. State
classification has been implemented as a described . The following states are recognised
by the algorithm implemented.
•Static The die is not moving.

•Move The die is in the air or rolling.

•Shake The die was shaken.
For the classification task, we use a supervised Bayesian maximum a posteriori classifier
(MAP).
You can choose to make use of standard six -sided dice or dice
with written numbers and up to 20 sides. If you want to easily create math problems with
this tool, simply choose the number of dice you’d like to roll (2 through 5 in this
instance) and check the box in the settings that shows “calculate”. Then, you can easily
use these dice to practice addition and have Gynzy provide the answer to every unique
roll.
Dice is a small throwable object with multiple resting
positions, used for generating random numbers. DICE ROLLING SIMULATOR is an
intuitive, simple and lightweight simulating gaming app that can be used for any situation
that requires number generation. However, new theoretical models and high-speed movies
of dice rolls ofnumerous numbers shapes and sizes confirm this isn’t strictly the case.
Theyshow that dice thrown with a 1 on the top are slightly more likely to land as a 1 than
as the other values for every type of the vario us kinds of dice they studied.
But at the same time , it’s actually too hard for someone to predict the outcome
of the throw of a single die.

CHAPTER 5
IMPLEMENTATION
Implementation is the carrying out, execution, or practice of a plan, a method, or any design for
doing something. It encompasses all the processes involved in getting new software or hardware
operating properly in its environment, including installation, configuration, running, testing, and
making necessary changes. The word deployment is sometimes used to mean the same thing.
Dice rolling applications are typically used for tabletop games, which includes a
wide variety of games, as well as for gambling. Examples of tabletop games that involve
the use of dice include games like backgammon, Boggle, and Yahtzee , where dice are a central
component of the game.
Fig 5 : Sample dice pictures used in games

Real-time implementation is a fully-functional prototype of game application. Currently it allows

to simulate the die on any Android device and represents the result of unloading algorithm. Next
versions will allow to use several dice in thes ame game and support multiple users. Application
consists of the following parts.
:•Hardware implementation: Two foam-rubber dice loaded with an IMU on different distances
from the center of die.
•Software implementation. Android phone with the application for the visualization of algorithm
data and automatic detection of states.

5.1 SOURCE CODE :
5.1.1 Android Mainfest.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<ImageView
android:id="@+id/imageView"
android:layout_width="131dp"
android:layout_height="121dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:srcCompat="@drawable/dice3d160" />
<TextView
android:id="@+id/dice_no"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Dice Number : ? Spin it "
android:textSize="25sp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintHorizontal_bias="0.498"
app:layout_constraintTop_toBottomOf="@+id/imageView"
app:layout_constraintVertical_bias="0.157" />
<TextView
android:id="@+id/textView2"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textColor="#0184FC"
android:textSize="25sp"
android:textStyle="italic|bold"
android:text="Click on the Dice to Spin it"
app:layout_constraintBottom_toTopOf="@+id/imageView"
app:layout_constraintTop_toTopOf="parent" />

5.1.2 MAIN ACTIVITY.JAVA
package protocoderspoint.com.androiddicerollertutorial;
import android.media.AudioAttributes;
import android.media.SoundPool;
import android.os.Build;
import android.os.Handler;
import android.os.Message;
import android.os.Bundle;
import android.view.View;
import android.view.animation.Animation;
import android.view.animation.LinearInterpolator;
import android.view.animation.RotateAnimation;
import android.widget.ImageView;
import android.widget.TextView;
import androidx.appcompat.app.AppCompatActivity;
import java.util.Random;
import java.util.Timer;
import java.util.TimerTask;
import protocoderspoint.PreLollipopSoundPool;
public class MainActivity extends AppCompatActivity {

ImageView dice_picture;
Random rng=new Random();
SoundPool dice_sound;
int sound_id;
Handler handler;
Timer timer=new Timer();
boolean rolling=false;
RotateAnimation rotate;
int soundplay;
TextView dice_no;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
dice_no=(TextView)findViewById(R.id.dice_no);
InitSound();
dice_picture = (ImageView) findViewById(R.id.imageView);

dice_picture.setOnClickListener(new HandleClick());
rotate = new RotateAnimation(0, 360, Animation.RELATIVE_TO_SELF, 0.5f,

Animation.RELATIVE_TO_SELF, 0.5f);
rotate.setDuration(3000);
rotate.setInterpolator(new LinearInterpolator());
handler=new Handler(callback);
}
private class HandleClick implements View.OnClickListener {

public void onClick(View arg0) {
if (!rolling) {
rolling = true;
dice_picture.setImageResource(R.drawable.dice3d160);
soundplay= dice_sound.play(sound_id, 1.0f, 1.0f, 0, 0, 1.0f);
dice_picture.startAnimation(rotate);
timer.schedule(new Roll(), 3000);
}
}
}
5.1.2.1 NEW CODE TO INITIALIZE SOUND PLAYBACK:
void InitSound() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
AudioAttributes aa = new AudioAttributes.Builder()
.setUsage(AudioAttributes.USAGE_ASSISTANCE_SONIFICATION)
.setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION)
.build();
dice_sound= new SoundPool.Builder().setAudioAttributes(aa).build();
} else {
dice_sound= PreLollipopSoundPool.NewSoundPool();
}
sound_id=dice_sound.load(this,R.raw.shake_dice,1);
}
class Roll extends TimerTask {

public void run() {
handler.sendEmptyMessage(0);
}
}
Handler.Callback callback = new Handler.Callback() {

public boolean handleMessage(Message msg) {

switch(rng.nextInt(6)+1) {
case 1:
rotate.cancel();
dice_no.setText("Dice Number : 1");
dice_picture.setImageResource(R.drawable.one);
break;
case 2:
rotate.cancel();
dice_picture.setImageResource(R.drawable.two);
break;
case 3:
rotate.cancel();
dice_picture.setImageResource(R.drawable.three);
break;
case 4:
rotate.cancel();
dice_picture.setImageResource(R.drawable.four);
break;
case 5:
rotate.cancel();
dice_picture.setImageResource(R.drawable.five);
break;
case 6:
rotate.cancel();
dice_picture.setImageResource(R.drawable.six);
break;
default:
}
rolling=false;
return true;
}
};
protected void onPause() {

super.onPause();
dice_sound.pause(sound_id);
}
protected void onDestroy() {
super.onDestroy();
timer.cancel();
}
}

5.3 SNAPSHOTS:

CHAPTER 6
SYSTEM TESTING
Software testing is a process of executing a program or application with the intent of finding the
software bugs. It can also be stated as the process of validating and verifying that a software
program or application or product meets the business and technical requirements that guided its
design and development. The purpose of testing can be quality assurance, verification and
validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness
testing and reliability testing are two major areas of testing. Software testing is a trade-off
between budget, time and quality.
6.1. What is Verification and Validation?
Verification is the process to make sure the product satisfies the conditions imposed at the start of
the development phase. In other words, to make sure the product behaves the way we want it to.
Validation is the process to make sure the product satisfies the specified requirements at the end
of the development phase. In other words, to make sure the product is built as per customer
requirements.
6.2. Key Benefits of Testing
The key benefits of testing are
 Reduced risk of failures (or incidents) once systems are transferred to live operation
 Demonstrative proof that business requirements have been met
 Assurance that the system will function appropriately with existing legacy systems
where required and will integrate with other systems as necessary
 Assurance that the users for which the solution was designed are able to operate
productively
Acknowledging these benefits requires accepting the reality that testing costs money. Too much
testing could be risky, as it may delay product launch and allow a competitor to steal significant
market share. Unfocused, inefficient approaches to test management often result in poor return
on investment in testing. As a rule of thumb, sufficient testing is where the costs of testing can be
balanced against the potential costs of failures and over run. The risks of failure and business
benefit should be used to determine how much testing is performed.
6.3. Basics of Testing

There are two basics of software testing: Blackbox testing and Whitebox testing.

6.3.1. Behavioural testing:

Behavioural or Black-box testing is a method of software testing that examines the functionality
of an application without peering into its internal structures or workings. This method of test can
be applied to virtually every level of software testing: unit, integration, system and acceptance.
6.3.2. Structural Testing
Structural or White box testing is a testing technique that examines the program structure and
derives test data from the program logic/code. The other names of glass box testing are clear box
testing, open box testing, logic driven testing or path driven testing or structural testing.
6.4. Types of Testing
Testing is the process where we validate and verify if the product meets the user’s requirements
and adheres to the specification. There are several types of testing processes available.
• Unit Testing
• Integration Testing
• Functional Testing
• System Testing
• Stress Testing
• Performance Testing
• Usability Testing
• Acceptance Testing
• Regression Testing
• Beta Testing
6.4.1. Unit Testing

Unit testing is the testing of an individual unit or group of related units. It falls under the class of
white box testing. It is often done by the programmer to test that the unit he/she has implemented
is producing expected output against given input.
6.4.2. Integration Testing
Integration testing is testing in which a group of components are combined to produce output.
Also, the interaction between software and hardware is tested in integration testing if software
and hardware components have any relation. It may fall under both white box testing and black
box testing.
6.4.3. Functional Testing
Functional testing is the testing to ensure that the specified functionality required in the system
requirements works. It falls under the class of black box testing.

6.4.4. System Testing

System testing is the testing to ensure that by putting the software in different environments (e.g.,
Operating Systems) it still works. System testing is done with full system implementation and
environment. It falls under the class of black box testing.
6.4.5. Stress Testing
Stress testing is the testing to evaluate how system behaves under unfavourable conditions.
Testing is conducted at beyond limits of the specifications. It falls under the class of black box
testing.
6.4.6. Performance Testing
Performance testing is the testing to assess the speed and effectiveness of the system and to make
sure it is generating results within a specified time as in performance requirements. It falls under
the class of black box testing.
6.4.7. Usability Testing
Usability testing is performed to the perspective of the client, to evaluate how user-friendly the
GUI is? How easily can the end users learn? After learning how to use, how proficiently can the
users perform? How pleasing is it to use its design? This falls under the class of black box
testing.
6.4.8. Acceptance Testing
Acceptance testing is often done by the customer to ensure that the delivered product meets the
requirements and works as the customer expected. It falls under the class of black box testing.
6.4.9. Regression Testing
Regression testing is the testing after modification of a system, component, or a group of related
units to ensure that the modification is working correctly and is not damaging or imposing other
modules to produce unexpected results. It falls under the class of black box testing.
6.4.10. Beta Testing
Beta testing is the testing which is done by end users, a team outside development, or publicly
releasing full pre-version of the product which is known as beta version. The aim of beta testing
is to cover unexpected errors. It falls under the class of black box testing.
6.5. Manual and Automation Testing

6.5.1. Manual Testing
Manual testing includes testing a software manually, i.e., without using any automated tool or
any script. In this type, the tester takes over the role of an end-user and tests the software to

identify any unexpected behaviour or bug. There are different stages for manual testing such as
unit testing, integration testing, system testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of
testing. Manual testing also includes exploratory testing, as testers explore the software to
identify errors in it.
6.5.2. Automation Testing
Automation testing, which is also known as Test Automation, is when the tester writes scripts
and uses another software to test the product. This process involves automation of a manual
process. Automation Testing is used to re-run the test scenarios that were performed manually,
quickly, and repeatedly.
Apart from regression testing, automation testing is also used to test the application from load,
performance, and stress point of view. It increases the test coverage, improves accuracy, and
saves time and money in comparison to manual testing.
6.6. Test Cases
A test case is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly. The process of developing test cases
can also help find problems in the requirements or design of an application.
Writing good test cases involve the following steps —
• Test cases should be ‘atomic’; they should not overlap or complicate testing. Each test case
should be written such that only one thing should be tested at a time
• All positive and negative scenarios should be considered
• Each test case should be written in a language that is simple and easy to understand, using an
active voice, and using consistent and exact names
The characteristics of a good test case are —
• Accurate
• Economical
• Traceable
• Repeatable
• Reusable

Test Cases:
Testcase Testing scenario Expected output Actual output Result

ID
TC-01 Application is Application should Application is running Pass
running properly run properly properly
TC-02 Click on the dice Should be show Random number 1-6 is Pass
random number 1-6 displayed successfully

CONCLUSION
This virtual dice roller can have any number of faces and can generate
random numbers simulating a dice roll based on the number of faces
and dice. Examples of tabletop games that involve the use of dice include
games like backgammon, Boggle, and Yahtzee, where dice are a central
component of the game.
The outcome of the experiments shows that technology is quite reliable and
can be implemented in different applications on different platforms.
The application created during research can be used for
both scientific and entertainment purposes: for collecting
and processing roll statistics and representing game content.
The method described in is proved as working in real
conditions and also can be used in other applications.
FUTURE SCOPE AND PLAN

In this project we have used the random module for this, since we want to randomize the
numbers we get from the dice. It can be further improved by making a attractive graphical user
interface or any other upgradation to this that it can be supported in most of the device. Beginners
of games or any gamer can easily get its concept and plays it because it is fully user friendly. We
are still working on implementing some graphical interface
.
REFERENCES
 Android developer fundamentals course- concepts
 Erik Hellman, “ANDROID PROGRAMMING- PUSHING THE LIMITS”,1st edition,
India Pvt ltd,2014.
 Dawn Griffiths and David Griffiths, “HEAD FIRST ANDROID DEVELOPER”, 1st
edition, O’reillySPD publishers 2015.
 W.-Y. Chen, P.-J. Lin, and D.-Y. Kuo, “Dice image recognition
scheme using pattern comparison technique,” in in Proc. Int. Symp.
Computer Consumer Control, Taichung, Taiwan, June 4-6 2012, pp.

128–131.
 B. A. B. Correia, J. A. Silva, F. D. Carvalho, R. Guilherme,
F. C. Rodrigues, and A. M. de Silva Ferreira, “Automated
detection and classification of dice,” in Proc. SPIE 2423,
Machine Vision Applications in Industrial Inspection III, San
Jose, CA, Mar. 27 1995, pp. 196–202. [Online]. Available:
http://dx.doi.org/10.1117/12.205506
 I. Lapanja, M. Mraz, and N. Zimic, “Computer vision based reliability
control for electromechanical dice gambling machine,” in Proc. IEEE
Int. Conf. Industrial Tech., Goa, India, Jan 19-22 2000, pp. 325–328.
 G. S. Hsu, H. C. Peng, and S. M. Yeh, “Color and illumination
invariant dice recognition,” in 2012 IEEE Int. Conf. on Systems, Man,
and Cybernetics (SMC), Oct 2012, pp. 857–862.
 J. von Neumann, “Various Techniques Used in Connection with
Random Digits,” J. Res. Nat. Bur. Stand., vol. 12, pp. 36–38, 1951.
 A. Juels, M. Jakobsson, E. Shriver, and B. Hillyer, “How to turn
loaded dice into fair coins,” IEEE Trans. Inf. Theory, vol. 46, no. 3,
pp. 911–921, May 2000.
 Y. Hao, Z. Xiong, W. Gao, and L. Li, “Study of strapdown inertial
navigation integration algorithms,” in Proc. Int. Conf. Intelligent
Mechatronics Automation, Chengdu, China, Aug 26-31 2004, pp.
751–754.
 M. Xu, N. Fan, and Z. Wang, “Study on extended kalman filtering
for attitude estimation of micro flight vehicle,” in Proc. Int. Conf.
Measuring Tech. Mechatronics Automation, Shanghai, China, Jan 6-7
2011, pp. 457–460.
 H. Rehbinder and X. He, “Nonlinear pitch and roll estimation for
walking robots,” in Proc. IEEE Int. Conf. Robotics Automation, San
Francisco, CA, Apr. 24-28 2000, pp. 2617–2622 vol.3.
 C. C.-Y., “On the detection of vehicular crashes-system characteristics
and architecture,” Vehicular Technology, vol. 51, no. 1, pp. 180–193,
2002.
 H. Tabata and K. Kushida, “Automatic accident reporting apparatus
for two-wheeled vehicles,” Apr. 29 2009, EP Patent 1,197,426.
 J. Parviainen, J. Collin, T. Pihlstrom, J. Takala, K. Hanski, and ¨
Lumiaho, “Automatic crash detection for motor cycles,” in Proc.
Ann. Conf. IEEE Industrial Electronics Soc., Dallas, TX, Oct. 29 -
Nov. 1 2014, pp. 3409–3413.
 Unity3d, what is unity? http://goo.gl/n3YtYX. [Online; accessed Dec.
2015].
 R. Rosenkrantz, “Concentration of distributions at entropy maxima
(1979),” in E. T. Jaynes: Papers on Probability, Statistics and
Statistical Physics, ser. Synthese Library, R. Rosenkrantz, Ed.
Springer Netherlands, 1989, vol. 158, pp. 315–336. [Online].
Available: http://dx.doi.org/10.1007/978-94-009-6581-2 11
 M. Kapitaniak, J. Strzalko, J. Grabski, and T. Kapitaniak, “The
three-dimensional dynamics of the die throw,” Chaos, vol. 22, no. 4,
2012. [Online]. Available: http://goo.gl/Cga9iZ
 M. Small and C. K. Tse, “Feasible implementation of a prediction
algorithm for the game of roulette,” in Circuits and Systems, 2008.

APCCAS 2008. IEEE Asia Pacific Conference on, Nov 2008, pp.
1208–1211.
 www.developers.android.com
 https://www.scribd.com/presentation/410927469/Dice-Rolling
 web&rct=j&url=https://cod ereview.stackexchange.com/questions/46328/dice-rolling-
simulator&ved=2ahUKEwiouf2juaPcAhUKto8KHca8BMYQFjAMegQIBBAB&usg=A
OvVaw3mHIjKVr4u8N0TWWY4KmgZ
 https://www.google.co.in/url?sa=t&source=web&rct=j&url=%23&ved=2
ahUKEwiouf2juaPcAhUKto8KHca8BMYQwqsBMAF6BAgKEAU&usg=AOvVaw0VT
JzWxrN8ZFOD4xbU2nov
 https://www.google.co.in/url?sa=t&source=web&rct=j&url=https://en.
m.wikipedia.org/wiki/Dice_control&ved=2ahUKEwjm-MzvuaPcAhVJtY8K
HT02CN0QFjABegQICxAG&usg=AOvVaw3jCIUTvZucMYWe_kI428z1
 https://www.google.co.in/url?sa=t&source=web&rct=j&url=https://ygor
ganization.com/dicetheory/amp/&ved=2ahUKEwjm-MzvuaPcAhVJtY8KH
T02CN0QFjAVegQ

CSE - 2020 - 27 - Android Dice Roller App

Uploaded by

Copyright:

Available Formats

You might also like

CSE - 2020 - 27 - Android Dice Roller App

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSE - 2020 - 27 - Android Dice Roller App

Uploaded by

Copyright:

Available Formats

VISVESVARAYA TECHNOLOGICAL UNIVERSITY

“JNANA SANGAMA”, BELGAUM - 590018

ANDROID DICE ROLLER APP

UNDER THE GUIDANCE OF

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

[Mr. SAGAR B] [Dr. MADHU B K]

1.2 Problem statement 3

1.5 Advantages 3-4

1.6 Tools and Technology 4

2.1 Related work 5

3. System Analysis 6-11

3.1 Hardware Requirements 6

3.2 Software Requirements 7

3.3 Existing Systems 7

3.4 Proposed System 8

3.5 Feasibility Study 9

3.6 Functional and non-functional requirements 10

4. Design and Analysis 12-18

4.1 System Design 18

4.1.1 Product Perspective 14

4.1.2 Design Process 15

4.1.3 Design stratergies 15

4.2 System Architecture 16-18

6. System Testing 26-30

6.1 What is Verification and Validation? 26

6.2 Key Benefits of Testing 26

6.3 Basics of Testing 26-27

6.4 Types of Testing 27-28

6.5 Manual and Automation Testing 28-29

6.6 Test Cases 29

3.4.1 Block diagram 8

4.1.1.1 Flow diagram of system 14

4.2.1 Architectural flow Diagram 16

5 Dice pictures used in games 19

DEPT OF CSE,VVIET 2020-21 PAGE 1

DEPT OF CSE,VVIET 2020-21 PAGE 2

1.2 Problem statement

The model has several advantages over real dice.

DEPT OF CSE,VVIET 2020-21 PAGE 3

 Virtual dice roll faster.

1.6 Tools and Technology

DEPT OF CSE,VVIET 2020-21 PAGE 4

2.1 Related work

DEPT OF CSE,VVIET 2020-21 PAGE 5

 Profile of people who are operating on the system.

3.1 Hardware Requirements

Processor : Intel core i5(6 th Generation) or higher

RAM : 8GB or higher

Memory : Minimum of 10GB

Display : Any display of viewable size

DEPT OF CSE,VVIET 2020-21 PAGE 6

3.2 Software Requirements

Operating System : Microsoft Windows 7 ultimate or higher

Tool : Android Studio

Coding language : Java,python, XML

3.3 Existing Systems

DEPT OF CSE,VVIET 2020-21 PAGE 7