Document on mutli player strategy game

Software Requirements
Specification for

Multi Strategy-Game Version

Prepared by

A.Vishnu

A-24
 Document on mutli player strategy game

Table of Contents

Table of Contents ....................................................................................................

Revision History ..................................................................................................... 1.
Introduction ........................................................................................................

1.1 Purpose ......................................................................................................

1.2 Document Conventions .............................................................................
1.3 Intended Audience and Reading Suggestions ...........................................
1.4 Project Scope ............................................................................................. 1.5
References .................................................................................................

2. Overall Description
2.1 Product Perspective ...................................................................................
2.2 Product Features ........................................................................................
2.3 User Classes and Characteristics ...............................................................
2.4 Operating Environment .............................................................................
2.5 Design and Implementation Constraints ...................................................
2.6 User Documentation .................................................................................. 2.7 Assumptions
and Dependencies ................................................................
 3. System Features .................................................................................................
3.1 Face Submission ........................................................................................
3.2 Facial Expression Matching ......................................................................
3.3 Credits Given For Astropolis Colony Sim ................................................ 3.4 Events
Logged ...........................................................................................

4. External Interface Requirements .......................................................................

4.1 User Interfaces ...........................................................................................
4.2 Hardware Interfaces ..................................................................................
4.3 Software Interfaces .................................................................................... 4.4
Communications Interfaces .......................................................................

5. Other Nonfunctional Requirements ...................................................................

5.1 Performance Requirements .......................................................................
5.2 Safety Requirements .................................................................................
5.3 Security Requirements ..............................................................................
5.4 Software Quality
Attributes ...................................................................... ...................................................
.........................................................................

WHAT DOES SRS MEAN?

A software requirements specification (SRS) is a description of a

software system to be developed. It lays out functional and
nonfunctional requirements, and may include a set of use cases that
describe user interactions that the software must provide.

Software requirements specification establishes the basis for an

agreement between customers and contractors or suppliers (in
market-driven projects, these roles may be played by the marketing
and development divisions) on what the software product is to do as
well as what it is not expected to do.

Software requirements specification permits a rigorous assessment

of requirements before design can begin and reduces later redesign.
It should also provide a realistic basis for estimating product costs,
risks, and schedules. Used appropriately, software requirements
specifications can help prevent software project failure.

The software requirements specification document enlists enough

and necessary requirements that are required for the project
development.

To derive the requirements we need to have clear and thorough

understanding of the products to be developed or being developed.
This is achieved and refined with detailed and continuous
communications with the project team and customer till the
completion of the software.

The SRS may be one of a contract deliverable Data Item Descriptions

or have other forms of organizationally-mandated content.

HISTORY

Strategy video games are a video game genre that focuses on skilful
thinking and planning to achieve victory. It emphasizes strategic,
tactical, and sometimes logistical challenges. Many games also offer
economic challenges and exploration. They are generally categorized
into four sub-types, depending on whether the game is turn-based or
real-time, and whether the game focuses on strategy or tactics

A strategy game or strategic game is a game (e.g. video or

board game) in which the players' uncoerced, and often
autonomous decision-making skills have a high significance in
determining the outcome. Almost all strategy games require
internal decision tree style thinking, and typically very high
situational awareness.

The term "strategy" comes ultimately from Greek, (στρατηγια or

strategia) meaning generalship. It differs from "tactics" in that it
refers to the general scheme of things, whereas "tactics" refers
to organization and execution.

Types
1.1Abstract strategy
1.2Team strategy
1.3Eurogames
1.4Simulation
1.5Wargame
1.6Strategy video games
Abstract strategy
In abstract strategy games, the game is only loosely tied to a
thematic concept, if at all. The rules do not attempt to simulate
reality, but rather serve the internal logic of the game.

A purist's definition of an abstract strategy game requires that it

cannot have random elements or hidden information. This definition
includes such games as chess, Go and Arimaa (a game with multiple
moves within a turn). However, many games are commonly classed
as abstract strategy games which do not meet these criteria: games
such as backgammon, Octiles, Can't Stop, Sequence and Mentalis
have all been described as "abstract strategy" games despite having
a chance element.[citation needed] A smaller category of non-perfect
abstract strategy games incorporate hidden information without
using any random elements; for example, Stratego.

