No More Fatties Modern Software Specification For Junior Project

barbarousmonthΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

73 εμφανίσεις

CST 326

Team RTFM, 2012

Page
1


No More Fatties

Modern Software Specification

For Junior Project



Version <1.
1
>





CST 326

Team RTFM, 2012

Page
2


Table of Contents

1.

Introduction

4

1.1

Purpose

4

1.2

Scope

4

1.3

Definitions, Acronyms and Abbreviations

4

1.3.1

Definitions

4

1.3.2

Acronyms

4

1.3.3

Jargon

4

1.4

References

5

1.5

Overview

5

2.

Overall Description

5

2.1

Business Case

5

2.1.1

System Description

6

2.1.2

Market Sector

6

2.1.3

Competing System Survey

6

2.1.4

Cost Analysis

7

2.1.5

Conclusion

7

2.2

Assumptions and Dependencies

7

3.

Requirements

8

3.1

Functionality

8

3.1.1

Dungeon
-
crawler

8

3.1.2

Communication

9

3.1.3

Game Control

9

3.1.4

Overlord

10

3.2

Performance

11

3.2.1

Play between Dungeon Crawler and Overlord will be as lag
-
free as possible with an intended goal
of less than 150ms

11

3.2.2

Dungeon Crawler will operate at as close to 60 FPS as possible

11

3.2.3

Overlord client wil
l operate as close to 30 FPS as possible

11

3.2.4

Game Control must be able to handle at least 5 concurrent game

11

3.3

Design Constraints

11

3.3.2

Game Control component will be developed in C#

11

3.3.3

Game Control will implement a Microsoft SQL Server

11

3.3.4

Overlord will be developed in O
bjective
-
C using the CoCo2D library

12

3.4

Purchased Components

12

3
.5

Interfaces

12

3.5.1

User Interfaces

12

3.5.2

Hardware Interfaces

12

3.5.3

Software Interfaces

12

3.5.4

Communications Interfaces

12

3.6

Licensing Requirements

13

4.

Use
-
Case Model Survey

13

4.1

Introduction

13

4.2

Survey Description

13

4.3

Use
-
Case Model Hierarchy

13

4.3.1

Communication

13

4.3.2

Dungeon Crawler

13

4.3.3

Overlord

14

CST 326

Team RTFM, 2012

Page
3


4.3.4

Game Control

14

4.4

Use Case Model Diagrams

15

4.4.1

Communication Use Case Model

15

4.4.2

Overlord Use Case Model

16

4.4.3

Dungeon Crawler Use Case Model

17

4.4.4

Game Control Use Case Model

18

4.5

Use
-
Case Specifications

19

5.

System Architecture

19

5.1

Functional Architecture

19

5.1.1

Dungeon Crawler:

19

5.1.2

Overlord:

19

5.1.3

Game Control:

19

5.1.4

Communication:

20

5.2

Logical Architecture

21

5.2.1

User Interface

21

5.2.2

Business Object Logic

21

5.2.3

Business Objects

21

5.2.4

Persistence

21

CST 326

Team RTFM, 2012

Page
4


Modern Software Requirements Specification


1.

Introduction

The modern software requirements specification will provide an overview of the entire system’s
requirements and how they map to logical components. But first, a few goals need to be stated
and terms will need to be defined. This section will include the purpose, scope, definitions,
acronyms, abbreviations, references and overview of the modern softw
are requirements
specification.

1.1

Purpose

The purpose of the modern software requirements specification is to fully describe the external
behavior of the application. It will also describe nonfunctional requirements, design constraints
and other factors nece
ssary to provide a comprehensive description of the requirements for the
system.

1.2

Scope

This modern software requirements specification will apply to Team RTFM’s junior project: No
More Fatties, a cross
-
platform action game. This document applies to all sub
-
systems of the
project, including the Dungeon Crawler sub
-
system and the Overlord sub
-
system, as well as all
systems that work to integrate the Dungeon Crawler and Overlord systems.

1.3

Definitions, Acronyms and Abbreviations

This section will define all term
s, acronyms and abbreviations used.

1.3.1

Definitions



Dungeon Crawler:

an action game where up to four players can work together to fight
monsters to reach the end of the dungeon. Played on the Windows platform.



Overlord:
a game where the player becomes the cont
roller of the enemies the players in
the Dungeon Crawler fight. Played on the iOS platform.



CoCos2D:
A graphics software library used to create 2D games with detailed graphics
on the iOS platform.



iOS:

