Cards Against Humanity Web Game

Final Report

Version No. 1.0

Sammy Dagher
Robert Thompson
LeRoy Eberly
Zev Lopez

Contents
1.0 Introduction
1.1 Goals and objectives
1.2 Statement of scope
1.3 Software context
1.4 Major constraints
2.0 Usage scenario
2.2 Use-cases
2.3 Special usage considerations
3.0 Data Model and Description
3.1 Data Description
3.1.1 Entities and attributes
3.1.2 Relationships
3.1.3 Complete build ERD
4.0 Functional Model and Description
4.1 Description for Functions
4.2 Software Interface Description
4.2.1 Human interface
4.2.1.1 Home Page
4.2.1.2 Play Screen
4.2.1.3 Create a game
4.3 Use Case Diagrams
4.3 Sequence Diagrams
5.0 Behavioral Model and Description
5.1 Description for software behavior
5.1.1 Events

5.1.2 States
5.2 State Transition Diagrams
5.3 Activity Diagram
6.0 Restrictions, Limitations, and Constraints
7.0 Validation Criteria and Testing
7.1 Classes of tests
7.2 Expected software response
8.0 Appendices
8.1 Analysis metrics to be used
8.2 Supplementary information
8.3 Updates and Issues
8.4 Lessons learned

SOFTWARE REQUIREMENTS SPECIFICATION

1.0 Introduction
This section provides an overview of the entire requirement document.
This document describes all data, functional and behavioral requirements
for the game.
1.1 Goals and objectives
The goal of our project is to take an existing web game and recreate it with new
features and different functionality using ASP.Net. We wanted to choose something
that would be fun and enjoyable to make and to use. We want to take inspiration from
the game that is currently there and make it more interesting and interactive for the
players. We hope to accomplish this by making the user interface more appealing and
engaging.

1.2 Statement of scope

What are we going to build?
We are going to build a replica of the popular card game, Cards Against Humanity,
that is hosted on a website. The game consists of 4-10 players and are given a
starting hand of 10 white cards. Each turn, everyone draws a new white card to their
hand. To start the game, someone at random is chosen to be the card Czar and a
black card will be drawn and shown to all players. Players will then choose the card
they find the funniest, best fitting, or most clever card. Once all players have chosen a
card, the Card Czar will then choose the one that he/she finds the best. The winning
player is then awarded an awesome point and the next Czar is chosen in round-robin
fashion. The game ends when a player reaches a certain number of points. The Game
Host determines the numbers of points that will end the game. Before the game is
started, the host will select pre-defined rules for the game.
Why is this interesting?
This web application is interesting in the same way that the physical card game is
interesting. There exists many web clones of the game, but many of them are difficult
to use or not customizable to the extent we would like them. We want to take the
open source game and transform it into a more customizable game experience for all
users.

1.3 Software context

The big picture is to have a fun and easy to use web game that you can use to sit
down and play a funny game with some friends. It will easily allow people to play the
game and create new games. The web page will also allow for customization in the
rules of the current game and the cards used during games. An important factor for
the games is flexibility.

1.4 Major constraints

The main constraint for this project is that all the planning, coding, testing, and Web based
implementation and debugging must be completed by the deadline date: December 10 th, 2015.

2.0 Usage scenario

This section provides a usage scenario for the software. It organized
information collected during requirements elicitation into use-cases.
2.1 User profiles
1. Player - The player can create a new game or join an existing game. If the player creates a new game
they can start the game to begin playing. A player can also select the rules of the game to play with voting
or with a czar. A player can also create new cards for future games. During a game, players can play one
white card and then they can vote for the best white card played, or they can choose one white card and
wait for the czar to pick the best one.

2. System - The system keeps track of a new game and it begins the game once a player decided to start
the game. The system keeps track of existing cards and newly created cards. The system changes the
game based one the player selected rules. During a game, the system keeps track of the points each
player has and the winners of each round. Once the win condition is met the system will end the game
and start a new game.
3. Czar - The czar role is used only when that game type is selected. If a czar is used, then each round one
player becomes the czar. The czar chooses who they think played the best white card and the system
gives the owner of that card one point.

