EECS 22L Project 2: Online Poker

EECS 22L Project 2: Online Poker
May 7, 2024
1 Online Poker Application
This is the second team programming project of EECS 22L, ”Software Engineering Project in C language”.
The goal of this programming exercise is to design and develop a poker application in which a user can play with
other players across the Internet. To play the game, users need to connect to the host server, enter their name, and
choose a seat. Human users will also connect to Zoom in parallel, so that players can chat and have fun together. This
version of poker will be a game among friends, with no gambling involved.
After the dealer has dealt the cards, each player will have a turn to take. The poker application should be able to deal
cards to players and maintain the game automatically. The mandatory (default) poker variant is Texas Hold’em for
this project, but different variants can be provided optionally.
This project is designed to be an interesting exercise where you can practice essential elements of software engineering
and work in teams. In particular, you will practice specifying and documenting the software program, designing
data structures and algorithms, designing software modules, writing original source code, testing and debugging the
software program, and collaborating and communicating effectively in a team.
1.1 The rules of Poker
Poker is a relatively simple game to learn. In Texas Hold’em Poker, the dealer hands two cards to each player. Then
a round of betting takes place in a clockwise manner from the dealer. The ffrst player declares a starting bet which
the next player can either match (’call’), ’raise’, or drop (’fold’). If they cannot match the bet and choose to drop, the
game continues without them. After each player has bet, the ffrst round of the game is completed. The dealer then
places three community cards facing up in the middle of the table. Each consecutive round an additional community
card is placed, for a maximum of ffve. Once all ffve community cards are placed, the ’showdown’ begins, where
each player compares their two cards with the cards on the table. Then the winner is the player who has the best ’hand’.
Figure 1 shows the possible poker ’hands’ available, in decreasing order of value. Further rules and documentation
can be found online.
2 Program Speciffcation
In this project, we want to design an online poker game consisting of a central server which can host a Texas Hold’em
variant of poker. Then guest users should be able to connect and play poker with the central host.
There are several features that we expect the poker program to have. We distinguish between the minimum requirements
for this project, and more advanced options that are goals and optional features (bonus points).
1Figure 1: Different possible poker hands. Source- upswingpoker.com/poker-hands-rankings/
2.1 Basic functions that are required:

1. Each player should be able to connect with the online poker program and choose their seat, and their name
   should be shown when playing the game.
2. The server keeps track of the points for each player. We do not want a gambling application, but a card game
   among friends!
3. The server deals the cards to the various players, and also randomly shufffes them.
4. The server needs to properly end a game during the ffnal round and award the winner with points.
5. For this project, a graphical user interface is mandatory at the client (user) side. It is highly recommended to use
   GTK 2.0.
6. Program should have at least one basic Bot Player.
7. Git version control is mandatory for this project.
8. To communicate between the server and users, TCP/IP communication should occur via sockets.
9. Unit test for all major modules in the project.
10. Well structured user/software deliverable and detailed documentation which meets the requirements speciffed in
    the grading criteria.
    22.2 Advanced options that are desirable (but optional): (Bonus)
11. A simple timer which lets others know how long the round is. This could be useful if users are not playing via
    Zoom.
