Jason Cameron

ElevenLabs

5 min read

Activity 3

Question 3

The required sequence of random integers r generated for k=3, k=2, and k=1 respectively is 0, 1, 1.

  • For k=3 ({1, 2, 3, 4}), r=0 swaps 4 and 1 → {4, 2, 3, 1}.
  • For k=2 ({4, 2, 3, 1}), r=1 swaps 3 and 2 → {4, 3, 2, 1}.
  • For k=1 ({4, 3, 2, 1}), r=1 swaps 3 and 3 → {4, 3, 2, 1}.

Activity 6

Play Results

Elevens has a low win rate. Typically, after playing several games, you might win 0 or 1 time.

Question 1

Given 5♠ 4♥ 2♦ 6♣ A♠ J♥ K♦ 5♣ 2♠:

  • Pairs summing to 11: (5♠, 6♣), (5♣, 6♣).
  • JQK triplet: No Queen present, so not possible.
  • Possible plays are: (5♠, 6♣) or (5♣, 6♣).

Question 2

No. If the deck is empty and no legal plays (pair sum 11 or JQK) remain, the game ends in a loss. The board could contain cards other than J, Q, K, such as [7♠, 8♥, K♣], which has no valid plays.

Question 3

No, Elevens involves very little strategy. Since replacement cards are drawn randomly from the deck, the choice between multiple valid plays rarely has a predictable impact on winning. Luck is the dominant factor.

Activity 7

Question 1

The necessary private instance variables for ElevensBoard are:

  • private Deck deck;
  • private Card[] cards;

Question 2

  1. Create and shuffle a deck.
  2. Deal initial cards to the board array.
  3. Loop:
    • Check win (deck & board empty?) → Stop (Win).
    • Find all legal plays (pair sum 11 / JQK).
    • If no plays AND deck empty → Stop (Loss).
    • If plays exist: Select one, remove cards, deal replacements from deck (if available).
    • Repeat loop.

Question 3

Yes, the ElevensBoard.java structure contains the necessary state (deck, cards arrays) and behavior (method signatures like newGame, deal, isLegal, anotherPlayIsPossible, etc.) to model the game.

Question 4a

The dealMyCards method is called in the ElevensBoard() constructor and the newGame() method.

Question 4b

public boolean isLegal(List<Integer> selectedCards) and public boolean anotherPlayIsPossible() should call the containsPairSum11 and containsJQK helper methods to check the game rules.

Question 4c

The cardIndexes() method iterates through the cards array and returns a list containing the indices of only the non-null cards. For the input [J♥, 6♣, null, 2♠, null, null, A♠, 4♥, null], the returned list would be {0, 1, 3, 6, 7}.

Question 4d

 public static void printCards(ElevensBoard board) { // Or Board board
  List<Integer> cIndexes = board.cardIndexes();
  System.out.println("Cards at specified indices:");
  if (cIndexes.isEmpty()) {
      System.out.println("  <None>");
  } else {
      for (Integer index : cIndexes) {
          System.out.println("  Index " + index + ": " + board.cardAt(index.intValue()));
      }
  }
 }

Question 4e

public boolean anotherPlayIsPossible() needs to call cardIndexes() first. It must check for any possible legal play among all cards currently on the board, so it needs the list of all valid card indices before checking rules with the helper methods. isLegal already receives the specific indices to check.

Activity 8

Question 1

  • Similarities: Solitaire games, standard deck, board layout, card removal based on rules, card replacement from deck, goal to clear deck/board, common actions (shuffle, deal).
  • Differences: Board size (9, 10, 13), specific card removal rules (sum 11/JQK, sum 13/King, sum 10/4-of-kind), effective point values, specific helper logic needed.

Question 2

The Board instance variables (cards, deck) are initialized using the subclass’s specific values (board size, ranks, suits, point values) passed via the super() call within the subclass constructor (e.g., ElevensBoard’s constructor calls Board’s constructor).

Question 3

  • Abstract Methods: isLegal(List<Integer>) and anotherPlayIsPossible().
  • Implementation: ElevensBoard provides @Override stubs (to be filled in Activity 9) showing it will implement these with Elevens-specific logic.
  • Coverage: They define what must differ (rule checking) but not how. Board size/deck config are handled by the Board constructor. Game-specific helper logic (like containsPairSum11) remains within each subclass. So, they cover the need for rule variation but not the entire implementation detail of all differences.

Activity 9

Question 1

The board size is needed by the Board constructor (invoked via super()) to initialize the cards array (the board’s state). It’s determined at object creation time, not a behavior that varies afterward. Board provides a concrete size() method (return cards.length), so it doesn’t need to be abstract.

Question 2

Card selection is typically handled by the player/GUI/simulation (external to the board logic itself). Card replacement uses the same logic for all games (deal from deck into empty slots), so it’s implemented as a concrete method (replaceSelectedCards) in the Board superclass. Neither varies based on specific game rules in a way that requires an abstract method.

Question 3

  • Polymorphism: Yes, the GUI could still call methods defined in the Board interface polymorphically.
  • Work as well? No.
  • Why: Interfaces cannot contain instance variables or concrete method implementations (before Java 8 defaults). All common state (cards, deck) and common behavior (deal, newGame, replaceSelectedCards, etc.) would need to be duplicated in every class implementing the interface (ElevensBoard, ThirteensBoard). The abstract class design is better here because it allows defining common state and implementing common methods once in the superclass, promoting code reuse.

Graph View