2.2 Use-cases
1. Create Game - Allows a player creates a new game where other players can join in to play.
2. Join Game - Allows another player to join a game that is about to begin.
3. Start Game - Once all the players are ready, start game begins the game. The game begins with each
player having 0 points and 10 cards.
4. Create Custom Deck - Allows a player to create new cards and new decks by saving their cards in a
group as decks.
5. Select Card - During a game the player selects the white card they would like to play on that round. Each
player in the game selects the card they wish to play for the round.
6. Player Vote - All the players vote for who they think played the best card for the round. This functionality is
only available if the voting game type is chosen.
7. Select Rules - A player can select the game type and card decks to include before the game begins.
Choosing different options will change the rules for the next game.
8. Choose Winner - The czar chooses who won the round by picking the card that he thought was the
funniest and the point is given to the player that is chosen. This functionality is only available if the czar
game type is chosen.
9. Track Points - The system keeps track of each player's score after each round. The point count is used to
determine the winner of the game.
10. End Game - The system ends the game once one player has reached the right amount of points. The
winning number of points is determined based on the rules the player chooses.

11. Game Transition - After a game has finished the players can start a new game or end the game. During
the game people can quit out of the game

2.3 Special usage considerations

N/A
3.0 Data Model and Description
This section describes information domain for the software
3.1 Data Description
Entities and relationships that will be managed/manipulated by the software
are described in this section.
3.1.1 Entities and attributes
1.
a.
b.
c.
2.
a.
b.
c.
d.

Decks - Decks will keep track of all the created decks that can be used in the game and it
will keep track of which cards are assigned to which decks. The attributes include the
following:
Deck name
Deck#
Number of cards
Cards - Will keep track of all the cards created for the game. The attributes include the
following:
Card type
Card#
Card text
Parent deck

3.1.2 Relationships
Added to - the relationship among the cards and decks entities which means
that a card is in a deck.

3.1.3 Complete build ERD

4.0 Functional Model and Description

Description of major software functions along with UML Use Case, and
sequence diagrams.
4.1 Description for Functions
A detailed description of each software function.
1.
1.1.

Use case 01
Use Case
Create Game

1.2.
1.3.

Actors
Player, and System

Preconditions
1) If a new person wants to play a game and no current games exist then the player will
create a new game.

1.4.

Triggers
Use case initiates when a new player wants to play a game and no current games exist or if
a new player wants to create their own game to play with their Friends.

1.5.

Post Conditions
1) A new game will be made where new players can join.

2.
2.1.

Use case 02
Use Case

2.2.

Join game

Actors
Player

2.3.

Preconditions
1) If a player wants to join an existing game then they can join it.

2.4.

Triggers
When a player wants to join a friends game or a random game then the use case is
triggered.

2.5.

Post Conditions
1) The player has joined an existing game and is ready to begin playing.

3.
3.1.

Use case 03
Use Case

3.2.

Start Game

Actors

Player, and System

3.3.

3.4.

3.5.

Preconditions
1) In order for a game to start a game has to have been created and players need to be in
the game ready to play.
Triggers
A game can begin when all the players in the current game are ready to begin and all the
rules for the game have been set. The game begins when the one that created the game,
starts the game.

Post conditions
1) After a game has been started then the players can begin to play and choose their cards
each round.

4.
4.1.
4.2.

Use case 04
Use Case
Create custom deck

Actors

Player, and System

4.3.

4.4.

Preconditions
1) A user must be on the web page.
2) A user must not be in a game.
Triggers
Use case is initiated when a player not currently in a game wants to create new cards for
future games.

4.5.
4.6.

Post conditions
1) New cards are created and those new cards can be stored together as decks.
2) New cards and new decks can be used for later games.

5.
5.1.

Use case 05
Use Case

