Mind Boggling Conundrum's

So I have not been programming long and I'm sure I get stuck easier than the next guy.

But I find that if I can articulate things .. that is say them out loud in a plain and simple way - then programming it is much easier.

So I've been trying to program in a subroutine/function to determine the following

• Are there any moves left on the board?
• If so where is it?
• Can we give the player a hint about it?

And honestly for two weeks this has been defeating me. I've deferred that process to work on graphics as you can see almost all my updates recently have been due to graphics.

But finally this weekend I drew the line ..

Read more after the break...



When I can not articulate things out as noted above - this is when I resort to pen & paper.

So  after about 300 lines of failed code I came up with this piece of work on a plain sheet of white paper:

I don't expect you to be able to read my hand writing so I will summarize. 

Essentially what this does is describe two possible linear match situations.

• 1 2 1 1 
• 2 2 1 2

You will note in both situations there are 4 numbers.

Also in both situations there is a number that sits in the middle of other numbers essentially 'blocking' them from becoming a 3 in a row match.

I needed to plot out how to understand it in an algorithm.

You'll note the use of A, B , C , D , E labels.  These were the key for me. When I add up A-E if the value =2 I know a 'potential match' exists and then can move forward.

The way this happens is in two passes.

First you check the following

• Does 1=2 ?  The answer to this is A
• Does 2=3 ? The answer to this is B
• Does 3=4 ? The answer to this is C

On the second pass you determine

• Does 1=3?  The answer to this is D
• Does 2=4? The answer to this is E

What I found was that  when the two scenarios noted above existed the answer to A + B+ C+ D +E always equaled 2. 

I did not need to account for values greater than 3 because my main program already makes sure no more than 2 in a row will ever exist without the player's intervention.

Now you may not realize it but this ONLY accounts for matches on the X and Y axis in direct lines.

In a situation where this exists it would not detect it:

2211
3134

Here you would have to move the 1 upwards and swap it with the 2 to create a match.  I still have to work that out - but in fact I think that's fine! I'm new to programming and handling things in simple and easy to understand way is in fact the way I get things done. 

If you can get it done in a simple way this is a hell of a lot better than not getting it done at all I say.

Additionally I like this because what I will do (in pseudo code) is the following:

1. Check if any potential matches exist on the X axis.
2. If No then Check if any potential matches exist on the Y axis.
3. If no then check more complex multi-axis matches. (this part I have not programmed yet)

But you see the way I expressed this? The program can stop on step 1 if it finds a potential match. I do not need to progress any further if  I find what I'm looking for.

So in the end my inability to make it all check in a single pass could be less work for the computer by checking the simplest type of matches first and stopping as soon as it fines one.

I assume that experienced people will read this and laugh , but I really am sharing it for people who are learning and find yourself drowning in mind boggling problems that you couldn't think yourself out of to save your lives.  I think the example I provided may give some food for thought to creative ways to think yourself out of those boxes.

I was able to get 1 foot out of a two week deep box with this piece of paper, I hope you enjoyed reading about the experience.