8-ball Pool Game Development

Major
project UIIT 8th semester
CHAPTER 1
INTRODUCTION
1.1 Problem Definition
1:- To study about the corona SDK.
2:- To study the Lua language and its various features.
3:- Application Development:- Using the Corona SDK as game engine and Lua language
to develop a sample 8 ball pool game.
1.2 Objectives
Understanding the Corona software development kit and Lua language.
8 ball pool game development.
1.3 Introduction to 8-ball Pool Game

There is no limit to the potential of computers in the game design field, which is quickly
becoming the premiere medium for cultural storytelling, information and entertainment.
Playing games is an important part of our social and mental development
and computers are a real fun when it comes to the games.
The Pool game, also more formally known as pocket billiards (mostly in North America) or
pool billiards (mostly in Europe and Australia), is the family of cue sports and games played
on a pool table. There are hundreds of pool games. Some of the more well known include
eight-ball, nine-ball, ten-ball, straight pool, one-pocket and bank pool. The 8-ball pool game
can be played on any android device, anywhere and anytime. The game is a real fun for the
game lovers and includes 1-player as well as 2-players gaming mode. This game shows the
use of the latest technology and also the innovative ideas we can implement by using these
technologies.
1.3.1 The Pool Game

There are hundreds of pool games and some of the more well known include eight-ball, nineball, ten-ball, straight pool, one-pocket and bank pool. We are here giving the basic idea
about the 8-ball pool game since this is the game on which our project is based upon.
Major
In the United States, the most commonly played game is eight-ball. The goal of eight-ball,
which is played with a full rack of fifteen balls and the cue ball, is to claim a suit (commonly
stripes or solids, and reds or yellows), pocket all of them, then legally pocket the 8 ball, while
denying one's opponent opportunities to do the same with their suit, and without sinking the
8 ball early by accident. On the professional scene, eight-ball players on the International
Pool Tour (IPT) were the highest paid players in the world as of 2006 (the IPT nearly folded
in 2007, and as of 2008 is attempting a comeback). In the United Kingdom the game is
commonly played in pubs, and it is competitively played in leagues on both sides of the
Atlantic. The most prestigious tournaments including the World Open are sponsored and
sanctioned by the International Pool Tour. Rules vary widely from place to place (and
between continents to such an extent that British-style eight-ball pool/blackball is properly
regarded as a separate game in its own right). The growth of local, regional and national
amateur leagues may alleviate this confusion eventually.
1.4 Gist of the Project
The project uses following main technologies:
Lua
Corona SDK
1.4.1 LUA
Lua (meaning "moon") is a lightweight multi-paradigm programming language designed as a
scripting language with "extensible semantics" as a primary goal. Lua is cross-platform since it is
written in ISO C. Lua has a relatively simple C API, thus "Lua is especially useful for providing
end users with an easy way to program the behavior of a software product without getting too far
into its innards."
Major
Figure 1.1
Paradigm(s): scripting, imperative (procedural, prototype-based object-oriented)
Appeared in: 1993
Designed by: Roberto Ierusalimschy,Waldemar Celes,Luiz Henrique de Figueiredo
Stable release: 5.2.2 (March 27, 2013)
Influenced by: C++, CLU, Modula, Scheme, SNOBOL
Influenced: Io, GameMonkey, Squirrel, Falcon, MiniD
Lua is commonly described as a multi-paradigm language, providing a small set of general
features that can be extended to fit different problem types, rather than providing a more
complex and rigid specification to match a single paradigm. Lua, for instance, does not contain
explicit support for inheritance, but allows it to be implemented relatively easily with metatables.
Similarly, Lua allows programmers to implement namespaces, classes, and other related features
using its single table implementation; first-class functions allow the employment of many
powerful techniques from functional programming; and full lexical scoping allows fine-grained
information hiding to enforce the principle of least privilege.
In general, Lua strives to provide flexible meta-features that can be extended as needed, rather
than supply a feature-set specific to one programming paradigm. As a result, the base language is
light the full reference interpreter is only about 180 kB compiled and easily adaptable to a
broad range of applications.
Lua is a dynamically typed language intended for use as an extension or scripting language, and
is compact enough to fit on a variety of host platforms. It supports only a small number of atomic
data structures such as Goolean values, numbers (double-precision floating point by default), and
strings. Typical data structures such as arrays, sets, lists, and records can be represented using
Luas single native data structure, the table, which is essentially a heterogeneous associative
array.
3
Major
Lua implements a small set of advanced features such as first-class functions, garbage collection,
closures, proper tail calls, coercion (automatic conversion between string and number values at
run time), corutines (cooperative multitasking) and dynamic module loading.
By including only a minimum set of data types, Lua attempts to strike a balance between power
and size.
1.4.2 CORONA SDK

Corona SDK is a software development kit created by Walter Luh, co-founder of Corona Labs
Inc. (formerly known as Ansca Mobile). It allows software programmers to build mobile
applications for the iPhone, iPad, and Android devices.
Corona lets developers use integrated Lua, layered on top of C++/OpenGL, to build graphic
applications. The SDK does not charge per-app royalty or impose any branding requirement, and
has a subscription-based purchase model that allows new features to be rolled out immediately to
users. Corona Labs Corona SDK will fundamentally change how you approach iOS and Android
software development, whether youre an engineer, a web developer, or a designer.
Corona SDK allows you to rapidly create native apps and high-performance games for the iOS
and Android devices. You get full access to device-specific features such as the camera,
keyboard, GPS, accelerometer, video playback, audio recording, multitouch input and embedded
web views.
Major
Screenshot 1.1
The Corona development process is simple:
Design images, audio, video, and animation assets using your favorite creative tool.
Rapidly develop your mobile apps using Corona SDK, taking full advantage of the multiplatform Corona Simulator to preview your application as it will appear on different iOS
and Android screens.
Compile native optimized apps in a few clicks, and distribute them on the Apple App
Store and Google Play.
Major
As a developer, you will program in Lua, a simple and intuitive scripting language with
exceptional performance, and leverage Corona's innovative and robust APIs.
1.4.3 Corona Development Environment

The Corona SDK development environment consists of two aspects: the Corona Simulator and
the Corona Simulator Output window.
1. The Corona Simulator is a visual representation and test environment for your app.
What you see in the Simulator is generally what your app will look like and how it
will function when deployed to an actual device. The Corona Simulator is an essential
tool because it allows you to view changes to your code instantly in an active, responsive
environment that closely mimics the device.
2. The Corona Simulator Output is where you can view diagnostic messages about what's
happening in your program. This window is automatically displayed when you launch the
Corona Simulator.
Welcome Window
The Welcome Window provides access to Corona developer resources. From here, you can also
press Cmd-R to relaunch the most recently edited app.
Major
Screenshot 1.2
Sample Apps access the wealth of sample applications included with the Simulator.
You can build these for a device and examine their code.
APIs open the Corona Docs page where you'll find details on all of the Corona SDK
features and APIs.
Forums open the Corona Forums where you can discuss developer topics with other
Corona users.
Share Code open the Share Your Code page where you can view code from other
Corona developers and/or submit your own.
Tutorials access Corona's extensive tutorials on mobile application development.
New Project this is the same as File New Project and is used to create a new
project with an optional template.
Simulator this is the same as File Open... and is used to open an existing project.
Dashboard open the Dashboard page (Pro subscribers only).
Major
Demo open the demo window which contains step-by-step examples of how Corona
applications are made.
RSS Feed click one of the changing headlines at the bottom to access that article on
our website.
File Menu
The File menu is where projects (applications) are created or opened. This is also where you
build your apps for distribution or testing on devices. Finally, this menu provides access to the
Simulator Preferences which are discussed in detail below.
Hardware Menu
The Hardware menu is used to simulate physical device actions such as rotating the screen.
View Menu
The View menu has options to manipulate the Simulator window or change the skin (View
View As).
Corona Simulator Preferences
The Simulator has several preferences which let you customize the development workflow.
Deauthorize and Quit the number of different computers on which you're allowed to
run the Simulator is limited, so you'll need to deauthorize a computer if you stop using it.
You can also use this button if you need to change the Corona account credentials you're
developing with.
Anonymous feedback approve the sending of anonymous usage information that