5.2.

Select Cards

Actors
Player

5.3.

Precondition
1) A game needs to have been created.
2) The player choosing the cards needs to be a player that is currently playing in the game.

5.4.

Triggers
The event is triggered when a player wants to select which white card they think is the
funniest. Then the players plays their card for that round.

5.5.

Post Conditions
1) all of the players have played their funniest card and the game is ready for voting.

6.
6.1.

Use case 06
Use Case

6.2.

Player vote

Actors
Player

6.3.

6.4.

Preconditions
1) A game needs to have been created.
2) The created game needs to have been started.
Triggers
When a game is in session, each round players will vote for the card that they thought was
the funniest.

6.5.

Post Conditions
1) Funniest card has been voted on by each player or by the czar.
2) System is ready to determine the winner of the round.

7.
7.1.

Use case 07
Use Case

7.2.

Select Rules

Actors

Player, and System

7.3.

7.4.

Preconditions
1) A game needs to have been created.
2) The player selecting the rules needs to be the one that created the game.
Triggers
The event is triggered when the player that created the game wants to change the rules for
the game or the cards to include in the game.

7.5.

Post Conditions
1) A game is ready to start with the set rules and cards.

8.
8.1.

Use case 08
Use Case

8.2.

Choose Winner

Actors

Czar, and System

8.3.

8.4.

Preconditions
1) A game needs to have been created and started.
2) All players have played a card for the round.
Triggers
Once all the players have played their cards then either the czar can choose the winner or
the system must determine the winner depending on the rules chosen.

8.5.

Post Conditions
1) The winner of the round was determined.
2) Depending on the rules, a new czar was chosen.

9.
9.1.

Use case 09
Use Case

9.2.

Track Points

Actors
System

9.3.

9.4.

Preconditions
1) A game needs to have been created and started.
2) All players have played a card for the round.
3) Players have been winning the rounds.
Triggers
This use case is triggered when the game is playing out. After each round the system keeps
track of the ongoing points.

9.5.
9.6.
10.
10.1.
10.2.
10.3.

10.4.

Post Conditions
1) The Points have been kept and the winner can be determined after each round.
Use case 10
Use Case
End Game
Actors
System
Preconditions
1) A game needs to have been created and started.
2) All players have played a card for the round.
3) Players have been winning the rounds.
4) A player has reached the winning number of points.
Triggers
This use case is triggered when a player has reached the winning number of points for a
game.

10.5.

Post Conditions
1) The game is ended and the winner is announced.
2) A new game can be started or players can leave.

11.
11.1.

Use case 11
Use Case

11.2.

Game Transition

Actors

Player, Czar, and System

11.3.

Preconditions
1) A game needs to have been created and started.
2) All players have played a card for the round.
3) Players have been winning the rounds.

11.4.

4) A player has reached the winning number of points.

5) A game has ended.
Triggers
This use case triggers when a game has ended or during the middle of a game when a
player wants to leave.

11.5.

Post Conditions
1) A player has left the current game.
2) The game has finished and a new game has been started or the game has been ended.
4.2 Software Interface Description
The software interface to the outside world are described here.
4.2.1 Human interface
4.2.1.1 Home Page

Caption: This is the home page that a player will see once they navigate
to the website.

10

4.2.1.2 Play Screen

Caption: The is the game screen that the player will see while in a game

11

4.2.1.3 Create a game

Caption: This is the screen the player sees when setting up the game rules
and when they are interacting with the card and deck creator

12

4.3 Use Case Diagrams

13

4.3 Sequence Diagrams

Main flow - This shows the happy path of the web page and how a user would
interact with the game. One user would start a game and allow other players
to join. While other players are joining the user can select the rules and cards
for the game. Then the player begins the game and the rounds are played
until a player wins.

14

5.0 Behavioral Model and Description

A description of the behavior of the software is presented.
5.1 Description for software behavior
A detailed description of major events and states is presented in this section.
5.1.1 Events
Events consist of the following:

