For this final project you will work in 4-person teams to write a program to play the "Vatikan" variation of the Rummy card game, which is almost identical to the board game Rummikub. This problem is an exercise in using advanced object oriented programming techniques, including inheritance and exceptions. It builds on parts of your previous 2 assignments. It also gives you experience working in a larger team. Hopefully it will be fun!! Begin your work early...
Because this is a more extensive team project, there are several components that you must complete in addition to actually writing the code to solve the problem. First, you must prepare a design document explaining the project requirements, plan of attack, and implementation schedule. Next, write the actual code. The third component is a team demonstration to show the rest of us how your solution works. Lastly, you will be expected to do evaluations of your team members. Before you start any of that, I recommend playing the game to be sure you understand all the rules.
Write a design document which describes the project requirements, the overall operation of the program, and your strategy for programming the project. This document should be well-written, using proper English and nice formatting. Do not include actual code, but write it at a level such that you could give it to someone else to finish the actual implementation.
You must include a general overview of the game play, as well as a sample user interface. It should also include an overview of your class structure (OO solution), including diagrams of all the class relationships. It should be clear where each of the OO features detailed below will occur in your solution.
For each proposed class, provide a short written description, along with the key data and public member functions that will be present. Do not include complete header file information. Concentrate on the primary responsibilities of the classes and how they fit together to make the whole program. Be as detailed as possible without actually writing any code.
The document must also include an implementation plan. This must include the following information:
Only one design document should be submitted per team. It should be well written and nicely formatted. There is no length requirement for this document. However, a one page document is probably too short and a 15 page document would put us to sleep (unless it had lots of pictures). 5-10 pages with figures is appropriate. A hard copy of the design document must be submitted in class, and one group member must submit it on webCT as well.
Write a program to play the "Vatikan" version of the card game Rummy, as described on http://www.pagat.com/rummy/carousel.html. You may first want to read the rules for standard Rummy to get familiar with the basic concepts and terminology. The Vatikan version is much more interesting in that it allows for rearrangements of the cards on the table. It is nearly identical to the board game Rummikub ( http://www.pressmantoy.com/instructions/instruct_rummikub.html).
Your program must work for 2-5 players. The players can be human players (keyboard input) or computer players. However, it is very complex to automate moves with rearrangements of the board. Therefore you do not have to fully implement making moves for computers!! Minimally a computer player has to look for and play melds from its hand: 3 or 4 of a kind (group) or a run of 3 or more. You should also implement adding cards from the computer's hand to existing melds. However, you do not have to implement rearranging melds for the computer player (only for human players). When the game starts, the program should prompt for the number of players, and then the names and types of each (human or computer). It should then procede to play the game until there is a winner. You must implement the program according to the requirements below.
Your user interface should be separate from the main engine of the project. Make it as friendly as possible. Try to add nifty features to your project beyond the expected behavior. Keep in mind that the better you design your user interface, the smoother your demo will go. We expect you will have many classes, some general, some specialized. Some examples may include: Player, Human, Computer, Card, Hand, Meld, Run, Group, Move, Game, etc. Your main program should only handle the input details for the set-up (number, types and names of players), and then start the game. All other code should be organized into your classes. Lastly, you must do a reasonable amount of error checking, formally by using exceptions. This should include validating user input as well as checking that requested (human) moves are legal. You should try to make your solution first of all correct, and second of all as efficient as possible with respect to time (operations) and space.
Your projects must incorporate the following OOP features:
You are expected to use mercurial for version tracking and BitBucket for file sharing and updates. Also continue to use paired programming as much as possible since this is a very successful technique. You can recombine your 4 team members into different pairs depending on skills, availability, etc. Use everyone's strengths in the best ways possible. Some are good organizers and designers, others are better at coding, and some might be excellent testers and debuggers. However you end up dividing the work, make sure that all team members have a pretty good idea of how all the classes work, and are comfortable with inheritance and exception handling (for the final).
The finished product must be demo-ed in either the last class or lab sessions: Thu 5/6 3-4:15, 4:30-5:30 or Fri 5/7 3-4 or 4-5. All members should be present for the demo. Joanne will schedule the teams based on the lab section of the majority of the students in each group. Teams with diverging lab sections will be scheduled during the thursday lecture.
Your demo should consist of running the program for everyone else to see and appreciate. You may want to include some slides for a general overview. Make it clear exactly what your program can and cannot do. Plan this out ahead of time so that you know what input to use for an efficient demo. Treat this seriously - as if you are trying to sell your product to us and only the best one will be chosen. The students watching the demos will "grade" what they see. Each group will have approximately 15 minutes (if scheduling works out well) for their demo.