sol and sol "game over" test
- From: "Rocky Bernstein" <rocky bernstein gmail com>
- To: games-list gnome org
- Subject: sol and sol "game over" test
- Date: Sun, 9 Nov 2008 12:35:00 -0500
As a kid I used to infrequently play Klondike solitaire with where one
turns over 3 cards at a time from the "stock". I thought the game a
little lame since most of the time one loses.
I recently coming across this in Ubuntu with the variation of flipping
one card at a time. It is then a surprise to me to learn that I think
most the one can win using variation of the game. However, as with any
good game one may have to be careful about which moves to make. And
here the undo/redo feature is not only very nice but shows off
advantages of doing this on a computer rather than with a deck of
cards.
However there are a couple of annoyances in sol. It would be nice to
have a button to automatically move as many cards as possible from the
tableau (bottom area) to the foundation (top area). Compounded with
this is the existing test for the game over: having all 52 cards in
the foundation. Although technically correct, the game is over for me
when all cards in the tableau have been uncovered and I have at least
one redeal remaing. At this point I find it tedium to stack cards onto
the tableau.
(It seems that at one that at one time there was a test on the number
of cards in the stock; it was realized, of course, that this test is
faulty.)
I haven't quite convinced myself that I can *prove* that one can
complete the game if all of the cards are uncovered, but on the other
hand I can't come up with a counter example, except of course when the
number or redeals is 0 and low card, say a two of some suit has
already been skipped over. If someone can come up with a
counterexample I'd be interested.
Given this, here's a "game-over" test that assumes you've won awhen
all cards are exposed and you have access to the bottom stock card via
a redeal.
(define (game-won)
(or
(and (= 13 (length (get-cards 2)))
(= 13 (length (get-cards 3)))
(= 13 (length (get-cards 4)))
(= 13 (length (get-cards 5))))
(and
(or (< max-redeal 0) (> (- max-redeal FLIP-COUNTER) 0))
; slot 6 is always visible or empty
(or (empty-slot? 7) (is-visible? (car (reverse (get-cards 7)))))
(or (empty-slot? 8) (is-visible? (car (reverse (get-cards 8)))))
(or (empty-slot? 9) (is-visible? (car (reverse (get-cards 9)))))
(or (empty-slot? 10) (is-visible? (car (reverse (get-cards 10)))))
(or (empty-slot? 11) (is-visible? (car (reverse (get-cards 11)))))
(or (empty-slot? 12) (is-visible? (car (reverse (get-cards 12))))))))
Looking at the above, there's a lot of repetition. My understanding of
Scheme is a little weak. But I imagine there's DRY (don't repeat
yourself) way to do this. In Ruby the repeating fragments might be
done like this:
(2..5).any?{|c| 13 == get-cards(c)}
(7..12).any?{|s| empty_slot?(s) || get_cards.reverse.is_visible?(s)}
If someone wants to enlighten me as to the DRY way to do this in
Scheme I'd appreciate knowing that as well.
The last annoyance in sol is a little more difficult one to remove. I
don't like playing solitaire when it's impossible to win -- even if
one point of any solitaire is to waste time! So it would be nice if
the game didn't offer such guarenteed losing configurations.
Here's a sufficient but not necessary test. Suppose a pile in the
tableau (bottom part) has a card which has a lower rank card of the
same suit above it (hidden) in that pile and it also has both higher
rank cards of the opposite color also above it as well. Then there's
no way for this card to ever get moved and you have a loosing
configuration. Example:
pile: 1H 3S 3C 2H (exposed 2H)
This isn't sufficient because there can be transitive dependencies
between cards in different piles. For example:
pile 1: 1S 3S 3C 2H (exposed 2H)
pile 2 1H 3H 3D 2S (exposed 2S)
I suspect however if this is not the case then the game *can* be
solved. Again I don't have a proof, but would welcome one or leads to
other places where has been discussed.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]