INTRODUCTION

Objective
The aim of this project is to develop gaming software that can perform the following
objectives.
Computer Animation and Game Development graduates will have an understanding of
critical and aesthetic issues in computer graphics and mixed -media.
They will know basic aesthetic principles and concepts, and the production process.
They will be able to effectively use technical, conceptual and critical abilities, and
appropriate technology tools.
They will be effective written and oral communicators with the ability to function an
effective member of collaborative multi-disciplinary teams in the production process.
They will be able to critically evaluate computer graphics and the mixed media.
They will have an appreciation for the professional code of ethics for the creative process
and stages of the game development process. Attend of the project, each group is
required to demonstrate their game and present their work to the class.

Scope
As we know Gaming is one of the largest segments of the entertainment industry and is
considered the hottest profession widely across the world. It is a demanding career in today's
modern world. With the wide access to the internet has created a humongous demand for
online games and with the advent of technology, this industry is growing at fast pace. So, a
plethora of career options is available for as parents from artists to musicians to sound
engineers to programmers in this field. So, thinking about a career in the gaming industry: A
career in Gaming Industry is exciting but a strikingly competitive field with a combination of
creativity, technology, and fun. It is always an interesting and unique career for those who are
passionate about gaming and commit their lives to creating new and improved games. So,
creating a new game is not an easy task, as the competition rate is high and the game industry
is changing on a daily basis while more and more games are invented.
Therearezillionopportunitiesavailableinthegamingindustryhasitisahappening career for
youngsters. And, for those who want to be a part of the exciting of creating a new video but it
Is done by a team of skilled individual sand their work profile varies according to their
designations. Candidates securing a job in the Gaming industry must have acknowledge of
designing, programming, fine arts, software development, and framing.
 SDLC (GAMING SYSTEM)

1. Idea/Concept/Story of the product written in the Game Concept

Document.
2. Game Design/UI/Environment/Characters/Levels/Missions /Audio/story
board of the product written in the Game Design Document.
3. Technical Requirement Analysis of Framework/Plugins/Data/Scripts/Scene
Management/Software Pattern/Object pooling/UI

Development as Game Architecture for prototyping of the product written

in the Technical Specification Document.
4. Programming/Development-of the product written in the Technical
Design Document.
5. Testing –of the product written in Test Cases and Test Plans.
6. Deployment on the publishing platform of the product written as Release
Notes &Support Document.
Feasibility Study
The use of low-cost interactive game technology for balance rehabilitation has
become more popular recently, with generally good out comes. Very little
research has been undertaken to determine whether this technology is
appropriate for balance assessment. The Wii balance board has good reliability
and is comparable to a research grade for copulate; however, recent studies
examining the relationship between Wii Fit games and measures of balance and
mobility demonstrate conflicting findings. This study found that the Wii Fit was
feasible for community dwelling older women to safely use the balance board and
quickly learn the Wii Fit games. The Ski Slalom game scores were strongly
correlated with several balance and mobility measures, whereas Table Tilt games
cores were not. Based on these findings, the Ski Slalom game may have utility in
the evaluation of balance problem sin community-dwelling older adults.
 PROJECT PLANNING
Initial Planning
The design frame work laid at the project’s origin will determine the course for
the entire project’s development. It is important tore member at this step that
nothing is set in stone, but you should attempt be as accurate as possible.

Feature List
First, analyze the Design document and determine the game’s list of
requirements. Then, split out each requirement into a list of features that will be
required to implement the requirement. Breaking Down the Tasks
Take each feature and work with your Leads in each area (art, animation,
programming, sound, level design, etc.) to break it down into tasks for each
department (group, person, depending on the size of your team).

Assigning Tasks
The lead of each group should then create initial time requirement estimates for
each task, and then assign them to team members. This complete, he should
work with his team to ensure that his estimates are correct and reasonable.
Dependencies
The project manager then must take all of the task estimates and place the min
to a project management software package, whether it is Microsoft Project, Excel
(the two long-time industry standards), or any of the newer choices available for
agile project management.