Describes devices that work under Apple technology. Th
is includes iTouch, iPhone
and iPad.

1.3.2

Acronyms



UI:
User Interface. What the user actually interacts with.



XNA:
Short for “XNA’s Not Abbreviated.” A Microsoft software library package used to
create video games for the Windows and XBOX platform.



SRS:

short for Software Requirements Specification.



PC:

Short for “Personal Computer.” Describes any desktop or laptop computer running
the Windows operating system.



HUD:

Heads Up Display. A UI component that displays player statistics to the screen.

1.3.3

Jargon



Le
aderboard
:
describes a ranking of players based on some metric, such as score
.


CST 326

Team RTFM, 2012

Page
5


1.4

References

[1] C. Baker,
Demographics (age) data for iPhone and iPod Touch users
, Usability Notes, [online]
2009,
http://usabilitynotes.typepad.com/usabilitynotes/2009/10/demographics
-
age
-
data
-
for
-
iphone
-
and
-
iphone
-
touch
-
users.html

(accessed: 22 No
vember 2011).

[2] H. Leggatt, Study: Gamer demographic complex, BizReport, [online] 2008,
http://www.bizreport.com/2008/04/study_gamer_demographic_complex.html

(accessed: 22
November 2011).

[3] B. Gilbert, Dust 514 preview: Contractual Murder, Joystiq, [online] 2011,
http://www.joystiq.com/2011/08/20/dust
-
514
-
preview
-
contractu
al
-
murder/

(accessed: 22
November 2011).


[4] P. Davison, Card Game Bang! Gets PC/iOS Cross
-
Platform Multiplayer This November,
Gamepro, [online] 2011,
http://www.gamepro.com/article/news/224523/card
-
game
-
bang
-
gets
-
pc
-
ios
-
cross
-
platform
-
multiplayer
-
this
-
november/

(accessed: 22 November 2011).

[5] A. Yoon, PS3/PC/iOS/Android cross
-
platform multiplayer achieved in Dungeon Defenders,
Joystiq, [online] 2011,
http://www.joystiq.com/2011/03/02/ps3
-
pc
-
ios
-
android
-
cross
-
platform
-
multiplayer
-
achieved
-
in
-
dungeo/

(accessed: 22 No
vember 2011).

[6] A. Sliwinski, Dungeon Defenders sales hit 250k, majority on PC, Joystiq, [online] 2011,
http://www.joystiq.com/2011/11/02/dungeon
-
defenders
-
sales
-
hit
-
250k
-
majority
-
on
-
pc/

(accessed:
22 November 2011).

1.5

Overview

The SRS begins by presenting a business case and lays out assumptions and dependencies.

The document then describes all requirements for the system. The document then completes a
use
case model survey. The last section of the modern SRS describes System Architecture for
the system.

2.

Overall Description

The system No More Fatties (throughout referred to as NMF) is a cross
-
platform video game
where players can work together to fight throu
gh a dungeon, or become the overlord of that
dungeon allowing them to spawn monsters to fight against the players. This is accomplished
through two distinct sub
-
systems, the dungeon crawler and overlord.

Because there are two distinct sub
-
systems, they ar
e easily grouped into requirements.
Therefore, requirements concerning the dungeon crawler client are grouped in one package, and
the requirements for the overlord are grouped in another.

To allow the sub
-
systems to interface together
, there is another sub
-
system which interconnects
the Dungeon Crawlers and Overlords
. This is the communication sub
-
system which is
responsible for handling communication

(network traffic) between the Dungeon Crawler and
O
verlord.


The last sub
-
system
keeps track of the state o
f each Dungeon C
rawler and
O
verlord. This sub
-
system

game control

will keep track of

the

state for each individual connected client, and will
be the central repository for game data and statistics.

2.1

Business Case

This section proposes Team RTFM’s ideas on o
ur Junior Project. We will be discussing what our
project is and why we are creating it, who our target audience is, comparing other similar
systems, and what it will cost to produce our product. This will provide reasons for creating our
product and why i
t is important to produce.


CST 326

Team RTFM, 2012

Page
6


2.1.1

System Description

“No More Fatties” is a cross platform implemented game, with seamless online play. The game
features two primary systems: a PC game and an iOS

game. These two games will communicate
through a server to create a connected game experience. The main function of the PC game will
be a “dungeon crawler” type game, operated via mouse clicks. The iOS game is a strategy type
game, known as the “overlord”
, where the user places monsters on the map to fight the PC users
by using a touch screen interface.


