15 Solitaire Puzzle

30 Aug 2022 - 11:15 | Version 1 |
Be warned: There are a number of different games that might share the same name. Below is a brief description of the version we will work with: Fifteen Puzzle solitaire is a solitaire game played with one deck of 52-cards set. The game is unique in its game play as it is played much like a puzzle and not like the regular solitaire card games.

The player is dealt all 52 cards face-up in 13 piles each pile having 4 cards. There are two additional piles which are empty at the beginning. The cards are required to be moved around so that all cards of each rank are moved to the same pile and there are 13 piles each containing 4 cards of the same rank at the end of the game.

Objectives

  1. Learn about stacks and queues
  2. Learn to design code and tests before writing code
  3. Create a subclass and use it

Assignment

  1. Write a program that allows the user to play the 15 solitaire puzzle card game. Some rules:
    1. You can only move a card onto an empty pile or a pile that has the same value on the top and has room. For this implementation, you may substitute the following rule (if you wish)
      1. You may only move a card onto an empty pile or a pile that has room.
    2. The game is over when each pile contains 4 cards all of the same value
    3. Only four cards can be placed on a pile
  2. You are provided with the following bare bones java class. You should enhance them as needed. URL for GitHub: https://classroom.github.com/a/cFnebhRh
    1. Card.java. This class will represent a single card. It has a "suit" and a value. Since we only care about the value, that is the only accessor. Also, cards are not allowed to change.
    2. Deck.java. This class will hold a deck of cards in an array. It will create a deck assuming 4 suits with the specified number of cards (identified by the constant). It can shuffle the deck, deal out one card, and display the deck.
  3. Phase 1: Create a Software Design Report. See: wiki page for more details as to what should be included.
    1. The system design needs to be a class UML diagram. I highly recommend using Microsoft Visio. You have access to it in the lab and should be able to download in to your own windows machine. Send an email to me for more instructions on how to do that.
    2. You should spend time developing a testing plan that will help you when you begin programming. Your goal will be to develop the program in steps. What is your first step? How will you test it? One test (in the middle of your development) might be to test to see if the program can determine if the game is over (without having to plan an entire game). For that you might make a small deck (say 20 cards (5 different values of 4 suits), and create a driver that creates those cards (in an order) into an array of cards and then sends that card to the deck constructor. You can then use that deck (in order) to test the game (to see if it is done). This is not the only way to test for the end of game. It is just an example to get you thinking. If you have a good testing plan, it will help you create a more bug free program from the beginning.
    3. The piles of cards must be implemented via a stack
    4. Because you will need to know if all the cards in the stack are the same (and that is not a generic stack), create a subclass of the stack with one boolean accessor that will tell you if all the cards in that stack have the same value.
    5. The class that enforces the rules of the game should not do any input. This will allow the game to be converted to a GUI without any changes to the game itself.
    6. Turn in a pdf document with your software design report (on Canvas) by its specified due date. You will get quick feedback so that you can use that help write your code.
  4. Phase 2: Write the software and create the software development report for it.
    1. Implement the stack and subclass of the stack outlined above.
    2. Implement the other requirements outlined above
    3. Be sure to fix any mistakes identified in your software design report.
  5. Be sure to modify the comments as appropriate and maintain good programming techniques

Submission instructions

  1. Complete the SDR.
  2. Combine your SDR and all of your .java and testing files into one zip folder
  3. Submit the zip folder on Canvas by the due data specific there.

Restrictions:

  • You may not use any Internet resources (other than to look up Java syntax).
  • You may use code from this course or last semesters.
  • You may not use any stack/queue (or similar data structure) from the java API.
  • You must implement your own stack and/or queue based solely what was covered in class and your textbook.

Challenges

  1. Implement all the rules
  2. Change the game so that the user can decide if they want to use a stack or a queue for the piles. Discuss how that impacts the game in the SDR in the lessons learned.
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
This website is using cookies. More info. That's Fine