Casino Blackjack (Group 53)

Software Requirements Specification

Version 3

Revision History

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 or special messages to Dmitry.
• 1.3.2) See also project Glossary.
• 1.3.3) Changes since last version:
  • 1.3.3.1) Most bullet points have been ennumberated (as requested).
  • 1.3.3.2) All hows have been moved to sad (this could not be shown).
  • 1.3.3.3) A local, enumerated copy of the rules was created (see Appendix A: Game Rules).
  • 1.3.3.4) Networking terms were removed from the glossary.
  • 1.3.3.5) Changes have been shown using "{v2}" for an additons during version 2 and "{v3}" for any additons duirng version 3.
  • 1.3.3.6) A link to the game screenshots has been provided in the Interfaces section.

1.4 References

1.5 Overview

NOT REQUIRED.

2.                  Overall Description

2.1) Product Perspective:

• 2.1.1) A casino game (playing against the house for money) (v1) (8 points)

2.2) Product Functions:

• 2.2.1) Multi-threaded server: separate thread is created for each game (v1) (2 points)
• 2.2.2) Multi-threaded client: communication with a server is in a separate thread (v1) (2 points)
• 2.2.3) Client-to-Client chat (v1) (1 point)
• 2.2.4) Server based chat room (v1) (2 points)
• 2.2.5) Saving and replaying game/recent transaction history to/from a file/database (v2) (5 points)
• 2.2.6) {v2} Feature total = (20 points)

2.3) User Characteristics

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

2.4) Constraints:

• 2.4.1) A casino game (playing against the house for money)
• 2.4.2) All coding must be done in JAVA 1.4
• 2.4.3) 3-4 students per group
• 2.4.4) Client-server architecture
• 2.4.5) Server supported by a database (SQL)
• 2.4.6) Multithreading (client or server or both)
• 2.4.7) {v3} Provide a config file in XML format that stores the current System configuration.
• 2.4.8) {v3} Store all "hard-coded" values in that file as well as anything that determines the current configuration of your system.
• 2.4.9) {v3} Provide an option to enter host URL, database URL during the start up of applications.
• 2.4.10) {v3} Store last input into the config file and use appropriate values as initial or default values for the configuration parameters.

2.5) Assumptions and Dependencies:

• 2.5.1) A user is to only register one online virtual player
• 2.5.2) local machine should have a Java Runtime environment
• 2.5.3) network connection is required for more than one player.

2.6) Requirements Subsets:

• 2.6.1) Using XML encoding/decoding of objects passed through tcp/ip sockets as base for client-server architecture.

2.7) {v2} Feature Summary:

Casino Blackjack:	Points
Any coding must be done in Java 1.4. 3-4 students per group. Client-server architecture. Server supported by a database (e.g. mySQL). Multithreading (client or server or both). {v3} Provide a config file in XML format that stores the current System configuration. {v3} Store all "hard-coded" values in that file as well as anything that determines the current configuration of your system. {v3} Provide an option to enter host URL, database URL during the start up of applications. {v3} Store last input into the config file. Use appropriate values as initial or default values for the configuration parameters.	0
A casino game (playing against the house for money)	8
Multi-threaded server: separate thread is created for each game	2
Multi-threaded client: communication with a server is in a separate thread	2
Client-to-Client chat	1
Server based chat room	2
Saving and replaying game/recent transaction history to/from a file/database	5
Feature Total:	20

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.
• {v3} 3.1.5 - Configuring system options

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) {v3} The playerID entered by the user must be unique. 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

While at a table a player can chat to other players at that table:

• 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".

{v3} 3.1.5 - Configuring system options

• 3.1.5.1) {v3} Player should be able to manually enter the host (server-side application) URL he/she wishes to connect to. This should then be verfied and the user told if the URL is a valid blackjack server. SUPERSEEDED.
• 3.1.5.2) {v3} If the URL is valid, this information should be stored to disk so that the user won't have to re-enter it the next time he/she opens the program. SUPERSEEDED.
  • 3.1.5.2.1) {v3} NOTE: Configuing the host should be an option in the menu bar, however the program should be installed with a valid default host, so that the user can play blackjack without touching the configuration.SUPERSEEDED.
• 3.1.5.3) {v3} For secturity reasons, the user shouldn't have to configure the URL of the desired server. Instead, only one host, a default host should be provided.

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.1.4) {v3} Prevent more than one client application from running on a single computer.

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 800x600 pixel resolution in more than 256 colours.
  • 3.4.1.1.1) {v3} Estimated min. requirements: 500MHz, 512MB 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) {v3} Should run on an average PC (i.e. approx. 500MHz, 512MB 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) {v3} Conservative estimate: a 500MHz with 512MB 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.8) {v3} Provide a config file in XML format that stores the current System configuration (on the server).
• 3.6.9) {v3} Store all "hard-coded" values in that file as well as anything that determines the current configuration of your system.
• 3.6.10) {v3} Provide an option to enter host URL, database URL during the start up of applications.
• 3.6.11) {v3} Store last input into the config file and use appropriate values as initial or default values for the configuration parameters.

  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 initial drawing concepts.
• 3.6.1.1) {v3} See actual screenshots.

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

• 4.1) {v2} Appendix A: Game Rules