Once the tasks are added, the project manager must look at the tasks and match
dependencies between team stone sure that the timing of creating a feature
don’t have impossible relationships that prevent them from being completed
within necessary time frames. For example, in order to fully implement a racing
game, you would not schedule the coding of tire durability before the completion
of the physic system you would have no frame work to base the tire code upon.
Scheduling
This is where things get particularly complicated, but where the need to do
project management in the first place becomes more apparent.

The project manager then assigns estimated start and completion dates for each
task. In traditional project planning, you end up with a cascading “water fall”
view, which shows the time line for completion of the project and the
dependencies that link the tasks together.

In order to do this, it is critical tore member of actor in slippage, employee sick

time, unexpected delays on features, etc. This is a time consuming step, but it will
quickly give you an idea of exactly how much time the project will actually take to
complete.

What to Do with the Data

By looking at this project plan, you have the ability to determine if a feature is
going to be costly in time (and therefore, money), and make decisions about
whether the feature is necessary for the game to succeed. You may decide that
pushing a feature to an update—or even a sequel—makes more sense.

Also, tracking how long you’ve worked on a feature issue full in determining if it is
time to either try a technique to solve the problem, or cut the feature for the
good of the project.

Milestones
A frequent use of project planning involves the creation of milestones.
Milestones indicate where certain element of functionality, time period of
working on the project, or percentage of the tasks has been completed.

For internal project tracking, milestones are useful for planning purposes, and
giving the team specific goals to aim for. When working with a publisher,
milestones frequently determine how and when the developing studio is paid.

Final Notes
Project planning is regarded by many as a nuisance, but you will almost always
find that the developers who pre-plan projects and hit their milestones are the
ones who succeed in the long run.
 Software Requirement Specification
A software requirements specification (SRS) is a description of a software system
to be developed. It is modelled after business requirements specification
(CONOPS), also known as a stake holder requirements specification (SRS). The
software requirements specification lays out functional and non-functional
requirements, and it may include a set of use cases that describe user
interactions that the software must provide.

FOR EXAMPLE, SRS OF CHESS GAME-

Contents:
1 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Definitions
1.4 Overview
2 OVER ALL DESCRIPTION
2.1 Product perspective
2.1.1 System interfaces
2.1.2 User interfaces
2.1.3 Hardware interfaces
2.1.4 Software interfaces
2.1.5 Communications interfaces
2.1.6 Memory constraints
2.1.7 Operations
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions & dependencies
2.6 Requirements Apportioning
3 SPECIFIC REQUIREMENTS
3.1 User interface
4 USE CASES
4.2.1 Connect
4.2.2 Move
4.2.3 Redo
4.2.4 Resign
4.2.5 Save Log
1 INTRODUCTION

1.1 Purpose
This document specifies all the requirements for the Chess game software. These
requirements relate to the functionality, constraints, performance, attribute and the
system interface.
The Chess program is a program used to play game. First goal is to allow two users or
player stop play the game interactively from remote locations. And the second goal will
be that the program should be working and allow the users to play the game.

1.2 Scope
This document describes the software requirements for the Chess program. This
document will be used by the end-users, tester, and developers of the game.

1.3 Definitions
Bishop: one of two pieces of the same color that may be moved any number squares
diagonally, as long as no other piece block sits way. One piece always remains on White
squares and the other always on Black.

Castling: to move the king two squares horizontally and bring the appropriate rook to
the square the king has passed over.

Check: To make a move that puts the opponents King under direct attack.

Checkmate: a situation in which an opponent’s king is in check and it cannot avoid

being.

Captured. This then brings the game to a victorious result.

Chess Board: A board you need to play Chess. Have 64 black and white square.

Chess: A game played by 2 people on aches board with 16 pieces each.

Renasant: a method by which a pawn that is moved two squares can be captured by an
opponent's pawn commanding the square that was passed

King: The main piece of the game, checkmating this piece is the object of the game. It
can move 1 space in any direction.

Queen: This piece can move in any number of spaces in any direction as long as no
other piece is in its way.
2 OVERALL DESCRIPTIONS

2.1 Product perspective

Universitystudentsneedanentertainmenttooltoenjoyandplaywithfriendsover the network. As

described in section1.2, of this document, CHESS intent of ill this
needbyprovidingsoftwarewhichallowsentertainmentwithfriendsandoverthe network. Some
software games allow playing games with people that you may not know, and often times
require a monthly fee for the service.

