A puzzle game without a single Sokoban level

October 23, 2009 7:10 PM

Friday non-Flash Fun: Robozzle is a surprisingly deep puzzle game. If you don't want to install Silverlight, there's a Javascript version.

Mge almost posted it six months ago.

posted by you (29 comments total)

So...much....clicking. Once they came up with subroutines and color coding I quit. There's a reason I leave work at work.
posted by msbutah at 7:52 PM on October 23 [1 favorite has favorites]

Almost as exciting as Robizzle. Once I got to flipflop I realized I do not have enough time to obsess over this puzzle today.
posted by BrotherCaine at 8:15 PM on October 23

Neat, but I second the desire to leave work at work. On the other hand, this could be a great way to introduce programming concepts to curious non-programmers and kids.

When I was a kid (we're talking apple ||e days), I was fascinated with a similarly covertly education game that was all about programming robots to navigate perilous environments by using electronics logic gate symbols and wires. I'd forgotten all about that game until I started picking up embedded electronics as hobby -- and then realized, "oh yeah, THIS is what that game was about!"

I'm not sure the game fostered my interest in hobby electronics, but it certainly helped liberate the "geek within."
posted by treepour at 8:47 PM on October 23

DAMN YOU, YOU!!!!
posted by emeiji at 8:54 PM on October 23

...by which I mean "thanks for this most cracktastic of links."
posted by emeiji at 8:57 PM on October 23

Yeah. By which I mean: I loved that crazy game on the Apple ][, also.
posted by ~ at 9:14 PM on October 23

Back in the mid-'90s, my sister and I used to play "The Island of Dr. Brain" on our old PC. For those who haven't played it, it's a cute little semi-educational puzzle game made by Sierra. One of the puzzles was much like this, in that you had to program a robot to retrieve various treasures around a maze-like laboratory. Nominally, what the game wanted you to do was to program the full round-trip of the robot: to tell it how to get to the proper location, to pick up the treasure, to return to your location, and to drop the object at your feet. So, for example, you might tell the robot to "go forward, go forward, turn left, pick up object, turn left, go forward, go forward, drop object."

One of the features of this program was that if your program contained a command that caused the robot to bump into a wall, it would immediately reverse all the steps it had made up to that point. Normally, this would mean that the robot would return to you; if it had executed the "pick up" command in its routine, it would execute the "put down" routine when it was retracing its steps. The obvious intent of this was to make sure that you got the whole program right, and to "reset" the lab (putting the treasure back in its original location) if you made a false step.

However, one of us (I can't remember if it was my sister or me) figured out how to exploit this: you could tell the robot something along the lines of "pick up the (non-existent) treasure at my feet; go to the treasure's real location; drop the (still non-existent) object you're carrying; run into a wall." Once the robot ran into the wall, it would immediately run all of its prior steps backwards — which meant it would return to the location of the treasure, pick up the (real) treasure, return to you, and drop the (real) treasure at your feet. This saved a lot of time, since you only had to program a one-way trip (plus a few extra commands at the start and finish) rather than a full round trip.

I'm not sure whether this would propertly have been termed a kludge or an exploit, but it was my first exposure to the idea that you could get around the "rules" that computer programmers had imposed upon you if you were cleverer than they were.
posted by Johnny Assay at 9:20 PM on October 23 [14 favorites has favorites]

This works very badly on the Mac (and I installed Silverlight to do it).

I got to the second wall - and it now won't let me actually try the solution I've proposed, the stupid hint dialog is still there, the "Step" button is active but does nothing.

Not impressed.
posted by lupus_yonderboy at 10:49 PM on October 23

I am on Mac, too and it won't allow me to use the F2 command. No workee.
posted by bz at 10:54 PM on October 23

Yes, that is a lot like work.
posted by Artw at 11:11 PM on October 23

It's like the board game Robo Rally. I didn't like that game, either.
posted by meadowlark lime at 11:45 PM on October 23

This is fun!
posted by brundlefly at 11:45 PM on October 23

I'm on a Mac, works fine for me.
posted by Richard Daly at 12:24 AM on October 24

Anyone else bugged by it being two clicks rather than true drag and drop?
posted by Artw at 12:27 AM on October 24

Yes.
posted by Richard Daly at 1:33 AM on October 24

Treepour, is the game you are thinking of Chipwits?
posted by HeroZero at 5:02 AM on October 24

This reminds me of my favorite Myst-type game from back in the day, Obsidian -- specifically, the scene where you had to program a big iron spider-robot to walk around the inside of a cathedral, some of the areas of which would reprogram the robot. I spent ages getting that right, and it was so, so satisfying when I finally did (not least because the music was awesome).

Someone put a playthru of the whole game on YouTube -- the action starts about 5:20 into that clip.

And get outta here, meadowlark lime; Robo Rally is awesome. Well, so long as you've got enough players to reasonably crowd the board anyway.
posted by rifflesby at 5:15 AM on October 24

I had to opt for the javascript version and all I get is a big empty gray box with some controls at the bottom. What's supposed to be in the empty area?
posted by Thorzdad at 5:46 AM on October 24

Reminds me a little of the Flash game light-Bot (which I'm sure I saw on the blue but my search fails me) but this is much better (although most games can be improved with a cute hopping robot.) I've only played the JS version but I like it so far: clean unobtrusive UI and fun puzzles.

What's supposed to be in the empty area?

In each of the white boxes you can select a move or instruction and an optional color modifier. The color modifier allows you to limit an instruction to a certain square color.
posted by lmm at 6:57 AM on October 24

In each of the white boxes you can select a move or instruction and an optional color modifier. The color modifier allows you to limit an instruction to a certain square color.

Maybe I'm not getting it...but this is what I have to work with.
posted by Thorzdad at 7:09 AM on October 24

Hmm. You should be seeing something like this. Do you have another web browser to try with?
posted by lmm at 7:26 AM on October 24

I've tried it with both Firefox and Safari. Sure, they're both older versions, but this is the javascript version of the game.
posted by Thorzdad at 7:43 AM on October 24

In the javascript version you click on an empty square in the command queue, and then click the command you want in the mini popup.
posted by BrotherCaine at 3:00 PM on October 24

Can someone be a more helpful describing the counting or using stacks than the folks in the forum? http://robozzle.com/wiki/Counting.ashx has a suggestion, but it's not helping me implement anything, or understand it. I don't think the puzzle I'm stuck on could use it but I'm not sure.
posted by TuxHeDoh at 3:01 PM on October 24

THD, let's say you want to get from A to B:

 ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
| r | r | r | r | r | g | g | g | g | g | g |    ---->
| A |   | G | E | C |   |   |   |   |   |   |    facing this way
|___|___|___|___|___|___|___|___|___|___|___|
            |   |   | D | F | H |   | B |
             ... ... ... ...         ... 

You might say "move forward while there are red squares, then skip that number of green squares, then turn right". You don't actually have counters, though, so you need to be sneaky.

For the base case (getting from C to D), it's easy: you go forward one square, notice that you're on green, and go right:

F1 ("get from C to D") = forward, then if green(go right)

Now, if you already have a program for solving a smaller version of the problem, you can build one to solve a bigger verson:

F2 ("get from E to F") = forward, if red(do F1), then if green(go right)
F3 ("get from G to H") = forward, if red(do F2), then if green(go right)

Now you can collapse the pattern:

F1 = forward, if red(do F1), then if green(go right)

Don't think of F1 as 'going to F1', think of it as inserting a copy of F1 at the current point in the program.
posted by you at 5:52 PM on October 24

Crap, that was completely wrong. Let's try that again:

 ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
| r | r | r | r | r | g | g | g | g | g | g |    ---->
| A |   |   | G | E | C |   |   |   |   |   |    facing this way
|___|___|___|___|___|___|___|___|___|___|___|
            |   |   | D | F | H |   | B |
             ... ... ... ...         ...

F1 (C to D) = do nothing
F2 (E to F) = forward, then F1, then forward
F3 (G to H) = forward, then F2, then forward
F4 = forward, then F3, then forward
...

Now these can be compressed as
F1 = nothing
F2 = go forward, then (if green do F1; if red do F2), then forward

or even
F = go forward, if red do F, go forward
posted by you at 6:06 PM on October 24

TuxHeDoh: thanks for that link -- until I saw that I couldn't see how one of the puzzles ("Limit your stack!") was even possible. I'll explain what I realised from that cryptic comment in the wiki.

When a program's running, what does it do when it gets to a function command ("F1", "F2", etc.)? Well, it keeps a note of the function it's currently been working on and how far through that function it's got, and then switches execution to the function named in the command. When that named function is finished, execution switches back to where we left off in the original function we were in. (The puzzle "Smart reuse" illustrates this nicely.) In particular, these records are kept on a stack. If we nest function calls -- e.g., F1 calls F2 which calls F3 etc. -- then when F3 finishes we return to where we left off in F2, and when F2 finishes then we return to where we left off in F1. That is, subsequent function calls don't cause us to forget our progress through previously suspended (but uncompleted) functions.

The crucial thing to realise is that the above reasoning applies even when two functions are calling each other, or when one function is calling itself. So if F1 calls itself, we record our progress so far through F1 onto the stack, and then start a new instance of F1. If this latter instance of F1 is able to finish, then we look at the stack, remember where we got to through the previous instance of F1, and resume from there. This means that we can make any number of self-calls and the stack will remember exactly how many calls we've made.

The remaining problem is: how do we get one instance of F1 to make a self call, but another instance not to (so that this latter instance can finish, and we can work our way back through the stack of unfinished business)?

I hope this helps enough for you to solve your problem, and not so much that it solves your problem for you!
posted by logopetria at 6:46 PM on October 24

You, thanks :D - that's helpful, but I'm not seeing the counting part. Seems like you've explained recursion.

Logopetria.... that's much more informative... but I'm not seeing how it really works. I'll keep trying to figure it out.
posted by TuxHeDoh at 7:44 PM on October 24

But re-reading, the two of you together, I think have made it clear.
posted by TuxHeDoh at 7:47 PM on October 24