helps us improve the Corona Simulator.
Don't show the Welcome Window don't show the Welcome Window when launching
the Simulator.
Show Runtime Errors show a diagnostic popup when the application experiences a
runtime error. This helps in debugging application code.
Building Apps
When you want to build your app for distribution or to test on a device, choose
File Build for Android.
8
Major
Project Configuration
Configuration settings for an app are defined using a config.lua file written in Lua syntax. It
should be placed in the project's base directory.
Basic Structure
The config.lua file is set up using a content table nested within a application table as
follows:
application =
{
content =
{
--parameters here
}
}
Dynamic Scaling
Since most apps are developed for multiple devices and screen resolutions, Corona features
dynamic scaling. This allows you to use a common set of screen coordinates while Corona
automatically scales text, vector objects, and images to different resolutions depending on the
device.
Corona can scale both upward or downward depending on your "starting resolution". It can also
substitute higher-resolution image files when needed, ensuring that your app appears clear and
sharp on all devices (see Dynamic Image Selection below).
Content Area
A fundamental concept behind dynamic scaling is content area. In Corona, your base content
area can be whatever you wish, but often it's defined as a common screen resolution, for example
640 960 (iPhone4) or 800 1280 (Kindle Fire HD).
The content area represents the overall "stage" on which text, vector objects, and image assets
are displayed. Everything will be positioned in relation to this content area, which may or may
not match the screen's actual pixel resolution. The content area will be scaled to fit the screen,
with subtle differences dictated by the scale definition (see scale below).
The internal coordinate system is also dependent on the content area, with coordinates (0,0)
residing in the top-left corner of the content area, not necessarily the top-left corner of the
screen. For more information on the Corona coordinate system, see Display Groups and
Coordinates.
Major
width | height
The content area is defined by the width and height values in config.lua. If you omit or set
either of these values to 0, dynamic scaling will not be used.
application =
{
content =
{
width = 640,
height = 960,
}
}
The content area should always be defined in respect to portrait orientation. If your app is
designed for landscape orientation, you should still set the width and height according to
portrait orientation. In the example above, a landscape-oriented app for iPhone4 should still use
width and height parameters of 640 and 960 respectively, not 960 and 640.
To control an app's orientation on actual devices, you must define specific parameters in the
build.settings file.
scale
The scaling method of the content area is determined by the scale value.
application =
{
content =
{
width = 640,
height = 960,
scale = "letterbox",
}
}
The possible values include the following (case-insensitive):

scales the content area to fill the screen while preserving the same aspect
ratio. The entire content area will reside on the screen, but this might result in "black
bars" on devices with aspect ratios that differ from your content aspect ratio. Note that
you can still utilize this "blank" area and fill it with visual elements by positioning them
outside the content area.
letterbox
zoomEven
scales the content area to fill the screen while preserving the same aspect
ratio. Some content may "bleed" off the screen edges on devices with aspect ratios that
differ from your content aspect ratio.
10
Major
scales the content area to fill the entire screen. This is the default
method if you don't specify one of the above options, or if you omit the scale parameter
entirely. All content will remain on the screen, but it may be stretched horizontally or
vertically. This mode is not recommended, as it will often distort the content area.
zoomStretch
xAlign | yAlign
By default, dynamically-scaled content is centered on the screen. In letterbox scale mode,
empty screen area will be evenly divided between both sides. In zoomEven mode, the bleed area
will be cropped equally on both sides.
If you need to align the content area to a particular edge of the screen, you can use the xAlign
and yAlign values.
string value which sets the alignment in the x direction. Possible values are
left, center, or right.
xAlign
yAlign
string value which sets the alignment in the y direction. Possible values are
top, center, or bottom.
application =
{
content =
{
width = 640,
height = 960,
xAlign = "left",
yAlign = "top"
}
}
Content Properties
Several display properties are exposed within Corona to help you work with scaled content.
and display.contentHeight read-only
representing the original width and height of the content, in pixels.
display.contentWidth
display.pixelWidth
properties
and display.pixelHeight entire screen width and height, in
pixels.
and display.viewableContentHeight read-only

properties representing the viewable width and height. This is useful if you're using
zoomEven scaling, as it will reveal the viewable (uncropped) measurements, in pixels.
display.viewableContentWidth
11
Major
and display.contentCenterY read-only properties

representing the center of the content area, useful for positioning objects along either
central axis.
display.contentCenterX
Runtime Errors
In the Corona Simulator, there is a setting under Preferences called Show Runtime Errors
which defaults to on. This global setting triggers pop-up error messages while running an app in
the Simulator. If you don't like this feature or if it doesn't fit your workflow, you can turn it off.
You can also set this on a per-app basis from config.lua to control error messages while
running the app on a device. showRuntimeErrors accepts a boolean value (true or false). The
default is false.
application =
{
showRuntimeErrors = true,
}
Remember that disabling error messages doesn't mean that errors aren't occurring. The pop-up
alerts help you detect these errors.
Another option is to use the unhandledError Runtime listener to trap errors which would
otherwise trigger an error pop-up. This allows you to implement custom error reporting. Note
that even if you disable error messages, the listener is still called, but the return value doesn't
matter since the pop-up is never displayed.
function myUnhandledErrorListener( event )
local iHandledTheError = true
if ( iHandledTheError ) then
print( "Handling the unhandled error", event.errorMessage )
else
print( "Not handling the unhandled error", event.errorMessage )
end
end
return iHandledTheError
Runtime:addEventListener( "unhandledError", myUnhandledErrorListener )
Frame Rate (fps)