The server will be act as a translator running scripts for information received from both the PC
and iOS users. The data will be sent over TCP/IP data pac
kets. The server will receive TCP/IP
packets sent from both games and translate the data into scripts. These scripts will create TCP/IP
data packets with certain information that will be sent to the other users.


Whi
le cross platform gaming is not

a

new

co
ncept, there are many more platforms available today
than in the past. We are trying to connect two systems that are relatively new to cross platform
gaming with one another: the PC and iOS. With this connection comes the need for a seamless
connection wit
h no wait times.

Having seamless play allows for smooth gameplay, which is what
most game players are looking for.

Seamless online play will allow an iOS user to connect to a
match with multiple PC users without the PC user’s approval. This allows iOS user
s to jump in
and out of games without interrupting other u
sers’ game
-
play experience. The
goal is to have the
iOS user take control, and when
the iOS user

leave
s,

the server will continue with its scripts for
attacking the PC users.


2.1.2

Market Sector

This ty
pe of game has the potential to reach a global
audience, since

mobile and PC gaming has
become a global trend. Having a multi
-
system game such as this opens the market to two sets of
users: the mobile gamer and the PC gamer. Our primary audiences on the mo
bile iOS device will
be 13


17 and 18


24 as these groups form the majority of iTouch and iPhone users [
1
]. On the
PC
,

we will primarily target the 18


24 and 25


34 demographics as the average gamer is 33
years old [
2
]. Most of our users will have
both of the systems in order to experience both the
“dungeon crawler” and the “overlord” aspect. However, implementing both systems means that
the user only has to own one system in order to play; they will only get one experience though.
Having two differ
ent play styles will attract two types of users as well.


From personal experience, a user’s motivation for using the system is similar to most other RPG
games: to reach the next level and gain bigger bonuses. Whether this is the character’s physical
level

to gain a more effective attack or the next level in a world to have a new experience, people
will want to play to get to the next plateau and undergo the next challenge. Users are intrinsically
motivated to find out what the next big thing is for reachin
g the next level.


2.1.3

Competing System Survey

Cross platform seamless online play is a fairly new concept, but it is becoming rapidly popular.
The first game to attempt this is “Dust 514”, a cross platform game between a PC user and a
console user. This game
is still in production. “Dust 514” is not exactly competition because it is
implemented on PS3 instead of iOS. This just provides competition for users who have the
console system as well [
3
].


Another system just recently released is the card game “Bang!
”. While this game implements iOS
to PC cross platform gaming, it does not have seamless online play because players take turns
[
4
]. This means that when a new player joins, there will be a delay until they can play, instead of
immediately jumping in. Whil
e this is not a bad implementation for this game, it will not work with
CST 326

Team RTFM, 2012

Page
7


ours as users want to immediately jump into the action.


The biggest competition for users is the game “Dungeon Defenders”. This game has successfully
implemented iOS to PC
seamless on
line play. However, “Dungeon Defenders” has

enabled the
same game play on the two different systems, while we will have two different play styles, the
strategy on iOS and action based on the PC. Another major difference is the implementation of a
higher le
vel graphics engine for the iOS than what we will be implementing [
5
]. We can use
“Dungeon Defenders” as an example for how smooth a cross platform seamless online play
game should look and feel. “Dungeon Defenders” is our best example because it is using
the
same platforms we wish to use, and its sales numbers have reached 250,000 [6].


2.1.4

Cost Analysis

Our system will cost a moderate amount to produce. The greatest cost to our group is learning
objective C for the iOS game. The rest of the cost is fairly low

since

we are fluent with the rest of
the technologies we are using. Most of the cost will just be in the hours we take to form the entire
project. To estimate the total working man hours
,

we begin with a value of 528 hours in a 30 day
month without weeken
ds. After subtracting 8 hours a day for sleep
,

we arrive at 352 hours
available. From this
,

we subtract 16 hours a week in class and multiply th
at by 4 weeks leaving
288 hours. We then take out the time spent on other work at 2 hours a day per every hour w
e
spend in lecture,
creating 32 hours for homework per

week. This leaves a total of 160 available
hours. From this we subtract the average working time from the group at 36 hours a month,
leaving 124 hours a month. Finally, we subtract 10% or about 13 hour
s for travel time, eating,
bathroom time and any unexpected delays leaving a total of 111 hours per month. This means

that

we will have roughly 5.5 hours a week to work on the project. There are no plans for updates
to the game, so the only maintenance nee
ded will be server upkeep. This will require about 2 to 3
hours a week,

allowing

for unexpected bugs.


