@Kartoffelbrot I was thinking about doing that Kartoffelbrot, although detecting where you 'drop' a ring is slightly more difficult; however, I do plan on adding this, but I'll probably create a new scenario instead of adding to this one as I have to create a draggable ring. @Super_Hippo Ah, thanks, I'll try and fix that. The Glider class I created for the glideTo(x, y) method still has some bugs in it, one of which is that sometimes it will glide towards the destination, then simply go right past it, which is what happens in step 32 (It displays step 31 because that was the last step performed). Anyways, Super_Hippo, did you plan on watching 19 rings? Because I'll tell you now, it takes a LOT of moves.

@danpost The current state and move count to determine the next move? That sounds like an interesting algorithim, although it seems to be slightly more complex. One of the reasons I chose to do it this way was that earlier I had created a program in python that gave you instructions on how to solve the puzzle, and I became interested in creating graphics for it using Greenfoot. After some puzzling through, I ended up creating an arraylist of Instruction classes, each Instruction class composed of a destination rod and a current rod. I'm sure there are other ways of doing it, I simply chose to use that one. Also, yes, I forgot to mention in the description that it was 2^n - 1 moves, I was meaning to do that but forgot about it. Lastly, did that scenario you created like that always work? The way I check for completion is if all the instructions have been performed, though you could also do it by checking to see if the size of the destination stack is equal to the total number of rings.

Why is it that I only realize there's an existing project that basically does everything mine does and more AFTER I create and publish it? *sigh* Nice project, Duta. Just curious, but for your automatic solver, did you use the iterative algorithim or the recursive algorithim? I used and invented the recursive solution I used.

RUMMAKER, as for the first comment, the whole point of this game is not expecting what's going to happen next. And the heat seeking ones, they're not actually heat seeking, they just point towards you again when they accelerate. So, basically, after a certain point, it starts spawning 'accelerate' balls, which have a random time until the speed increases. As soon as it starts spawning these accelerate balls, there's a half-chance that they're going to be what I call 'double' balls. This means that when they accelerate, they turn towards you again, thus, they point towards you an launch twice, hence double. Anyways, I'm working on the balls colliding, and it seems it happens very often when three collide, and they keep bouncing off of each other.

Is the problem the ghosts not working? Just from looking at it, I'm guessing that you're having the ghosts do setRotation(Greenfoot.getRandomNumber(360)); This would cause them to turn in any random direction. In pacman, there are only four directions you move in, up, down, right, and left. For this I would reccomend something like this: setRotation(90 * (Greenfoot.getRandomNumber(4))); Also, they seem to be changing direction too often.