ENTITY RELATIONSHIP DIAGRAM

What is an ER diagram?
An Entity Relationship (ER) Diagram is a type off low chart that illustrates how “entities” such
as people, objects or concepts relate to each other with in a system. ER Diagrams are most
often used to design or debug relational data bases in the fields of software engineering,
business information systems, education and research. Also known as ERDs or ER Models,
they use a defined set of symbols such as rectangles, diamonds, ovals and connecting line
stodepict the inter connectedness of entities, relationships and their attributes.They mirror
grammatical structure, with entities as nouns and relationships as verbs.

How to draw a basic ER diagram

1.Purpose and scope: Define the purpose and scope of what you’r eanalyzing or
modeling.
2.Entities: Identify the entities that are involved. When you’re ready, start drawing them
in rectangles (or your system’s choice of shape) and labeling the masnouns .
3.Relationships: Determine how the entities are all related. Draw lines between the
mto signify the relationships and label them. Some entities may not be related, and
that’s fine. In different notation systems, the relationship could be labeled in a
diamond, another rectangle or direct ly on top of the connecting line .
4.Attributes: Layerinmoredetailbyaddingkeyattributesof
entities.Attributesareoftenshownasovals.
5.Cardinality: Showwhethertherelationshipis1-1,1-manyor many-to-many.
ER Diagram of Gaming System
UNIFIED MODELING LANGUAGE (UML) OVERVIEW

Unified Modeling Language (UML) is a graphical language for visualizing,

specifying, constructing, and documenting the artifacts of a software-intensive
system. It offers a standard way to write a system’s blueprints, including
conceptual things such as business processes and system functions as well as
concrete things such as programming language statements, database schemas,
and reusable software components.

Introduction
Unified Modeling Language (UML) is a standardized general-purpose modeling
language in the field of object-oriented software engineering. UML includes a
set of graphic notation techniques to create visual models of object-oriented
software systems. UML combines techniques from data modeling, business
modeling, object modeling, and component modeling and can be used
throughout the software development life-cycle and across different
implementation technologies.

Modeling
There is a difference between a UML model and the set of diagrams of a
system. A diagram is a partial graphic representation of a system’s model.
The model also contains documentation that drives the model elements and
diagrams (such as written use cases).

Diagrams Overview
UML has 14 types of diagrams divided into multiple categories.

1. Use Case Diagram

Describes the functionality provided by a system in terms of actors,
their goals represented as use cases, and any dependencies among
those use cases.

2. Class Diagram
Describes the structure of a system by showing the system’s classes, their
attributes, and the relationships among the classes.
3. Object Diagram
Shows a complete or partial view of the structure of an example modeled
system at a specific time.

4. Sequence Diagram
Shows how objects communicate with each other in terms of a sequence of
messages. Also indicates the lifespans of objects relative to those messages.
5. State Diagram
Describes the states and state transitions of the system.
6. Activity Diagram
Describes the business and operational step-by-step workflows of components
in a system. An activity diagram shows the overall flow of control.
7.Collaboration Diagram
A collaboration diagram, also known as communication diagram or interaction
diagram. It shows the interactions between objects or parts in terms of
sequenced messages. They represent a combination of information taken
from Class, Sequence, and Use Case Diagrams describing both the static
structure and dynamic behavior of a system.

8. Component Diagram
Describes how a software system is split-up into components and shows the
dependencies among these components.
9. Deployment Diagram
Describes the hardware used in system implementations and the execution
environments and artifacts deployed on the hardware.

Conclusion
In conclusion, our aim of this project is to develop gaming software that can
perform Computer Animation and understanding of critical and aesthetic
issues in computer. User will be able to critically evaluate computer graphics
and the mixed media. User will have an appreciation for the professional code
of ethics for the creative process and stages of the game development process.
As we know Gaming is one of the largest segments of the entertainment
industry and is considered the hottest profession widely across the world, a
plethora of career options is available for as parents from artists to musicians
to sound engineers to programmers in this field. It is a demanding career in
today's modern world. Candidates securing a job in the Gaming industry must
have acknowledge of designing, programming, fine arts, software
development, and framing. We make a Gaming System in UML by constructing
various diagram.