sample Zombiquarium SRS - Stony Brook University

ruralrompSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

78 views

1




Zombiquarium
TM

Software Requirements Specification




















Author
:

Richard McKenna

Debugging Enterprises
TM


Abstract:

This document descr
ibes the program requirements for

Zombiq
uarium, a casual
mini
-
game

to be developed and included as part of

Plants vs. Zombies. The program interface
and functionality with both be described as well as the overall goals of the project.


Based on IEEE Std 830
TM
-
1998 (R2009) document format


Copyright © 2011 Debugging Enterprises, which is a made up company and d
oesn’t really own
Zombiquarium, PopCap Games does.

Please note that this document is fictitious in that it simply serves
as an example for CSE 219 students
at Stony Brook University
to use in developing their own SRS.


No part of this publication may be re
produced in any form, in an electronic retrieval system or
otherwise, without the prior written permission of the publisher.

2


1

I
ntroduction


What could be more fun than
zombies creeping across your front lawn? How about snorkeling zombies
in a fish tank?
How about feeding snorkeling zombies in a fish tank? How about feeding snorkeling
zombies in a fish tank to prevent them from starving to death? Now we’re onto something.



1.1

P
urpose


The purpose of this document is to precisely specify how our Zombiquarium

mini
-
game should look and
play.

The intended audience for this document is all the members of the development team, from the
game designers to the artists, to the software engineers and even salespeople who will ultimately
interface with the customers. Th
is document serves as an agreement among all parties and a reference
for how the game should ultimately be constructed.

Upon completing the reading of this document, one
should clearly visualize how the game application will look and operate as well as und
erstand the game
rules.



1.2
Scope


Zombiquarium will be one mini
-
game among many to be included in the Plants vs. Zombies application.
Tools for its construction should be developed with this in mind such that additional mini
-
games may
avoid duplicati
on
of work. As such, a framework called the MiniGame Framework,

should be
constructed
to be used to make Zombiquarium as well as the other mini
-
games. Note that the point of
Zombiquarium is simply to entertain. It will be a simple point and click game using a
rtwork from the
main Plants vs. Zombies game as well as some new content.

This is not to be a game with a lot of depth
of play, just a simple, fun, little game that the player may pick
-
up and complete in 10
-
15 minutes.



1.3

Definitions, acronyms, and abbrevia
tions



Casual Game


A game that can be picked up and played quickly, where 15 minutes of entertainment
may suffice, but typically where richer experiences are also possible.


IEEE


Institute of Electrical and Electronics Engineers
, the “world’s largest

professional association
for the advancement of technology”.


Fram
e
work



In an object
-
oriented language, a collection
of classes and interfaces
that collectively
provide a service for building
applications or additional frameworks all with a common need
.


GUI



Graphical User Interface,
visual controls like buttons inside a window in a software application
that collectively allow the user to operate the program.


Java



A high
-
level programming language that uses a virtual machine layer between the Java
a
pplication and the hardware to provide program portability.

3



Mini
-
Game



A standalone game that is a subset of a larger game application, typically sharing the
primary game theme with that parent game application.


Mini

Zombie
Game Fram
e
work



The software

framework to be developed in tandem with the
Zombiquarium game such that additional mini
-
games can easily be constructed.


Plants vs. Zombies



The PopCap Games game that is the parent application of our Zombiquarium
mini
-
game. Note that Zombiquarium is t
o be distributed as part of that program.


Playtesting



The process of playing a game, getting feedback on it, and incorporating that feedback
into tweaking the game in order to improve it.


UML



Unified Modeling Language, a standard set of document form
ats for designing software
graphically.


Use Case Diagram



A UML document format that specifies how a user will interact with a system.
Note that these diagrams do
not include technical details. Instead, they are fed as input into the design
stage (stage
after this one) where the appropriate software designs are constructed based in part on the
Use Cases specified in the SRS.


Zombie



An undead creature, meaning something that has died and then come back to life. These
beings are typically slow moving and

love to eat brains.


Zombiquarium



The title of the mini
-
game described by this document. Again, note that this game
will be distributed as part of the Plants vs. Zombies application.



1.4

References



IEEE Std 830
TM
-
1998 (R2009)



IEEE Recommended Practice

for Software Requirements
Specification



1.5

Overview