2.1.5

Conclusion

“No More Fatties” will be another take on a fairly new systems technology. Our game will allow for
two different play styles, the “dungeon cra
wler” and the strategic styles. Having two different
systems as well as different play styles opens our potential market to a greater user base
because it allows for two different user bases. This is the main difference between the game
“Dungeon Defenders”

and our game. “Dungeon Defenders” has one play style while ours
accounts for two different types of users.

While there are other systems that have implemented cross platform integration and seamless
online play, our system is slightly different. The main
difference is that our system contains two
different types of play styles. This opens our potential user base to two separate markets of
gamers. This is the main factor that separates our game from others, the diversity of gameplay.


2.2

Assumptions and
Dependencies

A number of assumptions have been made in the creation of the design of NMF. These are:



Communication between the iOS platform and the XNA platform will be reliable and
efficient. If too much needs to be done in order to make the network trans
fer efficient and
reliable, the system will suffer.



Play must be smooth and at a reasonable frame rate (20+fps) on the iOS and XNA
platforms.



System must be able to handle up to at least five different instances of the game being
played (four players on th
e dungeon crawler client, and one player on the overlord client).

CST 326

Team RTFM, 2012

Page
8



3.

Requirements

This section of the modern SRS contains all of the software requirements. These requirements
are detailed enough to enable a designer to design a system to satisfy the require
ments. The
requirements are also detailed enough to allow testers to test the system to ensure the system
satisfies the requirements.

3.1

Functionality

This section
describes the functional requirements for the system. The requirements are divided
into categor
ies based on which package they belong to.

3.1.1

Dungeon
-
crawler

This system will feature up to four person multi
-
player and pits the players against an endless
wave of monsters which they must fight to get to the end of the dungeon. This system will
interface
with our Communication system so the overlord client can be the overlord for the game.

3.1.1.1

System will implement top
-
down view.

This requirement creates the stipulation that all gameplay action will occur in a two
-
dimensional
space, and as such there is no 3D
element. This can also be described as implementing the
game in a 2D manner. This creates a stipulation that all graphics will be 2D in nature.

3.1.1.2

System will allow player to control their character with input.

This requirement allows the player to issue comm
ands to their character in the game, and allows
players to expect a reaction from their player given a particular input. This input could be anything
from touch
-
screen to keyboard and mouse.

3.1.1.3

System shall allow the player to move around the map.

This requir
ement allows the player to issue a command to the game to move their character from
one spot on the map to another. Players however may not move through walls or other objects
that provide collision. This requirement is needed so the player has control of
their movement so
they move from room to room.

3.1.1.4

System shall allow the player to attack monsters.

This requirement allows the player to issue a command to the game to allow their character to
provide a means of attack. For most characters this will be accom
plished by allowing the player to
shoot a projectile (arrow, magic, knives, etc) to harm enemy monsters.

3.1.1.5

System shall allow the player to cast abilities and special attacks.

This requirement allows the player to issue a command to the game to perform
special attacks.
These are augmented attacks that do extra damage or other special effects to monsters. This
includes spells like “Fireball” or abilities like “Powerful Throw.” These commands are only usable
every so often during the course of a game and a
re considered special or extra powerful.

3.1.1.6

System shall allow the player to activate switches/toggles present in the map.

This requirement allows the player to flip switches or toggles present in the map. An example of
this is that a player may have to work
towards one end of the map, only to toggle a button that
opens a door earlier in the map. This provides an easy way to control gameplay, and create
puzzle
-
like situations.

CST 326

Team RTFM, 2012

Page
9


3.1.2

Communication

This system will be responsible for being the middle
-
man for each Dung
eon Crawler client and
the Overlord client. It will store all relevant level information such as where the players are, what
monsters are active and other information like that. It will also serve as a relay point for messages
between the Dungeon Crawler C
lient and the Overlord client. For instance, when the Overlord
game client spawns monsters for the players to fight, it is the Communication system's
responsibility to forward that information along to the Dungeon Crawler clients.

And lastly, the communica
tion system is responsible for keeping track of which game lobbies are
open, tracking which players are playing, what level they are playing and keeping track of general
statistics such as player level, and account statistics

3.1.2.1

System will receive status upd
ates from the Dungeon Crawler clients and store it locally
on the server.

This requirement will allow the communication system to receive
updated

information from their
clients (such as key
-
press, movement commands, etc) and
send

them to the Game Control s
ub
-
system to be stored. This requirement captures the need to relay information from each Dungeon
Crawler to the game control sub
-
system.

