Anyway sounds cool.

How do you ensure that the random instances are solvable?

I build my basic progs usually somehow like this:

Variables as following: for a menu, A the position, C the Keypress
Repeat A=3 and C=21  //A=3 is then the bottom-most menu item, exit
<draw menu>
Repeat C=21
<menu routine
End
If A=0
Then
<stuff for first menu point>
0->A //put cursor at the top again and prevent exiting
End
If A=1
Then
<stuff for second menu point>
0->A //put cursor at the top again and prevent exiting
End
If A=2
Then
<stuff for third menu point>
0->A //put cursor at the top again and prevent exiting
End

End


I like labels in BASIC because they can often be an excellent solution and often the best solution

Anyways, to answer harold, there are no unsolvable starting conditions. (Think of it like a scrambled Rubiks cube, or a scrambled knot in a string whose ends are tied together). When I made one, I wasn't sure if there were unsolvable solutions, so I just simulated n steps and presented the board.

EDIT: Oops, it seems there are some unsolvable boards for some sizes.

I like labels in BASIC because they can often be an excellent solution and often the best solution

I agree with Xeda. I used labels because I thought it was the best solution.

Anyways, to answer harold, there are no unsolvable starting conditions. (Think of it like a scrambled Rubiks cube, or a scrambled knot in a string whose ends are tied together). When I made one, I wasn't sure if there were unsolvable solutions, so I just simulated n steps and presented the board.

That must have been slow, Xeda.
Harold, I did my research first, and at least for 6 by 6 grids, there are no unsolvable starting conditions. So, int(2rand(36 was sufficient.

So, was the game good?

Hmm, try to avoid double posting please. You have an edit and a delete button at the top of your post.

Quote from: Xeda112358 on November 11, 2013, 12:56:18 pm

I like labels in BASIC because they can often be an excellent solution and often the best solution
[...]

When's that They also have that memory bug

That memory 'bug' isn't a bug, actually, it is just misuse of Goto and Lbl inside While, Repeat, and For loops.

Examples are when you use the Menu() command, the options need to jump to labels, then if you want to jump back to the menu, you either need to use a non-optimal Repeat loop, or the more optimal Goto. For example:
Lbl 0
Menu("HEADER","ITEM 1",01,"ITEM 2",10,"EXIT",1
Lbl 01
Pause "HI!
Goto 0
Lbl 10
Pause "HAHAHAHAHA
Goto 0
Lbl 1

In reality, While loops and Repeat loops use memory (so large nestings of these can consume lots of RAM) whereas Lbl and Goto use no memory. In RPGs, using labels is usually the best option, and for games where you want to use subroutines without using subprograms, you can take advantage of mixing labels and while loops. I made heavy use of this in an RPG a while ago.

To be more technical, the OS needs to push information onto an operator stack whenever it executes a loop. When it reaches an End, it uses that information and it doesn't remove it until the loop is finished. If you had 9 nested while loops, then , it pushes the data for each loop onto this stack, and when it reaches an End, the information is popped off in reverse order. If you use a Goto to jump out of a loop, the data never gets popped off the stack unless you place an unused end somewhere (but then only one item is popped off).