12. A scoreboard in the end showing player rankings and what poker hands that they received.
13. The ability to switch to other variations of poker such as Omaha Hi-Lo, 7-Card Stud etc..
14. Any other features that make Poker more fun.
15. Software Engineering Approach
    In the design and implementation of this project, we will follow basic principles of software engineering in a close-toreal-world
    setting. You will practice the major tasks in software engineering to build your own software product. We
    will not provide detailed instructions on how to design the program as we did for the assignments in EECS22. Instead,
    your team needs to come up with your own choices and practice designing the software architecture of a medium-size
    program and document it.
    3.1 Team work
    The software design programming in this course will be performed by student teams. Teams of 4-6 students will be
    formed at the beginning of this project. Team work is an essential aspect of this class and every student needs to
    contribute to the team effort. While tasks may be assigned in a team to individual members, all members eventually
    share the responsibility for the project deliverables.
    The overall tasks of software design, implementation and documentation should be partitioned among the team members,
    for example, to be performed by individuals or pairs (pair programming). A possible separation into tasks or
    program modules may include:
    • Poker rules
    • Poker server program
    • Poker client program
    • Graphical user interface for Poker players
    • Communication protocol (data structures for sockets)
    • Smart Poker bot
    • Documentation
    • Testing
    When planning the team partitioning, keep in mind that certain tasks depend on others and that some tasks are best
    handled by everyone together.
    A team account will be provided on the servers (bondi, laguna, crystalcove and zuma) for each team to
    share source codes, data and document ffles among the team members. Sharing of ffles across teams is not permitted.
    Every student is expected to show up and participate in team meetings. Attendance of the weekly discussion and
    lab sections is mandatory for the sake of successful team work.
    33.2 Major project tasks
    We list several steps here to approach the medium-sized programming project.
    • Design the software application speciffcation: work as a team to decide the functionalities of the program, the
    input and output of the program, and other things that describe the features of the program for the users.
    • Design the software architecture speciffcation: work as a team to design the data structure, program modules,
    application programming interface (API) and functions between modules.
    • Build the software package: write the source code and implement the program. Each team member may be in
    charge of their own modules and ideally work in parallel on implementation and module testing. Use Makeffle
    for rule-based compilation to integrate the modules from different owners.
    • Version control and collaboration: use a version control application, i.e. Git (introduced in Lecture 3) to maintain
    the team project documentation and source code ffles. Team members can synchronize their own work with
    the others through the team repository located in the team account.
    • Test and debug the software: work as a team to decide the testing strategies, write automated test programs or
    scripts, and debug the program when some of the test cases fail.
    • Software release: release the software package with the executable program and documentation, e.g. the
    README ffle, user manual, etc. Release also the source code as a package for the further developers or
    maintainers. In contrast to Project 1, Project 2 has 3 software releases, alpha, beta, and ffnal release.
    3.3 Deliverables
    Each team needs to work together and submit one set of deliverables each week. Here is the checklist of the ffles the
    team needs to submit and the due dates (hard deadlines).
    Table 1: The Online Poker Project Deliverables
    Week File Name File Description Due Date
16. Poker UserManual.pdf The application speciffcation 05/13/24 at 10:00am
17. Poker SoftwareSpec.pdf The software architecture speciffcation 05/20/24 at 10:00am
18. Poker Alpha.tar.gz The alpha version of the poker program, 05/27/24 at 10:00am
    Poker Alpha src.tar.gz including the program source code and documentation
19. Poker Beta.tar.gz The beta version of the poker program, 06/03/24 at 10:00am
    Poker Beta src.tar.gz including the program source code and documentation

20. Poker V1.0.tar.gz The released software package for the poker program 06/10/24 at 10:00am
    Poker V1.0 src.tar.gz and the program source code and documentation
    Note that we do require these exact ffle names. If you use different ffle names, we will not see your ffles for grading.
    We will separately provide detailed templates (document skeleton, table of expected contents) for the textual documents
    and a detailed list of contents (directory structure and expected ffles) for the ffle archives. These grading
    criteria will be provided at the Projects tab of the course webpage.
    3.4 Submission for grading
    To submit your team’s work, you have to be logged in the server zuma or crystalcove by using your team’s
    account. Also, you need to create a directory named poker in your team account, and put all the deliverables in
    that directory. Next, change the current directory to the directory containing the poker directory. Then type the
    command:
    % ∼eecs22/bin/turnin.sh
    which will guide you through the submission process.
    4For each deliverable, You will be asked if you want to submit the script ffle. Type yes or no. If you type “n” or
    “y” or just plain return, they will be ignored and be taken as a no. You can use the same command to update your
    submitted ffles until the submission deadline.
    Below is an example of how you would submit your team work:
    zuma% ls # This step is just to make sure that you are in the correct directory that contains poker/
    poker/

    zuma% ∼eecs22/bin/turnin.sh

    EECSL 22L Spring 2024:
    Project "poker" submission for team0
    Due date: Mon May 13 10:00:00AM 2024

21. Looking for files:

22. Poker UserManual.pdf

    Please confirm the following: *
    "I have read the Section on Academic Honesty in the *
    UCI Catalogue of Classes (available online at *
    http://www.editor.uci.edu/catalogue/appx/appx.2.htm#gen0) *
    and submit original work accordingly." *

    Please type YES to confirm. yes

    Submit Poker UserManual.pdf [yes, no]? yes

    File Poker UserManual.pdf has been submitted

    Summary:

    Submitted on Sun May 5 00:05:31 2024
    You just submitted file(s):
    Poker UserManual.pdf
    zuma% _
    For a binary package, we expect the user to read the documentation and run the executable program as follows:
    % gtar xvzf BinaryArchive.tar.gz
    % evince poker/doc/poker.pdf
    % poker/bin/poker
    For a source code package, we expect the developer to read the documentation and build the software as follows:
    % gtar xvzf SourceArchive.tar.gz
    % more README
    % more INSTALL
    % cd poker
    % make
    % make test
    % make clean
    Again, please ensure that these commands execute cleanly on your submitted packages.
    WX：codinghelp