3.1.2.2

System will be a middle
-
man between the Dungeon Crawler and Overlord clients.

This requirement captures the need for O
verlord data (such as spawn locations, traps, etc) to be
transmitted to the Dungeon Crawler clients for processing. For instance, a Overlord client may
choose a spawn point, this requirement allows that selection to be submitted to the Dungeon
Crawler clie
nts so the actual spawn point selection is fully carried out and affects the Dungeon
Crawler’s gameplay (more monsters to fight, a trap to avoid, etc).

3.1.2.3

Overlord will spawn monsters or cast effects on players, the server will receive this
information from t
he Overlord client and forward it to the Dungeon Crawler client.

This requirement formally states that the overlord will be able to make changes to the game world
(set spawn points, lay traps) and that these changes will be broadcasted to each Dungeon
Craw
ler in the game.

3.1.2.4

Dungeon Crawler will send movement information, Monster information, etc, to the server
who will then forward it to the Overlord client for updating.

This requirement formally states that the Dungeon Crawler’s movements, health percentages
, etc
will be available to the overlord client. This is accomplished by stipulating that all updated game
information, relevant to the overlord, will be sent to the overlord.

3.1.2.5

System will receive and dispatch messages about changes of game state between cli
ents.

This requirement allows the sub
-
system to receive messages intended for the game control sub
-
system (i.e. when a player wishes to join a game, it must first authorize against the game control
sub
-
system). This requirement also allows the sub
-
system t
o send messages to clients (i.e. when
the game control sub
-
system authorizes a connection, it uses this requirement).

3.1.3

Game Control

This set of requirements describe Game Control system components such as allowing players to
join/create games, and doing gen
eral game
-
management tasks such as keeping track of statistics
and what is happening in the game (monster/player location, etc)

3.1.3.1

System shall allow players to create a game.

This requirement allows a player to create and list a game on the game control sub
-
system. This
means that a player can choose to create a game (with his selection of map and difficulty). From
there, others can join this game and the game is ‘listed’, which means it is available in the list of
public games all players can join. From here
, others can join to fill in the missing roles.

CST 326

Team RTFM, 2012

Page
10


3.1.3.2

System shall allow players to join a game.

This requirement allows a player to join a game from the public list of games. This allows a player
to view a list of games that are available (created through the C
reate a Game requirement) and
choose one to join. This can be done either as an overlord or as a dungeon
-
crawler (though there
is a max of four dungeon crawlers per game, and one overlord per game).

3.1.3.3

System shall allow players to change game
-
related options

This requirement allows a player to choose settings specific to the game they are creating. This
includes the abilities to make the game private (game has a password and does not show up in
the public games list), change the level, difficulty, and whether

or not a human overlord is
allowed.

3.1.3.4

System shall allow players to exit a game.

This requirement allows a player to exit the game they are currently in through some sort of menu
system. This requirement is important as having a clean way to exit the game y
ou have joined is
a clear need of the player.

3.1.3.5

System shall keep track of player health, energy and experience.

This requirement allows the system to track and store each player in the game’s health, energy
and experience. Health is how much more damage a
character can take before dying, Energy is
consumed in the use of special abilities and attacks, and experience is a number that signifies
how powerful an enemy is.

3.1.3.6

System will keep track of what games are being played, who is in what game, what level
they

are playing, etc

This requirement allows the system to keep a list of which games are being played, which players
are playing in which game, and what level those players are playing on. This requirement sets up
the hierarchical nature of the game control
sub
-
system and allows the sub
-
system to keep track
of every game and every player in those games.

3.1.3.7

System will use the Communication sub
-
system to update Dungeon Crawlers and
Overlord of game state changes

This requirement allows the game control sub
-
system

to update each of the dungeon crawlers
and the overlord of game changes (such as a unit running into a wall, or a monster dying).

3.1.3.8

System will keep track of player profiles

This allows the game control system to keep track of player accounts and their asso
ciated
character. This allows a player to create an account, and add characters to that account whose
statistics will be saved for the accounts lifetime.

3.1.3.9

System will have a leaderboard that ranks based on score

This requirement allows the system to create
a leaderboard to rank players based on score. This
requirement allows the system to poll each account to determine which players ranked the
highest, and will be able to send this information to clients wishing to display it.

3.1.4

Overlord

This grouping of requi
rements will describe the Strategy Game Client and the requirements
necessary to provide functionality and use of the system. The system itself is a game that allows
the player to take control of the “Overlord” role for a particular dungeon. The player wil
l join a
game as the overlord, he will then be able to spawn monsters, direct AI, lay traps, etc for the
Action Client players to fight against.

