Computer Science Coursework
Poker Project
Contents Page
Contents Page 1
Analysis 2
Problem Identification / Overview 2
Features of my solution that make it programmable and suitable for computational
solution / Essential Features 3
Stakeholders 4
Investigation and analysis of results 5
Current Solutions 13
Limitations 17
Minimum Requirements to Run My Solution 17
My Success Criteria 20
Design 22
User Interface - Initial Designs 22
Initial Design - Feedback Summary 25
User Interface - Final Designs 26
Final Design - Feedback 30
Decomposition Diagram 30
Usability Features 38
Pseudocode / Algorithms 40
Key Variables / Data Structures / Classes 66
Key Buttons / Text Boxes 70
How I’m Going to Test my Solution 72
Test Table Checklist 72
Test Table No.1 - Iterative Development 73
Test Table No.2 - Post Development 80
Development and Iterative Testing 82
Prototype 1 82
Stage 1 - Prototype 1.1 - Hand Generation 82
Stage 1 - Prototype 1.1 - Hand Generation - Review 96
Stage 2 - Prototype 1.2 - Hand Evaluation 97
Stage 2 - Prototype 1.2 - Hand Evaluation - Review 168
Stage 3 - Prototype 1.3 - Game Management 169
Stage 3 - Prototype 1.3 - Game Management - Review 199
Prototype 1.0 - FINAL REVIEW 200
Prototype 2 203
Stage 4 - Prototype 2.1 - GUI and Difficulty 203
, Stage 4 - Prototype 2.1 - GUI and Difficulty - Review 225
Prototype 2 - FINAL REVIEW 226
Prototype 3 234
Stage 5 - Prototype 3.1 - Account System 234
Stage 5 - Prototype 3.1 - Account System - Review 250
Stage 6 - Prototype 3.2 - Password Encryption 251
Stage 6 - Prototype 3.2 - Password Encryption - Review 258
Prototype 3 - FINAL REVIEW 259
Post Development Testing / Testing Evaluation 266
Create Account System 266
Create Account System - Screenshots 267
Login Account System 269
Login Account System - Screenshots 269
Betting System 271
Betting System - Screenshots 272
Game Round Management System 276
Game Round Management System - Screenshots 279
Save Progress Management System 284
Save Progress Management System - Screenshots 285
Evaluation 289
Evaluation 290
Introduction 290
Criteria Met 290
Usability Features of my Solution 295
Evidence of Usability Features 295
Limitations of my solution and how these can be addressed in further development 295
Potential maintenance issues of my solution 297
Overall Conclusion 298
Reference 298
Final Code 298
Analysis
, Problem Identification / Overview
Currently, most poker games require players to be 18+ to play and require an internet
connection, as well as sometimes being forced to sign up to their service and invest real
money into an account to play. Furthermore, free-to-play poker games usually limit the
amount of chips players can play with and are filled with ads that interrupt the users gaming
experience and contain in-app purchases. Usually, If the players want to participate in big
tournaments they will often have to use real money to buy virtual currency, while not being
beginner friendly and offering minimum to no support for new players. The version of this
game I aim to build will allow users to learn how to play by allowing them to practise against
the computer offering three different levels of difficulty that affects how the computer
behaves. Additionally, this game will be completely free to play and if players want to they
can create an account to store the number of chips they have for a later date but this won't
be a requirement. Furthermore, current solutions also lack customization options such as the
ability to customise your avatar. Despite this not being a key feature of poker, this can add to
the player experience and make the game more immersive. Many other poker games also
have a limited number of game modes they offer. For example, most other online solutions
only offer users the ability to play texas holdem, this could be one of the key selling points for
my solution as I could offer the ability to play multiple different game modes.
Features of my solution that make it programmable and
suitable for computational solution / Essential Features
A poker game is programmable and suitable for a computation solution for many reasons.
The key reason is that poker involves a range of mathematical and boolean calculations. For
example, a poker game would need to generate random cards for each player and then
mathematically work out the strength of each player's hand and then at the end of the game,
compare all the scores to determine a winter. Furthermore, features such as the ability to
see how likely you are to win as a % depending on your hand would also require
mathematical calculations, as the player's hand would have to be compared to all the other
possible hands based on the cards dealt.
Another reason is that a poker game could make use of different data structures, such as
arrays, lists and hashsets. Lists and arrays would be suitable for storing each player's hand
as this way, they could be called upon and used elsewhere in the game. A hashset would
also be suitable for storing all the cards dealt as they only store unique data. This means
that we can store the number of cards dealt in a variable and compare this to the count of
the hashset to check for duplicate cards and then deal a new card instead. Furthermore, a
poker game would make use of sorting algorithms, such as a quick sort as the players hands
would need to be in sequential order to accurately check for hands such as straight and
royal flush.
Another reason is that poker can be approached using decomposition to break the problem
down into smaller subproblems. For example, the game would require many key algorithms
, to be created and work on their own before coming together and creating the final solution,
such as a card generation algorithm, duplicate card checker algorithm, and a redraw
algorithm. These would all work in a similar area of the game, but for the most part can be
created and tested isolated from the rest of the program, before being combined.
Furthermore, you can break the game down further, as you would likely need to create
different classes and functions to control different parts of the game, such as round
management, AI behaviour, and form controls.
A poker game would also make use of object oriented programming techniques, such as
encapsulation and inheritance. For example, you could have an AIBehaviour class and
depending on the difficulty selected, you could create new objects (bots) with different
properties that control their betting behaviours, for example, more risky bets and staying in
the game for longer despite having a weaker hand. Additionally, the use of encapsulation will
make for a better more robust gaming experience, as it could be used to protect the game
state and stop the manipulation of variables and the deck of cards by making them
inaccessible other than when called through methods
Throughout development, a poker game could also make use of abstraction while
developing different prototypes. For example, in the first prototype, abstraction could be a
key part of development as I could be focused on only adding the key features, such as the
card generation algorithms, player and dealer behaviour algorithms and a basic working UI.
This would also allow for more efficient testing so you can ensure the game has a robust
foundation to add more features later in development, as there aren't other unrelated
algorithms that could potentially be breaking the game or changing variables during runtime
unexpectedly. Although it should be noted that abstraction could become less useful in later
prototype versions, as features that aren't key for the game to work are added in to improve
the experience, such as an algorithm to tell the player the chance of them winning, or the
ability to play on a slot machine while it's not your turn.
A poker game would also make use of input validation, as during the betting round, our
game would need to ensure that the players are entering their input in the correct format. For
example, if they enter a string into a custom bet box, the game would need to perform an
interrupt to stop the usual code from executing and show a message box telling the player
that their input is invalid and ask them to try again. Furthermore, input validation could also
be used to check if the player can afford their bet. For example, if they try to bet £1000 but
only have £100 in their account, then the game should perform an interrupt to tell the user
that they can't afford it and prompt them to re enter their bet.
Another reason why poker leans itself to a computation solution is due to the variety of
potential game modes and settings there are. For example, in real life if you wanted to play
texas holden, ohana and 3 card poker you would need to have a minimum of 3 physical
poker tables and this isn't even accounting for betting limits / buy in stakes. Due to the
variety of different options available, poker is suitable to a computation solutions, as you can
code them all into a one size fits all solution. This allows for fast movement between game
modes, as well as more replayability. Players will also be able to switch game does and
stakes faster than real life, as they wont have to worry about changing physical locations.
