EECS 22L代做、代写c++程序语言
- 首页 >> Matlab编程 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)
1. A simple timer which lets others know how long the round is. This could be useful if users are not playing via
Zoom.
2. A scoreboard in the end showing player rankings and what poker hands that they received.
3. The ability to switch to other variations of poker such as Omaha Hi-Lo, 7-Card Stud etc..
4. Any other features that make Poker more fun.
3 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
1 Poker UserManual.pdf The application speciffcation 05/13/24 at 10:00am
2 Poker SoftwareSpec.pdf The software architecture speciffcation 05/20/24 at 10:00am
3 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
4 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
5 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
* Looking for files:
* 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.
5
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)
1. A simple timer which lets others know how long the round is. This could be useful if users are not playing via
Zoom.
2. A scoreboard in the end showing player rankings and what poker hands that they received.
3. The ability to switch to other variations of poker such as Omaha Hi-Lo, 7-Card Stud etc..
4. Any other features that make Poker more fun.
3 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
1 Poker UserManual.pdf The application speciffcation 05/13/24 at 10:00am
2 Poker SoftwareSpec.pdf The software architecture speciffcation 05/20/24 at 10:00am
3 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
4 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
5 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
* Looking for files:
* 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.
5