3.1.4.1

System shall allow player to set locations on the map from which monsters will spawn

This requirement allows th
e overlord to place a spawn
-
location point on the map. Over time
monsters will spawn from these locations and try and attack the player. The overlord uses this
requirement to choose locations that will best try and kill the enemy players.

CST 326

Team RTFM, 2012

Page
11


3.1.4.2

System shall allo
w player to spawn special enemies on the map

This requirement gives the overlord the ability to spawn super
-
powerful creatures that the players
must fight. These creatures are substantially stronger than normal monsters and the overlord only
has a limited
supply of these creatures.

3.1.4.3

System shall allow a player to assume the overlord role

This requirement allows a player to become the overlord of a particular game. Basically this
requirement is the piece that allows a player to join a game and assume the role

of creating
monsters and directing AI.

3.1.4.4

System shall allow players to cast status
-
effects and other abilities upon the player to
slow their progress through the level

This requirement gives the overlord the ability to place traps in a level to slow down pl
ayers and
provide additional obstacles.

3.2

Performance

This section describes the performance aspects of the system. These are non
-
functional
requirements of the system
.

3.2.1

Play between Dungeon Crawler and Overlord will be as lag
-
free as possible with an
intende
d goal of less than 150ms

This requirement creates a stipulation in which players who are playing against each other can
expect their input to be responsive. 150 ms describes how much time passes between a user
submitting a command and receiving the expect
ed output (character moves, or attacks).

3.2.2

Dungeon Crawler will operate at as close to 60 FPS as possible

This requirement creates the stipulation that Dungeon Crawler graphics performance must
attempt to maximize frames per second to get smooth clean gameplay with no artifacting or
hitching.

3.2.3

Overlord client will operate as close to 30 FPS as possible

The iOS
platform has weaker requirements for performance and as such we are only expecting
30 FPS out of the overlord client. Otherwise this requirement is very similar to 3.2.2.

3.2.4

Game Control must be able to handle at least 5 concurrent game

This creates the stipu
lation that the game server must be able to handle up to five distinct games
(where each game may have up to 5 players). This creates a good testing area where we can
stress test the server code with roughly 25 players.

3.3

Design Constraints

This section describes requirements that control
the way the system will be constructed. This is
usually constraints of languages and libraries.

3.3.1

Dungeon Crawler will be developed in C# using XNA game library

This creates the stipulation that the Dungeon Cr
awler software package must be written in the
programming language C# and linked against the XNA game library.

3.3.2

Game Control component will be developed in C#

Creates the stipulation that all game server related code will be developed in the programming
lan
guage C#

3.3.3

Game Control will implement a Microsoft SQL Server

This creates the stipulation that the database used in the project will be Microsoft SQL server.

CST 326

Team RTFM, 2012

Page
12


3.3.4

Overlord will be developed in Objective
-
C using the CoCo2D library

This requirement states that all

graphics and game programming done on the iOS platform will be
done using the programming language Objective
-
C and linked against the cocos2D library.

3.4

Purchased Components

XNA Creators Club

License

Apple Developers License

3.5

Interfaces

This section will dis
cuss the specific interfaces, both hardware and software, that our system will
require in order to become a workable finished product.

3.5.1

User Interfaces

This section describes the interfaces used by each subsystem to gain information from the user.

3.5.1.1

System
will implement a HUD for bo
th Overlord and Dungeon
-
crawler
clients

This requirement forces the Dungeon Crawler and Overlord clients to present useful information
to the player through a HUD. This includes Player Health, Energy and Experience for the
Dungeo
n Crawler, and other player’s information (health/energy) for the overlord.

3.5.1.2

System will implement a menu system for both Overlord and Dungeon
-
crawler clients

This requirement states that a menu system (for creating/joining games, changing options, etc)
wil
l be implemented for both the Overlord and the Dungeon Crawler systems.

3.5.2

Hardware Interfaces

This

section describes the low level interface that the user will interact with to give the system
information.

3.5.2.1

Touch Screen iPhone

The touch screen will be the use
r’s interface for issuing commands into the device. It will be used
to spawn monsters, choose location for spawn, and move their field of view around the map.

3.5.2.2

Keyboard/Mouse

The keyboard/mouse will be how the dungeon crawler user will interface into the sy
stem. The
keyboard will be used to move their player sprite around the map, while the mouse will be used to
target enemies/attack.

3.5.3

