Casino Blackjack (Group 53)

Software Requirements Specification

Version 1

Revision History

Date | Version | Description | Author
12/03/03 | v1 | Most of section 1. | Paul
15/03/03 | v1 | Most of section 2. | Andrew, Danny, Jon & Paul
18/03/03 | v1 | Neatened HTML & CSS (so we'll be able to use Dreamweaver). | Andrew
19/03/03 | v1 | Added to section 3 & made srs_interface.htm | Andrew
21/03/03 | v1 | Talked about unresolved issues. | Andrew, Danny, Jon & Paul
22/03/03 | v1 | Added changes | Paul
23/03/03 | v1 | Reviewed changes | Andrew
23/03/03 | v1 | Added changes | Jon
23/03/03 | v1 | Reviewed changes | Jon
04/03/03 | v1 | Wrote content for rules (as requested by Dmitry) | Paul
05/04/03 | v1 | Made minor changes based on Dmitry's feedback & added srs_rules.htm | Andrew

NOTE: This is an outdated version of the SRS (kept only for record-keeping purposes) - srs_v2.htm is the newer version.

Table of Contents

- 1. Introduction
  - 1.1 Purpose
  - 1.2 Scope
  - 1.3 Definitions, Acronyms and Abbreviations
  - 1.4 References
  - 1.5 Overview
- 2. Overall Description
- 3. Specific Requirements
  - 3.1 Functionality
  - 3.2 Usability
  - 3.3 Reliability
  - 3.4 Performance
  - 3.5 Supportability
  - 3.6 Design Constraints
  - 3.7 Online User Documentation and Help System Requirements
  - 3.8 Purchased Components
  - 3.9 Interfaces
    - 3.9.1 User Interfaces
    - 3.9.2 Hardware Interfaces
    - 3.9.3 Software Interfaces
    - 3.9.4 Communications Interfaces
  - 3.10 Licensing Requirements
  - 3.11 Legal, Copyright and Other Notices
  - 3.12 Applicable Standards
- 4. Supporting Information

Software Requirements Specification

# 1. Introduction

- Version 1.01
  - This project was initiated by Dmitry Konovalov, to fulfil the need for online gaming/chat environments where people could meet safely online.
    This Blackjack game is for entertainment purposes only - no actual transfer of money takes place, in accordance with Australian Online Gaming legislation.
  - Our main focus is the development of the Blackjack game using client-server architecture.

## 1.1 Purpose

- 1.1) This SRS describes requirements for Casino BlackJack program. This SRS is written for to formally acknowledge this project, and to gain a better understanding of what the project requires
  - 1.1) This document will updated, and used a reference throughout the project's lifespan.
- 1.1) The project itself is an online virtual casino environment that allows people to play blackjack and chat to other players online. The player is able to create virtual player with a name, password and given a starting bank roll to play with against the house. Once a virtual player is created, the player can enter the casino. They are then assisted to a table to match their skills against a dealer, or play with others to test their skills against the house.

## 1.2 Scope

> NOT REQUIRED.

## 1.3 Definitions, Acronyms and Abbreviations

- 1.3.1) Any red text in this document is unnecessary in the SRS, but was included to illustrate potential problems.
- 1.3.2) See also project Glossary.

## 1.4 References

Title | Report number | Date | Publishing organization | Sources references obtained
Pure Java2 | null | 1999 | SAMS | sockets, jdbc
Core Java V1 Fundamentals | null | 2001 | Sun Microsystems Press | coding
Core Java V2 | null | 2000 | Sun Microsystems Press | coding
Jupiters Blackjack manual | null | 1998 | Jupiters Ltd. | blackjack rules
Mastering XML | null | 1998 | Sybex | understand XML
Java 1.4: | null | null | null | java.sun.com

## 1.5 Overview

> NOT REQUIRED.

# 2. Overall Description

> Product Perspective:

> - A casino game (playing against the house for money)(V1) (8 points)

> Product Functions:

> - Multi-threaded server: separate thread is created for each game(V1) (2 points)
> - Multi-threaded client: communication with a server is in a separate thread(V1) (2 points)
> - Client-to-Client cha(V1) (1 point)
> - Server based chat room(V1) (2 points)
> - Saving and replaying game/recent transaction history to/from a file/database (V2) (5 points)
> - Feature total = (20 points)

> User Characteristics

> - A user will have a persistent virtual personality consisting of a name, password and a bank roll.
>   - NOTE: This will be stored online in a database.

> Constraints:

> - a casino game (playing against the house for money)
> - All coding must be done in JAVA 1.4
> - 3-4 students per group
> - Client-server architecture
> - Server supported by a database (SQL)
> - Multithreading (client or server or both)

> Assumptions and Dependencies:

> - A user is to only register one online virtual player
> - local machine should have a Java Runtime environment
> - network connection is required for more than one player.

> Requirements Subsets:

> - Using XML encoding/decoding of objects passed through tcp/ip sockets as base for client-server architecture

# 3. Specific Requirements

## 3.1 Functionality

> The functionality requirements of this game have been broken into four features:

> - 3.1.1 - Creation of virtual players.
> - 3.1.2 - Logging into the virtual casino and getting assigned to a table.
> - 3.1.3 - Playing blackjack at a table.
> - 3.1.4 - Online chat feature within the game environment.

> Note that, all these requirements relate to version 1.01, and were used as a guideline for creating the user interface.

> ### 3.1.1 - Create New Virtual Player

> A new user, at the startup screen, should be able to:

> - 3.1.1.1) Create a new virtual player - user enters a unique player ID and a password.
>   - 3.1.2.1.1) The playerID entered by the user must be unique and the password must be between five and ten characters long. If so, a new virtual player is created (in the database) with a starting bankroll of $25,000 and the user is logged directly into the virtual casino. If not, an appropriate message appears, and the user can try again.
>     - NOTE: there is nothing stopping a single user from having more than one virtual player.

> ### 3.1.2 - User logs into virtual casino and gets assigned to a table

> If a user has already created a virtual player, they should be able to:

> - 3.1.2.1) Log into the main 'virtual casino' environment using their unique player ID and password.
>   - 3.1.2.1.1) The playerID and password must be valid. If so, the player is logged in the casino environment and his/her bankroll is retrieved. If not, error messages appear and the user must re-enter his player ID and password.
> - 3.1.2.2) For version 1.01 the 'virtual casino' is just a decorative screen where the player has two options: to "view rules" (which merely hyperlinks to the complete rules) or "join a table". When the user clicks "join a table", he is automatically assigned to a table. The player may or may not be alone at this table depending on the number of vacancies at other tables.
>   - 3.1.2.2.1) NOTE: In a later version, each player may be given some option as to which table he/she join.

> ### 3.1.3 - User plays blackjack at a table

> Once the player has been assigned to a table (thread), he/she should be able to play in the very next round of blackjack:

> - A set of blackjack rules are available in Appendix A: Game Rules. Gameplay should follow these rules quite accurately, with a few noticeable exceptions:
>   - Each table will have only 4 boxes.
>   - Each player will only be allowed to split once.

> The basic sequence of the game is as follows:

> - 3.1.3.1) A player enters a bet (between min and max bets for that particular table) and the bet is submitted when a 10 second timer expires.
>   - NOTE: The interface will be designed such that it is impossible for the user to bet outside of the min and max bets or exceed his/her bankroll.
>   - Effectively, a player is forced to bet every round (and that amount is immediately deducted from his/her bankroll), unless he/she leaves the table.
>     - NOTE: A player who is away from his/her keyboard must either leave the table, or else risk losing money each round.
> - 3.1.3.2) An initial set of cards are deal out (two cards for each player and one card for the dealer).
> - 3.1.3.3) Next, each player (in sequence) takes turns.
>   - If it's the user's turn, he is presented with a set of options. Depending on the values of the user's cards and the dealer's cards, these options may include a combination of:
>     - hit
>     - stay
>     - split
>     - double
>     - insurance
>   - The user will keep taking turns until he/she decides to stay (on his/her last hand), or goes bust (on his/her last hand).
>     - NOTE: If a player splits, he/she will have two hands, and plays one hand after the other. Due to the amount of space on a screen, this blackjack game will only ever let a player split once - i.e. a player will never have more than two hands.
>   - If the user fails to make a decision before a 10 second timer runs out (and is therefore delaying the game for other players), he will be forced to stay on that hand.
>   - If it's not the users turn, he/she waits and watches as another players undergoes the same process.
> - 3.1.3.4) The dealer takes its turn
>   - NOTE: Rules for the dealer are fixed. The dealer's turn is over when its hand goes bust, or totals seventeen or greater (see Appendix A).
> - 3.1.3.5) The outcome of the game is then calculated.
>   - For each hand, the end result is one of the following:
>     - win - the player gets back twice the money he/she bet.
>       - NOTE: If a player's hand wins with a blackjack (i.e. two cards totaling twenty one), he/she gets back 2.5 times what he/she bet.
>     - lose - the player loses his/her money.
>     - push - the player gets his money back.
>   - The results of the round will update the players bankroll and this will be securely stored (in the database).
>   - If a players bankroll decreases to $0, he/she will see a message (along the lines of "you're bankrupt") and is forced to leave the table - he/she goes straight back to the virtual casino environment.
>     - his/her bankroll is then reset back to the starting bankroll (to save him from having to create a new virtual player).
> - 3.1.3.6) All cards are removed from the table and the next round starts.

> Other in-game options:

> - 3.1.3.7) At any time a player can hit "leave table".
>   - If the player leaves the table while he has an outstanding bet, he/she will instantly forfeit that money.

> ### 3.1.4 - Online chat feature within the game environment

> - 3.1.4.1) While a player is assigned to a table he/she should be able to chat to all of the other players at that table.
>   - 3.1.4.1.1) At any stage of the game the user can type a message into a text box, and when he/she hits enter (or presses send), and the other players at that table will see the message appear.
>   - 3.1.4.2.2) A user should also have the option to send a private message to a particular player by clicking his/her name on the list and clicking "private message".

## 3.2 Usability

### 3.2.1 User's Requirements:

- 3.2.1.1) Java 1.4 must be installed on the user's computer in order to run the program.

> ### 3.2.2 Foolproof use

> - 3.2.2.1) This program should be able to deal gracefully with:
>   - 3.2.2.1.1) Players who get disconnected suddenly (without logging off)
>   - 3.2.2.1.2) Players who take too long to make their turn.

## 3.3 Reliability

> ### 3.3.1 Client-side

- 3.3.1.1) Images should be stored on the client, so that images are not being transferred between the client and the server.
- 3.3.1.2) Limit the user input to known values where possible through use of buttons and list boxes. All text user input should be tested before using in game critical areas.
- 3.3.1.3) Log-in data security to ensure maximum reliability.

> ### 3.3.2 Server-side

- 3.3.2.1) If the client-server crashes, the database should rebuild the game state to before the crash.
- 3.3.2.2) To ensure optimal bandwidth the game state information should be small and staggered using a turn base design to ensure small packets being sent between the client and the server.
- 3.3.2.3) User passwords will be one way hash encrypted for security.
- 3.3.2.4) Beta testing should be used as classes and functions are added to the project during stage development
- 3.3.2.5) The server should be benchmarked to determine maximum number of table threads it can handle gracefully.
  - 3.3.2.6) The server code should then be modified so the server cannot create more than this many table threads.

## 3.4 Performance

> ### 3.4.1 Client-side Program Requirements

> - 3.4.1.1) Should be able to run on any PC that supports 800 x 600 pixel resolution in more than 256 colours.
>   - 3.4.1.1.1) Estimated min. requirements: 200MHz, 32MB RAM computer.
>   - 3.4.1.1.2) Most of the in-game calculations should be done by the server - all the client computer needs to do is repaint the images.
> - 3.4.1.2) Will need an average speed Internet connection (or better).
>   - 3.4.1.2.1) Estimated min. requirements: 28 kbps modem Internet connection.
>   - 3.4.1.2.2) NOTE: the initial testing platform of this game will probably be client-to-server via a university's Ethernet LAN, and single PC acting as both client and server.

> ### 3.4.2 Server-side Program Requirements

> - 3.4.2.1) Should run on an average PC (i.e. approx. 500MHz, 128MB RAM).
>   - 3.4.2.1.1) However, the performance of the server-side program depends on the client-generated traffic. If too many clients are playing blackjack simultaneously on our server, a mid-range PC would be unable to maintain the required number of table threads.
>   - 3.4.2.1.2) Conservative estimate: a 500MHz with 128MB RAM computer should be able to support up to ten clients (two or three table threads) quite comfortably. This will be benchmarked during project development.
> - 3.4.2.2) Should be connected to the Internet (or which-ever the clients reside) via a fast connection, or at least a TCP/IP network.
>   - 3.4.2.2.1) A slow (28kbps) modem connection to the Internet, may serve as a bottleneck.
>   - 3.4.2.2.2) Conservative estimate: a 56kbps modem connection (from the server to the nearest ISP) would mean any more than four clients would make the game too slow to play

## 3.5 Supportability

- NOT REQUIRED.

## 3.6 Design Constraints

- 3.6.1) A casino game (playing against the house for virtual money)
- 3.6.2) All coding must be done in JAVA 1.4
- 3.6.3) Java Runtime-environment
- 3.6.4) 3-4 students per group
- 3.6.5) Client-server architecture
- 3.6.6) Server must be supported by a database (mySQL)
- 3.6.7) Multithreading (client or server or both)

  ### 3.6.1 Java

  - 3.6.1.1) Java 1.4 must be used for all programming components of the system

  ### 3.6.2 Client-server architecture

  - 3.6.2.1) TCP/IP network architecture should be used for client server communication.

## 3.7 On-line User Documentation and Help System Requirements

- 3.7.1) Basic help (eg: how to join a game and chat) should be available through 'Help' on the menu bar. This should include a hyperlink to the rules of the game and online documentation.
- 3.7.2) Extensive rules and documentation will be available on-line on a website.
- 3.7.3) Based on users' feed back additional help and documentation will be provided.

## 3.8 Purchased Components

> N/A

## 3.9 Interfaces

> ### 3.9.1 User Interfaces

> - 3.6.1.1) See screen shots.

> ### 3.9.2 Hardware Interfaces

> > N/A

> ### 3.9.3 Software Interfaces

> > N/A

> ### 3.9.4 Communications Interfaces

> > N/A

## 3.10 Licensing Requirements

- 3.10.1) Sun licence for java 1.4 usage.

## 3.11 Legal, Copyright, and Other Notices

- 3.11.1) Sun, Java and some java related software tools and products are trademarks or registered trademarks of Sun Microsystems, Inc. TBD: Acknowledge other copyrights and trademarks.
- 3.11.2) Copyright © School of Information Technology, James Cook University, 2003.

## 3.12 Applicable Standards

- 3.12.1) Java 1.4
- 3.12.2) XML
- 3.12.3) SQL
- 3.12.4) JDBC
- 3.12.5) HTML
- 3.12.6) CCS
- 3.12.7) TCP/IP

# 4. Supporting Information

- Appendix A: Game Rules