This SRS will
clearly define how the Zombiquarium game should look and operate as well as how to
actually play the game. Note that this is not a software design document. This document does not
specify h
ow to build the appropriate technologies, it is simply an agreement concerning what to build,
not how to build it. Section 2 of this document will provide the context for the project and specify all the
conceptual design, including the game rules and param
eters. Section 3 will present how the game
interface should be laid out and all program functionality. Section 4 provides a Table of Contents, an
Index, and References.


4


2

Overall description


Gamers love variations on a theme. They love
playing games with
different modes and perspectives
that
share

a common thread. And so, gamers love mini
-
games that fit neatly into a broader context. Our
broader context is that zombies are trying to eat your brain. The primary gameplay in Plants vs. Zombies
hammers that po
int home. Mini
-
games work around that theme, giving the player alternative scenarios
and gameplay mechanics that enrich the overall experience of playing the game. Zombiquarium turns
the context on its head, allowing the player to feed brains to pet snorke
ling zombies in order to preserve
zombie life.




2.1

Product perspective


Casual games should be easy to pickup and put down. They should be easy to learn to play and should
not take an eternity to complete. Gameplay mechanics should be simple and straightfor
ward, with an
emphasis on mouse
-
clicks rather than keyboard short
-
cuts and

on easing a player into more complex
gameplay mechanics. Games such as these are particularly popular on mobile devices, where a player
can entertain oneself on a 15 minute subway r
ide. Note that the ease of use and frequent feedback via
rewards are common requirements for casual games like Angry Birds and Diner Dash, but this does not
have to mean that the game is overly simple. The best casual games should cultivate player skills a
nd
reward game advancement with more difficult tasks. Line balancing
, for example, is a common task in
these games because it can be easy to present in a gaming context, but difficult to master at advanced
levels for the gamer, and thus can provide a rich,

rewarding gaming experience.



2.1.1

System Interfaces


The Zombiquarium mini
-
game will ultimately fit into the larger Plants vs. Zombies game application.
This application has many different modes of play, as specified in
Figure
2.
1
. Adventure mode provides
ch
apter play where the user may progress through increasingly difficult levels and save progress. Puzzle
games challenge the player to solve zombie puzzles in two different modes: Vasebreaker and I, Zombie.
Mini games presents many different gameplay mechani
sms, all variations on the primary theme.
Survival is an eternal struggle to preserve ones brain against an infinite wave of zombies. Zen Garden is
not really a game, but more like a trophy room of plants won in various battles.











Figure
2
.
1
:

Zombiquarium as it fits into the Plants vs. Zombies game context.

Plants vs. Zombies Game Applicatio
n

Mini Games

A
dventure

Puzzle Games

S
urvival

Zombiquarium

Mini
-
Game X

:

Zen Garden

5


Note that although Zombiquarium will ultimately be part of the Plants vs. Zombies Application, it
should also exist as a standalone application such that it can be developed and tested i
ndependently of
the broader game application. This will allow for a smoother development process, free of lingering,
unfinished dependencies stalling progress.



2.1.2

User Interfaces


Due to the simplicity of the gameplay, players will use the application in li
mited ways. For example,
there need to be a few GUI controls inside the Zombiquarium application itself, and we limit player
interactions to the mouse. The following UML Use
-
Case diagrams summarize the ways with which the
user will interact with our Zombiq
uarium application. Note that “Clicks” always refers to a left
-
mouse
-
button click. These Use
-
Case diagrams should be fed as input directly into Section 3.1, external
interfaces, which is where the design of the user interface is specified. Figure 2.2 outli
nes the Use
-
Case
diagrams included, which is enough to summarize all user interactions for this application.







Figure
2.2:

Overview of Use
-
Case Diagrams


Again, note that the player will start out in the
Plants vs. Zombies
TM

application, and will reac
h the
Zombiquarium mini
-
game via the button menu there as specified in Figure 2.3.




















Figure
2.3:

Use
-
Case diagram of Plants vs. Zombies Overview



6


Once the user enters the Zombiquarium mini
-
game application there are very few choices. Again
,
remember that this is a casual little game to quickly pick up and put down, so the user is presented with
limited options. This makes making our Use Case diagrams easier, since we don’t need many controls.
Starting and quitting this application is descri
bed in Figure 2.4.
















Figure
2.4:

Use
-
Case diagram of Zombiquarium Overview


As far as th
e actual gameplay is concerned the
objective of
, when the game starts, the user will have 50
Sun. Sun is important because by collecting Sun the user may

earn enough to buy more zombies at a
cost of 100 Sun each, and the winning trophy at a cost of 1000 Sun. The game will start with two
zombies randomly placed in the tank moving in a random direction (left or right) at a velocity randomly
scaled in a range