Software Interfaces

This section describes the high level interfa
ce, typically seen as libraries.

3.5.3.1

Cocos2d

A 2D game engine used with Xcode for developing iPhone games.

This gives us access to sprite
management, menu management, and animation management which objective
-
c does not have
natively.

3.5.3.2

XNA

A toolset created by Microsoft for developing games.

Like Cocos
2d this gives us access to sprite
management, menu management, and animation management which is not native to the C#
language.

3.5.4

Communications Interfaces

This section describes the communication abstraction layers between subsystems. These are
usually desc
ribed in network protocols.

CST 326

Team RTFM, 2012

Page
13


3.5.4.1

Dungeon Crawler will implement UDP network communication

This requirement states that the dungeon crawler system will use the UDP protocol in order to
transfer and receive information from the game control component.

3.5.4.2

Overlord
will implement UDP network communication

This requirement states that the overlord system will use the UDP protocol in order to transfer
and receive information from the game control component.

3.5.4.3

Communication sub
-
system will implement UDP network communicat
ion

This requirement states that the Communication’s system form of communication will be the UDP
networking protocol.

3.6

Licensing Requirements

XNA Creators Club

Apple Developers License

4.

Use
-
Case Model Survey

This section discusses the Use Cases associated w
ith the system

4.1

Introduction

The purpose of this section is to provide a description of the interaction between known actors
and the system.

4.2

Survey Description

The purpose of this project is to allow users to play a game shared between mobile iOS client and

a PC client.

4.3

Use
-
Case Model Hierarchy

This section discusses how the use cases interact within the system.

4.3.1

Communication

This package handles the communications between the Overlord and the Dungeon Crawlers



This package contains the use cases:

o

Update Ove
rlord

o

Update Dungeon Crawler



This package contains the actor:

o

User



Use Case relationships
:

o

The user engages the Update Overlord use case

o

The user engages the Update Dungeon Crawler use case.


4.3.2

Dungeon Crawler

This package handles all use cases involving the

Dungeon Crawler



This package contains the use cases:

o

Join Public Game

o

Join Private Game

o

Move Character

CST 326

Team RTFM, 2012

Page
14


o

Throw Projectile



This package contains the actor:

o

Dungeon Crawler



Use Case relationships
:

o

The Dungeon Crawler engages the Join Public Game use case

o

The
Dungeon Crawler engages the Join Private Game use case

o

The Dungeon Crawler engages the Move Character use case

o

The Dungeon Crawler engages the Throw Projectile use case


4.3.3

Overlord

This package handles all use cases involving the Overlord



This package
contains the use cases:

o

Join Public Game

o

Join Private Game

o

Set Spawn Location



This package contains the actor:

o

Overlord



Use Case relationships
:

o

The Overlord engages the Join Public Game use case

o

The Overlord engages the Join Private Game use case

o

The Overl
ord engages the Set Spawn Location use case


4.3.4

Game Control

This package handles how the game will start and operate while running



This package contains the use cases:

o

Spawn Monster

o

Create Account

o

Start Program

o

Log In

o

Create Game

o

Log out

o

Close Program



This p
ackage contains the actors:

o

Timer

o

User



Use Case relationships
:

CST 326

Team RTFM, 2012

Page
15


o

The Timer will engage the Spawn Monster use case

o

The User will engage the Start Program use case

o

The User will engage the Create Account use case

o

The User will engage the Log In Program use
case

o

The User will engage the Log Out use case

o

The User will engage the Create Game use case

o

The User will engage the Close Program use case

o

Start Program precedes Log In

o

Start Program precedes Create Account

o

Create Account precedes Log In

o

Log In precedes
Create Game

o

Log In precedes Log Out

o

Log Out precedes Close Program

o

Close Program extends to Log Out

4.4

Use Case Model Diagrams

This section includes all of the use case model diagrams for the system. The section is organized
by which package of use case is be
ing
discussed
.


4.4.1

Communication Use Case Model

This use case model describes the actor ‘User’ interaction with the communication package.
These include Update Overlord and Update Dungeon Crawler. This can be seen in Figure 1.


Figure
1
: Communication Use Case Model

CST 326

Team RTFM, 2012

Page
16


4.4.2

Overlord Use Case Model

This use case model describes the actor ‘Overlord’ interaction with the Overlord package. These
include Join Public Game, Join Private Game and Set Spawn Location
. This can be seen in
Figure 2.


Figure
2
: Overlord Use Case Model

CST 326

Team RTFM, 2012

Page
17



