Skip to content

Latest commit

 

History

History
130 lines (76 loc) · 13.9 KB

F17_lab03.md

File metadata and controls

130 lines (76 loc) · 13.9 KB
Raw

Eliza R. and Kailash B.

Description of Project

This project is a GUI application that runs a poker game in the style of "Texas Hold'em," with two decks, as stated by the README.

User Stories

The user can do the following:

  1. Single Player Game - Start a game by pressing the "Play Single Player" button. The user will compete against AI.

  2. Create a Poker Server (disabled by previous contributers). This button creates a local server and returns its IP address, which the user then enters in a separate session via the "Connect to Poker Server" button. The user can also distribute the IP address to other players willing to join a game.

  3. Connect to Poker Server (disabled by previous contributers). Takes an IP address and connects the user to its corresponding poker game. Inputting "localhost" or the IP address "127.0.0.1" connects the user to their local server.

  4. Create Poker Chat Server - Clicking this button creates a socket server for a chat program (similar to #2).

  5. Connect to Poker Chat Server - Joins a Chat Server by taking an IP address and connecting (similar to #3).

Proposed User Stories

  1. Adjust AI difficulty - Currently, there is no option to change the difficulty level on Single Player Mode. This would present the player with "Easy," "Intermediate," and "Hard" difficulties.

  2. Play against multiple AIs - The user only encounters one AI in Single Player; the option to play against two or more increasesthe game's complexity and playability.

  3. Remove redundancies in creating servers - Creating a local server currently depends too much on the user. The program should take the generated IP address and automatically produce a server, not return the IP address for the user to input.

  4. Restore Multiplayer and Servers - Reimplement these features back into the game.

Software Status

When the game runs, a window pops up with three buttons: Single Player Mode, Create a Chat Server, and Connect to Chat. Single Player generates a game between the user and AI, which works smoothly. However, creating a Chat Server does not function as well as it could. An IP address is returned, but the program hangs immediately after. Connecting to the Chat Server on the local machine lets the user input their chat name and creates a chat window, but nothing occurs when the user inputs a string.

README.md Quality

The previous two generations of programmers wrote a brief assessment of the software in its final states. Comments range from the developers' courses of action to their visions for the future of the game. These notes provide a starting point for project development.

There is also a description of the game's mechanics and features, including several screenshots. How the code actually works is hidden in this file; it basically instructs the user on the GUI and how to run the application.

build.xml State

The build.xml is neatly optimized. All targets have relevant names and brief, informative descriptions.

Current Issues

There are currently 14 open issues:

  1. Issue #23: Integrate chat into multiplayer (300 pts) - This issue is fairly self explanatory. Chat currently needs to be set upseperately from the poker game. However, integrating it into the multiplayer game will also require implementing a multiplayer game mode since multiplayer currently does not exist. While this issue is easy to understand, fixing it would require major refactoring of the codebase.

  2. Issue #28: Game Over (100 pts) - Currently, there is no game over screen when a game ends indicating that the chips are being reset. Adding a game over screen would make the game easier to navigate. This requirement is clear, but leaves all of the actual design and layout decisions for the game over screen up to the programmer.

  3. Issue #33: Move towards a cohesive design principle (200 pts) - The various classes in the application are currently tightly coupled and poorly organized. Moving the game to a MVC pattern would make the code much more flexible and easier to maintain. Like Issue #23, this issue is easy to understand, but requires much of the code to be refactored.

  4. Issue #38: Create Cool Animations (200 pts) - This issue asks us to create animations for each card as it is dealt to the players. This requirement is very clear as to what it wants.

  5. Issue #39: Create a Poker Server with Chat Server Functionality (300 pts) - This issue asks us to implement multiplayer server that allows two (or more, for more credit) players to play against one another from different machines. The multiplayer game should also incorporate chat functionality instead of requiring it to be a seperate window. Once again, this issue is easy to understand, but since it requires multiplayer support, it requires major refactoring of the code.

  6. Issue #46: Refactor PokerGame.java for multiplayer flexibility (250 pts) - Currently, PokerGame.java is written assuming that the game will be always be a "player vs. computer" game. This should be changed to be able to handle an arbitrary number of players, any of which could be a computer. This could be done by seperating the player and computer into seperate classes and have both implement a common interface or inherit from the same super classes. Because of the other issues, this should be done at the same time or in preperation for #33 and in preparation for #39. Although this requires significant refactoring, it will make issues #33 and #39 much easier to fix.

  7. Issue #47: Make the 'run' target work on both Linux and Windows (20 pts) - Currently, the 'run' target only runs on Linux. A minor change can be made to add support for Windows.

  8. Issue #51: Make AI seperated from the PokerSinglePlayer class (250 pts) - The code implementing the AI is currently in a method of PokerSinglePlayer and dependent on PokerSinglePlayer. This would make the overall design much more flexible and cleaner, and this issue is closely related to #46, as it would make implementing multiplayer much easier.

  9. Issue #52: Create an "all-in" betting option (100 pts) - Currently, if the player tries to bet more chips than the opponent has, the game does not allow the bet. This should be fixed by implementing "all-in" based on the rules from actual poker.

  10. Issue #54: Add a message saying what the winning hand was (200 pts) - Currently, the only message displayed when someone wins is "player/opponent" wins. This should be changed to display the winner and the winning and losing hands.

  11. Issue #55: Improve the ComputerAI algorithm (200 pts) - The current Computer AI is entirely based on the player's moves and is very predictable and weak. This should be improved to make the AI both less predictable and more "intelligent" in its decision making.

  12. Issue #56: Improve how CompareHands handles ties (200 pts) - CompareHands currently handles ties terribly, and is often wrong when deciding the winner of a tie. There are several possible options given for improving handling ties. The first requires major changes to CompareHands, but would result in a much cleaner design and faster program. The second also requires major changes, but the end result would be much more difficult to maintain and extend than the first option. However, both options would still be major improvements over the current CompareHands.

  13. Issue #58: Add more Javadoc comments (100 pts) - Currently, much of the codebase lacks Javadoc comments. This should be changed so the code is easier to understand for other programmers.

  14. Issue #59: Publish javadoc using the gh-pages workflow and remove javadoc from .gitignore (100 pts) - The project should be changed so the javadoc gets published online using Github Pages.

###Summary of Issues###

Overall, each issue is very clear in terms of what it expects. The only gray area is the issues involving multiplayer support, as although they are different, there is some overlap in the issues. For example, it would be very difficult to fix issue #39 without first fixing issue #46, as the class for the multiplayer game would likely extend PokerGame. Despite this overlap, each issue is still very clear in what it wants. With a total of 2520 points available, there are more than enough issues for us to earn 1000 points.

Other Issues

  1. Improve CompareHands - Since this is closely related to issue #56, and would be solved by the first proposed method in #56, I have not created a seperate Github issue for this. Issue #56 focuses on improving how CompareHands handles ties and adding more tests to CompareHandsTest, but most of the behavior in CompareHands can (and should) be improved. While much of the code itself should be refactored, the underlying behavior of CompareHands could be changed to allow for more distinction between various hands.

Code Organization and Quality

The code is organized fairly well. The purpose of each class and method is clear, and the classes do not have overlapping functionality. Additionally, it is easy to see how each class relates to the others by examining each class's members and method signatures. The Player class has a Hand object and PokerGame object as members, and the Hand class has an arrayList of Card objects and an int variable representing the Hand's value. The TableCards object also has an arrayList of Card objects, in addition to two Card objects representing the turn and river cards. Although the Card class itself is simple, with its only members being primitives representing the suit and value, using it often requires the use of the Deck class. The Deck class contains two arrayLists of Card objects, one representing the active cards and one representing the discarded cards. Whenever an object wants a Card object, it generally has to "ask" the Deck object for a card. The Deck object responds by returning a Card from the active list while also moving the Card to the discarded cards list. The exception to this is the CompareHands class, which works directly with the Card objects to compare the value of each player's hand. While the classes themselves are organized well, many of the methods could be refactored to increase the overall code quality and organization. Numerous methods are much lengthier than they should be, and much of the code in the methods could be factored out into helper functions, making it much easier to understand how a method works. Currently, it is difficult to determine how some of the methods work due to large blocks of nested if/else statements. Most of this decision-making code should be in private helper methods instead of directly in the method. This is an especially big issue in CompareHands.java, in which most of the methods are extremely lengthy and difficult to follow due to nested if/else statements. The game itself is run using the main method in PokerMain.java. However, all the main method does is display an option screen to the player to choose between single player, joining a chat room, or creating a chat room, and create an object to run the selected option. Currently, if the user chooses to create a poker chat server, the window becomes unclickable and does not exit, and must remain open for the chat server to continue running. In order to connect to the just created chat server, the user must launch another instance of the game and connect to the IP returned by the first instance of the game. This functionality that the code for the opening screen can (and probably should) be improved. The code itself is organized fine, but the functionality could be improved. The code for PokerChatClient and PokerChatServer is self contained, and unlike the classes for the actual game, the methods are much more concise and do not need to be refactored. This code should only be modified if working directly on the chat client or server. If the user chooses to play a single player game, the game is launched using the PokerSinglePlayer class, which inherits its GUI code from the PokerGameGui class. PokerGameGui extends the PokerGame class and inherits all of the relevant variables representing the current game state. Because of this, PokerSinglePlayer is able to access any relevant game state variables. Examples of these variables include two references to Player objects, one for each player, a reference to a Deck object to represent the deck, and a reference to a TableCards object to represent the current cards on the table. Additionally, there are numerous methods for the various actions that will happen throughout a game, such as fold() and collectPot(). Since much of the code for the actual game is in the PokerGame class and not PokerSinglePlayer, it would not be difficult to extend PokerGame's functionality to game modes other than 1v1 with an AI opponent. Overall, the main issue with the code base is a lack of helper functions. Much of the code could be much cleaner and easier to read if there were more helper functions, and if trying to improve code quality and organization, helper functions should be a priority.

Test Coverage

The test coverage for this project is abysmal. The only class tested is the CompareHands class, and these tests could be expanded to test more edge cases as well as provide more comprehensive testing in general. The test coverage could be expanded to ensure that the classes representing various parts of the game (Card, Hand, etc.) are functioning properly. This could be done by testing the constructor as well as the various methods of each class. There could be tests ensuring the getters and setters are working properly, as well as tests for the methods that use multiple classes. Additionally, PokerGame, PokerGameGui, and PokerSinglePlayer should all have their various methods tested to ensure that the game itself is functioning properly. One way to test these functions is by ensuring all of the game state variables are correct after a method is called.