COMP 303 (Fall 2005) Project Deliverable Three

Goal

Required Problem

1. It must allow a number of players (between one and at least two) to register and play against the dealer using a user-specified amount of money.
2. It must allow registered players to play as long as they have money to bid.
3. Players should be able to join or leave the game between hands.
4. The application should respect the rules of the game and prevent users from breaking them (see the Project Overview).
5. Using your statistics module (project 1), the application should keep statistics about each hand and allow users to save them to disk at a location of their choice.
6. You should use the code of the dealer component that you submitted for project 2 (but you can improve it if you document your changes in a README file).

Hints and Advice

1. This deliverable involves more coding that the previous two. Make sure you give yourself enough time to complete it and seek any assistance you may require from the TA.
2. To manage risk, "grow" your solution. Start with a basic but functional solution, and then add more advanced features and improved layouts, etc.
3. If you wish, you can use the code of the following Cards program. This is a jar file containing images of the 52 cards plus the joker and the back of the cards, and a sample program to use the images. Note that this is an executable jar (on Windows click on it to run the demo). Note also that you'll probably have to modify the source code to fit your design. You do not have to use this API if you do not want to.
4. The requirements for this application are incomplete. At a number of points you will find yourself wondering how you should support this or that functionality (e.g., "how do I deal with players wanting to bid more than they have?"). In such cases, make a reasonable call based on your judgment, and document your decision.

Things to Submit

You must do this project individually. By submitting your project you acknowledge your understanding of McGill University's academic integrity policy.

Evaluation

• Whether your application meets the specifications above.
• Whether your design respects the principles covered in class.
• The overall quality of the software you provide (how smoothly it runs).

Optional Problem

• Design a IRobot interface. This interface will implement method that return the decision of the robot regarding how much to bid and what to do given a certain hand and dealer hand. The IRobot interface should also include a getName() method returning the name of the robot player.
• Implement different playing behavior by implementing the IRobot interface.
• Extend your GUI so that it is possible to add certain players as robot (i.e., computer) players.
• The GUI should automatically search a directory for all classes implementing IRobot and present these classes as a choice for the player to register. The class should then be loaded through reflection and used to control the behavior of the player. The directory to search for robot classes can be found according to the scheme of your choosing, as long as it isn't a hard-coded absolute path.

Special Bonus: If you implement this option, you can get an additional 5 marks (out of 20). Furthermore, if this results in a score above 20, any leftover bonus can be directly applied to previous projets. Partial marks will be considered for a partial (but working) implementation.