4.4.3

Dungeon Crawler Use Case Model

This use case model describes the actor ‘Dungeon Crawler’ interaction with the Dungeon
Crawler package. These include Join Public Game, Join Private Game, Move Char
acter, Throw
Projectile
. This can be seen in Figure 3.


Figure
3
: Dungeon Crawler Use Case Model



















CST 326

Team RTFM, 2012

Page
18


4.4.4

Game Control Use Case Model

This use case model describes the actors ‘Timer’ and ‘User’ interaction with the Game
Control
System. Use Cases included are Spawn Monster, Create Account, Start Program, Log In, Create
Game, Log Out and Close Program.

This can be seen in Figure 4.



Figure
4
: Game Control Use Case Model

CST 326

Team RTFM, 2012

Page
19


4.5

Use
-
Case Specifications

Use
-
Case Specifications

are documents that fully describe a particular use case. They contain
enough details to be implanted by developers on a team or be tested by testers on a team. This
section includes all of the use cases for the project, a brief desc
ription and a citation for where
more info may be found.

1.

Dungeon_Crawler_Join_Private_Game:
Use Case describes a user joining a private
password
-
protected game
on the dungeon crawler client.

2.

Dungeon_Crawler_Join_Public_Game:
Use Case describes a user joini
ng a public
game on

the dungeon crawler client
.

3.

Dungeon_Crawler_Throw_Projectile:
Use Case describes the player’s character
throwing
a projectile due to user input
.

4.

Dungeon_Crawler_Move_Character:
Use Case describes a player’s chara
cter moving
due to user
input
.

5.

Overlord_Join_Private_Game:
Use Case describes a user joining a private password
-
protected gam
e on the overlord client
.

6.

Overlord_Join_Public_Game:
Use Case describes a user joining a publ
ic game on the
overlord client
.

7.

Overlord_Set_Spawn:
Use Case d
escribes a player setting a spawn point as the
overlord,

from which enemies will spawn
.

8.

Communication_Update_DungeonCrawler:
Use Case describes the communication
package updating each Dungeon

Crawler of game
-
state changes
.

9.

Communication_Update_Overlord:
Use Case describes the communication package
updating each
Overlord of game
-
state changes
.

10.

Game_Control_Spawn_Monster:
Use Case describes the game control’s timer actor
ticking and spawning

a monster at each spawn point
.


5.

System Architecture

This section
describes the system architecture and the overall system organization.

5.1

Functional Architecture

This section desc
ribes the statements related to
system operations.

5.1.1

Dungeon Crawler:

This system will feature up to 4 person multi
-
player and pits the players ag
ainst an endless wave
of monsters which they must fight to get to the end of the dungeon. This system will interface with
our Communication system so the strategy game client can be the overlord for the game.

5.1.2

Overlord:

This grouping of requirements will de
scribe the Strategy Game Client and the requirements
necessary to provide functionality and use of the system. The system itself is a game that allows
the player to take control of the “Overlord” role for a particular dungeon. The player will join a
game a
s the overlord, he will then be able to spawn monsters, direct AI, lay traps, etc for the
Action Client players to fight against.

5.1.3

Game Control:

This set of requirements describe Game Control system components such as allowing players to
join/create games,
and doing general game
-
management tasks such as keeping track of statistics
and what is happening in the game (monster/player location, etc)

CST 326

Team RTFM, 2012

Page
20


5.1.4

Communication:

This system is response for two key components. Firstly, this system will receive updates from
both
the Dungeon
-
crawler and the Overlord and store them locally on the server. It will provide
this information to Game Control. And Secondly, this system will be responsible for handling all
communication to and between clients. For instance, if Game Control
made changes and needed
them reflected on the clients, it would invoke this system to send those messages out. This is the
absolute core of our entire project.

This can be seen in Figure 5.



Figure
5
: Functional Architecture
Model



CST 326

Team RTFM, 2012

Page
21


5.2

Logical Architecture

This section demonstrates how the classes within the system.

This can be seen in Figure 6.

5.2.1

User Interface

The User Interface is what the user sees and interacts with. T
his layer stores no data. The UI
layer relies heavily on Bu
siness Object Logic in order to use the Business Objects.

5.2.2

Business Object Logic

The Business Object Logic is all classes related to gaining to the Business Objects.

5.2.3

Business Objects

The Business Objects are all classes relating to data storage.

5.2.4

Persistence

This layer relates to all classes where data is stored, keeping consistency along multiple clients
and program usage.


Figure
6
: Logical Architecture