Team strategy
One of the most focused team strategy games is contract bridge. This
card game consists of two teams of two players, whose offensive and
defensive skills are continually in flux as the game's dynamic
progresses. Some argue that the benefits of playing this team
strategy card game extend to those skills and strategies used in
business [3] and that the playing of these games helps to automate
strategic awareness.
Eurogames
Main article: Eurogame
Eurogames, or German-style boardgames, are a relatively new genre
that sit between abstract strategy games and simulation games.
They generally have simple rules, short to medium playing times,
indirect player interaction and abstract physical components. The
games emphasize strategy, play down chance and conflict, lean
towards economic rather than military themes, and usually keep all
the players in the game until it ends.

Simulation
This type of game is an attempt to simulate the decisions and
processes inherent to some real-world situation. Most of the rules are
chosen to reflect what the real-world consequences would be of each
player action and decision. Abstract games cannot be completely
divided from simulations and so games can be thought of as existing
on a continuum of almost pure abstraction (like Abalone) to almost
pure simulation (like Strat-o-Matic Baseball).

Wargame
Main article: Wargaming
Wargames are simulations of military battles, campaigns or entire
wars. Players should consider situations that are analogous to the
situations faced by leaders of historical battles. As such, war games
are usually heavy on simulation elements, and while they are all
"strategy games", they can also be "strategic" or "tactical" in the
military jargon sense.
Traditionally, wargames have been played either with miniatures,
using physical models of detailed terrain and miniature
representations of people and equipment to depict the game state; or
on a board, which commonly uses cardboard counters on a hex map.

Popular miniature wargames include Warhammer 40,000 or its

fantasy counterpart Warhammer Fantasy. Popular strategic board
wargames include Risk, Axis and Allies, Diplomacy, and Paths of
Glory. Advanced Squad Leader is a successful tactical scale wargame.

Strategy video games

Main article: Strategy video game
Strategy video games are categorized based on whether they offer
the continuous gameplay of real-time strategy (RTS), or the discrete
phases of turn-based strategy (TBS). Often the computer is expected
to emulate a strategically thinking "side" similar to that of a human
player (such as directing armies and constructing buildings), or
emulate the "instinctive" actions of individual units that would be too
tedious for a player to administer (such as for a peasant to run away
when attacked, as opposed to standing still until otherwise ordered
by the player); hence there is an emphasis on artificial intelligence.

MULTI PLAYER VIDEO GAME MEANS??

A multiplayer video game is a video game in which more than one
person can play in the same game environment at the same time.
Video games are often single-player activities, putting the player
against pre-programmed challenges or AI-controlled opponents
(which lack the flexibility of human thought). Multiplayer games
allow players interaction with other individuals in partnership,
competition, or rivalry, providing them with social communication
absent from single-player games. In multiplayer games, players may
compete against two (or more) human contestants, work
cooperatively with a human partner to achieve a common goal,
supervise other players' activity, co-op, and objective-based modes
assaulting (or defending) a control point. Multiplayer games typically
require players to share the resources of a single game system or use
networking technology to play together over a greater distance.

In this strategy game I want to describe about astropolis game,how

the srs requirement has made for it.
BLOCK DIAGRAM ON MULTIPLAYER STATEGY
GAME
1. Introduction
1.1 Purpose
This SRS is for a video game which will be used to test people with
Autism spectrum conditions. This game will be embedded inside of a
larger game, called Astropolis, which contains a number of other
mini-games.
1.2 Document Conventions
N/A

1.3 Intended Audience and Reading Suggestions

This document should be read by the developers, customers, and
Faculty advisor. The developers should read every section to ensure
that there is an understanding for the project. The main sections for
the customers and faculty advisor to review are section 1.4 Project
Scope, 2.7 Assumptions, and section 3. Features.

1.4 Project Scope

The purpose of this software can be broken down into two major
goals. The first is to allow experimental data to be collected from the
players of the game. This data is valuable in the research of Autism
Spectrum conditions. The second goal is to have a fun game that
actually helps people with Autism Spectrum conditions to recognize
facial expressions. This goal is important because many people with
Autism spectrum conditions have difficulty in recognizing emotions
based on facial expressions.
1.5 References
google

2. Overall Description
2.1 Product Perspective
The Astropolis Mini-game will be a new addition to Astropolis, which
is a colony simulator that contains a number of mini-games. The new
mini-game will rely on some previously implemented components
and resources of the Astropolis game.

