Deck’d Out
This application will be a graphical user interface that will act as a hub for the user to access the two card games that we are developing: Spades and Euchre. The application will allow the user to play different card games while keeping track of the score. There will also be user profiles, which will track the number of respective games the user has won and will be able to rank the users against each other.
In terms of the population who might eventually our system, it would be used by younger or middle-aged working men and women who enjoy card games, but are not intense enough to play at weekly in-person meetings. Then again, those intense individuals could also use our app and compete with others via the ranking system. Many older and younger individuals will likely either not understand or have access to the required technology to run our application, though technology like this is becoming more accessible every day.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.
Playing Card - One of a set of 24 to 78 thin rectangular pieces of cardboard or plastic marked on one side to show its rank and suit and used in playing any of numerous games [1]
Suit - All the playing cards in a pack bearing the same symbol [1]
Trump - A card of a suit any of whose cards will win over a card that is not of this suit [1]
Bid - An announcement of what a cardplayer proposes to undertake [1]
Trick - The cards played in one round of a card game often used as a scoring unit [1]
Card Game - A game that uses a deck of cards [1]
Spades (card game) - A card game commonly played with four players in pairs with a standard 52-card deck. Spades are always trump. Other suits have no intrinsic value during play, but a card of the suit led in the current trick will beat a card of any other suit except a spade. The goal is to score 500 points to win. Points are accrued by winning at least the number of tricks bid in each hand and are lost by failing to take at least that many, or in some cases by taking too many. [2]
Euchre - A card game commonly played with four players in pairs with a 32-card deck. Each player is dealt five cards and the player making trump must take three tricks to win a hand. The team that reaches 10 points first wins. [2]
ID | Description | Priority | Status |
---|---|---|---|
R1 | When the user first opens the application the frontend SHALL display the register page. | Med | Closed |
R2 | When the user clicks on the sign in button after entering their valid username and password on the login page, the frontend SHALL display the game lobby page. | High | Closed |
R3 | When the user clicks on the "Join Now" button on the login page, the frontend SHALL display the register page. | High | Closed |
R4 | When the user clicks on the profile button on any screen that it appears in, the frontend SHALL display the profile page. | Med | Open |
R5 | When the user clicks on the settings button on any screen that it appears in, the frontend SHALL display the settings page. | Low | Open |
R6 | On the game lobby page, when the user selects a game to play, the frontend SHALL display the game in question, and the backend SHALL begin the repsective game() method. | High | Closed |
R7 | When the user clicks on the leaderboard button, the frontend SHALL display a leaderboard containing the ranking of all registered users. | Med | Closed |
R8 | When the user clicks on the home button (top left, in the form of the logo), the frontend SHALL display the game lobby home screen. | Med | Open |
R9 | When the user selects a card to play, the card will be inserted into the trick, the card SHALL be removed from the user's hand of cards, and the correct winner of the trick will be determined by the backend logic. | High | Open |
R10 | When the winner of a trick is determined, the application SHALL display who won the trick to the user. | Med | Closed |
R11 | After a round of spades, the correct number of points SHALL be calculated and added to each teams total, and if one team has over 500 points then they SHALL be declared the winner of the game. | Med | Open |
R12 | [GENERAL REQ] When the user begins a game of spades, the game logic defined in the backend SHALL be correctly implemented and allow for a legal game of spades to be played. | High | Closed |
R13 | Users SHALL be able to sign into the application with an account and access their high scores. | Med | Closed |
R14 | Users SHALL be able to play the specified card games against other players. | Low | Open |
R15 | There SHALL be a ranking system that compares the user's scores to other player's scores. | Med | Closed |
R16 | The user SHALL be able to access a hub that will allow them to pick the card game that they want to play. | High | Closed |
R17 | The logic of each card game SHALL work properly, and allow for a winner and a loser, as well as correct scoring. | Med | Closed |
R18 | Application UI SHALL be as accessible and clear, with no confusing buttons or settings. | High | Closed |
R19 | The application SHALL be able to connect to the backend logic and display the correct information to the user. | High | Closed |
R20 | The application SHALL be able to handle an incorrect username / password pair and display an error message to the user. | High | Closed |
R21 | The application SHALL be able to prevent users from making illegal moves in the card games. | High | Closed |
R22 | The user SHALL be able to see the cards that they are playing with in a graphical representation. | High | Closed |
R23 | The user SHALL be able to see the game of spades that they are playing. | High | Closed |
R24 | The user SHALL be able to see the game of euchre that they are playing. | High | Open |
R25 | The user SHALL be able to view all the past card games they played while logged into their account. | Low | Open |
As a user, I want to be able to register for an account so that I can access the features available to my account.
As a user, I want to log into the card game hub using a username and password so that I can access the features available to my account.
As a user, I want to be able to use the graphical user interface (GUI) to select the mode of operation.
As a user, I want to be able to use the GUI to view all the past card games I played while logged into my account.
As a user, while viewing past card games, I want the application to show the optimal move for any given card hand, based only on the information known to the player.
As a user, I want to play a legal game of Euchre against a computer player.
As a user, I want to play a legal game of Spades against a computer player.
As a user, I want the card application to prevent me from making an illegal move.
As a user I want the Euchre backend logic to be correct.
As a user, I want to play a legal game of Euchre against a human player over the internet.
As a user, I want to play a legal game of Spades against a human player over the internet.
As a user, I want to be able to view my game statistics, including the number of wins and losses in each card game.
As a user, I want to my game statistics to update after I play games.
As a user, I want to be able to view a leaderboard to see how I rank against other players.
As a user, I want to be able to view my leaderboard rank update as I play more games against other players.
As a user, I want to be able to navigate between screens.
As a user, I want to be able to access the game lobby from any screen.
As a user, I want the card data from the UI to connect with the Backend functionality in both Spades and Euchre logic.
As a developer, I want more insight on how to connect frontend to backend.
As a user, I want a graphical representation of the cards that I am playing with.
As a user, I want to be able to see the game of Spades that I am playing.
As a user, I want to be able to see the game of Euchre that I am playing.
As a user, I want to be able to view all the past card games I played while logged into my account.
The user interface for the application will have a login page, a register page, a home page, a game page, and a leaderboard page.
The login page will have a text field for the user to enter their username and a text field for the user to enter their password. There will be a sign in button that the user can click to sign in and a join now button that the user can click to register. The register page will have a text field for the user to enter their username, a text field for the user to enter their email, a text field for the user to enter their password, and a text field for the user to verify their password.
The home page will allow the user to select a game to play.
The game page will display the game that the user is playing. For both Spades and Euchre
The leaderboard page will display the user's rank compared to other users.
ID | Description | Priority | Status |
---|---|---|---|
SR1 | Users should be able to safely input their username and password and know it is protected. | Low | Open |
SR2 | Users should be able to log into their account anytime they wish assuming they have the correct password. | High | Closed |
SR3 | Incorrect username / password pairs should not be allowed to access accounts. | High | Closed |
SR4 | Users should not be able to access other user's accounts. | High | Open |
SR5 | Users should not be able to access the backend logic of the application. | Low | Closed |
SR6 | Users should not be able to access the database of the application. | High | Open |
ID | Description | Priority | Status |
---|---|---|---|
SYSR1 | We are targeting Windows users with our application. | Med | Closed |
SYSR2 | We are targeting MacOS users with our application. | Med | Closed |
SYSR3 | We are targeting Linux users with our application. | Med | Closed |
SYSR4 | Web browsers that support JavaScript are required to run our application. | High | Closed |
SYSR5 | The application should be able to run on a computer with at least 4GB of RAM. | High | Closed |
SYSR6 | The application should be able to run on a computer with at least 1GB of free storage space. | High | Closed |
SYSR7 | The application should be able to run on a computer with at least a 2.0 GHz processor. | High | Closed |
SYSR8 | The application should be able to run on a computer with at least a 1280x720 resolution screen. | High | Closed |
User Interface Frontend:
- Technologies: JavaScript, Maven
- Purpose: This layer handles the presentation and interactivity with the user, delivering a responsive and accessible experience.
Backend:
- Technologies: Java, Spring Boot
- Purpose: The backend serves as the bridge between the frontend and the game engine, handling requests, and processing the game logic.
Game Engine:
- Technologies: Java
- Purpose: The core of the game's operation, managing game state, enforcing rules, and running the main game loop.
Game Logic:
- Technologies: Java
- Purpose: Implements the specific rules and mechanics of each game (Euchre, Spades), including scoring calculations and decision-making.
Networking:
- Technologies: Java Database Connectivity (JDBC)
- Purpose: To connect to the database, allowing for the storage and retrieval of user data, game states, and scores.
User Authentication:
- Technologies: JSON Web Tokens (JWT)
- Purpose: To securely identify users and manage sessions, ensuring that users can securely log in and interact with the system.
Database:
- Technologies: MySQL Database
- Purpose: To store user information, game states, scores, and potentially complex game-related data structures.
Score Calculation:
- Technologies: Java
- Purpose: To calculate and maintain scores based on the rules of Euchre and Spades, respectively.
---
title: Deck'd Out Database ERD
---
erDiagram
User {
int id PK "NOT NULL"
varchar(255) email "NOT NULL"
varchar(255) username UK "NOT NULL"
varchar(255) password "NOT NULL"
int spades_num_games "DEFAULT 0"
int spades_games_won "DEFAULT 0"
int euchre_num_games "DEFAULT 0"
int euchre_games_won "DEFAULT 0"
}
Card {
int id PK "NOT NULL"
boolean is_played "DEFAULT 0"
varchar(50) owner "NOT NULL"
varchar(50) suit "NOT NULL"
int value "NOT NULL"
}
---
title: Class Diagram
---
classDiagram
class Player {
- String userName
- int bid
- ArrayList<Card> hand
+ Player(String userName)
+ Card pickCard(Card card)
+ void setBid(int bid)
+ int getBid()
+ void setHand(ArrayList<Card> hand)
+ ArrayList<Card> getHand()
+ void removePlayedCard(Card playedCard)
+ String getuserName()
+ boolean hasTrump(ArrayList<Card> hand)
+ boolean hasLeadingSuit(ArrayList<Card> hand, String leadingSuit)
+ Card getHighNorm(Player player)
+ Card getLowNorm(Player player)
+ int numtrump(Player player)
+ boolean containsCard(Card card, Player player)
+ boolean containsNormAce(Player player)
+ Card getHighSuit(Player player, String suit)
+ Card getLowSuit(Player player, String suit)
+ boolean hasGivenSuit(Player player, String suit)
+ boolean hasGivenCard(Player player, Stringsuit, int cardVal)
+ int numNonTrumpVals(Player player, int cardVal)
+ Card cpuChooseCardSpades(Player cpu, String leadingSuit, Player startPlayer)
+ int cpuChooseBid(Player cpu)
+ String[] cpuSuitDecision(Player cpu, String flippedTrump)
}
class Card {
- String suit
- int cardValue
- Player owner
- boolean dealt
+ Card(String suit, int cardValue, Player owner)
+ Card(String suit, int value)
+ void setOwner(Player owner)
+ void setDealt(boolean dealt)
+ boolean getDealt()
+ String getSuit()
+ int getCardValue()
+ Player getOwner()
+ boolean isSpade()
+ String toString()
}
classDiagram
class Deck {
- ArrayList<Card> deck
+ Deck()
+ void shuffle()
+ ArrayList<Card> spadesDeal(Player playerName)
+ ArrayList<Card> euchreDeal(Player playerName)
+ Card cardCompareEuchre()
+ String toString()
}
class Trick {
- String leadingSuit
- String trumpSuit
- Card winningCard
- ArrayList<Card> trickCards
- Player winningPlayer
+ Trick(ArrayList<Card> trickCards)
+ Card winnerOfTrick()
+ Card winnerOfEuchreTrick()
+ Card cardCompareEuchre(String leadingSuit, ArrayList<Card> trickCards)
+ Player getWinningPlayer()
+ Card cardCompareSpades(String leadingSuit, ArrayList<Card> trickCards)
}
class SpadeGameLogic {
String player1Name
String player2Name
String player3Name
String player4Name
Deck deck
int team1PT
int team2PT
int placeHldrBid
+ void gameLogic()
}
classDiagram
class EuchreRound {
- String declaredTrump
- String flippedTrump
- int p1EuchreTricks
- int p2EuchreTricks
- int p3EuchreTricks
- int p4EuchreTricks
- String teamPrediction
- int team1EuchreTricks
- int team2EuchreTricks
- Trick[] euchreTrick
- Player euchreStartPlayer
- Deck deck
- Player p1Euchre
- Player p2Euchre
- Player p3Euchre
- Player p4Euchre
- String EuchreLeadingSuit
- boolean goAlone
- boolean nameSuit
- int dealerTracker
+ EuchreRound(String teamPrediction, Player p1Euchre, Player p2Euchre, Player p3Euchre, Player p4Euchre)
+ trickLogicSpades(ArrayList<Card> p1EuchreHand, ArrayList<Card> p2EuchreHand, ArrayList<Card> p3EuchreHand, ArrayList<Card> p4EuchreHand, Player euchreStartPlayer)
+ int[] playRoundEuchre()
}
classDiagram
class SpadesRound {
- int p1SpadesBid
- int p2SpadesBid
- int p3SpadesBid
- int p4SpadesBid
- int p1SpadesTricks
- int p2SpadesTricks
- int p3SpadesTricks
- int p4SpadesTricks
- int team1SpadesPred
- int team2SpadesPred
- Trick[] spadesTrick
- Player spadesStartPlayer
- Deck deck
- Player p1Spades
- Player p2Spades
- Player p3Spades
- Player p4Spades
- int team1SpadesOvrTricks
- int team2SpadesOvrTricks
- String spadesLeadingSuit
+ SpadesRound(int team1SpadesPred, int team2SpadesPred, Player p1Spades, Player p2Spades, Player p3Spades, Player p4Spades)
+ boolean legalCardCheck(Card card)
+ Player trickLogicSpades(ArrayList<Card> p1SpadesHand, ArrayList<Card> p2SpadesHand, ArrayList<Card> p3SpadesHand, ArrayList<Card> p4SpadesHand, Player spadesStartPlayer)
+ int[] playRoundSpades()
+ int pointCalc(int player1SpadesTrick, int player2spadesTrick, int prediction, int teamOverspadesTrick, String team)
+ void setTeam1OvrspadesTrick(int num)
+ void setTeam2OvrspadesTrick(int num)
+ ArrayList<Card> getLegalCards(String spadesLeadingSuit)
}
---
title: Deck'd Out Program Flowchart
---
graph TD;
Start([Start]) --> |Login| Login_Data[/Input Login Data/]
Start --> |Register| Register[/Input Registration Info/]
Login_Data --> Process_Valid_Data[Process Valid Data]
Register --> Process_Valid_Data
Process_Valid_Data --> Select_Game{Select Game}
Select_Game --> |Spades| Spades_UI
Select_Game --> |Euchre| Euchre_UI
Spades_UI --> Play_Spades[Play Spades]
Euchre_UI --> Play_Euchre[Play Euchre]
Play_Spades --> End([End])
Play_Euchre --> End
---
title: State Diagram For Deck'd Out Application
---
stateDiagram
[*] --> Ready
Ready --> Login : Login
Ready --> Register : Register
Login --> GameLobby : Login Success
Register --> GameLobby : Register Success
Login --> Login : Login Failure
Register --> Register : Register Failure
GameLobby --> Spades : Spades
GameLobby --> Euchre : Euchre
GameLobby --> Leaderboard : Leaderboard
Spades --> SpadesGame : Play Spades
Euchre --> EuchreGame : Play Euchre
Spades --> GameLobby : Select Another Game
Euchre --> GameLobby : Select Another Game
SpadesGame --> Spades : Spades Game Over
EuchreGame --> Euchre : Euchre Game Over
sequenceDiagram
participant ReactFrontend
participant SpringBootBackend
participant MySQLDatabase
ReactFrontend ->> SpringBootBackend: HTTP Request (e.g., GET /api/card)
activate SpringBootBackend
SpringBootBackend ->> MySQLDatabase: Query (e.g., SELECT * FROM card)
activate MySQLDatabase
MySQLDatabase -->> SpringBootBackend: Result Set
deactivate MySQLDatabase
SpringBootBackend -->> ReactFrontend: JSON Response
deactivate SpringBootBackend
stateDiagram
User --> Frontend: User Interface
Frontend --> Backend: User Input
Backend --> Frontend: Game State
Backend --> GameEngine: Game Logic
GameEngine --> GameLogic: Game Rules
GameLogic --> Spades: Spades Rules
GameLogic --> Euchre: Euchre Rules
Spades --> ScoreCalculation: Score Calculation
Euchre --> ScoreCalculation: Score Calculation
ScoreCalculation --> Backend: Score Update
Backend --> Database: Data Storage
Database --> Backend: Data Retrieval
Frontend --> Database: User Data
This document serves as the complete definition of L3-33’s coding standards for source code in the Java programming language.
External Resource: Oracle’s Javadoc
Heavily references: Java Coding Standard
—
- Use descriptive names for all variables, function names, constants, and other identifiers.
- Use single letter identifiers only for the counter in loops.
- Class names use PascalCase.
- Variable names use camelCase.
- Variables include parameters, local variables, and data fields
- EXCEPTION: use UPPER_CASE for constants/final variables.
- Method names use camelCase.
- The source file name consists of the case-sensitive name of the top-level class it contains, plus the .java extension
Every class should be preceded with a descriptive comment using the Javadoc notational convention. The comment should describe the purpose of the class. Class names start with an uppercase letter (as mentioned above).
Every method definition should be preceded with a descriptive comment using the Javadoc notational convention. The comment should include a description of the method, the name and description of each parameter, a description of the return value, and the name and description of any exceptions thrown within the method using Javadoc keyboards and formatting.
Each public variable should be preceded with a descriptive comment using the Javadoc notational convention. The comment should describe the purpose for the public variable.
In-line comments should be used to explain complicated sections of code, such as loops. Use the // comment delimiter for in-line comments. Do not comment on generally known features of the Java language.
Use two blank lines to separate each method within a class definition. Use one blank line to separate logical sections of code within a method
Put a single space before each ‘{‘. Separate all binary operators, such as ‘+’, ‘-’, ‘*’, ‘/’, ‘%’, etc., with a single space. EXCEPTION: unary operators such as ‘++’, ‘--’, etc.
Open braces do not start a new line. Close braces do start a new line, and are indented with the code they close. Comments line up with the block they comment.
Lines of code should be kept short, generally less than 80 or 100 characters wide. Each public class is contained in a separate file. Each file has the name of the public class contained within it.