Spider Solitaire
What is the problem?
We are recreating the Spider (solitaire) game, most famously seen in Microsoft Windows.
We will be implementing the Spider 1 Suit variant, which means the cards will be from the same suit. We will investigate whether the game is easy to implement in Haskell.
There are the rules for our game:
- There are 104 cards in total, and the final goal is to pile them up as 1, 2, 3, ... 10, J, Q, K
- There are 10 piles of card, at the beginning, each pile only have one card facing up (shown as the bottom of the list), and each time you remove the card, the next one will face up.
- When you click on a card and want to move it to other piles, make sure the set of the card you select is continuous (5, 6, 7...), and after the movement, the set should also be continuous.
- When there's no more move available, you can click the upper left corner to deal cards, where there will be one more card on top of each pile.
- When there's a set (1,2,3...Q,K) shown continuous in a single pile, it will automatically pile up and remove from the current pile.
- it is ok to move the cards to an empty pile, and it's ok to deal cards with some piles empty.
Something extra
We will be creating a graphical user interface that hopefully looks nice.
We add a graphic card picture to visualize it. There's a place to click to deal cards, and when you click on different cards, it will choose/move the card accordingly. Also, if you click AI, there will be a hint shown on the page.
We will also try to implement a basic AI player that can assist the player by making an optimal move to serve as a hint system. We also design an algorithm to completely solve the solitaire and return the steps needed to solve it.
What did we learn from doing this?
What is the bottom-line? Is functional programming suitable for (part-of) the task? Make sure you include the evidence for your claims.
Functional programming is suitable for specifying the rules of the game and designing a solver that solves the game. However, it is less suitable when it comes to creating graphical user interfaces, as dealing with user interactions is a bit tedious. The reason why functional programming is good for writing the logics of the game itself is the ability to split the rules apart into manageable bits to work on individually. It requires less effort when we don't have to think about how the piece connects with the rest of the game when working on a specific piece of the code. Making a solver for the game with functional programming is also relatively easy due to the wide range of syntax Haskell supports for recursion.
Work division
do not want it to be public.