2.2 Product Features

1. The mini-game will display faces with varying expressions.
These faces will be images of people which can be easily
replaced by the customer.
2. Players will be awarded points for matching a face portraying a
certain emotion with other faces showing the same
emotion.
3. Players will be awarded credits for the Astropolis colony
simulator after completing the mini-game.
4. All of the player’s moves and game events will be logged into a
file with a timestamp.
5. Multiple levels will exist, with varying degrees of difficulty.

2.3 User Classes and Characteristics

The set of users who will most frequently use this software will have
an Autism spectrum condition. These conditions vary greatly, but the
main user audience will consist of high-functioning Autistic spectrum
users. The target demographic will be children and young adults, but
the experimental data collected would be valuable from any age
group.

2.4 Operating Environment

The Astropolis mini-game will require the XNA 2.0 redistributable in
order to run on a client’s machine. This software can only be run in
Microsoft Windows XP or greater. When a test is being executed in
the lab there will be additional hardware, including an EEG reader.
This additional hardware is not integrated with the game, and will
run independently.

2.5 Design and Implementation Constraints

The main design constraint is that the game must be playable by
people with Autism spectrum conditions, therefore the proper
considerations must be made for the users. There are certain safety
requirements that we must follow. See section 5.2.

The mini-game will be written in C# using the XNA libraries and

functions. Therefore, the mini-game will comply to the programming
practices of C#. The delivered software will be open-source and
maintained by Belmonte Labs.

2.6 User Documentation

There will be a basic tutorial document along with an in game
tutorial to aid users.
2.7 Assumptions and Dependencies
1. The Astropolis event logger component will be fully functional
and available to the mini-game.
2. XNA 2.0 remains stable and compatible with Windows XP and
greater.
3. The Astropolis game will be functional.
3. System Features
3.1 Face Submission

3.1.1 Description and Priority

The customer and end-users should be able to easily up-load an
image into the game to be used. When uploading an image, the user
should be able to specify which category of emotion that the picture
belongs to. This task is of Low priority.
3.1.2 Stimulus/Response Sequences
When starting the mini-game, the user will be given the option
on the main menu to add faces to the game. This will load an
interface that will as for the path to the desired picture and the
emotion of the picture. The system will then save the image into a
directory based on the emotion of the face.

3.1.3 Functional Requirements

REQ-1: A picture must be added to the game.
REQ-2: A picture must be associated with the correct emotion.

3.2 Facial Expression Matching

3.2.1 Description and Priority
Users will be rewarded points for identifying which faces are missing
from the game board. Refer to section 3.2.2 for more details. This
feature is High priority.

3.2.2 Stimulus/Response Sequences

The users should be presented a game board of faces in a grid. See
Appendix for screenshot. Certain faces will be removed from the grid and
lined up at the bottom of the screen. The user must select which missing
face will create a row of 3 identical emotions in the game board.

3.2.3 Functional Requirements

REQ-1: A game board will exist in a 3x4, 4x4, or 4x5 grid.

REQ-2: The game board will be filled with faces depicting emotions.
REQ-3: Random faces will be removed from the board and replaced
with a blank space.
REQ-4: Faces will appear in a row at the bottom of the screen
outside of the grid one-by-one at an interval of 1 second +- a 200
millisecond jitter.
REQ-5: Players can place a face back on the game board by clicking
on the face and then clicking on the blank space on the board.
REQ-6: Players can remove faces they have placed by clicking on the
face and pressing a remove button.
REQ-7: Players will press a button labeled “Submit” to begin
validation of the game board.
REQ-8: Players can press “Submit” with one or more blank space
filled with their answer.
REQ-9: Pressing “Submit” will validate the board by checking to
see if the filled in spaces connect 3 like emotions.
REQ-10: After pressing “Submit”, if the user-filled blank space does
not connect 3 like emotions horizontally or vertically, then the answer
was incorrect and the face is removed from the board and placed
back at the bottom of the screen outside the grid.
REQ-11: If the answer was incorrect then the player looses points.
REQ-12: After pressing “Submit”, if the user-filled blank space
connects 3 like emotions horizontally or vertically then the player will
be rewarded points.
REQ-13: After pressing “Submit”, bonus points will be given if the
player gets multiple correct answers.
REQ-14: There will always be faces available that will successfully
connect 3 like emotions.