The default frame rate is 30 frames per second, but you can set it to 60 frames per second by
adding the fps key. Values other than 30 or 60 will be ignored.
application =
{
content =
12

{
}
Major
fps = 60,
Dynamic Image Selection

In addition to dynamic scaling, Corona supports dynamic image selection. If you are developing
an app for both normal and "Retina/HD" devices, you should not rely on Corona to simply scale
one set of images across a wide array of screen resolutions. There are several issues related to
this:
1. If you design all of your images in low resolution and allow Corona to scale them up for
Retina/HD devices, the images may appear fuzzy and pixelated. Not only will this result
in poor visual appearance, but it may cause the app to be rejected before it reaches the
marketplace.
2. In contrast, if you design all of your images for Retina/HD and allow Corona to scale
them down for lower resolution devices, the larger images will require the same amount
of texture memory on those devices. This may adversely affect the performance of your
app or worse, those images will not appear if they exceed the maximum texture size
on a device.
The solution is to create multiple images tailored for two or three similar resolutions, allowing
Corona to automatically select the nearest match. Then, if necessary, Corona will scale the
images by a small percentage in relation to the the content scale.
The first step is to declare a imageSuffix table within the content table. Each key-value pair in
the table consists of a image suffix and a scale factor. In the following example, there are just
two image sets, but each one spans several devices.
application =
{
content =
{
width = 800,
height = 1200,
xAlign = "center",
yAlign = "center",
imageSuffix =
{
--iPhone4 / iPod4 / iPad1 / iPad2 / Kindle Fire HD 7" / Galaxy S3
["@2x"] = 0.8,
--Retina iPad / Kindle Fire HD 9" / Nexus 10
["@4x"] = 1.5,
13

}
Major
Corona handles dynamic image selection automatically, assuming the imageSuffix table is set
up properly. In addition, you must use the display.newImageRect() API to output dynamic
images. Animated sprites using the display.newSprite() API are dynamically selected as well,
assuming the image sheet is configured properly.
Image Suffix
Each image suffix must be specified within brackets and quotes as in ["@2x"]. The suffix can be
named whatever you want, but it should be short and logical since you must append the same
suffix to all image files designed for that image set. Apple tends to use the @2x convention for
Retina devices, while Android uses suffixes like -xhdpi and -hdpi.
When adding a suffix to each image file, do not include the bracket or quotes just append the
suffix itself.
myImage.png
myImage@2x.png
myImage-hdpi.png
Scale Factor
The scale factor specifies the threshold above which Corona will use images in that suffix set.
This code can help you determine the proper values:
print( display.pixelWidth / display.actualContentWidth )
Add this code to your project, access the Corona Simulator, and use Window View As to
simulate different devices. Note the output in the Terminal/console this is the scale factor for
the device. If the value on a particular device is greater than or equal to the number you specify
for the scale factor, Corona will use images from that suffix set.
App Licensing
The Corona licensing library lets you confirm that the app was bought from a store. To
implement licensing, the license parameters must be added to the application table.
application =
{
license =
{
google =
{
key = "Your key here",
14

},
Major
policy = "this is optional",
},
In addition, you must require the licensing library in your core project file.
Analytics (LaunchPad)
Corona SDK Analytics is a free service given to all Corona SDK developers. You can view data
about your published apps, including the number of sessions, the number of unique users, and
session lengths. Session data is displayed in graphs broken up by device type (iPhone, iPad, iPod
touch, and Android) and for device types combined. You can access Corona SDK Analytics
through your account dashboard.
Analytics are enabled by default. To disable them, add a launchPad key set to false within
config.lua.
application =
{
launchPad = false,
}
Important
1. Use of certain Corona libraries (require = ("[library]")) will override the opt-out
setting. These libraries include ads, credits, and gameNetwork.
2. If you're using Analytics on Android, you must grant Internet permission to the device. If
you don't, the app will not send out analytics data, nor will a warning or error be
reported.
Anti-Aliasing
Anti-aliasing caused incorrect rendering issues on certain vector objects. Thus, the antialias
key within the content table should be removed.
Advantages of Corona include:
We write less code. Its that simple.

But you still have access to a powerful OpenGL-based platform with features like built-in
physics, Facebook Connect, maps, push notifications, in-app purchases and more.
We can go cross-platform with ease.
15
Major
Corona is the best solution for developing cross-platform apps for all major platforms and
devices. Write once and build to iOS, Android, Kindle Fire and NOOK at the touch of a
button. Corona makes dealing with different device sizes and resolutions easy.
Leverage industry standards.
Corona is built on industry standards including OpenGL, OpenAL, Google Maps, Box2D,
Facebook, Game Center, in-app purchases and much more.
Publish and monetize.
With Corona, we can retain all rights to our apps. They never take revenue share, but will
make it as easy as possible to publish on all the top app stores.Corona gives you all the
options to monetize your apps choose from leading ad networks and mediation layers or
monetize using in-app purchases.
Enjoy ultimate flexibility.
Corona is renowned for game creation, but is an equally powerful tool for other app types
including business apps, utility apps, educational apps, eBooks and more.
Publishing with Corona is FREE.
With Corona SDK Starter you can build and publish your app for FREE.
1.5 Scope
The corona Sdk provides the most promising environment for the game apps development. Many
popular android games are being developed in Corona sdk using Lua language. Our project helps
in understanding both the technologies and developing various games.
1.6 Work Division
Richa Thakur- Designing user interface of the game and coding.
Jyoti Logic of the game and coding.
16
Major
CHAPTER 2
FEASIBILITY STUDY & REQUIREMENT ANALYSIS
2.1 Introduction
The first step is to study whether or not it is worth carrying on with the requirement analysis. The
following questions should be answered in this phase:
Does this project contribute to the overall objective?
Can the application be implemented with current technology and within given cost and
schedule?
Is the technology effective and efficient?
What is the cost estimate?
17
Major
In Feasibility study we analyze our proposed solution being feasible or not. Since this is an
Android project, so we will take into consideration two types of feasibility studies, mainly: Technical Feasibility
Economic Feasibility
2.2 Technical Feasibility

Technical feasibility centers on the existing computer system (H/W and S/W) whether it can
support the addition of proposed system, if not, to what extent it can support and the
organizations capacity to acquire additional components.
The technical feasibility looks at the aspect whether the problem can be
solved technically with the help of computers. Also, the technology used
should be efficient and flawless. After a detailed session of brainstorming and
technical reviews, we conclude the project is technically feasible as it will
employ the following technologies to be implemented.
Corona Sdk
Lua language,
OpenGL API
2.2.1 About The Technology

Corona Sdk overview:
Corona SDK is a software development kit created by Walter Luh, co-founder of Corona Labs
Inc. (formerly known as Ansca Mobile). It allows software programmers to build mobile
applications for the iPhone, iPad, and Android devices.
Lua language:
Lua ( meaning "moon") is a lightweight multi-paradigm programming language designed as a

scripting language with "extensible semantics" as a primary goal. Lua is cross-platform since it is
written in ISO C. Lua has a relatively simple C API, thus "Lua is especially useful for providing
end users with an easy way to program the behavior of a software product without getting too far
into its innards."
OpenGL overview:
18
Major
OpenGL (Open Graphics Library)is a cross-language, multi-platform API for rendering 2D and
3D computer graphics. The API is typically used to interact with a GPU, to achieve hardwareaccelerated rendering. OpenGL was developed by Silicon Graphics Inc. (SGI) from 1991 and
released in January 1992 and is widely used in CAD, virtual reality, scientific visualization,
information visualization, flight simulation, and video games. OpenGL is managed by the nonprofit technology consortium Khronos Group.
2.3 Economic Feasibility

Among the most important information contained in the feasibility study is Cost Benefit Analysis
and assessment of the economic justification for a computer/handset based system project. CostBenefit Analysis delineates costs for the project development and weighs them against tangible
and intangible benefits of the system. Cost-Benefit Analysis is complicated by the criteria that
vary with the characteristics of the system to be developed, the relative size of the project and the
expected return on investment desired as part of companys strategic plan. As this is an in-house
project for the college (or maybe a vast number of people), to be used for its own convenience
and also it is an open source project, so neither it requires a huge amount of money nor any
costly tools or infrastructure need to be set up for it. Moreover, since all the technologies chosen
are also open source, thus they make the project Economically Feasible.
2.4 SYSTEM REQUIREMENTS

On Mac OS X:
Mac OS X 10.7 or later.
Intel Mac.
Apple's iOS SDK and Xcode must be installed to create final iOS device builds.
Note
The Android SDK is not required to create Android device builds on Mac OS X.
The Corona SDK on Mac supports building for both iOS and Android.
19
Major
Only Android devices running version 2.2 or higher and ARMv7 processor are supported
(ARMv6 is no longer supported).
You don't need to join the Apple Developer program just to test your app in the iOS Simulator.
You only need to install Apple's iOS SDK and Xcode on your Mac and build for Xcode
Simulator. You will need to join Apple Developer's program to test on an actual iOS device.
On Microsoft Windows:
Windows 8, Windows 7, Vista, or XP operating system.
1 GHZ processor (recommended).
38 MB of disk space (minimum).
1 GB of RAM (recommended).
OpenGL 1.3 or higher graphics system (available in most modern Windows systems).
In order to do Android device builds, you will also need to install the 32-bit version of the Java 6
Development Kit (JDK). (Note: Corona does not support JDK7.)
Note
The Android SDK is not required to create Android device builds on Windows.
The Corona SDK on Windows only supports building for Android.
Only Android devices running version 2.2 or higher and ARMv7 processor are supported
(ARMv6 is no longer supported).
CHAPTER 3
INSTRUCTIONAL DESIGN
3.1 Audience Analysis
Audience Analysis is an analysis of the learner's current skills and how those skills map to
the instructional content. Skills represent actions that can be taken in game. Each action is
tracked by its own system of skill points. Skill points are a measure of how proficient the
20
Major
player is at these skills and increasing those grants benefits to the skill as well as granting
access to perks that may be taken upon leveling up.
Key components of games are:
Goals
Rules
Challenge
Interaction
Games generally involve mental or physical stimulation, and often both. Many games help
develop practical skills, serve as a form of exercise, or otherwise perform an educational,
simulational or psychological role.
3.2 Gameplay elements and classification
Games can be characterized by "what the player does." This is often referred to as gameplay.
Major key elements identified in this context are tools and rules that define the overall context of
game.
3.2.1 Tools
Games are often classified by the components required to play them (e.g. a game-pad or a
computer). Also many countries in Europe, for instance, have unique standard decks of playing
games. Many game tools are tokens, meant to represent other things. A token may be a pawn on
a board, play money, or an intangible item such as a point scored. Games with the same or
similar rules may have different gameplay if the environment is altered.
3.2.2 Rules
Whereas games are often characterized by their tools, they are often defined by their rules. While
rules are subject to variations and changes, enough change in the rules usually results in a "new"
game. For instance, baseball can be played with "real" baseballs or with wiffleballs. However, if
the players decide to play with only three bases, they are arguably playing a different game.
There are exceptions to this in that some games deliberately involve the changing of their own
rules, but even then there are often immutable meta-rules.
Rules generally determine:
Turn order,
The rights and responsibilities of the players, and
21
Major
Each players goals.
Player rights may include when they may spend resources or move tokens. Common win
conditions are being first to amass a certain quota of points or tokens (as in Settlers of Catan),
having the greatest number of tokens at the end of the game (as in Monopoly), or some
relationship of ones game tokens to those of ones opponent (as in chess's checkmate).
3.2.3 Skill, strategy, and chance
A games tools and rules will result in its requiring skill, strategy, luck, or a combination thereof,
and are classified accordingly.
Games of skill include games of physical skill, such as wrestling, tug of war, hopscotch, target
shooting, and stake, and games of mental skill such as checkers and chess. Games of strategy
include checkers, chess, go, arimaa, and tic-tac-toe, and often require special equipment to play
them. Games of chance include gambling games (blackjack, mah-jongg, roulette, etc.), as well as
snakes and ladders and rock, paper, scissors; most require equipment such as cards or dice.
However, most games contain two or all three of these elements. For example, American football
and baseball involve both physical skill and strategy while tiddlywinks, poker, and Monopoly
combine strategy and chance. Many card and board games combine all three; most trick-taking
games involve mental skill, strategy, and an element of chance, as do many strategic board
games such as Risk, Settlers of Catan, and Carcassonne.
Single-player games
Most games require multiple players. However, single-player games are unique in respect to the
type of challenges a player faces. Unlike a game with multiple players competing with or against
each other to reach the game's goal, a one-player game is a battle solely against an element of the
environment (an artificial opponent), against one's own skills, against time, or against chance.
It is not valid to describe a computer game as single-player where the computer provides
opposition. If the computer is merely record-keeping, then the game may be validly singleplayer.
Many games described as "single-player" may be termed actually puzzles or recreations.
22
Major
CHAPTER 4
GAME DESIGN
4.1 Introduction : What is game design?
The goal of a computer game is to deliver an entertaining interactive experience to the player. If
we examine games that have been commercial and/or critical successes, we find that the most
common trait of these games is that they are entertaining. Although beautiful graphics, fancy
technology, or a big license can contribute to a games success, none of these, on their own, are
sufficient for even minimal success.
If we want to increase the appeal of our games, it is necessary to understand what makes an
experience entertaining, and how such an experience can be created. The discipline that tries to
answer these questions is called game design.
Game design is not programming or art
The entertainment value of a game is not linked to any well-understood discipline such as
graphic art or software engineering. A game can have brilliant graphics, a groundbreaking 3D
engine, or fantastic artificial intelligence, while at the same time being frustrating or
uninteresting to play. Conversely, a game such as Civilization, with lousy graphics and a lame
2D display engine, can be a classic masterpiece that has become both a critical and a commercial
success.
So quality of entertainment is not solely linked to the quality of graphics or the quality of
programming, although both certainly have an impact. Instead, successful game developers have
found a way to make a game more than the sum of its graphical and programming parts, by
focusing on and emphasizing design. Implicit in this is the idea that game design should be
recognized as distinct from other aspects of game development.
Game design is hard.
A close look at games on the market today clearly shows that making entertaining games is hard.
How many mediocre games are released each year? How many games are exciting because of
some gosh-wow feature, only to be forgotten a month later? If making software in general is
difficult, then making software entertaining should be recognized as being extremely difficult.
Designing games takes time, effort, skill and sensibility. It is important to realize that game
design is difficult, and to make sure that appropriate resources are directed at the process.
23
Major
There is no official way to learn game design, therefore it is often ignored.

In order to make an interactive experience entertaining, it is necessary to understand what an
entertaining experience is and how it can be created. Unfortunately, although it is possible to
study various disciplines that are part of the game development process, such as art and
programming, these disciplines are not concerned with entertainment.
Worse, there is no formal education that teaches how to make entertaining games. Is there at least
an informal way of learning game design? Arent there theories on game design that are
commonly accepted in the industry? The answer is no, and the central reason for this is that the
field is new and constantly changing.
Which means that the skills needed to design an entertaining game cannot be easily learned or
taught. Just as there are no accepted universal theories, there is no shared vocabulary.
Technical terms commonly used in the industry, such as fun and cool, are less than
helpful. Playability and good gameplay are a slight improvement, but are far from being
basic, well-defined concepts that allow for deeper discussion, or successful implementation. Still,
it is possible to learn how to design entertaining games, but it requires a lot of effort and original
thought. It cannot be done incidentally.
Game design is hard to identify.
Without a commonly accepted theory of game design, it is hard to recognize good game design
when it is present, and easy to ignore it during development and critical appraisal. How does a
company determine if someone is a good designer? How does it train game designers? How does
it prove that bad game design was why its last game was a failure?
The most serious consequence of this lack of common knowledge is that it is easy to
underestimate the value and worth of game design. If you cant study game design as an
educational discipline, and there are no accepted methods by which to measure the return of
investment of a game designer, how can you justify investing time and money in game design?
How can you justify paying someone to focus on game design?
Game design is essential.
Given that game design is integral to product success, the more relevant question is, how can you
justify not paying someone to focus on game design? However vague or ill-defined the process
of game design currently is, without someone in the role of designer, the probability of making
an entertaining game is largely left to chance. With a talented designer in a well-defined role, the
probability of making a great game is greatly increased.
Someone must be responsible for a games design.
Someone must be responsible for the design of a game, and for making sure that the enjoyment
of the game survives the production process. If no one is specifically charged with this
24
Major
responsibility, it is too easy to lose track of the end goal while facing the pressures and
necessities of production.
Making someone responsible for game design ensures that game design skills are actually
present within the team. It also forces people in the team to think more about game design,
because they have to deal with the designer, in the same way that a lead programmer cannot
make graphical decisions on his own because he knows the lead artist has to be consulted.
Does a game designer make all of the creative decisions on a project?
Since game design is about entertainment value, and this is the aspect of a game that has the
highest correlation with success, the game designer has a vital position within the team.
However, without good graphics and programming, even the most well designed game will not
be successful. It is the entire experience, the synergy that makes the whole more than its parts,
that makes a game entertaining.
Contrary to popular opinion, one of the most important tasks of the game designer is taking the
ideas of other team members and advising on the best way to integrate those ideas into a
coherent whole. At other times it is important that the designer be able to explain the
consequences of a given design suggestion, and to defend the quality and coherence of the design
against suggestions which might damage the projects overall intent. (A lead programmer has the
same task.)
Additional benefits of game design.
While increasing the chance that a game will turn out entertaining and successful, a dedicated
game designer and design process also provide other benefits. Chief among these is the cost
savings associated with the streamlining of the production process that a good game design
yields. Fewer features end up being implemented on a speculative basis, only to be cut later.
Fewer surprises arise if only because someone has considered the ramifications of various design
choices beforehand. And fewer morale problems arise because there is, from the beginning, a
viable, coherent vision of what the product can and should be.
Conclusion: Design is good.
Game design is a vital element of the game development process. Games such as Goldeneye 007,
Metal Gear Solid, Starcraft, Resident Evil or Half-Life, to name just a few recent successful
games, did not become great games by accident. They did not become hugely entertaining
because they had good graphics or fantastic code. They became great because the people who
made these games wanted to deliver an entertaining experience to the player. Like any non-trivial
activity, achieving that end required careful thought and an intentional focus.
In any act of commercial production, it is important to know what you want to do, and how you
are going to do it, before you begin. Although a relatively new medium, interactive entertainment
25
Major
is no different, and without careful game design as a basis for production the success of a given
product is left to chance. When taken together with the fact that there is no detrimental effect
related to an insistence on good game design, it only makes sense to pursue good design as
vigorously as possible on a product-by-product and company-wide basis.
4.2 Game Description: Here is a broad description of the 8-ball pool game.
Some basic terminology dealing with a cue and a pool table:
Figure 4.1
26
Major
Some terminology related to a pool shot:
Figure 4.2
Aiming a pool shot:
Figure 4.3
The biggest challenge of pool is visualizing the necessary shot line that sends the cue ball (CB)
to the ghost-ball (GB) position to contact the object ball (OB) at the point where the line of
centers through the GB and OB heads to the target direction (e.g., to a pocket).
Adjusting Aim for Throw
27
Major
It is important to understand how friction between the CB and OB can change the direction of
the OB. This effect is called throw. Throw is not very large with fast speed shots, and it is less
when the CB has topspin or bottom-spin, but the effect can be significant with slower-speed
shots, especially with stun. When throw is due to cut angle alone, the effect is called cut-induced
throw (CIT):
Figure 4.4
And when it is due to sidespin, it is called spin-induced throw (SIT):
Figure 4.5
Cue Ball Position Control

Once you know how to aim and execute basic shots, the next step is learning and controlling
where the CB will go for the next shot. The most important goal in pool is to pocket the OB, but
the 2nd most important goal is to leave the CB in a good spot to allow you to pocket the next and
remaining OBs. It is also important to predict CB motion when needing to detect and avoid a
28
Major
scratch, plan position routes, avoid "traffic" (obstacle balls), and to aim carom (kiss) shots and
break-out (cluster separation) shots.
Below is an illustration of reference directions useful for predicting the path of the CB.
Figure 4.6
English (sidespin)
English refers to sidespin imparted to the CB by hitting the CB off center. Here are the different
names used to refer to the type of english:
29
Major
Figure 4.7
The purpose for sidespin is to alter the path the CB takes when it hits the rail cushions:
Figure 4.8
English is also given different names based on how it is used:
30
Major
Figure 4.9
To use sidespin effectively, you need to be aware of the effects of squirt, swerve, and throw
illustrated here:
Figure 4.10
31
Major
Kick and Bank Shots

A kick shot is one where you bounce the CB off one or more rails to reach an OB. A bank shot is
one where you bounce an OB off one or more rails to reach a pocket. In simple terms, both are
based on the mirror system, which uses the diamonds on the rails of the table as aiming
references. Here is some basic terminology and aiming principles related to kick and bank shots:
Figure 4.11
4.3 Genre: What kind of game is it?

Video game genres are used to categorize video games based on their gameplay interaction
rather than visual or narrative differences. A video game genre is defined by a set of gameplay
challenges. They are classified independent of their setting or game-world content, unlike other
works of fiction such as films or books. For example, an action game is still an action game,
regardless of whether it takes place in a fantasy world or outer space.Within game studies there is
a lack of consensus in reaching accepted formal definitions for game genres, some being more
observed than others. Like any typical taxonomy, a video game genre requires certain constants.
Most video games feature obstacles to overcome, so video game genres can be defined where
obstacles are completed in substantially similar ways.
Following is a listing of commonly used video game genres:
Action
Action-adventure
Adventure
32
Role-playing
Simulation
Strategy
Arcade game
Music game
Party game
Programming game
Puzzle game
Sports game
Educational game
Major
8-ball Pool is an Arcade game.

Arcade games is a genre often used to describe a vast variety of games ranging from Angry Birds
(could also be classified as a physics-based game) to Pac Man to other games that differ
drastically in game play. A consensus on a specific, concrete definition of this genre is hard to
find explicitly and even implicitly (the definition arrived at by looking at what elements the
games in this genre have in common). Obviously, the games that came out on the arcade
machines when they were popular are commonly classified and referred to as arcade games.
Games that are classified as arcade usually have a score system, little (like Angry Birds) or no
story (like Pac Man), have linear game progression, have obvious and well-defined levels (like
Pac Man and Angry Birds), etc.
4.4 Platform: Will this run on a PC, console, PDA, phone, etc.?
Corona is the best solution for developing cross-platform apps for all major platforms and
devices. Write once and build to iOS, Android, Kindle Fire and NOOK at the touch of a button.
Corona makes dealing with different device sizes and resolutions easy.
33
Major
Figure 4.12
4.5 Game Mechanics:

Game mechanics are constructs of rules intended to produce a game or gameplay. All games use
mechanics; however, theories and styles differ as to their ultimate importance to the game. In
general, the process and study of game design, or Ludology, are efforts to come up with game
mechanics that allow for people playing a game to have an engaging, but not necessarily fun,
experience.
The interaction of various game mechanics in a game determines the complexity and level of
player interaction in the game, and in conjunction with the game's environment and resources
determine game balance. Some forms of game mechanics have been used in games for centuries,
while others are relatively new, having been invented within the past decade.
Complexity in game mechanics should not be confused with depth or even realism. Go is
perhaps one of the simplest of all games, yet exhibits extraordinary depth of play. Most computer
or video games feature mechanics that are technically complex (when expressed in terms of
making a human do all the calculations involved) even in relatively simple designs.
In general, commercial video games have gone from simple designs to extremely complex ones
as processing power has increased. In contrast, casual games have generally featured a return to
simple, puzzle-like designs, though some are getting more complex. In physical games,
differences generally come down to style, and are somewhat determined by intended market.
Game mechanics fall into several more or less well-defined categories, which (along with basic
gameplay and theme) are sometimes used as a basis to classify games.
Turns
34
Major
A game turn is an important fundamental concept to almost all non-computer games, and many
video games as well (although in video games, various real-time genres have become much more
popular). In general, a turn is a segment of the game set aside for certain actions to happen before
moving on to the next turn, where the sequence of events can largely repeat. In a truly abstract
game (backgammon) turns are nothing more than a means to regulate play. In less abstract games
(Risk), turns obviously denote the passage of time, but the amount of time is not clear, nor
important. In simulation games, time is generally more concrete. Wargames usually specify the
amount of time each turn represents, and in sports games a turn is usually distinctly one 'play',
although the amount of time a play takes can vary.
Action points
These control what players may do on their turns in the game by allocating each player a budget
of action points each turn. These points may be spent on various actions according to the game
rules, such as moving pieces, drawing cards, collecting money, etc. This type of mechanism is
common in many "German-style board games," such as Pictionary and Trivial Pursuit.
Movement
Many board games involve the movement of playing tokens. How these tokens are allowed to
move, and when, is governed by movement mechanics.
Some game boards are divided into more or less equally-sized areas, each of which can be
occupied by one or more game tokens. (Often such areas are called squares, even if not strictly
square in shape.) Movement rules will specify how and when a token can be moved to another
area. For example, a player may be allowed to move a token to an adjacent area, but not one
further away. Dice are sometimes used to randomise the allowable movements.
4.6 Victory condition mechanics

These mechanics control how a player wins the game.
Goals
This is the most general sort of victory condition, which can be broad enough to encompass any
method of winning, but here refers to game-specific goals that are usually not duplicated in other
games. An example is the checkmate of a king in chess.
Loss avoidance
35
Major
Some games feature a losing condition, such as being checkmated (chess), running out of cards
first (War), running out of hitpoints (Quake), or being tagged (tag). In such a game, the winner is
the only remaining player to have avoided loss.
Victory points
A player's progress is often measured by an abstract quantity of victory points, which
accumulate as the game develops. Victory points or similar quantities need not be restricted to
development games, but are most common in that type as they ensure sufficient reward for all
aspects of development. For example, in a game involving the development of civilizations, there
is usually no need to reward investments such as trade and military expenditures, which yield
their own strategic benefits. However, a victory point system may be used to reward more
subjective aspects of civilization-building, such as the arts.
The winner can be decided either by:
The first player to reach a set number of points.
The player with the most points at a predetermined finishing time or state of the game.
This mechanism is often used explicitly in German-style board games, but many other games are
played for points that form a winning condition. The electoral college of the United States
political system is also a well-publicized example of this type of victory condition. Victory points
may be partially disguised in the role of game resources, with play money being a common
example.
4.7 Game modes
A game mode is a distinct configuration that varies gameplay and affects how other game
mechanics behave. A game with several modes will present different settings in each one,
changing how a particular element of the game is played. One of the most common examples of
game mode is the single player versus multiplayer choice in video games, where multiplayer can
further be cooperative or competitive.
Changing modes while the game is ongoing can be used as a means to increase difficulty and
provide additional challenge, or as a reward for player success. Power-ups are modes that last for
a few moments or that change only one or a few game rules; for example power pellets in PacMan give the temporary ability to eat the enemies for a few seconds.
36
Major
Other examples include the availability of a sandbox mode without predefined goals or
progression. The division of game content in stages or chapters, where each stage expands the
rules that a player can use with respect to the previous stage, increases game complexity and
variety. If the game advances through these stages by moving through different areas, these areas
are called levels or maps; if the character unlocks new abilities through activities or rewards,
they receive a currency called experience points. These points can be used to upgrade or augment
various pre-determined abilities.
A game mode may restrict or change the behavior of the available tools ( e.g. play with
limited/unlimited ammo, new weapons, obstacles or enemies, a timer, etc.), establish different
rules and game mechanics.
4.8 Shortcut key
A shortcut key is a finite set of one or more keys that invoke a software operation. There is only
one shortcut key used in the game:
Ctrl + R ------ For restarting the game.
Ctrl + W ------ To go to the welcome window of the Corona SDK.
37
Major
4.8 Design for the 8 ball pool game consists of:

4.8.1 Structural design
We can analyze the underlying structure and logic of the game with the help of context diagram
and flow chart of the game logic.
4.8.1.1 Context diagram of 8 ball pool game
Player
Open libraries when

event occurs
Request for play
Design
Integration
Request to open
libraries
0.1
8 ball pool game

Provide graphical user
interface for the game
calls
Deployment
Listen to the function
Script
Organization
38
Major
Figure 4.13
4.8.1.2 Flow chart for the 8 ball pool game
Start
Continue
New game
1 player game
2 player game
Game begins
No
Win
Yes
Yes
Play again
39
Major
No
End
Figure 4.14
4.8.2 User Interface Design
Game engine: What is a game engine?
A game engine is a system designed for the creation and development of video games. The
leading game engines provide a software framework that developers use to create games for
video game consoles and personal computers. The core functionality typically provided by a
game engine includes a rendering engine (renderer) for 2D or 3D graphics, a physics engine or
collision detection (and collision response), sound, scripting, animation, artificial intelligence,
networking, streaming, memory management, threading, localization support, and a scene graph.
The process of game development is often economized, in large part, by reusing/adapting the
same game engine to create different game or to make it easier to "port" games to multiple
platforms.
Game engine for 8 ball pool game
Our project on 8 ball pool game require following technology:
Corona SDK
OpenGL application programming interface(version 3.0)
40
Major
Screenshot 4.1: GUI of the 8 ball pool game
CHAPTER 5
IMPLEMENTATION & CODING
The Implementation phase has been divided into numerous steps for the sake of convenience for
the user. Further it has been elaborated into a Problem Solving approach in which
implementation is thought of as a problem, its requirements are specified and then it is solved on
the basis of these three steps:
5.1 Installing Corona SDK Windows
These are the steps for installing Corona SDK for Windows.
Installing Corona SDK
Activating the SDK
Java Development Kit Setup

41
Major
Choosing a Text Editor
5.1.1 Installing Corona SDK

Please note that Corona SDK on Windows only supports device builds for Android devices.
Corona SDK on Mac OS X supports both iOS and Android development.
You do not need to install the Android SDK to use Corona SDK. However, to create device
builds to test on actual Android devices, you will need the Java Development Kit. The
installation process is described below.
Download Corona. Now, double-click the .msi installer file and follow the steps in Corona's
installation wizard.
5.1.2 Activating the SDK
In order to use the Corona SDK, you must be connected to the Internet and perform a simple
one-time authorization process.
Open the Corona Simulator from the folder where you installed it. The first time you launch,
you will be presented with a License Agreement (EULA). Read the license terms and click
Agree. If you've already registered for a Corona account, simply enter your account e-mail and
password to activate the SDK. Otherwise, click Register to create an account.
Screenshot 5.1
Upon successful login, you will receive a confirmation dialog. You're ready to get started!
42
Major
Screenshot 5.2
5.1.3 Java Development Kit Setup
Installing the Corona SDK lets you create and test Corona apps locally on your PC. To build an
app for testing on an Android device, you need to install the Java 6 Development Kit (Corona
does not support JDK7). If you already have JDK6 installed, you can use it, provided that it is
the x86 (32-bit) version, not x64 (64-bit). If you're not sure which version you have, it's
recommended that you follow these instructions.
1. Go to the JDK download page.
2. Locate Java SE 6 and click the JDK "Download" button. Do not download JDK 7.
3. Read the license agreement and accept it if you agree.
4. Click the "Windows x86" link to download the install program.
5. Run the installer.
5.1.4 Choosing a Text Editor
Corona doesn't come with a built-in program editor, so you need to use your own text editor.
Many people already have their favorite text editor, but if you don't, the following options are
recommended. These advanced text editors automatically color your Lua code, provide
comprehensive search/replace options, and allow you to jump between blocks of your code
(functions).
Koneki
Notepad++
LuaEdit IDE
Vim
43
Major
5.2 Building and Coding the app

5.2.1 Project Configuration
Configuration settings for an app are defined using a config.lua file written in Lua syntax. It
should be placed in the project's base directory.
Basic Structure
The config.lua file is set up using a content table nested within a application table as
follows:
application =
{
content =
{
--parameters here
}
}
5.2.2 Implementing Physics

Physics Editor helps developers edit physics shapes. By drag shapes inside the editor and
pressing the auto trace button, developers can adjust the shapes physics parameters and directly
export to a game development framework.
5.2.1.1 Physics world setup
This line makes the physics engine features available under the physics namespace:
local physics = require "physics"
5.2.1.2 Starting, pausing, and stopping the physics world

The following functions start, pause, and stop the physics simulation.
physics.start()
either instantiates or resumes the world.
Important: it must be called before any of the other functions in this section.
is treated as a request to destroy the world, so if you merely want to pause the
physics engine, you should use physics.pause().
physics.stop()
physics.start()
-- must do this before any other physics call!
physics.pause()
physics.stop()
44
Major
By default, Box2D bodies not involved in a collision will "sleep" after a couple of seconds. This
reduces overhead, but in some cases you may not want this behavior. For example, the
"ShapeTumbler" sample code will not work well if bodies are allowed to sleep, since sleeping
bodies do not respond to changes in the direction of gravity.
You can override this behavior on a given body with body.isSleepingAllowed = false, but
you can also override this globally for all bodies in the world by using an optional boolean
parameter in start:
physics.start( true ) -- prevent all bodies from sleeping
physics.start( false ) -- default behavior; bodies may sleep
5.2.2.3 physics.setGravity
Sets the x,y components of the global gravity vector, in units of m/s2. The default is ( 0, 9.8 ) to
simulate standard Earth gravity, pointing downwards on the y-axis.
physics.setGravity( 0, 10 )
5.2.2.4 physics.getGravity
Returns the x,y components of the global gravity vector, in units of m/s2. This takes advantage of
the fact that Lua functions can return multiple values.
gx, gy = physics.getGravity()
5.3 Detailed coding

For further coding go to Appendix B
a
CHAPTER 6
SYSTEM TESTING
6.1 Introduction
Software testing is a critical element of software quality assurance and represents ultimate
review of design; specification and coding notion of correctness of software just developed
45
Major
and overcome a conflict of interest that occurs when errors are recovered. A thorough testing of
system before any implementation is mandatory.
Testing can be done with two types of data. These are live data and Test Data.
Live data: - Data actually to be used in the proposed system.
Test Data: - The previously designed input to achieve predictable results.
6.1.1 Objectives of Testing

Testing is the process of execution of a program with the intent of finding error.
A good test case is one that has a high probability of finding an undiscovered error.
A successful test is one that uncovers an as-yet-discovered error.
6.1.2 Testing Principles
All tests should be traceable to customer requirements.

Test should be planned long before testing begins.
Testing should begin in small and progress towards testing in the large.
To be most effective an independent third party should conduct testing.
6.2 Test Plan

The basic function of testing is to detect the errors in the s/w after the coding phase. This implies
testing has not only to uncover errors introduced during coding but also errors introduced during
last phase. Thus the goal of testing is to uncover requirement, coding and design errors in the
program.
6.3 Levels of Testing:
Client Needs
Acceptance
Testing
46
Requirement
Design
Code
System Testing
Unit
Integration
Testing
Testing
Major
Figure 6.1
6.4 Test Cases:

Various test cases are used to check overall integrity, validity and quality of the game. These test
cases include:
Valid input cases

Following issues are considered:
Is the score increasing when a ball is going into the pocket?
Is the cue-ball having the right direction with the inclination?
Is the game coming to an end with the 8th ball going into the pocket?
Is the interface showing the right information?
Invalid input cases

47
Major
The score increasing automatically with time.

The score of 1st player increasing while the ball going into the pocket is of 2nd player.
Is game still continuing while the 8th ball has gone into the pocket?
Compatibility consideration cases

Is the game working good given the hardware requirements are complete?
Is the game working on the platforms where it should run (i.e. android, iOS, Kindle Nook
etc.)?
Functionality consideration cases

Are the shortcuts in the game working according to their functionality?
Is the cue-ball working accordingly with the force and inclination given to it?
Is the gaming coming to an end?
CHAPTER 7
CONCLUSION AND FUTURE SCOPE
7.1 Conclusion
This report helps us achieve the following objectives:
Understanding Corona Sdk.

Understanding the Lua language.
How to implement lua language in Corona Sdk for development of games.
Understanding games Development by making a sample: 8 ball pool game.
7.2 Future Scope

This report has a future under the following concepts:
48
Major
This report can help us to develop many more new games. We can implement our ideas
about a game and develop various interesting games of different categories.

In the 8 ball pool game Application, more features for e.g. sounds, can be added, more
widgets can be introduced and much more customization is possible.

We can develop new and unique games , register them in corona Labs and we can get the
executable code of the game in order to run our game on the mobiles.
VARIOUS ANNEXURES
49
Major
Appendix A
SCREENSHOTS
SCREEN: USER INTERFACE
This will be the user interface for the game. The user will reach to this interface by clicking on
Simulator option in the welcome window of the Corona Sdk.
50
Major
Screenshot A.1
SCREEN: Single-Player Interface
This is the user interface for the single player.
51
Major
Screenshot A.2
SCREEN: 2-Players Interface

This is the user interface for the 2 users gaming mode.
52
Major
Screenshot A.3
SCREEN: PLAYING GAME

These are the screenshots when user is playing game.
53
Major
Screenshot A.4
SCREEN: GAME OVER

This screenshot is showing the interface when game is over.
54
Major
Screenshot A.5
Appendix B
SOURCE CODE OF THE POOL GAME
55
Major
--A Pool Game as a major project

-- A basic game of billiards using the physics engine
local physics = require("physics")
physics.start()
physics.setScale( 60 ) -- a value for small objects
physics.setGravity( 0, 0 ) --no gravity vector
display.setStatusBar( display.HiddenStatusBar )
--Constants
local spriteTime = 100 -- sprite iteration time
local feltColorIndex = 1
local animationStop = 2.8 -- Sprite Animation Stops Below this velocity
local screenW, screenH = display.contentWidth, display.contentHeight
local viewableScreenW, viewableScreenH = display.viewableContentWidth,
display.viewableContentHeight --Screen Size properties
local ballBody = { density=0.8, friction=1.0, bounce=.7, radius=15 }
local onePlayer = 1
local twoPlayer = 2
local options = 3
--Foward Declarations
local gameOver
local mode
--Load Audio
--local buzzAudio = audio.loadSound("buzz.mp3")
local collisionAudio = audio.loadSound("ballsCollide.mp3")
--Setup Splash/Display Screen
function splash()
splashGroup = display.newGroup()
local splashBG = display.newImage("splashBG.png", true, 20, 1, true)
splashGroup:insert(splashBG)
local onePlayerButton = display.newImage( "onePlayerButton.png",
200, 550, true)
onePlayerButton.id = onePlayer
splashGroup:insert(onePlayerButton)
local twoPlayerButton = display.newImage( "twoPlayerButton.png",
200, 700, true)
twoPlayerButton.id = twoPlayer
splashGroup:insert(twoPlayerButton)
local optionsButton = display.newImage( "optionsButton.png", 200,
850, true)
optionsButton.id = options
splashGroup:insert(optionsButton)
local fillBot = display.newImage( "fill_bkg.png", true )
fillBot.rotation=180; fillBot.x = 384; fillBot.y = 1117
56
Major
splashGroup:insert(fillBot)
onePlayerButton:addEventListener("touch", init)
twoPlayerButton:addEventListener("touch", init)
optionsButton:addEventListener("touch", init)
--Buzzing Splashing screen animation
function buzzLogo()
local buzzGroup = display.newGroup()
local randBuzz = math.random(1,6)
local animationOne = 1
local animationTwo = 2
if randBuzz == animationOne then
local buzzOn = display.newImage( "neonOn.png", 150, -50,
true)
buzzGroup:insert(buzzOn)
audio.play(buzzAudio)
timer.performWithDelay(1000, function()
buzzOn:removeSelf(); end, 1)
elseif randBuzz >= animationTwo then
local buzzOff = display.newImage( "neonOff.png", 150,
-50, true)
buzzGroup:insert(buzzOff)
timer.performWithDelay(1000, function()
buzzOff:removeSelf() end, 1)
end
end
buzzTimer =
animation
timer.performWithDelay(400, buzzLogo, -1) --Loops buzz
end
--Setup Gameplay Stage
function gameStage()
stageGroup = display.newGroup()
local table = display.newImage( "table_bkg.png", true) -- "true"
overrides downsizing of large images on smaller devices
stageGroup:insert(table)
table.x = 384
table.y = 512
local tableTopColor =
display.newImage( "table"..feltColorIndex..".png", true) -- "true"
overrides downsizing of large images on smaller devices
stageGroup:insert(tableTopColor)
57
Major
tableTopColor.x = 384
tableTopColor.y = 512
local fillTop = display.newImage( "fill_bkg.png", true )
stageGroup:insert(fillTop)
fillTop.x = 384; fillTop.y = -93
local fillBot = display.newImage( "fill_bkg.png", true )
stageGroup:insert(fillBot)
fillBot.rotation=180; fillBot.x = 384; fillBot.y = 1117
local endBumperShape = { -212,-18, 212,-18, 190,2, -190,2 }
local sideBumperShape = { -18,-207, 2,-185, 2,185, -18,207 }
local bumperBody = { friction=0.5, bounce=0.5,
shape=endBumperShape }
local bumper1 =
display.newImage( "bumperEnd"..feltColorIndex..".png" )
stageGroup:insert(bumper1)
physics.addBody( bumper1, "static", bumperBody )
bumper1.x = 384; bumper1.y = 58
local bumper2 =
display.newImage( "bumperEnd"..feltColorIndex..".png" )
bumper2.x = 384; bumper2.y = 966; bumper2.rotation = 180
-- Override the shape declaration above, but reuse the other body
properties
bumperBody.shape = sideBumperShape
local bumper3 =
display.newImage( "bumperSide"..feltColorIndex..".png" )
local bumper4 =
physics.addBody( bumper4, "static", bumperBody)
local bumper5 =
local bumper6 =
58
Major

pauseBtn = display.newImage("pause.png",720,0 )
pauseBtn:addEventListener("touch",
function()
local gameState = "paused"
restartMenu(gameState)
end
)
if mode == onePlayer then

--Setup Up Player Score Board for only one player
local solidScoreBoard = display.newImage("solidScore.png")
stageGroup:insert(solidScoreBoard)
solidScoreBoard.y = 500; solidScoreBoard.x = 53;
solidTotal = 0
solidScoreText = display.newText(solidTotal, 0, 0,
native.systemFontBold, 30 )
solidScoreText:setTextColor( 0, 0, 0, 255 )
solidScoreText.x = 50; solidScoreText.y = 400;
solidScoreText.rotation = 270
timer.performWithDelay(500,
function()
local player1 = display.newImage("player1.png")
stageGroup:insert(player1)
player1.y = display.contentHeight/2; player1.x =
display.contentWidth/2; player1.alpha = 0;
local player1 = transition.to( player1, { alpha= 1,
time=400, x=53, y=540 } )
end
,1)
elseif mode == twoPlayer then
--Setup Up Player Score Board for two players
local solidScoreBoard = display.newImage("solidScore.png")
stageGroup:insert(solidScoreBoard)
solidScoreBoard.y = 500; solidScoreBoard.x = 53;
local stripeScoreBoard = display.newImage("stripeScore.png")
stageGroup:insert(stripeScoreBoard)
stripeScoreBoard.y = 500; stripeScoreBoard.x = 715;
stripeScoreBoard.rotation = 180
solidTotal = 0
solidScoreText = display.newText(solidTotal, 0, 0,
solidScoreText:setTextColor( 0, 0, 0, 255 )
59
Major
solidScoreText.x = 50; solidScoreText.y = 400;

solidScoreText.rotation = 270
stripeTotal = 0
stripeScoreText = display.newText(stripeTotal, 0, 0,
stripeScoreText:setTextColor( 0, 0, 0, 255)
stripeScoreText.x = 718; stripeScoreText.y = 602;
stripeScoreText.rotation = 90
--Player one animations
function()
local playerOneAnimation =
display.newImage("player1.png")
stageGroup:insert(playerOneAnimation)
playerOneAnimation.y = display.contentHeight/2 ;
playerOneAnimation.x = display.contentWidth/2; playerOneAnimation.alpha =
0;
local playerOneAnimation =
transition.to( playerOneAnimation, { alpha= 1, xScale= 1, yScale=1.0,
time=400, x=53, y=540 } )
end
,1)
-- Player two animations
function()
local playerTwoAnimation =
display.newImage("player2.png")
stageGroup:insert(playerTwoAnimation)
playerTwoAnimation.y = display.contentHeight/2;
playerTwoAnimation.x = display.contentWidth/2; playerTwoAnimation.alpha =
0; playerTwoAnimation.rotation = 180;
local playerTwoAnimation =
transition.to( playerTwoAnimation, { alpha= 1, xScale= 1, yScale=1.0,
time=400, x=715, y=460 } )
end
,1)
end
ballProperties()
end
--Sets up all pool ball functions
function ballProperties()
gameBallGroup = display.newGroup() --Create ball group
local v = 0
local reqForce = .18
local maxBallSounds = 4
60
Major

--OnCollision Audio
function ballCollisionAudio( self, event )
local force = event.force
local objId = event.other.id
local reqId = "spriteBall"
if force >= reqForce and reqId == objId and v <= maxBallSounds

then -- Audio Play back is determined by the amount of force
audio.play(collisionAudio)
v = v + 1
timer.performWithDelay(1000, function() v = v - 1
end, 1)
end
end
--Create cueball
cueball = display.newImage( "ball_white.png" )
gameBallGroup:insert(cueball)
cueball.x = display.contentWidth/2; cueball.y = 780
physics.addBody( cueball, ballBody )
cueball.linearDamping = 0.3
cueball.angularDamping = 0.8
cueball.isBullet = true -- force continuous collision detection, to
stop really fast shots from passing through other balls
cueball.type = "cueBall"
cueball.collision = onCollision
cueball:addEventListener("collision", cueball) -- Sprite balls start
animation on Collision with cueball
cueball.postCollision = ballCollisionAudio --Sets Event Listener for
Audio on Collision
cueball:addEventListener( "postCollision", cueball )
--Creat Rotating target
target = display.newImage( "target.png" )
target.x = cueball.x; target.y = cueball.y; target.alpha = 0;
--Ball Properties Table
local ballTable = {
{type
{type
{type
{type
{type
{type
{type
{type
{type
{type
{type
{type
{type
{type
{type
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
"solid"},
"solid"},
"solid"},
"solid"},
"solid"},
"solid"},
"solid"},
"eightBall"},
"stripe"},
"stripe"},
"stripe"},
"stripe"},
"stripe"},
"stripe"},
"stripe"}
61
Major

}
local spriteInstance = {}
local n = 1
for i = 1, 5 do
for j = 1, (6-i) do
spriteInstance[n] = display.newImage("ball_" ..
n .. ".png")
gameBallGroup:insert(spriteInstance[n])
physics.addBody(spriteInstance[n], ballBody)
spriteInstance[n].x = 279 + (j*34) + (i*15)
spriteInstance[n].y = 185 + (i*27)
spriteInstance[n].linearDamping = 0.3 -- simulates
friction of felt
spriteInstance[n].angularDamping = 2 -- stops balls
from spinning forever
spriteInstance[n].isBullet = true -- If true
physics body always awake
spriteInstance[n].active = true -- Ball is set to
active
spriteInstance[n].bullet = false -- force
continuous collision detection, to stop really fast shots from passing
through other balls
spriteInstance[n].id = "spriteBall"
spriteInstance[n].type = ballTable[n].type
spriteInstance[n].postCollision =
ballCollisionAudio
spriteInstance[n]:addEventListener( "postCollision",
spriteInstance[n] )
n = n + 1
end
end
cueball:addEventListener( "touch", cueShot ) -- Sets event
listener to cueball
setPockets()
end
--Reset cueball
function resetCueball()
cueball.alpha = 0
cueball.x = 384
cueball.y = 780
cueball.xScale = 2.0; cueball.yScale = 2.0
local dropBall = transition.to( cueball, { alpha=1.0, xScale=1.0,
yScale=1.0, time=400 } )
end
--Sets up pockets
function inPocket( self, event )
62
Major
local fallDown = transition.to( event.other, { alpha=0, xScale=0.3,

yScale=0.3, time=200 } )
local object = event.other
event.other:setLinearVelocity( 0, 0 )
if event.other.type == "cueBall" then
timer.performWithDelay( 50, resetCueball )
elseif event.other.type == "solid" and event.other.active == true
then
event.other.active = false
--Update Solid Score
solidTotal = solidTotal + 1
solidScoreText.text = solidTotal
elseif event.other.type == "stripe" and event.other.active == true
and mode == 2 then
event.other.active = false -- Prevents balls from
--Update Stripe Score
stripeTotal = stripeTotal + 1
stripeScoreText.text = stripeTotal
elseif event.other.type == "eightBall" then
gameOver()
end
end
-- Create pockets
function setPockets()
local pocket = {}
for i = 1, 3 do
for j = 1, 2 do
local index = j + ((i-1) * 2) -- a counter from 1 to 6
-- Add objects to use as collision sensors in the pockets
local sensorRadius = 20
pocket[index] = display.newCircle( -389 + (515*j), -436 +
(474*i), sensorRadius )
stageGroup:insert(pocket[index])
-- (Change this value to "true" to make the pocket
sensors visible)
pocket[index].isVisible = false
physics.addBody( pocket[index], { radius=sensorRadius,
isSensor=true } )
pocket[index].id = "pocket"
pocket[index].bullet = false
pocket[index].collision = inPocket
pocket[index]:addEventListener( "collision",
pocket[index] ) -- add table listener to each pocket sensor
end
end
end
63
Major
-- Shoot the cue ball, using a visible force vector

function cueShot( event )
local t = event.target
local phase = event.phase
if "began" == phase then
display.getCurrentStage():setFocus( t )
t.isFocus = true
-- Stop current cueball motion, if any
t:setLinearVelocity( 0, 0 )
t.angularVelocity = 0
target.x = t.x
target.y = t.y
startRotation = function()
target.rotation = target.rotation + 4
end
Runtime:addEventListener( "enterFrame", startRotation )
local showTarget = transition.to( target, { alpha=0.4,
xScale=0.4, yScale=0.4, time=200 } )
myLine = nil
elseif t.isFocus then
if "moved" == phase then
if ( myLine ) then
myLine.parent:remove( myLine ) -- erase previous
line, if any
end
myLine = display.newLine( t.x,t.y, event.x,event.y )
myLine:setColor( 255, 255, 255, 50 )
myLine.width = 15
elseif "ended" == phase or "cancelled" == phase then
display.getCurrentStage():setFocus( nil )
t.isFocus = false
local stopRotation = function()
Runtime:removeEventListener( "enterFrame",
startRotation )
end
64
Major
local hideTarget = transition.to( target, { alpha=0,

xScale=1.0, yScale=1.0, time=200, onComplete=stopRotation } )
if ( myLine ) then
myLine.parent:remove( myLine )
end
-- Strike the ball!
local cueShot = audio.loadSound("cueShot.mp3")
audio.play(cueShot)
t:applyForce( (t.x - event.x), (t.y - event.y),
t.x, t.y )
end
end
return true -- Stop further propagation of touch event
end
--Displays game over screeen
function gameOver()
gameOverGroup = display.newGroup()
local overSplash = display.newImage( "game_over.png", true )
gameOverGroup:insert(overSplash)
overSplash.alpha = 0
overSplash.xScale = 1.5; overSplash.yScale = 1.5
local showGameOver = transition.to( overSplash, { alpha=1.0,
xScale=1.0, yScale=1.0, time=500 } )
cueball:removeEventListener( "touch", cueShot )
local gameState = "gameOver"
restartMenu(gameState)
end
--In game restart menu
function restartMenu(gameState)
pauseBtn:removeSelf()
menuGroup = display.newGroup()
if gameState == "paused" then
local backDrop = display.newRect(0, 0, screenW, screenH )
menuGroup:insert(backDrop)
backDrop:setFillColor(0, 0, 0,100)
end
local restartGameImage =
display.newImage("newGameButton.png",200,200,true )
menuGroup:insert(restartGameImage)
restartGameImage.state = gameState
restartGameImage:addEventListener('touch', restartGame)
65
Major
end
--Restart Game
function restartGame( event )
local gameState = event.target.state
if event.phase == "ended" then
if gameState == "gameOver" then
gameOverGroup:removeSelf()
end
stageGroup:removeSelf() -- Removes All Stage Objects
gameBallGroup:removeSelf() --Removes Ball Objects
menuGroup:removeSelf() --Removes Menu Group Objects
timer.performWithDelay(1000, splash, 1) -- Calls splash
screen
end
end
--Displays options menu
function optionMenu()
local stroke = 5
local optionsGroup = display.newGroup() --Create options menu group
local function changeFelt(event)
local feltObject = event.target
local feltColor = event.target.id
if event.phase == "ended" then
feltColorIndex = feltColor
feltObject.selected = true
optionsGroup:removeSelf()
feltObject:setStrokeColor(16,255,4)
function()
transition.to( splashGroup, { alpha= 1,
xScale= 1, yScale=1.0, time=1000} )
end
,1)
end
end
local optionsBG = display.newImage("optionsBG.png",-5,540,true)
optionsGroup:insert(optionsBG)
local greenFelt = display.newImage( "sample1.png", 49, 701, true )
optionsGroup:insert(greenFelt)
greenFelt:setStrokeColor(255,255,255)
greenFelt.strokeWidth = stroke
greenFelt.id = "1"
greenFelt:addEventListener('touch', changeFelt)
66
Major
local purpleFelt = display.newImage( "sample2.png", 219, 701, true )

optionsGroup:insert(purpleFelt)
purpleFelt:setStrokeColor(255,255,255)
purpleFelt.strokeWidth = stroke
purpleFelt.id = "2"
purpleFelt:addEventListener('touch', changeFelt)
local redFelt = display.newImage( "sample3.png", 392, 701, true )
optionsGroup:insert(redFelt)
redFelt:setStrokeColor(255,255,255)
redFelt.strokeWidth = stroke
redFelt.id = "3"
redFelt:addEventListener('touch', changeFelt)
local tealFelt = display.newImage( "sample4.png", 565, 701, true )
optionsGroup:insert(tealFelt)
tealFelt:setStrokeColor(255,255,255)
tealFelt.strokeWidth = stroke
tealFelt.id = "4"
tealFelt:addEventListener('touch', changeFelt)
local selectFeltText = display.newText("Select a table color!", 150,
625, systemFontBold, 50 )
optionsGroup:insert(selectFeltText)
selectFeltText:setTextColor(255,255,255)
end
function init( event )

mode = event.target.id
if mode == onePlayer or mode == twoPlayer then
timer.cancel(buzzTimer)-- Removes buzzing animation
splashGroup:removeSelf()-- Removes splash screen objects
timer.performWithDelay(800, gameStage, 1)
elseif mode == options then
local splashButtonAnimation = transition.to( splashGroup,
{ alpha= 0, xScale= 1, yScale=1.0, time=400} ) -- Transitions splash Menu
to options Menu
optionMenu()
end
end
67
Major
-- Set Up Splash Screen

splash()
--Sets game splash button listeners
68
Major
Appendix C
FIGURES AND SCREENSHOTS
Figures
Page No.
Figure 1.1: The Lua icon--------------------------------------------------------------------------2

Figure 4.1: Pool table-----------------------------------------------------------------------------24
Figure 4.2: Terminology related to pool game------------------------------------------------25
Figure 4.3: Aiming a pool shot------------------------------------------------------------------25
Figure 4.4: The CIT shot-------------------------------------------------------------------------26
Figure 4.5: The SIT shot--------------------------------------------------------------------------26
Figure 4.6: Various directions in pool game---------------------------------------------------27
Figure 4.7: Terminology related to directions-------------------------------------------------27
Figure 4.8: Various paths to play ---------------------------------------------------------------28
Figure 4.9: Various paths-------------------------------------------------------------------------28
Figure 4.10: Side spin shots ---------------------------------------------------------------------29
Figure 4.11: Kick and bank shots----------------------------------------------------------------29
Figure 4.12: Different platform for corona apps-----------------------------------------------31
Figure 4.13: Context diagram for the game----------------------------------------------------35
Figure 4.14: Flow chart for the game-----------------------------------------------------------36
Figure 6.1: Levels of testing---------------------------------------------------------------------43
69
Major
Screenshots:
Page No.
Screenshot 1.1: Corona simulator----------------------------------------------------------------4

Screenshot 1.2: Corona Welcome window-----------------------------------------------------6
Screenshot 4.1: Corona UI----------------------------------------------------------------------37
Screenshot 5.1: Corona registration and log in window ------------------------------------39
Screenshot 5.2: Registration successful window---------------------------------------------39
Screenshot A.1: User interface of 8 ball pool game------------------------------------------47
Screenshot A.2: Single-player game interface------------------------------------------------48
Screenshot A.3: 2-players game interface-----------------------------------------------------49
Screenshot A.4: Playing mode game interface-----------------------------------------------50
Screenshot A.5: Game over----------------------------------------------------------------------51
Appendix D
70
Major
ABBREVIATIONS USED
2D: 2-Dimensional
3D: 3-Dimensional
API: Application Programming Interface
CB: Cue Ball
CIT: Cut-Induced Throw
GB: Ghost-Ball
GPS: Global Positioning System
HD: High Dimension
IPT: International Pool Tour
OB: Object-Ball
OpenGL: Open Graphics Library
SDK: Software Development Kit
SIT: Spin-Induced Throw
RSS: Really Simple Syndication
Appendix E
71
Major
BIBLIOGRAPHY / REFERENCES
We took help from the following books to prepare this report:
Fernandez, Michelles Corona SDK Mobile Game Development: Beginner's Guide
Burton, Ed.D., Brians Mobile App Development with Corona (1st ed.)
Dave Shreiner, The Khronos OpenGL ARB Working Group: OpenGL Programming
Guide: The Official Guide to Learning OpenGL(8th Edition)
Ierusalimschys Programming in Lua (2nd ed.)

Jung, K. Browns Beginning Lua Programming.
Websites: www.wikipedia.com
www.1000projects.com
www.coronalabs.com
www.gamecareerguide.com
www.lua.org
www.google.com
72

8-ball Pool Game Development

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

8-ball Pool Game Development

Uploaded by

Copyright:

Available Formats

Major

project UIIT 8th semester