Click Start Game

Upon clicking the Start Game button, the user will now be in the
administrator of the game session. They have access to controls that others
who join the session do not. These controls include Game Settings, Active
Card Decks to choose From, Create New Deck of Cards, and Import a Deck of
Cards.

Click Join Game

Upon clicking the Join button from the home screen, the user will be directed
an idle game page, where the administrator/ host is still choosing
settings/cards or waiting for more players to join before they click Create
Game.

Click Create Game

Clicking the Create Game initializes the beginning of the game between
players currently in the session.

Click Quit Game

This will prompt a player back to the home screen. If a host quits, then host
is migrated to player with highest score.

Click Create Custom Deck

Clicking the Create button to create a new deck will prompt you to a new
screen to create question and answer cards.

End of Game
This event occurs when a certain number of points is reached or only one
player remains in the session.

15

5.1.2 States
A listing of states (modes of behavior) that will result as a consequence of
events is presented.

Home Screen
Host Screen
Player Screen
Card Creation Screen
Game Transition Screen

5.2 State Transition Diagrams

16

5.3 Activity Diagram

6.0 Restrictions, Limitations, and Constraints

Special issues which impact the specification, design, or implementation of
the software.
Limited time.

7.0 Validation Criteria and Testing

Will be done after implementation
7.1 Classes of tests

Input

Expected Output

Test create game and choose alias

A game will be created with the host

Test choose decks

Decks will be added to the game

Test chose number of players

Number of players can join

17

Test one round

The winner will be chosen and new round

starts

Test winning game

Play game until the maximum number of

points is reached.

7.2 Expected software response

N/A.
8.0 Appendices
Presents information that supplements the Requirements Specification
8.1 Analysis metrics to be used
Requirements metrics - Eleven functionalities.
Testing metrics - To be done with the software.
User interface - 3 Main pages for user interaction.

8.2 Supplementary information

Infrastructure
Platforms: The application will be available on all systems that can use the web, this includes PC
and Mobile systems. This will work with IE, Chrome, FireFox, and Safari. The technology will be
written in asp.net with c# codebehind. The system will use a mysql database to store all of the card
decks.

Task List
Milestones:

1. November 1st - Have complete software specifications and planning to begin implementation
2. December 1st - Have a full working system that has all use cases and usage scenarios
complete. Only bug fixes should be left after this milestone is reached.
3. December 10th - Project will be completed.
Individual Tasks
Interface Design - Zev
Network Connectivity - Sammy
Database - Robert
Code behind - LeRoy
Documentation - Everyone

18

Project Web Link

http://68.46.191.28:8085/CAH/

8.3 Updates and Issues

Major system updates and changes
Database: One major change we made is not using a database to store our cards. Initially we
were going to use a database to store our cards and decks. The cards and decks could then be
used in the game. We decided to use a cardcast API instead to pull cards and decks from there to
give us more time to work on the actual gameplay. Additionally we storing the data for each game in
a global application Cache.The cache is cleared when the application is cycled (in our case, when IIS is
turned off/restarted).

Caption: As a result of not using the database the system pull cards from the API.
Web Page Updating: We used ajax in c sharp to do the updating on the web pages. We just used
update panels combined with a timer that refreshed the cards every second without reloading the page.
We used this with the player cards, end of round selected cards, players in pregame lobby, and current
sessions on the home page.

19

Final Interface Design:

Home Page

Game Setup Page

20

In Game Interface

21

Outstanding Issues
Time constraint: We choose to do a project that we thought would be
interesting and fun to do but it turned out to be more difficult than we
anticipated and as a result we were not able to accomplish as much as we
wanted. In the end we opted for using a card API instead of a database and we
were not able to make the functionality to allow the users to make their own
cards.

Updated Usage Scenario

22

8.4 Lessons learned

Start Sooner was our biggest lesson learned so that we could have spent more time
on figuring out things to do.
Estimating the amount of work that is needed for each task.

23