SECTION A: Sprint Backlog
The sample sprint backlog for the ROOMs project is shown in Figure A.1. This is a variant of the sprint
backlog on slide 25 of http://www.engr.uconn.edu/~steve/Cse2102/finagile.pptx and captures. There are four
product backlog items (PBIs –see Figure F.1 in Section F).
For each item, there is:



Primary and secondary individual in charge of the item (initials)
The different task for the PBI in the sprint.
Effort in hours for weeks 1, 2, 3, and 4
Note that each team member is 10 hours/week or 40 hours for the sprint.
The excel spreadsheet is an embedded object in MS word. You can right click, Worksheet Object, Open and it
will open the spreadsheet in excel.
You can use this as a template for your sprint backlog.
Note that as a rule of thumb we are going to establish that each team member works for 10 hours/week on the project
Each team member should add up to a total of 10 hours for each week across all of the various tasks
TC, AC, NV, etc. are the initials of each team member and there are both primary and secondary (backup)
Primary
Secondary
Description
Week 1
Week 2
Week 3
Week 4
Total Estimated Days of Effort:
TC
AC
TC
NV
NV
NV
NV
TC
TC
TC
TC
NV
NV
NV
AC
MG
ND
ND
ND
MG
MG
MG
AC
AC
Game Play
Navigation: Creating, entering and leaving rooms
Items: Define and Implement; collected by game players
Monsters: Define and Implement monters; battled by game players
In Game Entities defined for for Story and diaglog
Game Engine
Mechanics
Event System
Entity
Website
Account Creation - create user accounts
Play the Game
Use the Editors
Database
User table to track registered and active users
Items and Monsters tables
Figure A.1 Sprint Backlog for the Rooms Project.
1
3
4
2
4
2
4
0
0
2
2
2
2
2
2
2
2
2
4
4
4
2
2
2
2
2
2
2
2
2
SECTION B: User Stories/Use Cases
Users are grouped into three main categories: guests, players, and administrators. These roles and their
capabilities are described in the use-case diagrams in Figure B.1.
Figure B.1 - Guest use-case diagram for website - Nikolaj
Guests are able to access limited features on the website, such as public rankings, viewing public user
generated content, or registering to become a “Player” as shown in Figure B.2. These users have the most
restrictive permissions, but will be allowed to play a demo version of the game anonymously.
Figure B.2 – Player use-case diagram for website – Nikolaj.
Players represent the majority of users and will be able to log into the game and access their own personal
information, as well as content that they’ve generated. Players “play” the game as intended by design and can
also log into the website with the same credentials to access the editor. Players may also view the player
statistics of other players, including content created with the editor, and any statistics associated with it, and
inherit all of the permissions of Guest users. Additionally players can manage their account through the website
by managing their in-game characters and contacts.
2
Administrators are privileged users. These users have full access to modify almost everything. For example,
they can view any information available to players, ban given players from the site temporarily and/or
permanently, or view currently banned players and unban them. Additionally admins have control over custom
content uploaded by users.
Figure B.3 - Admin use-case diagram for website – Nikolaj
As previously discussed, ROOMS will feature three editors accessible from the website: a room editor,
an item editor, and a monster editor. The editors will let you create new content which you can upload to the
game and can be encountered by all players. Everything made with the editor will have a chance to be
encountered in a player’s game. Figure B.4 (below) shows the general use case diagram for the various editors:
Figure B.4 - User use-case diagram for editor. Nikolaj
As you can see from Figure B.4, the user will be able to edit not only how their content looks, but also all of its
characteristics and effects on the game. All content created through the editors will have a ‘rarity’ level
calculated. This ‘rarity’ is determined based on how ‘good’ or difficult the object is. For example:
- if an item is extremely powerful, its rarity will increase.
- if a monster is made very strong, its rarity will increase.
- if a room has many rare or powerful items, its rarity will increase.
3
In addition to the calculated rarity, as the content appears in game, it will accumulate aditional statistics. For
example, a monster may accumulate a set of ‘success rates’ that will correspond to a level of difficulty to
defeating that monster. These stats will also contribute to the frequency the item appears in the game.
Website users will fall into the following three user roles: Guest, Player, and Administrator. A brief
description of each role along with a use-case diagram is provided below:
●
Players in Figure B.5 represents the majority of users and will be able to log into the game and access
their own personal information, as well as content that they’ve generated. Players “play” the game as
intended by design and can also log into the website with the same credentials to access the editor.
Players may also view the player statistics of other players, including content created with the editor,
and any statistics associated with it, and inherit all of the permissions of Guest users.
Figure B.5 - Registered User use-case diagram for website - Nikolaj.
●
Guests in Figure B.6 are able to access limited features on the website, such as public rankings, viewing
public user generated content, or registering to become a “Player”. These users have the most restrictive
permissions, but will be allowed to play a demo version of the game anonymously. No personal data
should be tracked for these users.
Figure B.6 - Guest use-case diagram for website - Nikolaj
●
4
Administrators in Figure B.7 are privileged users. These users have full access to modify almost
everything. For example, they can view any information available to players, ban given players from the
site temporarily and/or permanently, or view currently banned players and unban them. Additionally
admins have control over custom content uploaded by users. Administrator accounts should be
monitored for unauthorized access. Security measures such as 2-step authentication might be considered
since unauthorized access to these accounts will cause many headaches.
Figure B.7 - Admin use-case diagram for website – Nikolaj
SECTION C: User Based Specification/Interfaces
A mockup screen of the in-game interface is shown in Figure C.1. When played in the browser, the
majority of the game is controlled with the mouse. Depending on what element in the game environment the
players click on, the avatar will perform a corresponding action, such as moving to a location, picking up an
item or attacking a monster. Several hot keys on the keyboard can also be assigned for quick access to the
inventory. Other than that the keyboard will only be used for the room chat.
Figure C.1. Screen Mockup of the Rooms Game - by Ashley
All system interactions are server/client based. While most of the game logic (path-finding, monster AI,
animation, etc.) occurs in the client (desktop or mobile device), the server keeps track of the current game state
(currently active rooms, players stats, etc.). This leads to frequent communication between the client and the
server. One of the more unique technical aspects of Rooms is that the game is an MMO playable both in the
browser and on mobile devices. For that reason two main performance bottlenecks have to be taken into
consideration: the server/client interaction and the limited processing power of smart phones. These are handled
5
by limiting the amount of information sent back and forth between the client and the server to a minimum and
by avoiding 3D graphics which might be too taxing to smart phone processors.
C.1 Website Home Page
As discussed previously, ROOMS will have both a mobile app and a website. The Website will afford
much additional functionality including editors to upload custom content to the game. The basic layout of the
site will look like Figure C.2 below. The one on the left is what it will look like when you are logged in and the
one on the right is what it will look like if you are not logged in.
Figure C.2 - Website Mockups of Home Page - Ashley
C.1.1 Logged In
As you can see from the mockups, when a user is logged in you can see their name in the top left corner.
We will display the user’s First & Last name (which does not need to be unique). We will also show their
profile picture. By clicking on their name, you will access the following menu:
User
- Profile: a link to the member’s profile
- Settings: a place where they can edit settings on their account
- Logout: a link to logout and end their session
As shown in the mockups, there are three additional menu items on the top right of the screen. From these you
will also be able to access the following pages:
About
- What is rooms?: a description about ROOMS
- How to Play: a basic tutorial about how to play the ROOMS game
- Development Team: information about the team that built ROOMS
Forums
Create
- About creating custom content: a tutorial to create custom content
- Create New Rooms: the editor to create custom rooms
- Create New Items: the editor to create custom items
- Create New Monsters: the editor to create custom monsters
6
When a user is logged in, the home screen will be dominated by the current state of the user’s game. By
clicking the ‘Resume Game’ button, they will be able to pick up game play where they last left off.
C.1.2 Logged Out
In the case when no user is logged in, rather than showing the previous game state, a video will be
displayed with clips of other players playing. This will give new site visitors an incentive to create an account
& play. Additionally, guests will have the ability to demo the game. This will let them play a modified version
of the game and determine if they wish to make an account.
Finally, by clicking the login button, users will be able to log in to their accounts and resume game play.
C.2 Website Profile
By clicking on a player’s name within the website, you will be taken to that player’s profile shown in Figure
C.3. On a player’s profile, you will be able to see their game stats, any players they are teamed up with, and
any custom content they have created in the editors.
Figure C.3 - Website Mockups of Profile - Ashley
The mockup on the left in Figure C.3 is a depiction of the ‘Stats’ tab on a profile page. . We will allow
players to save multiple games in Rooms. Each game will have its own game character & various stats
associated with that game. The mockup on the right of Figure C.3 is a depiction of the ‘Teammates’ tab. By
clicking on the teammates tab, you will be able to see that various users that you are teamed up with.
7
Figure C.4 - Website Mockups of a User’s Custom Content displayed on their Profile - Ashley
In addition to the ‘Stats’ and ‘Teammates’ tabs, you will also be able to see the custom content a user has
created. Each will include a variety of stats about the object (as shown in Figure C.4 above).
C.3 Gameplay
Figure C.5 is a mockup of what the general game will look like on both the website and the app. As you
can see, the top is dominated by the current room you are in while the bottom portion of the screen will have a
simple menu bar.
Figure C.5 - Gameplay - Ashley
As you can see from Figure C.5, comment 1, you will be able to configure three main weapons. These
weapons will be quickly accessible from hotkeys or clicks on the website, and taps on the app. In reference to
Figure C.5, comment 2, you will be able to chat with people in the same room. You will be able to see in the
chat whenever other people are typing and whenever they enter/exit the room. By clicking on a player you will
be able to team up with them. Additionally, by clicking the ‘Team’ button on the bottom menu, you will be able
to see all the people in the room who you are currently teamed up with. In reference to Figure C.5, comment 3,
you will be able to pause the game. By tapping or clicking the ‘Pause Game’ button, you will be able to teleport
your character to a safe room where your game is paused. Doing this will fork the current room you are in
8
(minus the players) & save it so you can resume play in it later. The safe room will always take you back into
the room you were in before (not a new one).
Items will also be easily accessible from this bottom bar as shown in Figure C.6. By clicking (or
tapping) on the item, you will be able to access a set of actions to do with them. Depending on the item, these
will include:
- using the item
- giving the item to a player in the room
- combining the item with another item (to create a new item)
- accessing the info for the item.
- discarding the item
The info window for the item will show the known effects of the item and any notes you have made about that
type of item. Because the effect will not be initially known, the notes section is important because it will allow
players to discuss and make note of an item’s speculated effect.
Figure C.6. - Game play, items - Ashley
C.4 Editor
As previously discussed, ROOMS will feature three editors accessible from the website: a room editor,
an item editor, and a monster editor. The editors will let you create new content which you can upload to the
game and can be encountered by all players. Everything made with the editor will have a chance to be
encountered in a player’s game.
C.4.1 Item Editor
When you create an item with the editor, you will be able to totally configure its look, properties, and
characteristics. The rarity of these items will be determined based on these characteristics. Figure C.7 below is
a mockup of what the item editor will look like.
9
Figure C.7 - Item Editor - Ashley
Figure C.7 is an example of designing a weapon. The fields will be different based on the type of item you are
creating. For a weapon, you will be able to decide its attack style, strength, and any additional attributes that the
item will cause in game.
C.4.2 Monster Editor
The Monster editor will let you design a monster that will appear in the game. Because we plan to
feature ‘intelligent’ monsters, the user will be able to highly configure the monster’s behavior based on a
stimulus and response. Figure C.8 is a mockup of the Monster Editor.
10
Figure C.8 - Monster Editor - Ashley
As with the item editor, the rareness of each monster is configured automatically based on the selections
the user makes for the monster’s level, behavior, and attributes. This is designed to ensure that there is a fair
distribution between easy and difficult monsters as you play. Additional stats about each monster will be
collected as they are encountered. These will be used to describe the success rate or difficulty of each monster.
C.4.3 Room Editor
The room editor will let users create rooms. These rooms will be encounterable during game play.
When a player enters thru a door, they will either be taken to a new random room, a room with another player in
it, or a room that has been created & uploaded by a player through the room editor.
Figure C.9 is a mockup of the Room Editor.
11
Figure C.9 - Room Editor - Ashley
Each room will have many options to add. You will essentially be configuring the initial setup of the room.
The editor will use a drag & drop interface to add item containers (which will hold a set of items), supplies,
weapons, artifacts, and monsters. The layout tab will allow you to change the look & feel of the room. You will
be able to add walls, move the doors, change the tiling images, and other things related to the room’s
appearance.
12
Section D: Detailed Design
D.1. Design Overview of ROOMS (Thom)
ROOMS provides users with three major facilities: a massively multiplayer game world, a content
creation and distribution system, and a website, the primary location for users to interface with these.
1
2
3
The game world consists entirely of sub-worlds known as “rooms”, each containing one or more of what
is typically described as a room. The vast majority of these sub-worlds are temporary and randomly
generated on the fly, however some are created by players via the “editor” (see 2.), and transferred to
the player and loaded during runtime. Players start in one of these rooms, and upon exiting it are
placed in another random room. Traveling back into the door from which they came takes them to yet
another randomly generated room, and not the room from which they came.
The content creation system, known as “the editor”, allows users to design, create and distribute their
own content throughout the Rooms gameworld. Users are permitted to customize Rooms, Monsters,
Items, and their Characters, known collectively as “editables”. The editor provides an interface for
changing the attributes of these editables, as well as their pictorial in-game representation, via either a
URL upload or a minimal bitmap editor located on the ROOMS website. Users may base their creations
off of existing creations made by them or others. Any existing “editable” must be customizable as an
prototypical version of the item being edited. The finished editibles will be randomly distributed
throughout the game, and players will have a mechanism for tracking the associated statistics (times
encountered, etc.).
The ROOMS website will primarily contain three things: The editor, user profiles, and a page which
embeds the game as a Flash object. In addition to this, various pages will hold static information about
the game, primarily help and information pages. The user profiles allow users to add “friends” (other
users with whom they may organize and start game sessions, chat with through the game’s minimal
built in chat system, and view creations).
To implement these features, the game itself must be very flexible, as we wish to avoid frequent game updates
(at least, newly created content must not require an update or patch to the game), and we want users to be
able to take any existing piece of game content, and create a new piece of content by changing one or more
attributes of the existing content.
ROOMS’ client and server is written in Haxe, and its website is written in PHP. Writing the client and
server in the same language allows us to reuse a great deal of code. Since synchronization concerns require
the client and server to run the game separately and simultaneously, this code reuse is a huge benefit.
Additionally, choosing Haxe as our language allows us to target multiple platforms with little extra effort (most
notably Flash and C++). Because libraries exist to allow games to run unchanged on the Flash and C++
platform. Due to this, ROOMS will run on both Flash and mobile platforms. Our primary focus however, at
least during the initial stages of implementation, will be the Flash platform.
In Figure D.1, ROOMS uses the Component-Entity-System pattern for its game logic (which will be
discussed at length in subsequent sections), and a very loose interpretation of Model View Controller for its
overall architecture. ROOMS’ game logic resides in the ROOMS.Model package, a rooms includes a very thin
view abstraction which serves as a wrapper around the abstraction layers provided by Flash/NME, so that
should some platform-specific be required, it won’t affect the rest of the codebase.
ROOMS.Controller.Server houses the server-specific portion of the logic, which will largely
involve running many instance of the game with no view and with no primary player (Our design of
ROOMS.Model intentionally avoids the notion of a “primary player”, and instead uses the Entity abstraction to
reference all game objects). Similarly, ROOMS.Controller.Client houses the client specific concerns for
running the game. This includes connecting to the server, resynchronizing when requested by the server, and
transmitting player actions to the server.
13
Figure D.1 ROOMS high level package structure
D.2. Design Patterns used in ROOMS (Thom)
Many of ROOMS’ features are contingent on a great deal of flexibility from the game objects. The most
important way we enable this is through the use of the Prototype creational design pattern, and the
Component-Entity-System structural design pattern. Component-Entity-System, while not a Gang of Four
design pattern is commonly used in game design (large frameworks such as Unity rely heavily on the
component-entity-system pattern), and used heavily enough in the design of ROOMS that mentioning it here is
warranted. The Prototype pattern is used to facilitate ease of extensibility for users of the editor. A key feature
of the editor is the ability to select a “parent” for whichever object you are designing. For example, if designing
a monster, the user can select any monster used in the game as a “parent” for that monster, and automatically
inherit all the attributes applied to that monster. This way, we can facilitate a data-driven subclass-like
mechanism, without having to actually create the code for a new class (this point is important, as creating a
new class would require updating every client, not to mention rebuilding, or somehow patching the running
server, which is undesirable).
In this diagram, Data is an abstract superclass of ItemData, MonsterData, and CharacterData,
the three user-customizable data sets. (As a side note: A minor, unimportant point is that data is
parameterized on its subtype to reuse the code in its body. If clone() returned Data, then clients of data
would be forced to cast, which is undesirable. The other alternative is to retype the code in each subtype of
data. This would be more difficult to maintain). They support the operation clone, as any instance of a Data
type may be used as a parent of a new instance. It’s worth noting that we chose to maintain a pointer to the
parent instead of having clone() actually copy the data. This is because every data is immutable (within
the game), and holds values such as a monsters maximum health, or a weapon’s damage. This makes a full
copy an unnecessary waste of space.
14
Figure D.2 Prototype Pattern for ROOMS
The second design pattern in Figure D.2 is prevalent enough in ROOMS to merit discussion is the
Component-Entity-System design pattern, also known as CES. CES is used to decouple the functionality of
game objects from their abstraction. The implementation of this design pattern centers around three class
hierarchies: `Entity`, `Component`, and `System`, and a single class, the CESManager. The `Entity` class
wraps a list of component, and has operations to add, remove, and determine the presence of a given
component. Entities are instantiated with an Abstract Factory (or similar) creational pattern to ease creation
and to prevent Systems from depending on the concrete type of a given Entity. Each component holds an id
number, and some number of data values. Each system supports two public operations, appliesTo, and
apply, each taking an entity, and holds no public data values.
Conceptually, an Entity is a bag of Components, and a Component is a set of key value pairs which
some Entities would have, and some would not. The systems are where the Component specific logic lives,
which prevents coupling between related components. Systems which need to communicate with each-other
communicate by changing values on a given Entities component, and not directly.
The first of the System’s methods, appliesTo, takes an Entity and determines whether or not that
Entity has the necessary components for the system to work on it. Were performance not a consideration, this
function would be called for every System on every Entity during each game update (in a realistic
implementation, these values would be cached). The second operation supported by Systems is apply,
which performs a systems actions upon an entity. For example, a MotionSystem would move the x and y
position values of an entity based on its dx and dy, and decrease the dx and dy values based on some friction
value. It follows, then, that the MotionSystem requires x, y, dx and dy properties, and these are supplied by
the PositionComponent and MotionComponent, respectively. The RenderSystem might render the entity
on a screen at each update, given that they have a RenderComponent (containing an image), and a
PositionComponent (containing x and y values). (Realistically, a RenderComponent would want to avoid
redrawing unchanged entities, and would want to ensure that animations were sufficiently smooth.
Fortunately, considerations such as these require no change to our design.).
The CESManager is the glue which holds all the active systems and entities together, and orchestrates
the application of the different systems to the Entities they hold. It is where implementation considerations
such as caches would be kept, and would be responsible for updating the game at a reasonable pace.
This design pattern is composition-heavy, and allows a great deal more flexibility than a class hierarchy
would, as this allows us to create new types simply by the composition of various components. Additionally,
systems solve the potential problem of component dependencies. Components are not allowed to know about
other components on their entity, however Systems are allowed to know about any number of components.
The drawback to this design pattern is the lack of static type information available to programmers. There is no
way to statically determine, for example, that a RenderSystem requires a RenderComponent and a
PositionComponent, or to statically ensure that every entity passed to it has both of these. However, given
that many of ROOMS intended features explicitly require dynamism and runtime flexibility, this is an acceptable
tradeoff.
15
Figure D.3 An example class diagram showing the use of the Component Entity System pattern in ROOMS
D.3. ROOMS Game State Diagram (Nikolaj)
The ROOMS Game State Diagram in Figure D.4 describes the possible states that the game can be in
and the transitions between them. Since the various game states are associated with different interfaces and
functionality it is crucial to distinguish between them. The main distinction in functionality is between the InGame State and the other states. In the In-Game State players interact with the extremely dynamic game
world while the other states are menu interfaces that predominantly remain static.
After game initialization the game enters the Main Menu from where Character Selection or the Options
menu can be accessed. In the Options Menu options such a Graphics and Controls can be modified. From
Character Selection a new character can be created or an existing character selected. All of these states are
associated with menu interfaces taking mouse input. In these states most of the in-game mechanics on the
client-side can be suspended. By choosing the play option the game then enters the In-Game mode during
which the player can navigate and interact with the game world. In this state all in-game mechanics are fully
active. From the In-Game state the player can also access the Options menu, the Inventory or NPC dialogue.
In the Inventory and NPC Dialogue states the game continues in the background while a menu object is
layered on top of it. In-game mechanics are not suspended but the controls are modified. Instead of navigating
the gameworld the player navigates the menu. A game session can be terminated at any time from within the
Options menu state.
16
Figure D.4 State Diagram for ROOMS’ User Interface
D.4. Entity Relationship Diagram (Mevludin)
Most design decisions for the ER diagram was flexibility, to allow future game changes with little to no
changes to the database schema. The game contains users, characters, items, monsters and rooms. And
since these are all represented differently, there needs to be a table for each one. There will exist relational
tables which connect these tables. A design decision has been made to remove the Entities and
TypeLookUp tables. The Entities table was used to stored the instances of rooms, monsters and items.
The TypeLookUp was to set a type system for rooms, items, character and etc. But both of these were
unnecessary because since they complicated the design. Also, another design decision was to remove the
Attributes table which was used to store attributes associated to monsters, items, room, characters or
anything else that would exist later on. The table would store multiple attributes associated with one ID. For
example, one item could contain multiple attributes, and each would be a separate row in MySQL. Instead, a
field called Attributes is created for each table that uses attributes, and will be stored as a JSON string
which would contains all the attributes. The reason for this change is because the data flow communication
between components is via a JSON string, so there will be no need to encode or decode the JSON string
when a component needs to fetch from the database or store to the database.
To support the entity class flexibility, connection between any two tables with a relation is possible. Our
ER diagram in Figure D. 5 demonstrates this through Users, Rooms and Characters tables. The Users table
has a one to many “own” relation to Character table, since a user can own many characters. Also the Users
table has multiple one to many “created” relation to Monster, Item, and Rooms tables because a user can
create a monster, item and room using the editor. The Rooms table has multiple one to many “Contains”
relation to Characters, Monsters and Items tables. These relations are used to show that multiple characters,
monsters and items can exist inside a room. If a new table is created, the room can be made to contain the
table by a “contains” relation. A possible new table would be a non-playing characters (NPC) information table.
These NPC’s would be able to give characters quests. So this relation allows the NPC to exist within the room.
Also, the Characters table has a one to many “own” relation to Items. This may be used as inventory.
But other “own” relations can exist. For example the character can be able to own monsters, or rooms. This
allows characters to have monsters as pets and/or allow the character to be able to summon the monster for
17
help. And character owning rooms could be made to allow them to “teleport” to a room which has an NPC for
the quest they might be doing. These examples are not part of the game but are used to show the kind of
flexibilities this schema allows. Lastly, in case the game has a friend system, there is a many to many “Friend”
relation from User to User. Note that it is not a character to character relation because users should not have
to
re-add
all
their
friends
when
switching
between
different
characters.
Figure D.5 ROOMS Entity Relationship Schema
D.5. Web Editor Dataflow Diagram (Nhat)
The data flow diagram in Figure D.6 highlights the transfer of data between the Custom Content Editor
and the main database for ROOMS. It is very important to have a well designed data flow for the Editor since
ROOMS is almost totally driven by custom content generated by our users. This will allow for a community
driven game, which has proven to be the best direction for a game like ROOMS.
ROOMS’ users can create their own content, such as new monsters, items, or rooms. While some of
the monsters and items will be exist in the initial release of the game, new content will be added on by users
who submit them via the Editor. This content can either be created using a default template, or by loading a
previously saved “in-progress” project from our “Incomplete Project Data” tables. This will allow users to
continue their customization of monsters before finalization and submission to be integrated into ROOMS’
custom content ecosystem. However, before anything can be submitted and verified, the editor must check
each attributes against predefined constraints for known conflicts. For example, submitting an item which
allows a player to move faster (Shoes) and slows them down (Heavy item) should not be allowed.
The Editor itself can be accessed by client via the website. It will be implemented either in flash or a
combination of javascript and HTML/CSS. The main interaction between the editor and user will be updates to
the GUI. For example, when a user requests a previously saved monster, the Editor will have to request the
monster data from the database before updating the GUI with this data. The implementation will not be too
important since we will be using an all purpose REST API which will expose our database to the Editor (and
the Game server) securely.
18
Figure D.6 ROOMS Website Dataflow Diagram
D.6. Entity, Component, and System Class Diagrams (Nikolaj)
Figure D.7 shows the relation between entities and components in a class diagram. Note that some of
this information has already been provided in the prior but will be included in a summarized form in this section
as well, for the sake of completeness and understandability. Entities represent any agent that is active within
the game. The majority of entities can be divided into three subclasses - Player, Monster, and Item. These
classes are included for convenience only. Entities however are in no way limited to these three classes. As
mentioned before entities are composed of components. An entity with any set of non-contradicting
components can be instantiated within the game. An entity's methods are entirely focused on component
management. Components can be removed, added or accessed. Additionally an entity can perform a sanity
check. componentSanityCheck() returns a list of components that prevent the entity from functioning
correctly. An example would be an entity that has a MoveComponent but does not have a
PositionComponent.
Components represent an entity's capabilities. I.e. if an entity has a move component it has the
capability to move. Components are not to be confused with systems though since they don't implement any of
the functionality associated with a capability. They serve as flags for systems and as containers for information
associated with a certain capability. E.g. the MoveComponent does not make the entity itself move it merely
holds its direction vector and destination. The Component class is abstract and only its subclasses can be
instantiated. Note that the component subclasses contain numerous private fields. These fields can be
accessed and mutated through mutator and accessor methods automatically generated by Haxe. While most
of the component subclasses are self-explanatory some ought to be elaborated on.
The AttackComponent does not only hold information about the damage an entity can deal it also
holds the boolean field isAttacking and a Entity field denoting the target. This way the CombatSystem,
which will be discussed later in this section, will know which entities are currently in combat and towards which
entities attacks are directed. The InventoryComponent holds a list of ItemData as opposed to Items. This is
because once an item is inside the inventory its functionality is reduced to displaying an icon and holding
relevant item stats. Any other capability it might have had as an entity becomes irrelevant and therefore the
inventory does not need to store Item entities only ItemData. The AIFlagComponent indicates that an Entity
is controlled by AI. The AI is implemented as a server-side state machine that is not part of this diagram.
19
Data is another crucial superclass. Instances of Data contain JSON objects that represent all relevant
information of an archetype of Player, Monster, Item objects. These are obtained from and stored in the
database. (For database design see figure x, ER diagram). Data instances have a clone() method. This
method allows us to create a duplicate of a given data object which in turn can be modified to create a new
archetype. The parent field refers to the Data object which called its clone method to create this object.
Entities, including Player, Monster and Item instances can be created from a data object through the use of the
EntityFactory class. Since numerous Entities and Components will be instantiated continuously throughout
the game we delegate two factory classes to the creation of these objects.
The EntityFactory is responsible for instantiating Entities within the game. Only one instance of the
EntityFactory will exist in the game. That instance can be accessed through the static get() method. The
EntityFactory will be able to instantiate new Entities by calling the corresponding create method. The
create methods either take a Data object which allows us to create Entities by accessing data from the
database, or take a list of parameters. In this way we can also create Entities without database access. The
ComponentFactory is almost identical to the EntityFactory apart from the fact that components cannot
be created from Data objects. Instead, parameters that correspond to the fields of a given component are
used. While the overall concept of systems has previously been described at length this class diagram
provides a more detailed and complete description of each system class. As already mentioned, Systems are
applied to Entities to perform their capabilities. In the apply() method a given System verifies whether an
Entity possesses all Components required by the System and if so executes a behavior.
The MotionSystem, PathfindingSystem and CollisionSystem together manage all motion
related capabilities of Entities. The MotionSystem takes the current location of an entity from the
PositionComponent and the destination and current direction from the MotionComponent. Then the
PathfindingSystem is used to compute a new path or update and old path from the current location of the
entity to its destination. As an Entity is moving the CollisionSystem checks for possible collisions with the
environment or other Entities. The RenderSystem displays this motion on the screen displaying the applicable
animations of an Entity.
The CombatSystem only apply to Entities whose isAttacking boolean field is set to true. In that
case it examines the target field of the Entity and applies damage to it by calling by updating the current health
of the target through the HealthSystem. It also calls the RenderSystem to display combat-associated
animations. The HealthSystem and HungerSystem manage an Entities health and hunger. These are
updated based on time passing as well as combat and the use of items. The AISystem forwards all Entities
with an AIFlagComponent to a server-side state machine not discussed in this diagram. The exact
implementation of the PlayerInputSystem also goes beyond the scope of this diagram.
20
Figure D.7 ROOMS Component and Entity Class Diagram
Figure D.8 ROOMS Systems Class Diagrams
D.7. Client-Server Sequence Diagram
The sequence diagram in Figure D.9 highlights the communication between the client game and the
game server, specifically for the purposes of multiplayer game play. It is essential in a multiplayer game
21
scenario that all the clients remain in sync with each other and with the server. However, it is equally vital that
this synchronization does not cause the client game to lag or to be noticeably slow.
To accomplish this, the server will broadcast updates to the clients. These updates will consist of a
series of time stamped actions for each client game to render. An action could be anything, for example,
moving to a new location, picking up an item, or attacking. Each client will be constantly listening, but never
waiting for these updates from the server. Additionally, the server will only send updates when a change has
occurred. These changes are based by room and can originate from player’s (in that room) performing actions
in the same room, or from monster AI determining a new action for a monster (in that room) to perform. This is
important because the amount of server communication is directly proportional to the amount of activity.
The sequence diagram above represents how an action performed on client A will be synchronized to
all involved clients: client A through client N. The diagram begins when a user performs an action on client A.
As stated above, all actions will be immediately timestamped. As soon as the action has been time stamped,
the process of simulation will begin on client A’s game view. This simulation assumes success. For example,
if the action is to walk to a new point, the player’s character will begin walking to the appropriate location on
client A. As soon as the simulation is started, client A will check the time stamped actions it has received from
the server since the action was time stamped & simulation was started. This is a preliminary means to verify
sync. Because the server can send new updates at any time, this will allow us to adjust the simulation
execution accordingly before sending the final action to the server. It lets client A’s game view be as accurate
as possible.
Once the action has been appropriately adjusted based on the data client A has currently received, the
action is sent to the server. The server will perform additional verification to assure that the action is in sync
with the other actions that have previously been received and any that have been received since the last
broadcast. In the event of a conflict in action, the server will use the timestamps to determine the true action
and adjust the other one accordingly. For example, if two players were trying to move to the same place, the
server will determine who gets there first by the timestamps and adjust the path of the other player. Upon
verification, the server will broadcast the resulting update to the appropriate client set, client A through client N.
This update will include all actions the server received and modified since the last broadcast. When client A
receives this update, it will begin to simulate any of the indicated changes to in its display.
Figure D.9 ROOMS Client-Server Sequencing
In final note, the time is highly exaggerated in the sequence diagram above. It is likely that the initial
simulation of the action has not finished before the server responds with the update. It is equally possible that
a simulation is already running. A simulation is merely the process of rendering a set of changes occurring
within a time span. For example, if player A is moving and player B is moving then the simulation will be done
by simultaneously moving player A by (dxA, dyA) and player B by (dxB, dyB) where the deltas are small
enough to appear like smooth motion and are determined to occur within the same small time span (governed
by the game’s internal timer).
D.8. Network Diagram (Nhat)
This Network Diagram in Figure D.10 uses the standard three-tiered server architecture. The client,
web, and database components are all modularized. The benefits of using a modularized three-tiered model
provides standardized interfaces and makes it easy to update any particular module.
● Game client 1 .. N
22
●
●
●
1 ... N indicates that there are more than one concurrent game clients at a time.
The game client represents a user’s machine running a ROOMS game client. The ROOMS game client
may fetch assets (such as images) from the web application, in which case it will use a HTTP
connection. All other connections will be from and to the Game Server.
Game Server
The game uses general game networking server-client code to connect to game clients. It also uses
HTTP connections to connect to the web server for asset definitions. It has a direct connection to the
database, which it uses to load persistent data which define rooms, monsters, items, etc.
Web Application Server
The web application server will serve up the game editor and basic web pages. It also serves up static
assets such as client downloads, images, sounds, etc.
Database Management Server (DBMS)
The DBMS can be connected to using standard APIs such as Open Database Connectivity (ODBC). It
stores persistent game data.
Figure D.10 ROOMS’ Three-Tier Network Architecture
23
Section E: Test plans
SWAPNA – ANYTHING TO PUT HERE? I HAVE INCLUDED WHAT THEY SUBMITTED AT THE
END OF THE YEAR (MAY) – HOW MUCH TO LEAVE IN?
Performance Testing
All tests measure FPS out of a scale of 30. So when gives “x” in table, it means x/30
Terms:
Map Scale: The size of the application in terms of block sizes.
Room Count: The amount of rooms in the Map.
Room Size: The dimensions of each room, x by y.
Test #1: Monster Density
This test is to test when it becomes unbearable to play with the amount of entities visible to the player. In this test we used
zombies in a 25 by 25 room at a regular map scale of 70 by 70. The monsters did not move.
This test was tested on both low and high performance computer.
“x” means that on that level of performance the test was not conducted, usually because it was not necessary.
Monster Amount
High Performance
Low Performance
1
X
30
10
X
29
25
30
25
50
X
24
100
X
19
200
29
X
500
X
7
1000
26
2
1500
20
X
2000
17
X
3000
12
X
10000
2
Did not start
So low performance computers would not be able to handle more than 100 placeables that don’t move otherwise it will
decrease the users performance. While on the other hand high performance computer would be able to handle 1500
placeables. This amount should be the maximum visible entities at once since this is an isolated test because when other
components are added, the FPS would be lower.
Test #2: Collision Testing (Moving Monsters)
High performance test was performed by having 10 room each 5 by 5. With up to 60 placeable chairs so the zombies
collide with them. Monsters are split up evenly so 10 monsters means 5 zombies & 5 shadows. The reason it was kept to a
small amount of rooms is to test when they are within sight. When monsters are out of sight the FPS increases back to 30
because it was as if they did not exist.
Monsters
24
Player staying Player Moving
still
10
29
29
20
23
18
40
17
13
70
6
5
100
3
2
Low performance test was done at a different time and was done differently. It was in with three rooms and only
zombies. Also the values when the player moved were not recorded, but it tends to be smaller by 4-6 FPS
Monsters
Player staying still
1
30
5
25
10
16
25
8
50
2
From this we see that we should only be dealing with about 20 monsters maximum with the high performance computer
where as about 5 to 10 max with the lower performance computers. If the map is bigger, more than 20 monsters can be
placed since it only decreases FPS when all 20 monsters are coming at the player.
Test #3: Map Size Testing
In this experiment, the map size and room count were varied to see if there would be drop in performance. Both high and
low performance testing was done exactly the same. 10 Monsters were added to have monsters in the map. All room sizes
are 5 by 5.
With this test it was more so about how long it took to generate the map than FPS in game. The FPS was tested and
remained 30/30 after the map load. “Breaks,” in the table, mean that over elapsed time nothing was made yet. This is
mainly due to the map scale not being able to handle the room count with the 5by5 count, as well as it is due to the
computers performance. Everything is measured in seconds.
Scale of Map was set to 70 by 70.
Number
Rooms
of High
Performance
Low
Performance
10
Instantaneous
Instantaneous
50
Almost no wait 0.5
100
0.3
1
150
0.8
2
200
Breaks
Breaks
Scale of Map was set to 100 by 100.
Number of Rooms
25
High Performance
Low Performance
10
Almost no wait
Almost no wait
50
0.4
0.8
100
0.5
1.5
200
1
3
300
2
5
350
Breaks
Breaks
Scale of Map was set to 1000 by 1000
Number
Rooms
of High
Performance
Low
Performance
1 (no monsters 1
due to size)
2 to 3
10
1 to 2
3
100
1 to 2
3
200
2 to 3
5
300
2 to 3
6
500
4 to 5
10 to 20
700
5 to 10
Breaks
900
10 to 15
Breaks
1000
Breaks
Breaks
From this test, the scale of the map does affect the number of rooms we can create in the game. But with an increase in
map size the load time to create a level takes longer. Also with an increase in the number of rooms the longer it takes to
load the level. So we need to keep the scale of map low and the number of rooms low in order to not cause a delay when
starting the game.
Test #4: Light engine
The point of this test is to see how the use of the flashlight and its algorithms to cast the rays affects the FPS with varying
room sizes, room counts and map sizes. These tests were only conducted on the high performance computer.
In table terms: “Normal” means the default width light coming out of flashlight. “Half” means that the flashlight light
width covers 180 degrees. “Full” covers 360 degrees of light.
When standing still in the game, the FPS is at 30/30 for all light tests.
The first test was to keep a fixed map size and vary the room size and room count.
Scale of map 100 by 100, Room Size: 5 by 5
Room
Count
Normal
Half
Full
10
18
18
18
50
18
15
18
26
100
18
8
18
Scale of map 100 by 100, Room Size: 10 by 10
Room
Count
Normal
Half
Full
10
18
18
18
50
18
15
18
100
Breaks
From this first test, when dealing with smaller room sizes and larger room counts, using the flashlight creates slower FPS.
Even at small room counts the effect of the flashlight causes significant drop in FPS.
The second test was to create one large room size with different scales.
Room Size 50 by 50
Map Size
Normal
Half
Full
100
100
by 18
18
18
200
200
by 7
7
7
500
500
by 7
7
7
Half
Full
Room Size 100 by 100
Map Size
Normal
100
100
by Breaks
200
200
by 7
7
7
500
500
by 7
7
7
From the second test, we see that the map size affects the game in a large way. From this it is assumed that the ray casting
functions seems to cast past the point of sight.
When the flashlight was turned off, the performance was still at the low FPS which means the algorithms for the
lightengine were still running.
Concluding Remarks:
The light engine plays the biggest role in decreasing the FPS at regular game play. Regular game play means the low end
of monster density, monster collision, room count, room size, and map size. Although it does affect the FPS the most, the
FPS loss is not too significant that the user will experience major lag. It is one of our main features of the game so it will
have to stay. Since the lightengine still runs while the flashlight is off, the FPS does not change and the user does not
experience a drastic increase of performance when the flashlight. This is bad because it decreases performance when it is
off because it doesn’t need to run. But this is good because the user won’t be discouraged to use the flashlight. Also the
user will not know that there is a performance loss.
27
GUI Testing
1. Go to webpage
2. Click “Sign up” In the Navigation Menu
a. Filled in the form with the below information
Field
Username
Password
Password
Email
Value
Result
Invalid
Invalid
Invalid
Invalid
Requires
Required
Required
Required
Required
Field
Username
Password
Password
Email
Value
Bob
Test
Test
Test
Result
Invalid
Invalid
Invalid
Invalid
Requires
At least 5 in length
At least 6 in length
At least 6 in length
Valid email
Field
Username
Password
Confirm Password
Email
Value
$_3test
$_3Test
$_3Test1
$_3test@$_3.com
Result
Invalid
Valid
Invalid
Invalid
Requires
alpha-numerical
Match to Password
Valid Email
Field
Username
Value
Result
BobTestIsTheBestAndThisIsOver26Characters Invalid
Password
Confirm
Password
Email
$_3Test
$_3Test
Valid
Valid
3test@3.com
Valid
Field
Username
Password
Confirm
Password
Email
Value
BobTest
test12
test12
Result
Valid
Valid
Valid
test@test.com
Valid
Requires
Cannot exceed
26 characters
Requires
b. This results in a creation of user BobTest, with password test12, and email test@test.com.
3. Login In
a. Attempt to login with this information
All invalid logins say “Username ‘{Username}’ or password incorrect”
Log out when valid
Username Password
Result
BobTest
test
Invalid
BobTest
Test12
Invalid
BobTest
test12
Valid
Bobtest
test12
Valid
Test 4 passes because capitalization is not taken into account when registering
b. Go back to registration and try to register with:
28
Username
Result
BobTest
Invalid
Bobtest
Invalid
bobtest
Invalid
BOBTEST Invalid
BOBTEST1 Valid
From test 3a, a login for “BOBTEST1” with “bobtest1” is valid.
4. Create New Character
a. Fill in the information based on below table:
Character
Name
test
Test12
Test12
Test12
Test12
Hair
Color
Brown
Brown
Skin Color
Result
white
White
White
Invalid
Invalid
Invalid
Invalid
Invalid
Requires
Username to be set
Username at least 5 characters
Hair Color required
Brown
Skin Color required
Brow
Orange
Hair color “Brow” is not an option, must pick
correct one. Skin color “Orange” is not an option,
must pick correct one.
Brown
White
Valid
All met
b. Create new character again and follow the step’s below
Character
Hair Color
Skin
Result
Name
Color
Test12
Brown
white
Invalid
Test12
Brown
White
Invalid
Test122
Brown
White
Valid
5. Create New Item
a. Fill in the character name, with any hair and skin color.
Item Name
Item
Type
Image
Test
Weapon
Weapon
Test2
Test2
www
Test2
Test2
Test2
Test2
Requires
Username must be unique
Username must be unique
All met
Sword
Sword
Description Strength
against
Players
A
1
A
1
Strength
against
Monsters
1
1
Sword
Sword
A
A
1
1
1
1
Weapon
Artifact
Trap
Weapon
www
A
A
A
A
1
1
1
1
1
1
1
1
Test2
Artifact
www
A
1
1
Test2
Trap
www
A
1
1
29
Result
Requires
Invalid Item name required
Invalid Name must be
between 5-26
characters
Invalid Type is required
Invalid Type ‘www’ is not
an option, choose
correct value.
Invalid Weapon is required
Invalid Artifact is required
Invalid Trap is required
Invalid Weapon ‘www’ is
not an option,
choose the correct
value
Invalid Artifact ‘www’ is
not an option,
choose the correct
value
Invalid Trap ‘www’ is not
an option, choose
Test2
Test2
Test2
Test2
Test2
Test2
the correct value
Invalid Description is
required
Weapon Sword A
1
Invalid Strength against
player is required.
Weapon Sword A
a
1
Invalid Strength against
player must be a
number.
Weapon Sword A
1
Invalid Strength against
monster is required.
Weapon Sword A
1
A
Invalid Strength against
monster must be a
number.
Weapon Sword A
1
1
Valid
All correct
b. Create new item again, with all other fields correct except character name as below:
Weapon
Sword
1
1
Character
Requires
Name
Test2
Username must be unique
test2
Username must be unique
Test1
All met
6. URL hack the Edit Characters: set the ID to something that does not belong to you. The result is you will be
redirected to your characters.
7. The edit item button does not work because it was not finished.
From here on below, the implementation of Characters and items editing has not been finished because there were
more important aspects to worry about than website forms. If anything, since it is likely that barely anyone will even
use the website and create a character or item. This will have the users create more content.
30
Other Testing
Test
Room Gen
Open Rooms in browser.
Hit "Play Rooms" button.
Verify a room is shown with a player inside.
Hit "Play Rooms"
Verify the room has proper architecture. - no holes in walls, room has placeables
Verify the player has a light source (flash light)
Hit "Play Rooms"
Use the arrow keys to move the player
Verify player responds to the arrow keys as expected
Navigate the player to a door.
Verify that when the player walks on the door, you travel to a new room
Navigate the player to a door.
Pass through the door.
Navigate the player to a door.
Pass through the door.
Verify that each door pass takes you to a new room and not one that you were in before.
Light System
Hit "Play Rooms"
Verify that as the mouse moves, the flash light will change direction
Aim the flash light at a wall
Verify the light respects the wall's boundaries
Aim the flash light at a chair
Verify the light will illuminate the placeable
Verify the light will cast a shadow behind the placeable
Aim the flash light at a bed
Verify the light will illuminate the placeable
Verify the light will cast a shadow behind the placeable
Aim the flash light at a fridge
Verify the light will illuminate the placeable
Verify the light will cast a shadow behind the placeable
Aim the flash light at a table
Verify the light will illuminate the placeable
Verify the light will cast a shadow behind the placeable
Aim the light so that it is cut in half by a wall
Verify that the light is blocked appropriately.
Put the flashlight on the ground
Walk away
Verify that the flash light can be deposited on the ground & remains there when you walk
away from it
Adjust the width of the flashlight beam
Verify that the light adjusts appropriately
Battle
Navigate until a "Zombie" is encountered
Verify that zombies spawn in the rooms
Use the mouse to click
Verfify that bullets fire from the player's gun
Verify that bullets move in the direction the mouse is pointed
Navigate until a "Zombie" is encountered
Use the mouse to click on the zombie
Verify this Fires the gun
Verify the bullet hits the Zombie.
Encounter a Zombie
Use the mouse to fire bullets at the Zombie repeatedly until the zombie disapears
Verify the zombie can be killed
Encounter a Zombie
Do not attack the Zombie
Allow the Zombie to attack you
Verify the player is defeated
Encounter a Zombie
Run away from the Zombie
Verify the Zombie will chase you
Encounter a Zombie
Run away from the Zombie
Hide behind a chair
Verify the Zombie will push the chair and try to get at you
Encounter a Zombie
Run away from the Zombie
Hide behind a bed
Verify the Zombie will push the bed and try to get at you
Encounter a Zombie
Run away from the Zombie
Hide behind a fridge
Verify the Zombie will push the fridge and try to get at you
Encounter a Zombie
Run away from the Zombie
Hide behind a lamp
Verify the Zombie will push the lamp and try to get at you
Enter a room
Count the number of Zombies
Enter a new room
Count the number of Zombies
if needed, repeat
Verify that a new set of zombies is generated at each room.
Enter a room
Kill all the Zombies
Enter a new room
Verify that a new set of zombies is generated at each room.
31
Expected
Passed
The menu will display & the game will open when
'play' is clicked
x
Room will generate correctly & the light system will
display
x
User will be able to direct the players motion &
direction of the light source
x
Doors allow player to navigate to a new room
x
You cant travel backwards between rooms
x
the player's flash light will follow the mouse
x
the light will not travel through a wall
x
chairs will illuminate & cast shadows
x
bed will illuminate & cast shadows
x
fridge will illuminate & cast shadows
x
table will illuminate & cast shadows
x
When the light encounters a wall, it will stop, but in
places where there is no wall, it will continue
x
the flash light can be put down
x
the flash light angle can be adjusted
x
Zombies spawn
x
Bullets fire in the correct direction
x
the bullet will fire & hit the zombie. This can be
seen bc the bullet will disapear,& the zombie will
animate by bouncing back
x
Zombies can be defeated
x
the player can be defeated
x
the zombie chases you when it can see you
x
the zombie can move chairs
x
the zombie can move bed
x
the zombie can move fridge
x
the zombie can move lamp
x
new zombies spawn in each room
x
new zombies spawn in each room
x
Failed
Section F: Product Backlog Items (PBI)
The product backlog items (PBI) for the ROOMS project in Figure F.1. The leftmost column of Figure F.1
contains the six PBI entries identified so far, where the size/complexity of each item is labeled with: where
S=Small, M=Medium, L=Large, and XL= extra L. Of those six, four have been chosen for the initial sprint
(second column of Figure F.1), and for those four, all of the sprint items have been identified (blue boxes).
Note that this figure is using the notation from: http://scrumreferencecard.com/ScrumReferenceCard.pdf
The PPT below is an embedded object in MS word. You can right click, Presentation Object, Open and it will
open the spreadsheet in PPT. You can use this as a template for your PBI/Sprint backlog.
Product
Backlog
Sprint Backlog
Game Play
Game Play
Navigation
Items
L
L
Monsters
In-Game Ents
Game Engine
Game Engine
Mechanics
Event System
L
L
Entity
Website
Website
Acct Creation
S
L
Use Editors
Database
Database
User Table
M
M
Editors
M
Multiplayer
M
Figure F.1 PBI and Sprint Backlog for Rooms.
32
Play Game
Items &
Monster
Tables