Skip to content

Solitaire Design

Jump to bottom
Anna Nguyen edited this page Oct 20, 2020 · 9 revisions

Authors: Anna Nguyen, Katie Mendel, Andrew Heroux, Nathan Drees, Mia Li

I. Overview

The purpose of this project is to design a simulation of simple Klondike solitaire that is played using a procedural strategy in Java. It will follow the rules of Klondike solitaire, except only allowing three passes through the deck. The game strategies will be automatically executed from a predefined set of rules that we as developers will set. Strategy can be changed from run to run so that it is easy to compare the success of each strategy and figure out which ones perform better.

II. Context

It is impossible to calculate the probability of winning a game of Klondike solitaire because there are too many different possibilities. To find optimal strategies, the simulation described above will generate success statistics for each run. Statistics will include winning percentage over many games, the mean number of moves for the winnable game, and average move time for all games play. To validate the simulation, it will be tested on decks with a known shuffled order. Some of the orderings will be winnable while others will be unwinnable. We will ensure that our program matches the expected outcome.

III. Goals and Non-goals

Goals

  • Have strategy easy to change and save after game.
  • The success of the optimal strategies will be measured by the percentage of winning games. (higher is better)
  • The measure of strategy success is based on the average number of moves per game. (lower is better)
  • Use parallel computing to increase the number of games played at one time.
  • The success of the optimal strategies will be determined by the average time per game. (lower is better)

Non-goals

  • Making a simulation that can play multiple strategies in one game.
  • Designing a GUI for the game.
  • Making an AI learn after games to improve strategies by themselves.
  • Making a game where a user can determine individual moves.

IV. Milestone

  • Start date – October 6th, 2020
  • Milestone 1 – Finish all the entity classes
  • Milestone 2 – Finish the java implementation of all classes including a driver to play the game
  • Milestone 3 – Create a minimally functional simulation with a basic strategy
  • Milestone 4 – Add more elaborate strategies to improve the simulation
  • Milestone 5 – Multithreading capabilities
  • End date – October 22nd

V. Solution

a. Class diagram in Lucid Chart: could be found in issues in the Team Document repository. b. Description

i. Game setup

  1. There are seven tableaus each one with at least one face-up card and contain 1 to 7 cards respectively.
  2. Empty tableaus can only have a king placed in them.
  3. The remaining cards go to the deck.
  4. Tableaus that contain face-up cards can only have opposite color descending face-up cards placed on any face-up card in the tableau.
  5. There are four foundations that represent each suit and can only start with the ace and end with the king in ascending order to win the game.

ii. Basic strategy

  1. Check to see if any cards in the Tableau can be moved into the foundation
  2. Draw card from Deck Card
  3. Check if the card can go into any of the foundation stacks
  4. Check from left to right if the card can go into any of the tableaus
  5. Check if any of the top cards in the Tableau can go into the foundation
  6. Repeat steps 1 – 5 until win (when all 4 suits stack on the foundation) or loses the game (after 3 rounds of Deck of Cards)

iii. More elaborate strategies

  1. Always move aces and twos into the foundation when you have the chance
  2. Don’t empty a tableau stack if you don’t have a king to put there
  3. Turn the first card from the deck before making any moves the organize the tableau
  4. If you have the choice to expose hidden cards in more than one tableau stack, choose the stack with more hidden cards
  5. Check the tableau to see if there are any exposed cards in the tableau that could go up with partial stack moving
  6. Check to see if any moves can be made in the tableau

If there is a card that can be moved into the foundation that is under multiple face-up card, move the top of the stack if possible.

iv. Other Strategy

  1. Go until win, 1000 turns, or 3 times through deck
  2. Check deck for cards/reset
  3. Check cards in Tableau to move to foundation
  4. Move cards between tableau stack
  5. Repeat 3-4 until no more moves or infinite loop happens
  6. Draw card
  7. Check talon for move to foundation or until talon is empty
  8. Check talon for move to tableau or until talon is empty
  9. Check for moves in Tableau
  10. Check for moves in foundation
  11. Repeat 7-10 until no moves or infinite loops happen
  12. Repeat 1-11 until game is lost or won

VI. Alternative Solutions

a. Java versus Python

Cons:

  • Would not gain new skills in python
    Pros:
  • More familiar with Java compared to Python
  • Can include more capabilities within a shorter amount of time

VII. Impact of the project

  • The process of choosing optimal strategies for this Solitaire Simulation would speed up the process of improving strategies in general.
  • The process of choosing an optimal strategy could apply in many other fields such as finance and science.
  • The procedure of determining the success of a strategy could also apply to different projects.

VIII. Open Questions

  • A document includes different strategies and the user could pick strategies.
  • The simulation could run multiple games at once.
  • What is a good strategy? Which measures of success are most important?
  • How to calculate the chance of winning?
  • How many games needed to play in order to determine the success of the strategy?
  • How could we improve the time? Improve the iteration through the cards.
  • Have a chart for the statistical performance of strategies.

IX. Detailed Scoping and Timeline

  • Finishing class diagram – Date due: Thursday Oct 8 (by class time)
  • Created TableTop, Controller UML (separately)
  • Updated all other classes so that they reflect what we have in code
  • Implement the class diagram (Milestone 1): Thursday Oct 8 (night)
  • MEETING Thursday @11:00AM: Go through Class Diagram, Class Design
  • Created TableTop class, and TableTopTesting
  • Create a simulation (Milestone 2) - Friday Oct 9th
  • Create a Driver
  • Create Controller classes
  • Detailed job:
  • Updated Card class – Katie: Thursday
  • Implement TableTop Class – Andrew: Thursday Night
  • Test TableTop Class – Katie: Friday
  • Create a simulation that run one strategy (Milestone 3): Saturday Oct 10th
  • Detailed job:
  • Implement StrategyController Class – Anna: Friday
  • Test StrategyController Class – Mia: Saturday morning
  • Implement SimulationController Class – Katie: Saturday morning
  • Test SimulationController – Nathan: Sunday moring
  • SUNDAY FINAL TEAM MEETING @10:30 AM

Clone this wiki locally