UML DIAGRAM
3.3 Credits Given For Astropolis Colony Sim
3.3.1 Description and Priority
The completion of the mini-game will result in a reward for the
player which can be used in the Astropolis colony simulator. This
reward, along with the players score will be shown after the
minigame is completed on an End Game screen. Medium Priority.

3.3.2 Stimulus/Response Sequences

The stimulus would be the completion of the min-game. The
user is presented an End Game screen and must press the ‘Space-bar’
to exit back to Astropolis.

3.3.3 Functional Requirements

REQ-1: A screen is presented at the mini-games completion which
shows score and statistics.
REQ-2: A reward will be given which can be used in the colony
simulator based on performance in the mini-game.
REQ-3: Users press ‘Space-bar’ to exit back to Astropolis from the
End Game screen.

3.4 Events Logged

3.4.1 Description and Priority
All of the events in the game are logged into a file with the
event name and time stamp. High Priority.
3.4.2 Stimulus/Response Sequences
Events from the system and user will be logged constantly.
Events include: The appearance of the faces, the selection of faces,
the placement of faces, etc.
3.4.3 Functional Requirements
REQ-1: Each log entry must have a timestamp.
REQ-2: All events are logged in a log file.

3.5 Multiple Levels

3.1.1 Description and Priority
The mini-game will consist of multiple levels. At the completion
of a level, another board will be generated. Each new board
generated will be slightly more challenging by adding new rows or
columns to the board, adding more possible faces to fill-in the blank
spaces with, or by adding emotions to the board that have subtle
differences. This task is of High priority.

3.1.2 Stimulus/Response Sequences

Each level will be randomly generated when the new level is
started.

3.1.3 Functional Requirements

REQ-1: At the completion of a level, a new level will be generated.
REQ-2: At the completion of the 5th level, the game will end.
REQ-3: More points will be given for more difficult levels.
4. External Interface Requirements
4.1 User Interfaces
The look and feel must match the current Astropolis look and feel and
must capture part of the space theme prevalent throughout the
program. Other then these specific constraints the UI we have free
reign as long as we also are cautious of using autistic friendly UI
designs. Any instruction will have to be visual and be concise
complicated procedures will prove difficult for Autistic users.

4.2 Hardware Interfaces

There are 2 interfaces for us to interact with keyboard and mouse.
Both of these are handled by the XNA classes and will mostly be
simple for us to interact with. The program requires rather modest
computer hardware.

4.3 Software Interfaces

The game currently only supports the windows operating systems (XP,
Vista, Windows7). There will be two software interfaces one between
our game and the overlying Astropolis program and then between
our game and the ECS monitoring software. This first one will be
mostly the sharing of some underlying code and DLL’s. The second is
much more loosely coupled as we just write events out to a interface
and that will handle the monitoring of the player.

4.4 Communications Interfaces

There aren’t any communication interfaces as currently the game is
single player and does not send out the data it collects unless run in
the lab.

5. Other Nonfunctional Requirements

5.1 Performance Requirements
The game must be able to run at 50-60 frames per second on
Windows platform OS. At this frame rate, the game will remain
constant and playable. It will not be technically demanding and able
to run on lower end computers.

5.2 Safety Requirements

The main safety concern that we will be dealing with is the possibility
of inducing seizure in the user. Some autistic children are very
susceptible to flashing lights and this can be problematic. To
safeguard against this we will try to keep flashing lights and rapid
screen movements down to a minimum. We will not flash the screen
or change colors rapidly when it is unnecessary to do so.

5.3 Security Requirements

Security will not be a concern for this project since there is no
sensitive data being stored.

5.4 Software Quality Attributes

The two main quality attributes that the astropolis mini-game will be
focusing on is correctness and usability. The system needs to be able
to track time correctly. Since the mini-game will need to record
events and timestamp them with extremely high accuracy, it is
important that the timing is accurate and consistent. If the of these
events were to be off by a small amount then the research data
provided could be incorrect.
Usability is also a priority because this is a game. If the user were to
be confused or annoyed by the User interface, then the game would
be less enjoyable. There are also special considerations for autistic
children to include when developing the UI. These are more detailed
on the autisim collab wiki.