such that they appear to be lounging about the tank. Note that this rate should be
determined during the playtesting stage.

As the zombies swim about the tank, the user may place a brain
in the tank at a cost of 5 Sun per brain. T
he zombies will want to e
at the brains they can see, meaning
the ones that are close to them, so they will pursue them
















Figure
2.5:

Use
-
Case diagram of Zombiquarium Gameplay



7


2.1.3

Hardware Interfaces


The game should be designed and constructed such that it may be easily

ported and published on
multiple platforms. Target platforms should include the Windows PC, Mac,
Linux, Android, and
iPhone.
Note that mobile platforms are a natural match for this game because of its point and click simplicity.
No complicated keyboard co
mmands
or combinations

are needed. In addition, the still viewport also
makes the transition to a smaller mobile screen easier.



2.1.4

Software Interfaces


Zombiquarium will be developed using the Java language. Note that since this will be one mini
-
game
among

many, the Mini Zombie Game Framework should be developed in tandem with this application,
making it easier to develop future Plants vs. Zombies interfaces.
That framework should provide all
game timing, the update mechanism, GUI controls and Sprite manage
ment, and an overall structure to
support seamless custom rendering. The game will also be developed using Java’s Swing and AWT
frameworks for building user interfaces and rendering 2D graphics.


Java

version 6.0

will work on all desired platforms with the

notable exception of the iPhone. The game
will have to be ported to Objective C to operate there. For that reason, development will proceed first as
a Java game, and porting will proceed after completion of the Java game. Note again that due to the
vari
at
ions in screen resolutions,
careful planning should be done to account for platform independence
in all game data management.



2.1.5

Communications Interfaces


Note that this game will operate solely as a local game. There will be no networking requirements. Th
e
game will use accounts for keeping track of player records and results, but this will be stored locally.



2.1.6

Memory

Constraints


Since this
game will be ported to mobile devices, memory is an important issue. All images should be
provided in the precise si
zes they will be rendered. Images should never be scaled down. Note that the
memory requirements for each platform will be different, but that memory budgets should be defined
carefully before each port.



2.1.7

Operations


It is the goal of the player to win a

Zombiquarium trophy. Note that Zombiquarium is a true mini
-
game.
It does not have levels, the game plays precisely the same way each time. Now in order to win a trophy
the player must collect 1000 Sun. Sun doesn’t grow on trees, of course, zombies produce

it. So, as
zombies swim about the tank, they periodically spawn sun from their bodies that springs out and slowly
8


falls to the bottom of the tank. Zombies spawn this sun at random intervals. So, the zombie swims about,
spawns a sun, the user clicks on it
and earns 25 sun to add to the total.


Of course, zombies need to eat. If they don’t eat, they die. And if they die, they don’t spawn sun. And if
they all die, the player loses. So, the key for the player is to keep the zombies alive. In order to do this
t
he player must feed the zombies brains. The user may feed a zombie by clicking on the tank. When the
user clicks on the fish tank, a brain is placed there. Nearby zombies should
then try to eat that brain.
Note that placing a brain should cost 5 Sun, and t
hat the player may not have more than 3 brains placed
in the tank at a time.


Two snorkeling pet zombies wouldn’t be very exciting and it would take a long time to reach the 1000
Sun needed to win. So, a player may purchase additional Zombies by clicking o
n the Buy Zombie
button. Zombies cost 100 Sun each and makes the game more interesting. Zombies compete for placed
brains, and the player has to be more careful not to let zombies die. With more zombies in the tank, the
player is more active, eventually fr
antically trying to feed brains to the starving zombies all the while
collecting enough Sun to win.



2.1.8

Site Adaptation Requirements


N/A



2.2

Product functions



The sole function for this product is to casually entertain. The game does not need to save any ac
counts
data or player settings or results of any sort. In fact, the game data management needed for this program
is even very limited. This game is an silly little abstract representation of feeding pet zombies with an
added incentive of earning a trophy.



2.3

User characteristics


Plants vs. Zombies is a game that appeals to people of all ages, and Zombiquarium should be no
different. Even young children should find the point and click interface easy to pickup and use. Also
note that even though the game feat
ures the undead, it is presented in a humorous context such that
young players will find the zombies to be harmlessly entertaining.



2.4

Constraints


