Free Cell Clone

COMP 585 Project Free Cell Clone Free Cell is a solitaire card game. It was distributed for years on many versions of Microsoft Windows. Cards are distributed across several board areas called cascades, free cells, and foundations. The goal of a game is to start with cards randomly assigned to 8 stacks called cascades, move cards at the top of the cascades between cascades to sort them into ordered series, and gradually move all cards to the foundation stacks, with one foundation stack for each suit, and cards added to the foundation stack in face value order. The free cells are 4 empty slots to temporarily hold one card each while ordering and foundation building is proceeding. For simplicity, we’ll assume that the board is divided up into 10 columns as follows: • • Cascades: the first 8 columns. Each cascade is a stack of cards. Initially, the stack contains whatever cards were placed there by a random shuffle. The game starts by shuffling the 52 cards and distributing them across the cascades in row major format. This results in the first 4 cascades holding 7 cards and the last 4 holding 6 cards (4*7 + 4*6 = 4*13 = 52). Once the game begins, cards can be moved between cascades, but sequencing and card limit rules must be followed. While the game is being played, the lower cards in the cascades will be in their original random order. But gradually, some number of cards at the top of the cascade will gradually become ordered. Cards that are ordered at the top of a cascade are called a tableau. The tableau can be moved as a group from one cascade column to another, so long as the bottom card of the tableau forms an ordered sequence on top of the top card of the destination cascade. In addition, there are limits on how many cards in a tableau can be moved at once depending on the number of empty free cells and empty cascade columns. The order enforced by tableau cards is lowest face card at the top and highest face card at the bottom, plus alternating suit colors. So for example, the 7 of hearts (red) from one cascade column can be moved to another cascade column and placed on top of an 8 of spades or 8 of clubs. Generally, when an ace becomes the top card of a cascade column, it is moved directly to its foundation rather than being moved between cascade columns or to a free cell. For convenience, each card is offset from the card below so that all cards in the stack can be identified. Free Cells: column 9. This column contains 4 slots for individual cards, initially empty. Individual cards can be moved from the top of any cascade to any available free cell slot. A card can be moved from a free cell • slot back to the top of a cascade so long as sequencing rules are followed. The free cell cards are displayed separately (no overlap). Foundations: column 10. The foundations are four card stacks organized by suit, initially empty. The goal of the game is to move cards from the cascades or free cells to the foundations. The foundations must grow in ascending order of face value. That is, the ace of a suit must be moved to the foundation stack for that suit first, followed by the 2, and so on, for the entire suit, and similarly for the other suits. Implementation You will borrow some of the implementation from previous versions of the project: • Enums for Suit and Face • SuitAndFace class to represent a (suit,face) pair • CardImagePanel to display a single card • Hash map to associate CardImagePanel values with (suit,face) keys. The hash map will be the home of all card image panels. You will add them to and remove them from the CardTable panel as needed. During initialization, card images are loaded into the hash map, and they remain there for the entire game. To support game play, there may be the need to create additional data structures of references to the cards, and these various arrays don’t have to be mutually exclusive (multiple references to a single card can exist, depending on your logic. Separately, card images can be added to or removed from the main JPanel display as needed. But adding/deleting card images for the JPanel is only to arrange the display of the game board, it doesn’t affect the state of the hash map. The cascade columns will be implemented as a two-dimensional ArrayList of SuitAndFace values. The free cells will be represented as a single ArrayList of SuitAndFace values (maximum size = 4). The foundations will be represented as a two-dimensional ArrayList of SuitAndFace values, with a maximum of 4 rows, one for each suit. Initialization • Load cards from file into hash map • Display area of CardTable is initially empty. • Provide a Game menu with a New menu item. When selected, remove all CardImagePanels from the CardTable, and empy all cascades, free cells, and foundations. Create an ArrayList of all 52 SuitAndFace values. Shuffle the list with random number draws. For example: ArrayList deck = new ArrayList(); for (Suit s: Suit.values()) { for (Face f: Face.values()) { deck.add(new SuitAndFace(s,f)); } } Random r = new Random(); for (int i=1; i<10000; i++) { int j = r.nextInt(deck.size()); int k = r.nextInt(deck.size()); if (j != k) { SuitAndFace temp = deck.get(j); deck.set(j,deck.get(k)); deck.set(k,temp); } } • In the menu item listener, create and shuffle the deck, then layout the CardImagePanels onto the 8 cascades. Layout is described in more detail in the next section. The general skeleton in pseudo-code is: int xposition = startX; int yposition = startY; For all cards in the deck SuitAndFace x = current card CardImagePanel p = image card for key x from hash map Set p’s size to be its preferred size Set p’s location to xposition, yposition If continuing in current row, xposition = xposition + columnWidth Else if starting a new row, xposition = startX, yposition = yposition + rowHeight End For • • You will implement a mouse listener for the overall card display, not for individual cards. Also you will not need to implement any animation or move-on-drag effects for card images. Based on a press-drag-release motion, you will simply change the location of a card from one stack to another. The display will update with the new positions when the mouse release event is processed. Details on mouse event processing is given below. When all cards have been moved to the foundations, use a popup dialog like JOptionPane to announce a win. Rules for card movement are described below. Layout You will manage your own layout of the cards on the CardTable. To support the layout and the processing of mouse events later on, use a set of constants to define the parameters of the layout. In this figure, the cards are arranged in 10 columns. The first 8 columns are cascades and display cards in stacks with each card offset from the previous so that all cards can be seen at once. In column 9, the free cell cards are displayed, and these are stacked separately and not overlapped. Finally in column 10, the foundation stacks are displayed. There are four stacks, one for each suit. The stacks are not overlapped. But the cards in one stack are fully overlapped, only the top card in each foundation stack is visible. To easily manage the layout, use a series of constants like this: int int int int int int int startX = …; startY = …; cardWidth = …; columnWidth = …; cardHeight = …; rowHeightSmall = …; rowHeightFull = …; // // // // // // // dist from left margin to left edge of cards in column 1 dist from top margin to top edge of first card in column width of one card width of one column (width of one card plus separation) height of one card height of one row for overlapped cards height of one row for non-overlapped cards These values will also be useful for processing mouse press and release events, discussed below. Rules of Card Movement Unlike some commercial versions of the game, we will simplify the event processing by assuming that cards are moved between columns with a press-drag-release motion. The mouse press must hit a specific card, but the mouse release will be checked only for its column, it does not need to hit a specific card. There are 5 possible card movements allowed, depending on which card the mouse was pressed on, and which column the mouse was released in. • • • • • Case 1: move one or more cards from the top of one cascade column to the top of another cascade column. The pressed card must either be the top card in a cascade stack, or it must form a tableau with the cards above it. Furthermore, the pressed card must continue the sequence order of the top card in the released column. Case 2: move one card from the top of one cascade column to a free cell. The pressed card must be the top of its cascade, and there must be a free cell available to move it to. Case 3: move one card from the top of one cascade column to the top of the foundation stack for that card’s suit. The pressed card must be the top of its cascade column, and the card must be the next card in sequence for the foundation stack for its suit. Case 4: move one card from a free cell to the top of some cascade column. Pressed card must form a sequence with the top card of the destination cascade stack. Case 5: move one card from a free cell to the top of the foundation stack for that card’s suit. Pressed card must be the next card in sequence for the foundation stack for its suit. Cards cannot be moved out of the foundation stacks. Mouse Events No animation of card movements is required for this project. You will implement a mouse listener for the CardTable panel as follows: • • • On mouse pressed, record the card that was pressed. If the press does not occur on any card, the entire press-drag-release sequence will be ignored. On mouse drag, no event response needed for now. On mouse release, record the column of the release. The release does not need to be on any specific card. The mouse event and possibly mouse motion event listeners must be attached to the CardTable not the individual CardImagePanels. Specifically if you were to write a mouse listener and register it with each of the 52 card image panels, you would discover a problem. If a mouse press occurs on a specific card image panel, it is not possible in Swing for the corresponding release event to be associated with another panel. This effect is sometimes called mouse capture. To correctly process the press-drag-release sequence, the mouse listener must be registered with the CardTable panel, the panel that holds the card image panels as components. Once the event occurs, the mouse event can be checked to determine which component within the CardTable container was pressed. Once the pressed card, pressed column, and released column are determined, determine how to move cards based on the 5 cases above. I suggest that for each card move case, create two methods: a boolean canMove() method to confirm that the move is legal, and a void doMove() method that actually moves the cards. // case #1 private boolean canMoveBetweenCascades(SuitAndFace card, int srccolumn, int dstcolumn) { … } private void doMoveBetweenCascades(SuitAndFace card, int srccolumn, int dstcolumn) { … } // case #2 private boolean canMoveFromCascadesToFreecells(SuitAndFace card, int srccolumn, int dstcolumn) { … } private void doMoveFromCascadesToFreecells(SuitAndFace card, int srccolumn, int dstcolumn) { … } … Enforcing Card Sequence Rules The cards on the cascade stacks start off in random or shuffled order. To move one card from one cascade stack (the source) to another (the destination), the card being moved must be on the top of the source stack, and it must be placed on top of the destination stack, and it must form a sequence with the card it is placed on top of. The sequence is defined by descending face value and alternating suit color. For example, a 3 of clubs from the top of one cascade can be moved and placed on top of a 4 of hearts at the top of another cascade stack. After a few moves, the cards at the top of the cascade stacks begin to become ordered into short sequences. It is now possible to move any or all of the ordered cards at the top of a cascade to the top of another cascade, so long as the sequence between the top of the destination stack and the bottom of the sequence of cards being moved is maintained. A group of cards in sequence at the top of a stack is called a tableau. When performing a press-drag-release motion, the rules for processing now look like this: For case #1 – moving between cascades – the card that was pressed must be part of a tableau. If the pressed card is the top of the stack, then it trivially forms a tableau of size 1. If the pressed card is not the top of its stack, then all cards from the pressed card to the top of the stack must be in sequence, otherwise the pressed card is not the start of a tableau and the movement cannot be completed. Assuming the pressed card is the start of a tableau, the next constraint to check is to look at the cascade stack where the mouse release occurred. If the stack is empty, then the tableau can be moved. If the stack is not empty, then the card on top of the stack defines the start of a sequence, and the sequence must be continued by the beginning of the tableau being moved. For example, the tableau (6 clubs, 5 diamonds, 4 spades) can only be moved to a stack whose top card is (7 diamonds) or (7 hearts). The movement started when the user pressed the (6 clubs) card on its original stack, dragged it to its new stack, and released. The sequence order from (7 diamonds) or (7 hearts) can be continued with the tableau starting with (6 clubs). An easy way to check order of cards is to use the ordinal() method for enums. Assuming the face enum has defined face values in increasing order, the position values can be compared like this: enum Face {Ace, Two, Three, … }; Face f = Face.Two; Face g = Face.Three; if (f.ordinal()+1 == g.ordinal()) … // expression is true To check alternating colors of suits for the cards in a sequence, you will need another map to map suit to color, or simply implement a function like this: private Color getColor(SuitAndFace card) { if (card.getSuit().equals(Suit.Hearts) || card.getSuit().equals(Suit.Diamonds)) return Color.Red; else return Color.Black; } To check that two cards in a sequence have alternating colors, simply confirm that they have different colors. The Color class is pre-defined in the java.awt package. There is an additional rule that the size of any tableau is limited to the number of unused free cells plus the number of empty cascade columns. I suggest you not enforce this rule while testing. For your own bookkeeping, when moving cards from one stack to another, you will probably want to update the various array lists to remove references from one list and add them to another list. This will make it easier to quickly figure out the status of any one card during the game. As mentioned earlier, all cards being moved will have to have their location updated with the setLocation() method, since there is no layout manager for the CardTable panel. After moving a card, you should bring it to the top of the z order. The Foundations The goal of the game is to move cards one at a time from either the cascade stacks or the free cells onto the foundations, until all 52 cards have been moved to the foundations. There are four foundation stacks, one for each suit, all initially empty. Cards must be moved to the foundations in increasing face value order. In other words, the ace must be moved to its foundation first, followed by two, three and so on. Commercial versions of the game will automatically move cards to the foundations if there is no value in leaving the card on the cascades or free cells. In particular, aces are moved as soon as they are exposed. When the game starts, the foundation column is empty. Rather than having a reserved cell for each foundation, only create a foundation stack when that stack is started by dragging an ace to that column. There is no reason to order the foundation stacks in any particular order by suit.