Scramble, Unscramble, and Win

I'm still working hard to get Sluzzle ready for the CoCo Coding Contest review.  I may have to throw-out a few features, but it will still be fun to play.  I keep spending a little too much time "testing" to make sure it is still working -- it must be fun! :-)

Shuffle Like You Mean It

The whole point of a sliding puzzle game is to move the tiles back into their correct order.  That wouldn't be much fun if they weren't scrambled-up in the first place!  So with the basic mechanic of moving the tiles already working, the next order of business was to figure-out how to shuffle the tiles for a new game.

The shuffling routine needed a source of (pseudo-)random numbers.  The old LFSR workhorse rode to the rescue on this one.  In Fahrfall I used a 16-bit LFSR, but this time I am using an 8-bit one.  The 255 value wrap range seemed sufficiently larger than the 4 directional choices used for moving puzzle pieces -- no point in shifting 16 bits when 8 bits can do the job.

I was disappointed with my original shuffling algorithm.  It basically just got the next LFSR value, masked off unneeded bits, and then moved in that direction.  The problem was that this didn't seem to shuffle the board very much without really large numbers of moves.  All those extra moves introduced noticeable startup delay while shuffling the board.  I added code to the shuffling routine that refuses to make a move that undoes the previous move.  This allowed for satisfactory shuffles in just a few dozen moves!

Give Me A Hint

Since some pictures may be less familiar than others (and since people have faulty memories), I thought that it would be nice to provide a way to see the unscrambled picture without having to quit (or solve) a game.  I implemented the unscramble as a selection sort, using the blank square as a scratch space for swapping blocks.  This resolved the unscramble issue without any major issue.

The re-scrambling of the blocks seems like it should have been easy as well, since it is essentially just another sort using the block order saved from before the unscramble.  For some reason, it took me at least twice as long to implement the rescramble as it took to implement the unscramble.  I think that I was confusing myself between the numbered tags I used for tracking the block locations and the numbers I used for identifying the locations themselves.  Anyway, it goes to show you that even someone familiar with assembly language and coding in general can get stymied once in a while -- or, maybe I'm just getting old!  At least my CoCo is eternally youthful...

Is It Over?

There is little point in playing a game on a computer unless the computer can tell you when the game is over.  Implementing this was fairly easy.  As I hinted above, I maintain a map of which block is currently in each location.  After every move, I walk the map to check if the number of each block matches the number for the position it is in.  If they all match, the picture is unscrambled and the game is over  -- you win!  But really, playing is its own reward...

So, the basic game mechanics are in place.  The next major step I see is to implement a Color BASIC loader that lets you select which image you want to unscramble and then loads the image and the actual game binary.  After that, maybe there will be a little more time for a few more embellishments.

Wanna see it?  Then stay tuned...