Mobile screen resolutions, however, present a porting challenge. Different models support different
resolutio
ns and all mobile platforms fall short of PC/Mac capabilities. Note that the key hardware to
plan for are the mouse (or mobile pointing device) and the screen. The game is best played in full
-
screen
mode, so development should plan for two desired screen r
esolutions. 1280x720 (HDTV, Blu
-
ray
9


standard) for PCs/Macs, and 640x960 (iPhone) for mobile devices. Note that the mobile resolution can
be scaled down from there as needed.



2.5

Assumptions and dependencies


Note that we are developing the Zombiquarium game
separate
ly from
Plants v
s. Zombies. Therefore, it
should be built as a lightweight stand alone application. We may assume that our game implementation
with its rendering surface may be easily dropped into the main Plants vs. Zombies application at a later

date.



2.6

A
pportioning of the Requirements


It will be determined at a later date precisely how this Zombiquarium application will fit into the parent
Plants vs. Zombies application. It is the obligation of the software designers, however, to construct the
program such that it may easily be modified for use by another application.

10


3
Specific requirements


Zombiquarium will use a simple interface with few controls. It is not a fast
-
paced action game or
complex strategy game, it is a casual game in the true s
ense of the expression.

Note that the GUI
controls should always be neatly drawn, carefully spaced, and properly aligned.



3.1

External interfaces


The

player will only use mouse input to start and run the game, so the GUI will be straightforward.
Figure 3.1
below shows how it should be laid out. Note that most of the screen will serve as the playing
area where zombies may swim about and the user may place brains and collect sun.

Let’s break down
the interface and look at the individual controls one at a time.
































Figure
3.
1
:

Zombiquarium
GUI while game in progress.



11


New Game Button



Figure 3.2 shows the artwork to use for this control. Note that it should be placed
neatly in the top
-
right
-
hand corner of the game window. The artwork

is in keeping with the undead
theme, as the grey stone is similar to the look of a gravestone.






Figure
3.2:

Zombiquarium
GUI while game in progress.



In
-
Game Toolbar



Figure 3.3 shows the artwork to use for this toolbar. It should be placed neatly
in
the top
-
left
-
hand corner of the game window.

Note that this toolbar also contains the following three
controls:


Sun Collected Display



This display should update the sun total as sun is spent and gathered. It
should appear to the far left of the toolb
ar. Note that the numeric display need not display a
number of greater than 4 digits, since the game ends when buying a trophy for 1000 Sun.

Note
that there is a rendering of the Sun above the sun total so that it is clear for the player what that
number r
epresents.


Buy Zombie Button



This button
should only be enabled when the player has at least 100 Sun.
Note that when the button is enabled it appears bright as shown in Figure 3.3. When disabled
(player has less than 100 Sun), it should appear faded, as

the buy trophy does in the figure.


Buy Trophy Button



This button

should only be enabled when the player has at least 1000
Sun. Note that when the button is enabled it appears bright. When disabled (player has less than
1000 Sun), it should appear fade
d as shown in Figure 3.3.














Figure
3.3:

Zombiquarium
In
-
Game Toolbar
.





In
-
Game
Toolbar

Sun Collected
Display

Buy Zombie
Button

Buy Trophy
Button

12


Level

Progress Bar



Figure 3.4 shows the artwork

to be used for the Level Progress Bar, which should
appear in the bottom
-
right corner of the game screen. Note that

the display includes the
player’s
progress both numerically (i.e. 680/1000 Sun) and graphically (the green bar). This provides the user
with a consistent feedback that serves as a frame of reference for gauging how much longer the
Zombiquarium game will t
ake.

Note that the height of the green bar is constant, but the width of the bar
should be scaled according to progress towards 1000 Sun, where reaching that goal would mean the
green bar would fill the progress bar area all the way to the right.






Fig
ure
3.4:

Zombiquarium
GUI while game in progress.



Zombies



Figure
s

3.5

through 3.7 show

the artwork to be used for rendering zombies.
Note that a
snorkeling zombie may be in one of three states: normal, meaning its health is above 50%, dying,
meaning it
s health is less than 50% but above 0. And dead, meaning its health is 0. This state should
dictate which zombie artwork to use. Also not that in all three states a zombie may be facing either left
or right. We’ll use identically reversed artwork for these

renderings. Note that in the zombie artwork,
the background is orange. This color serves as the color key when loading these images, meaning that
pixels with that reserved color will be made fully transparent when the zombie is rendered onto the
game. Th
is allows the game background to show through in those parts of the zombie’s outline.

Note
that the color key to be used for all artwork is rgb = (220, 110, 0).







Figure
3.5:

Normal Zombies swimming left and right.







Figure
3.
6
:

Dying

Zombies sw
imming left and right.






Figure
3.
7
:

Dead

Zombies
facing

left and right.









13


Brains



Figure 3.8
shows the artwork to be used for brains. Note that when a brain is placed in the
tank, it should instantly appear where the player clicked and then slowly fal
l towards the bottom of the
tank. Brains that are not eaten should disappear after a period of time.
Note that brains are considered
eaten by zombies when the brain’s bounding box collides with the mouth region of the zombie.





Figure
3.8: A Brain




Su
n



Figure 3.9

shows the artwork to be used for suns.
Suns should be spawned from t
he center of the
zombie. Once spawned, suns should fall slowly towards the bottom of the tank. As with brains, they
should remain in the tank only for a period of time. Afte
r a time, if not collected by the player, the sun
should be removed.








Figure
3.9: A Sun




Win Display



Figure 3.10

shows the artwork to be used when the player wins the game. Note that this
image should not be scaled, and should be centered over t
he playing area. When displayed the game
should not continue, so mouse clicks on the game area should be ignored. To start another game, the
user should start a New Game.














Figure
3.10: Win Display




14



Loss Display



Figure 3.11

shows the artwork
to be used when the player loses.

This also should not be
scaled and should be centered over the playing area. Again, when displayed, mouse clicks on the playing
area should be ignored.
















Figure
3.11:
Loss Display





3.2

Functions


The user will

interact with the Zombiquarium game in limited ways, and again, only via mouse clicks.
GUI responses should proceed as follows:


New Game Function



When the New Game button is clicked, the game data should be reset. Note that
this button should always be

enabled, so the player may click on it when the application first starts, or in
the middle of a game, or when a game is over. When clicked, a new game should immediately
commence. When a game is started
:



2 brand new zombies with full health should be rand
omly spawned inside the tank. They should
be randomly sent either left or right at a velocity randomly selected from what the appropriate
zombie range is.



The player’s Sun total should be reset to 50.



The buy zombie and buy trophy buttons should be disabl
ed.



All brains and sun should be removed from the tank.



All necessary data should be updated for proper rendering next frame





15


Click on Tank Function



When the user clicks on the zombie tank, the functional response will
depend on a few different condit
ions:



If the user clicked on a spawned Sun,
the Sun will be removed from the playing area and 25 Sun
will be
added to the player’s total. Note that only one Sun should be credited for each click, so
once a Sun is found to be clicked on, not more Suns shoul
d be tested.



Else if the user clicks w
ithin the legal playing area and

there are not already 3 brains on the
screen

and the player has at least 5 Sun:

o

A
dd a new brain to the tank at the click location and give it a very slow falling velocity.

o

Deduct 5 Sun
from the player’s total

o

If the player has gone below 1000 Sun, disable the Buy Trophy button.

o

If the player has gone below 100 Sun, disable the Buy Zombie button.



Zombie Behavior

-

Note that when spawned, Zombies always start at full health. As the game
progresses, each frame, zombies should lose a little health. Also note that when a zombie eats a brain, it
regains full health. As far as Zombie behavior is concerned, Zombies should think as follows:



Living Zombies are never idle. They always swim. A Zomb
ie starts off swimming either left or
right and continues doing so unless it either reaches the edge of the tank or it starts pursuing a
brain.



When a Zombie is swimming and reaches the edge of the tank it should reverse direction and
pick another random v
elocity in the acceptable rang
e and go off in that direction.



Each frame,

the Zombie should do the following “thinking” during the update cycle:

o

If

the Zombie
has a target brain:



If the Zombie’s mouth is Colliding with the target brain:



remove the brain fr
om the game




set the Zombie to full health



set the Zombie as having no target brain



Else update the Zombie’s velocity vector such that it continues to pursue its target
brain. We need to do this because the brains are moving

o

E
lse i
f there are any brains in

the tank
:



go through all brains one at a time. If a brain is in the

Zombie’
s sight range:



set it as the target brain



stop searching for a new target




Buy Zombie Function



Note that the program should only test for mouse clicks on the Buy Zombie
button
when the button is enabled. When the user clicks on the enabled Buy Zombie button:



A new zombie is randomly spawned in the tank using a similar spawn technique as with a new
game, i.e. randomized location, direction, and velocity.



100 Sun is deducted from
the player’s total



If the player has gone below 1000 Sun, disable the Buy Trophy button



If the player has gone below 100 Sun, disable the Buy Zombie button



16


Buy Trophy Function



Note that the program should only test for mouse clicks on the Buy Trophy
bu
tton when the button is enabled. When the user clicks on the enabled Buy Trophy button:



Display the Trophy



Stop the game from updating



3.3

Performance requirem
ents


The primary performance concerns will be with rendering, since it is a real
-
time graphical ap
plication.
The program should run at a minimum, consistent rate of 30 frames per sec
ond, but preferably at 50
frames per second. Note that gameplay should be consistent (and so data updates should be properly
scaled)

regardless of the frame rate, but the h
igher the frame rate, the more responsive the program will
feel to the player, which is important for games.


Note that rendering performance testing should be an important component of the development process.
This is particularly true on mobile platforms
.



3.4

Logical database requirements


N/A



3.5

Design constraints



As mentioned, a primary concern should be efficient rendering. When available, the program should be
able to take advantage of hardware (GPU) acceleration for rendering. However, in order to app
eal to the
maximum number of users, it should also work well when that is not available. This is a reasonable
constrai
nt, since this is a 2D game with a small world and little artwork to render.



3.6

Software system attributes


As professionals, all members o
f this project must take this project seriously. We are dedicated to
producing robust software that exceeds the expectations of our customers. In order to achieve this level
of quality, we should build a product with the following properties in mind:


3.6.
1 Reliability



The program should be carefully planned, constructed and tested such that it
behaves flawlessly for the end user. Bug
s, including rendering problems, are unacceptable. In
order to minimize these problems, all software will be carefully desi
gned using UML diagrams
and a Design to Test approach should be used for the Implementation Stage.


3.6.2 Availability



Zombiquarium will be incorporated into the Plants vs. Zombies application
as a mini
-
game, and so will be made available as a downloadab
le Shareware product via the
Internet. Customers may download and install the game application for free, but will be required
17


to pay a fee to access the full game content, including the mini
-
games.

Note that the game should
also be made available through t
he appropriate online stores, including those for the various
target mobile platforms.


3.6.3 Security



All security mechanisms will be managed by the parent Plants vs. Zombies
application.


3.6.4
Extensibility


The Mini Zombie Game framework to be devel
oped in tandem with the
Zombiquarium mini
-
game should anticipate future updates, including the addition and even
changing of mini
-
games distributed with the application.



3.6.5 Portability



T
o start with, the game will target all platforms that support J
ava. An
Objective C port should follow thereafter to make the game playable on the iPhone.


3.6.6
Maintainability



The parent game itself should automatically and periodically check the
company server for appropriate updates to ensure current content. Thi
s mechanism must be
planned for in the development of the Plants vs. Zombies application.



3.7

Organizing the specific requirements


Note that the Zombiquarium game application is simple enough that we need not worry about using an
alternative arrangement of
the content of this document. The specific requirements for this application
already fit neatly into the sections listed in the IEEE’s recommended SRS format.



3.8

Additional comments


It is import
ant to keep in mind that
the reason specific game settings hav
e not been supplied by this
document is that predicting what is fun can be a tricky task. We anticipate that the Zombiquarium game
as a whole will fit in nicely with the Plants vs. Zombies application, and that it has the potential to
entertain, but the pr
ecise combination of zombie/sun/brain velocity ranges, Zombie sight range, and
Zombie spawn rates should be determined during the playtesting stage. The feedback from playing the
game should ultimately determine what settings should be used to optimize fun

in the player’s
experience.


18


4
Supporting Information


Note that this document should serve as a reference for the designers and coders in the future stages of
the development process, so we’ll provide a table of contents to help quickly find important s
ections.



4.1

Table of contents


1.

Introduction







2

1.

Purpose







2

2.

Scope







2

3.

Definitions, acronyms, and abbreviations



2

4.

References







3

5.

Overview







3

2.

Overall description






4

1.

Product perspective





4

2.

Product functions






8

3.

User characteri
stics





8

4.

Constraints






8

5.

Assumptions and dependencies




9

3.

Specific requirements






10

1.

External interfaces





10

2.

Functions







14

3.

Performance requirements




16

4.

Logical database requirements




16

5.

Design constraints






16

6.

Software system attr
ibutes




16

7.

Organizing the specific requirements



17

8.

Additional comments





17

4.

Supporting Information






18

1.

Table of contents






18

2.

Appendixes






18



4.2

Appendixes


N/A